EventBridge : architectures event-driven

À la fin de ce tutoriel, vous saurez expliquer pourquoi un bus d’événements, dessiner une architecture event-driven avec Amazon EventBridge, écrire des event patterns, brancher des targets (Lambda, SQS, SNS, Step Functions, CloudWatch Logs), et dérouler un lab safe en ca-central-1 (bus custom + PutEvents + règle + cleanup) sans exploser la facture.

Niveau : Intermédiaire · Temps estimé : 50–70 min · Versions cibles : Amazon EventBridge · AWS CLI v2 · Lambda / SQS / SNS · Dernière vérification : 2026-09-11 · Region : ca-central-1

Slug : wow-eventbridge-patterns · Série : WOW · Mot-clé SEO : Amazon EventBridge · Publish : HOLD

→ Aussi : SNS & SQS · Lambda + API Gateway · CloudWatch alarmes · Démarrer avec AWS

Prérequis

Coût estimé : quasi 0 € pour ce lab (bus custom, règles, PutEvents, Logs). Les targets Lambda/SQS/SNS restent dans le free tier si vous restez sur le volume du tutoriel. Cleanup obligatoire en fin de lab.

export AWS_PROFILE=lab
export AWS_DEFAULT_REGION=ca-central-1
aws sts get-caller-identity

Ce que nous allons construire

Amazon EventBridge event-driven (WOW) — ca-central-1
  ├── Pourquoi un bus (découplage, fan-out, audit)
  ├── Bus default vs custom + event buses partenaires
  ├── Event pattern JSON (source, detail-type, detail)
  ├── Rules → targets (Lambda, SQS, SNS, SFN, Logs)
  ├── Lab : bus custom + PutEvents + règle Logs
  ├── Archive / replay, DLQ, retries
  └── Quiz + FAQ + maillage SNS/SQS/Lambda

(Schéma — alt : « Producers PutEvents vers un bus custom EventBridge ; règles filtrent et routent vers Lambda, SQS, SNS et CloudWatch Logs en ca-central-1 ».)

Étape 1 — Pourquoi EventBridge en 2026 ?

Les architectures event-driven découplent producteurs et consommateurs. Au lieu d’appeler l’API du voisin en synchrone (timeouts, versions, blast radius), vous émettez un fait : OrderCreated, InstanceTerminated, DeployFailed. Les intéressés s’abonnent.

Amazon EventBridge est le bus managé AWS pour ça :

Besoin Pattern EventBridge
Fan-out 1→N Une règle, plusieurs targets
Filtrage riche Event patterns (JSON)
SaaS → AWS Partner event buses
AWS → vous Default bus (EC2, CloudTrail, etc.)
Replay / audit Archives + replay
Orchestration Target Step Functions

EventBridge route et filtre ; SQS absorbe le backlog ; SNS diffuse. Voir SNS & SQS — trio DEH.

Étape 2 — Vocabulaire utile

  1. Event bus — canal nommé. Default (événements AWS + custom si vous le choisissez), custom (votre domaine), partner (Stripe, Auth0, Datadog…).
  2. Event — envelope JSON : Source, DetailType, Detail, Time, Resources…
  3. Rule — filtre (event pattern ou schedule cron/rate) + targets.
  4. Target — Lambda, SQS, SNS, Step Functions, Kinesis, API Destination, CloudWatch Logs, Bus cross-account…
  5. Archive / Replay — rétention des events pour rejouer après un bug.
  6. Dead-letter queue (DLQ) — SQS pour les invocations target en échec répété.

Structure minimale d’un event custom :

{
  "Source": "deh.orders",
  "DetailType": "OrderCreated",
  "Detail": {
    "orderId": "ord-42",
    "amount": 19.9,
    "currency": "CAD",
    "env": "lab"
  }
}

Convention DEH : Source en reverse-DNS métier (deh.orders, deh.billing), DetailType en PastTense métier, Detail versionné (champ schemaVersion recommandé dès le jour 2).

Étape 3 — Event patterns : le cœur du filtrage

Une règle match si tous les champs du pattern matchent. Exemple : seulement les commandes CAD en lab :

{
  "source": ["deh.orders"],
  "detail-type": ["OrderCreated"],
  "detail": {
    "currency": ["CAD"],
    "env": ["lab"]
  }
}

Patterns utiles :

Intention Astuce pattern
Tout d’une source "source": ["deh.orders"]
Plusieurs types "detail-type": ["OrderCreated", "OrderCancelled"]
Présence d’un champ "detail": { "orderId": [{"exists": true}] }
Préfixe "detail": { "orderId": [{"prefix": "ord-"}] }
Anything-but "detail": { "env": [{"anything-but": "prod"}] }

