Amazon EventBridge: il router degli eventi

Amazon EventBridge riceve gli eventi emessi dai servizi AWS sul default event bus e li instrada verso dei target in base a una rule. Ogni rule contiene un event pattern che filtra gli eventi per campi come source e detail-type: solo gli eventi che corrispondono al pattern innescano il target. Esistono anche le scheduled rule (cron/rate) per azioni ricorrenti, ma la remediation reattiva si basa quasi sempre sul pattern matching in near-real-time.

Un caso tipico d’esame sono gli AWS Health event. Il servizio AWS Health pubblica su EventBridge eventi di manutenzione programmata, degrado di un servizio o problemi che riguardano risorse specifiche del tuo account. Una rule con event pattern su source: aws.health permette di reagire automaticamente — notificare un team o spostare un workload — senza fare polling manuale delle dashboard.

I target più frequenti sono AWS Systems Manager Automation, AWS Lambda e Amazon SNS. La rule richiede un IAM role (o una resource policy sul target) con i permessi per invocarlo.

Da evento a remediation: Automation runbook e Lambda

Un Automation runbook (documento SSM di tipo Automation) è la scelta preferita quando la remediation corrisponde a un’operazione infrastrutturale standard: riavviare o fermare un’istanza EC2, applicare un tag, isolare un security group, creare uno snapshot. AWS fornisce runbook gestiti e puoi crearne di custom con step sequenziali, gestione degli errori e approvazioni manuali. È idempotente, tracciabile e non richiede codice da mantenere.

AWS Lambda entra in gioco quando la logica è custom: orchestrazione condizionale, chiamate API a servizi terzi o elaborazione dati che un runbook non copre. Regola pratica: se un runbook fa il lavoro, preferiscilo a Lambda; passa a Lambda solo quando serve logica applicativa.

AWS Config con auto-remediation

AWS Config valuta la conformità delle risorse rispetto a delle Config rule (gestite o custom). Alla rule puoi associare una remediation action, che è a sua volta un SSM Automation document: quando una risorsa risulta NON_COMPLIANT, Config può eseguire automaticamente il runbook per riportarla allo stato desiderato (abilitare l’encryption, chiudere una porta aperta, rimuovere l’accesso pubblico a un bucket). La remediation può essere automatica o manuale, con retry in caso di fallimento.

Attenzione al confine: Config reagisce a cambi di configurazione valutando uno stato desiderato; EventBridge reagisce a eventi. Per una compliance basata su stato la risposta è Config + auto-remediation, non una rule EventBridge.

CloudWatch alarm con azioni

Un CloudWatch alarm passa fra gli stati OK, ALARM e INSUFFICIENT_DATA e a ogni transizione può eseguire delle azioni. Le alarm action più rilevanti per operations:

  • EC2 recover: si usa su un alarm basato sulla metrica StatusCheckFailed_System. Il recover riavvia l’istanza su hardware sano mantenendo instance ID, private IP ed eventuale elastic IP — è il rimedio a un guasto dell’host sottostante, non del sistema operativo.
  • EC2 reboot/stop/terminate: azioni per StatusCheckFailed_Instance o per policy di risparmio.
  • Notifica Amazon SNS: l’alarm pubblica su un topic SNS che fa fan-out verso email, SMS, endpoint HTTPS o una Lambda che avvia una remediation più complessa.

La gestione dei dati mancanti è un dettaglio d’esame: trattare i missing data come notBreaching evita falsi ALARM quando la metrica non arriva (istanza spenta di proposito), mentre breaching o missing cambiano il comportamento.

Trappole tipiche d’esame

  • Guasto dell’host fisico sotto una EC2 → EC2 recover su StatusCheckFailed_System: il recover è per i system status check (infrastruttura AWS). Se il problema è nel SO (StatusCheckFailed_Instance) serve reboot, non recover.
  • Rimediare automaticamente a risorse non conformi → Config rule + remediation action: la remediation di compliance passa da un SSM Automation document collegato alla Config rule, non da una alarm action di CloudWatch.
  • Reagire a manutenzioni o problemi annunciati da AWS → EventBridge rule su source aws.health: gli AWS Health event arrivano su EventBridge; basta una rule con event pattern, niente polling.
  • Alarm che scatta quando l’istanza è spenta di proposito → treat missing data as notBreaching: evita falsi positivi; impostare breaching darebbe ALARM su ogni gap di metrica.
  • Remediation semplice e standard (riavvio, tag, snapshot) → SSM Automation runbook, non Lambda: scegli Lambda solo quando serve logica custom o integrazioni che un runbook non copre.
  • Notificare un team a un cambio di stato → alarm action verso un topic SNS: SNS fa fan-out multi-canale e può innescare una Lambda per una remediation più articolata.