AWS Health, CloudTrail und Service Events
Prüfungsbezug: DOP-C02 Domain 5 — event processing, configuration response, and troubleshooting.
Lernziel
Service-Health-Events, API Activity, Resource Events, Organizations Aggregation und Response Classification mit präzisen Event Contracts, Least-Privilege Execution, begrenzten Retries, verlässlichen Nachweisen und sicherer Recovery entwerfen, implementieren und troubleshooten.
Berufliches Szenario
Eine Production-Umgebung nutzt Service-Health-Events, API Activity, Resource Events, Organizations Aggregation und Response Classification. Bei einem Operational Event verliert der Workflow Kontext, wiederholt eine unsafe Action oder bietet keinen zuverlässigen Pfad von Detection zu Mitigation und verifizierter Recovery.
Kernkonzepte
- Die Lektion fokussiert Service-Health-Events, API Activity, Resource Events, Organizations Aggregation und Response Classification.
- Ein Event beschreibt, was geschehen ist; ein Command fordert eine Aktion an.
- Event Consumer müssen idempotent sein, weil Retries und Duplicate Delivery vorkommen.
- Jede Automation benötigt Scope, Preconditions, Permissions, Rate Limits, Failure Handling und Evidence.
- Detection, Notification, Mitigation, Recovery und Prevention sind unterschiedliche Phasen.
- Die erste fehlerhafte Komponente oder der früheste unerwartete State liefert oft den besten Troubleshooting-Hinweis.
Architektur- und Response-Schrittfolge
- Trigger und Business Impact definieren.
- Representative Event, Alarm, Log oder Failure State erfassen.
- Source, Routing, Target, Execution Role und Ressourcen identifizieren.
- Event Contracts, Permissions, Quotas und Dependency Readiness validieren.
- Kleine kontrollierte Response oder Diagnostic Action ausführen.
- Resultierenden State prüfen und Evidence erhalten.
- Escalaten, rollbacken oder nächste Hypothese testen.
- Prevention dokumentieren und retesten.
Entscheidungshilfe
| Anforderung | Bevorzugte Richtung | Warum |
|---|---|---|
| Known Event mit Routing | EventBridge Rule mit präzisem Pattern | Native Event-Driven Response |
| Durable Decoupling | SQS Queue und idempotenter Consumer | Puffert und erhält Work |
| Multi-Step Response | Step Functions oder Systems Manager Automation | Explizite Retries, Branching und History |
| Resource-State-Verstoß | AWS Config plus sichere Remediation | Evaluates und korrigiert Non-Desired State |
| Unknown Failure | Hypothesis-Driven Investigation mit Logs, Metrics, Traces, Events und Health | Keine zufälligen Changes |
Fehlerbilder und Fehlersuche
- Rule matched zu breit und startet fremde Actions.
- Retry wiederholt destruktive nicht-idempotente Operation.
- Execution Role hat fehlende oder zu breite Permissions.
- Remediation Target ist stale, schon recovered oder genehmigte Exception.
- Responder ändern mehrere Variablen gleichzeitig und zerstören Evidence.
- Recovery stellt Service her, aber Risk wird nicht korrigiert oder retested.
Sicherheits- und Betriebskontrollen
- Detection-, Orchestration-, Remediation- und Audit-Rollen trennen.
- Reversible Containment/Mitigation vor destruktiven Actions bevorzugen.
- Event Buses, Runbooks, Pipelines, Incident Data und Evidence schützen.
- Keine Secrets, Credentials oder sensitive Payloads in Events/Notifications/Channels.
- Initiator, Approver, Executor und Verifier sensibler Actions erfassen.
Praxislabor
Ziel: Einen kleinen Incident- oder Event-Response-Workflow für dieses Thema bauen und validieren.
Aufgaben
- Trigger Event oder Failure Condition definieren.
- Source, Routing, Target, Permissions, Retries und Failure Destinations zeichnen.
- Minimalen Workflow oder detaillierte Config bauen.
- Controlled Failure einführen.
- Erste fehlerhafte Komponente diagnostizieren.
- Safe Remediation oder Rollback.
- Service State prüfen und Evidence erfassen.
- Prevention Action mit Owner und Retest Date.
Validierung
- Trigger matched nur gewünschte Bedingung.
- Duplicate Delivery erzeugt keine Duplicate Effects.
- Execution Role ist scoped.
- Failure ist sichtbar und recoverbar.
- Finaler Service-/Configuration-State ist verifiziert.
Kostenkontrolle: Synthetic Events und kleinen Test-Scope verwenden. Rules, Queues, State Machines, Runbooks, Testressourcen, Logs und Notifications entfernen.
Aufräumen
- Test Publisher und Scheduled Rules stoppen.
- Temporäre Targets, Queues, DLQs, Functions, State Machines, Runbooks und Alarms löschen.
- Test-Configuration-Changes zurücksetzen und finalen State bestätigen.
Prüfungsfallen
- Event als garantierte Exactly-Once Delivery behandeln.
- Auf jedes Event ohne Severity/Impact pagen.
- Automatisch remediaten ohne Scope/Current-State-Validation.
- Infrastruktur manuell ändern ohne Evidence/IaC-Reconciliation.
- Nach Mitigation ohne RCA und Prevention stoppen.
Wichtigste Erkenntnisse
- Service-Health-Events, API Activity, Resource Events, Organizations Aggregation und Response Classification.
- Automated Response muss präzise, idempotent, begrenzt, observable und möglichst reversibel sein.
- Troubleshooting beginnt mit Evidence und Hypothesen, nicht mit zufälligen Configuration Changes.
Wiederholungsfragen
- Was sind Trigger und Business Impact?
- Welcher Service produziert oder erfasst das Event?
- Wie Duplicate Delivery behandeln?
- Welche Execution Role führt aus?
- Was ist Failure Destination?
- Wie Current Target State validieren?
- Was ist Rollback-/Escalation-Pfad?
- Welche Evidence belegt Recovery?
Antworten
- Präzise definiertes Event, Alarm, Health State oder Failure mit messbarem Impact.
- AWS Service, CloudTrail, AWS Health, EventBridge, Custom Producer oder Telemetry System.
- Idempotency Key, State Check, Conditional Write oder repeatable Runbook.
- Least-Privilege-Rolle für den Workflow Step.
- DLQ, Failed Execution, OpsItem, Alert oder Failed Record.
- Resource-/Service-State unmittelbar vor Action lesen.
- Reversible Action, Previous Version, Manual Approval oder Incident Escalation.
- Metrics, Logs, Traces, Event History, Execution Output, Resource State und User Validation.