Piège : les clés du pattern sont en minuscules côté EventBridge (source, detail-type) même si l’API PutEvents utilise Source / DetailType. Testez toujours avec un event réel avant la prod.

Schedule (cron) reste une règle EventBridge : cron(0 9 ? * MON-FRI *) en UTC — documentez le fuseau (Montréal = UTC−4/−5). Pour DEH lab, préférez rate(1 hour) sur un bus jetable.

Étape 4 — Architecture DEH de référence

[Producers]
  app / Lambda / EventBridge Scheduler
        │ PutEvents
        ▼
  custom bus: deh-domain-bus (ca-central-1)
        │
        ├── Rule OrderCreated → Lambda enrich + SQS worker
        ├── Rule OrderCreated → SNS ops (email/Slack)
        ├── Rule *.Failed → CloudWatch Logs + alarme
        └── Rule audit-all → Archive 7j + optional Firehose

Principes DEH :

  • Un bus custom par domaine (orders, billing) plutôt qu’un monolithe « god bus » dès que plusieurs équipes publient.
  • Default bus pour les events AWS (EC2 state, CloudTrail via CloudWatch Events legacy → EventBridge).
  • Cross-account : bus dans le compte Shared/Platform, rules qui forwardent vers comptes Workloads — voir Multi-account Org.
  • Idempotence côté consumers : EventBridge garantit at-least-once vers les targets ; dédoublonnez sur orderId / id.

Étape 5 — Lab safe : bus custom + PutEvents + Logs (ca-central-1)

Objectif : créer un bus, une règle filtrante, un target CloudWatch Logs (pas de Lambda à packager), injecter un event, vérifier le log, tout détruire.

export AWS_PROFILE=lab
export AWS_DEFAULT_REGION=ca-central-1
BUS=deh-lab-eventbus
LOG_GROUP=/aws/events/deh-lab-eventbus
RULE=deh-lab-order-created

# 1) Bus custom
aws events create-event-bus --name "$BUS"

# 2) Log group + resource policy (EventBridge → Logs)
aws logs create-log-group --log-group-name "$LOG_GROUP" || true

ACCOUNT=$(aws sts get-caller-identity --query Account --output text)
aws logs put-resource-policy --policy-name EventBridgeToCWLogsDehLab --policy-document "{
  "Version":"2012-10-17",
  "Statement":[{
    "Sid":"EventBridgeToCWLogs",
    "Effect":"Allow",
    "Principal":{"Service":"events.amazonaws.com"},
    "Action":["logs:CreateLogStream","logs:PutLogEvents"],
    "Resource":"arn:aws:logs:ca-central-1:${ACCOUNT}:log-group:${LOG_GROUP}:*"
  }]
}"

# 3) Rule + pattern
aws events put-rule 
  --name "$RULE" 
  --event-bus-name "$BUS" 
  --event-pattern '{"source":["deh.orders"],"detail-type":["OrderCreated"]}' 
  --state ENABLED

# 4) Target Logs
aws events put-targets 
  --rule "$RULE" 
  --event-bus-name "$BUS" 
  --targets "Id"="1","Arn"="arn:aws:logs:ca-central-1:${ACCOUNT}:log-group:${LOG_GROUP}"

# 5) Injecter un event
aws events put-events --entries "[{
  "EventBusName": "$BUS",
  "Source": "deh.orders",
  "DetailType": "OrderCreated",
  "Detail": "{"orderId":"ord-42","amount":19.9,"currency":"CAD","env":"lab"}"
}]"

# 6) Vérifier (attendez quelques secondes)
aws logs filter-log-events --log-group-name "$LOG_GROUP" --limit 5

Si FailedEntryCount > 0 sur PutEvents, regardez ErrorCode / ErrorMessage (souvent JSON Detail mal échappé). Si la règle ne match pas, comparez source / detail-type exactement.

Cleanup (obligatoire)

aws events remove-targets --rule "$RULE" --event-bus-name "$BUS" --ids 1
aws events delete-rule --name "$RULE" --event-bus-name "$BUS"
aws events delete-event-bus --name "$BUS"
aws logs delete-log-group --log-group-name "$LOG_GROUP" || true

Étape 6 — Targets avancés, retries, DLQ, archive

Target Quand l’utiliser
Lambda Enrichissement, validation, side-effects courts
SQS Buffer + workers lents / burst
SNS Alertes multi-canal
Step Functions Runbooks / workflows (voir WOW Step Functions SRE)
API Destination Webhook HTTP hors AWS (Slack, PagerDuty)
Logs Debug / audit léger

