Amazon EventBridge: l’innesco degli eventi

Amazon EventBridge è il bus di eventi serverless al centro di ogni architettura di event-driven response. Un evento arriva su un event bus (il default bus per gli eventi dei servizi AWS, i custom bus per le applicazioni, i partner bus per i SaaS integrati) e una rule lo confronta con un event pattern: la corrispondenza avviene su campi come source, detail-type e sui valori dentro detail. Quando il pattern matcha, EventBridge instrada l’evento verso uno o più target: AWS Lambda, un runbook di AWS Systems Manager Automation, una state machine di AWS Step Functions, un topic Amazon SNS o una coda Amazon SQS.

Oltre alle rule basate su pattern, EventBridge supporta scheduling ricorrente con espressioni cron o rate per innescare azioni pianificate (audit, backup, cleanup); per lo scheduling avanzato conviene EventBridge Scheduler, servizio dedicato con time zone, one-time schedule e flexible time windows. Le sorgenti tipiche di un event pattern in ambito DevOps sono AWS Config (drift di conformità), Amazon GuardDuty (finding di sicurezza), gli Amazon CloudWatch Alarms in stato ALARM e i cambi di stato delle risorse (per esempio un’istanza EC2 che entra in stopped).

Remediation automatica: SSM Automation o Lambda

La auto-remediation si costruisce scegliendo l’esecutore giusto. AWS Systems Manager Automation esegue runbook (Automation document): esistono runbook gestiti AWS-* per azioni operative comuni (riavvio istanze, remediation di security group, gestione di snapshot) e runbook custom con step, rate control, step di approvazione manuale e un IAM assume role che delimita i permessi. AWS Config integra la remediation automatica proprio invocando un runbook SSM Automation quando una regola diventa NON_COMPLIANT.

AWS Lambda si usa quando la logica è custom: chiamate a più API, trasformazioni, integrazioni esterne. La regola pratica: se l’azione è un’operazione infrastrutturale prevedibile, con un runbook già pronto o con approvazioni/rate control nativi, si preferisce SSM Automation; se serve codice arbitrario o bassa latenza su una singola azione, si sceglie Lambda. Entrambi possono essere target diretti di una rule EventBridge.

Orchestrazione con Step Functions

Quando la remediation è multi-step, con retry differenziati, gestione degli errori, attese o approvazione umana, AWS Step Functions è la scelta corretta. Una state machine coordina Lambda, SSM Automation e altri servizi con error handling (Catch/Retry) e pattern di human approval tramite task token (callback). Rispetto a una singola Lambda, Step Functions rende visibile lo stato di esecuzione, gestisce workflow di lunga durata e toglie la logica di orchestrazione annidata dal codice applicativo. EventBridge può avviare direttamente la state machine come target.

Fan-out e disaccoppiamento con SNS e SQS

Per notificare più consumatori dello stesso evento si usa il fan-out: Amazon SNS effettua il push del messaggio a tutte le subscription (email, HTTP, Lambda, SQS) e il pattern canonico SNS→più code SQS permette a ogni sistema a valle di consumare in modo indipendente e resiliente. Amazon SQS aggiunge buffering e disaccoppiamento: assorbe i picchi, protegge i downstream dal throttling e, con una dead-letter queue, isola i messaggi non elaborabili. EventBridge stesso supporta una DLQ per gli eventi non consegnabili al target e retry policy configurabili.

Nell’incident response, EventBridge inoltra il finding a SNS per l’allerta on-call; per una gestione strutturata degli incidenti (escalation, runbook operativi, postmortem) si integra AWS Systems Manager Incident Manager.

Trappole tipiche d’esame

  • Metrica sopra soglia vs evento di stato → strumento giusto: un CloudWatch Alarm nasce da una metrica; un API/state change o un finding di Config/GuardDuty è un evento EventBridge. Non confondere l’alarm su metrica con l’event pattern.
  • Remediation di conformità già pronta → AWS Config + SSM Automation: se lo scenario parla di regole NON_COMPLIANT da rimediare automaticamente, la risposta è la remediation di Config via runbook Automation, non una Lambda custom scritta da zero.
  • Workflow multi-step con approvazione umana → Step Functions: una singola Lambda con logica annidata e sleep è la trappola; retry, catch e human approval via task token indicano Step Functions.
  • Consegnare lo stesso evento a più sistemi → SNS fan-out (spesso SNS→SQS): una sola coda SQS serve un solo gruppo di consumatori; per il fan-out serve SNS, tipicamente con più code SQS sottoscritte.
  • Eventi persi silenziosamente → DLQ e retry policy: se un target fallisce, senza dead-letter queue e retry policy su EventBridge (o sulla coda SQS) i messaggi si perdono; l’affidabilità richiede la DLQ.
  • Scheduling ricorrente → EventBridge (rule cron/rate o Scheduler): non serve un’istanza EC2 con cron di sistema; per i job pianificati usa una scheduled rule o EventBridge Scheduler.