Retries EventBridge vers une target : backoff automatique puis DLQ si configurée. Sans DLQ, l’event est perdu après épuisement — en prod DEH, DLQ SQS obligatoire sur les targets critiques.

Archive :

aws events create-archive 
  --archive-name deh-orders-7d 
  --event-source-arn "arn:aws:events:ca-central-1:${ACCOUNT}:event-bus/${BUS}" 
  --retention-days 7 
  --event-pattern '{"source":["deh.orders"]}'

Replay = filet après bug consumer. Pas un CDC Kafka : pour un event store durable, Kinesis / MSK / DynamoDB streams selon le cas.

Erreurs fréquentes

Erreur Impact Correction
Pattern Source au lieu de source Règle ne match jamais Clés pattern en minuscules
Detail string non JSON PutEvents / consumers cassés Detail = JSON stringifié valide
Tout sur le default bus Bruit AWS + collisions Bus custom par domaine
Pas de DLQ Events critiques perdus SQS DLQ + alarme profondeur
Fan-out synchrone Lambda→Lambda Couplage + timeouts Bus + règles + SQS
Region us-east-1 par défaut Hors standard DEH Forcer ca-central-1
Oublier resource policy Logs Target Logs silencieux put-resource-policy comme au lab

Quiz (5 questions)

1. EventBridge sert surtout à :
– A. Remplacer RDS
– B. Router / filtrer des événements vers des targets
– C. Remplacer IAM

2. Un event pattern match si :
– A. Au moins un champ correspond
– B. Tous les champs du pattern correspondent
– C. Le bus s’appelle default

3. Pour un backlog worker lent derrière un bus, le duo typique est :
– A. EventBridge → RDS only
– B. EventBridge → SQS → workers
– C. EventBridge → S3 website

4. Region lab DEH imposée :
– A. us-east-1
– B. ca-central-1
– C. eu-west-3

5. Sans DLQ sur une target critique :
– A. Rien ne change
– B. Risque de perte après retries épuisés
– C. EventBridge bascule automatiquement vers SNS

Réponses : 1‑B · 2‑B · 3‑B · 4‑B · 5‑B

FAQ

EventBridge vs SNS vs SQS ?

EventBridge = bus + filtrage riche + intégrations AWS/SaaS. SNS = pub/sub simple / fan-out notifications. SQS = file de travail durable. DEH : EventBridge route, SQS absorbe, SNS alerte. Voir SNS & SQS.

Default bus ou custom ?

Default pour events AWS et quelques customs simples. Custom dès qu’un domaine métier publie (isolation IAM, archives, quotas, clarté d’équipe).

EventBridge remplace-t-il Kafka ?

Non. Kafka / MSK = log haute volumétrie et replay massif. EventBridge = routing managé, patterns, targets serverless.

Pourquoi ca-central-1 ?

Standard lab DevOps Elastic Hayway : cohérence IAM, FinOps et tutos AWS entre guides.

Comment tester un pattern sans déployer Lambda ?

Target CloudWatch Logs (ce lab) ou SQS + receive-message. Validez le match avant d’ajouter de la logique métier.

Cross-account possible ?

Oui : permissions sur le bus, règles qui forwardent vers un autre bus / compte. Utile avec une landing zone multi-compte — Multi-account Org.

Combien coûte PutEvents ?

Facturation au million d’events + targets. Le lab est négligeable ; surveillez les rate() oubliés et le fan-out × N targets.

Pour aller plus loin

Maillage série WOW
← Précédent Step Functions pour runbooks SRE
→ Suivant OpenTelemetry : traces metrics logs
Aussi SNS & SQS · Lambda + API Gateway · Multi-account Org

Meta publication (SEO)

  • Title SEO : Amazon EventBridge : architectures event-driven (guide FR)
  • Meta description : Amazon EventBridge event-driven : bus custom, event patterns, règles, targets Lambda/SQS/SNS, archive/replay. Lab safe ca-central-1, FAQ, quiz DEH.
  • Focus keyword : Amazon EventBridge
  • Secondary : event-driven architecture, event bus, event pattern, PutEvents, EventBridge rules
  • Image : assets/web/devopelastichayway/cover-wow-eventbridge-patterns-1200x630.webp (à générer)
  • Catégorie : WOW / AWS · Niveau : Intermédiaire
  • URL cible : https://devopelastichayway.com/tutoriels/wow-eventbridge-patterns/
  • Post live : N/A (nouveau) · slug wow-eventbridge-patterns · Publish : HOLD (draft only — feu vert Maître requis)

← Catalogue Tutoriels

Pour aller plus loin — hubs live

Retour parcours Catalogue Tutoriels — hub de la série et leçons sœurs.

© 2023 devopelastichayway.com All rights reserved.