Handbuch - DOP-C02 AWS Certified DevOps Engineer Professional

Automatisches Rollback für eine fehlgeschlagene ECS Fargate-Bereitstellung ohne benutzerdefinierte Skripte.

Aktivieren Sie den ECS Deployment Circuit Breaker mit Rollback für den ECS-Dienst.

Warum: Natives ECS-Feature, das automatisch ein Rollback durchführt, wenn neue Tasks nicht stabilisiert werden können. Geringster Betriebsaufwand im Vergleich zu benutzerdefiniertem CodeBuild-Polling oder komplexen CodeDeploy-Einrichtungen.

Referenz

In einer primären Region bereitstellen, mit automatisierten Tests validieren und dann parallel in andere Regionen bereitstellen.

Verwenden Sie eine einzelne CodePipeline mit sequentiellen Stages: (1) Bereitstellung Region A, (2) eine CodeBuild-Test-Stage, die die Validierung durchführt, (3) eine parallele Bereitstellungs-Stage für die Regionen B & C.

Warum: CodeBuild fungiert als automatisiertes, programmatisches Gate. Eine einzelne Pipeline ist einfacher als die Orchestrierung mehrerer Pipelines mit Step Functions.

Ein lang laufendes Validierungsskript in einem CodeDeploy-Lifecycle-Hook führt zu einem vorzeitigen Bereitstellungserfolg.

Erhöhen Sie die `timeout`-Eigenschaft für das spezifische Lifecycle-Hook-Skript in der `AppSpec.yml`-Datei.

Warum: Das Timeout wird pro Hook in der AppSpec-Datei konfiguriert, nicht auf Ebene der Bereitstellungsgruppe. Dies stellt sicher, dass das Validierungsskript genügend Zeit zur Ausführung hat.

Beschleunigen Sie langsame CodeBuild Docker-Image-Builds, die durch das erneute Herunterladen von Abhängigkeiten und Image-Layern bei jedem Lauf verursacht werden.

Aktivieren Sie in der CodeBuild-Projektkonfiguration `LOCAL_DOCKER_LAYER_CACHE` und konfigurieren Sie einen S3-Cache für Abhängigkeitsverzeichnisse (z.B. `.m2`, `node_modules`).

Warum: Behebt beide Ursachen der Langsamkeit direkt. Docker-Layer-Caching verwendet unveränderte Image-Layer wieder; S3-Caching verwendet heruntergeladene Anwendungsabhängigkeiten wieder.

Implementieren Sie eine Canary-Bereitstellung für eine Lambda-Funktion mit automatisiertem, metrikgesteuertem Rollback.

Verwenden Sie AWS SAM mit `DeploymentPreference` (z.B. Typ `Canary10Percent5Minutes`). Fügen Sie einen CloudWatch-Alarm für die `Errors`-Metrik als Rollback-Trigger hinzu.

Warum: SAM integriert sich nativ mit CodeDeploy für Lambda und automatisiert das Verschieben von Alias-Verkehr, Monitoring und Rollback ohne benutzerdefinierte Skripte.

Referenz

Konfigurieren Sie IAM für eine CodePipeline in Konto A, um Ressourcen in Konto B bereitzustellen.

Die Pipeline-Rolle (Konto A) übernimmt eine Aktionsrolle (Konto B). Die Aktionsrolle in B vertraut der Pipeline-Rolle und verfügt über Bereitstellungsberechtigungen. Der S3-Artefakt-Bucket und der KMS-Schlüssel in A müssen Ressourcenrichtlinien haben, die der Aktionsrolle in B Zugriff gewähren.

Warum: Dies ist das standardmäßige, sichere kontoübergreifende Zugriffsmuster: Rollenübernahme für Aktionen, ressourcenbasierte Richtlinien für den Datenzugriff.

Implementieren Sie einen GitOps-Workflow für EKS, bei dem der Cluster-Zustand automatisch und kontinuierlich mit einem Git-Repository abgeglichen wird.

Stellen Sie einen GitOps-Controller (z.B. Flux, ArgoCD) im EKS-Cluster bereit. Konfigurieren Sie ihn so, dass er das Git-Repository überwacht und Änderungen anwendet/abgleicht.

Warum: Dies ist das Standard-"Pull-basierte" GitOps-Muster. Der In-Cluster-Controller übernimmt die kontinuierliche Abstimmung und Drift-Erkennung, was das Kernprinzip von GitOps ist.

Erlauben Sie einem CodeBuild-Projekt in einem zentralen Tooling-Konto, Kubernetes-Manifeste in EKS-Clustern in separaten Workload-Konten bereitzustellen.

Erstellen Sie in jedem Workload-Konto eine kontoübergreifende IAM-Rolle, der die CodeBuild-Rolle vertraut. Ordnen Sie diese neue Rolle einer Kubernetes-RBAC-Gruppe in der `aws-auth`-ConfigMap des EKS-Clusters zu. Das CodeBuild-Skript übernimmt die Rolle, bevor `kubectl` ausgeführt wird.

Warum: Dies ist das standardmäßige, sichere Muster für den kontoübergreifenden EKS-Zugriff. Es folgt dem Prinzip der geringsten Rechte, indem eine dedizierte, vertrauenswürdige Rolle für diesen Zweck erstellt wird.

Führen Sie eine komplexe RDS PostgreSQL- oder MySQL-Schema-Migration mit null oder nahezu null Ausfallzeiten durch.

Verwenden Sie das Amazon RDS Blue/Green Deployments Feature. Erstellen Sie eine synchronisierte Staging-Umgebung (grün), wenden Sie Schemaänderungen darauf an und wechseln Sie dann, um sie in die Produktion zu befördern.

Warum: Dies ist der speziell entwickelte, verwaltete Dienst für sichere RDS-Updates ohne Ausfallzeiten. Er übernimmt das Klonen, die Synchronisation und einen schnellen (< 1 Min.) Switchover mit integrierten Schutzmaßnahmen.

Stellen Sie eine neue Version einer Single-Page Application (SPA) auf S3/CloudFront bereit und stellen Sie sicher, dass Benutzer die neue Version sofort mit minimalen Cache-Invalidierungskosten erhalten.

Verwenden Sie inhaltsbasiertes Hashing für Asset-Dateinamen (z.B. `app.a1b2c3d4.js`). Nach der Bereitstellung neuer Assets invalidieren Sie nur die Datei `index.html` in der CloudFront-Distribution.

Warum: Gehashte Dateinamen sind eindeutig, sodass CloudFront sie als neue Objekte behandelt und sie vom Ursprung abruft, wodurch der Cache umgangen wird. Nur die einzelne Einstiegspunktdatei (`index.html`) muss invalidiert werden, was erheblich günstiger ist als eine Wildcard (`/*`) Invalidierung.

Implementieren Sie eine CI/CD-Pipeline für eine AWS CDK-Anwendung, die sich automatisch aktualisiert, wenn sich die eigene Definition der Pipeline ändert.

Verwenden Sie das CDK Pipelines-Konstrukt (`pipelines.CodePipeline`). Dieses Konstrukt erstellt standardmäßig eine Pipeline, die eine `SelfMutate`-Stage enthält.

Warum: CDK Pipelines ist ein speziell für dieses Muster entwickeltes High-Level-Konstrukt. Die `SelfMutate`-Stage stellt sicher, dass die Pipeline immer die neueste Definition aus dem Code widerspiegelt, bevor Anwendungsänderungen bereitgestellt werden.

Stellen Sie eine neue Anwendungsversion bereit, die eine abwärtskompatible Datenbankschemaänderung (z.B. das Hinzufügen neuer Spalten) erfordert, und zwar ohne Ausfallzeiten.

Implementieren Sie ein Expand-and-Contract-Muster (oder parallele Änderung). Stellen Sie zuerst die additiven, abwärtskompatiblen Datenbankschemaänderungen bereit. Stellen Sie zweitens die neue Anwendungsversion bereit, die das neue Schema verwendet. Sowohl alte als auch neue Anwendungsversionen können mit der aktualisierten Datenbank koexistieren.

Warum: Dieses Muster entkoppelt die Datenbank- und Anwendungsbereitstellungen und stellt sicher, dass der Datenbankstatus immer mit sowohl alten als auch neuen Anwendungsversionen kompatibel ist, wodurch Zero-Downtime-Rollouts ermöglicht werden.

Führen Sie eine neue Funktion schrittweise für bestimmte Benutzersegmente ein und messen Sie die Auswirkungen auf Geschäftsmetriken (z.B. Konversionsrate) mittels A/B-Tests.

Verwenden Sie Amazon CloudWatch Evidently. Erstellen Sie ein Feature mit mehreren Variationen, einen Launch zur Steuerung des Rollout-Prozentsatzes und ein Experiment zur Messung der statistischen Auswirkungen auf definierte Metriken.

Warum: Evidently ist ein speziell entwickelter Dienst für Feature-Flagging und A/B-Experimente, der nicht nur den Rollout-Mechanismus, sondern auch die statistische Analyse-Engine zur Messung der Auswirkungen bietet.

Erzwingen Sie verbindliche Tags auf allen EC2-Instanzen zum Startzeitpunkt über eine gesamte AWS Organization hinweg.

Verwenden Sie eine Service Control Policy (SCP), die `ec2:RunInstances` verweigert, es sei denn, die erforderlichen Tag-Schlüssel sind in der Anfrage vorhanden.

Warum: Präventive Kontrolle, die das Erstellen nicht konformer Ressourcen blockiert. Gilt für alle Konten und kann nicht durch lokale IAM-Richtlinien überschrieben werden.

Referenz

Verwalten und rotieren Sie Secrets (z.B. DB-Anmeldeinformationen), die von Anwendungen in mehreren Konten verwendet werden, ohne Ausfallzeiten.

Verwenden Sie AWS Secrets Manager mit aktivierter automatischer Rotation. Gewähren Sie kontoübergreifenden Zugriff mithilfe von ressourcenbasierten Richtlinien auf das Secret.

Warum: Secrets Manager unterstützt Rotationsstrategien ohne Ausfallzeiten (wechselnde Benutzer) und bietet eine sichere, native kontoübergreifende Freigabe.

Automatische Bereitstellung von grundlegenden Sicherheitsressourcen in neuen Konten, die über die Control Tower Account Factory erstellt wurden.

Verwenden Sie das Control Tower-Lebenszyklusereignis `CreateManagedAccount` über EventBridge, um eine Lambda-Funktion auszulösen, die ein CloudFormation StackSet bereitstellt. Alternativ können Sie Customizations for AWS Control Tower (CfCT) verwenden.

Warum: Ereignisgesteuerte Automatisierung ist das Standard-, skalierbare Muster zur Erweiterung von Control Tower-Baselines ohne manuelles Eingreifen nach der Kontoerstellung.

Ermöglichen Sie den SSM Session Manager-Zugriff auf EC2-Instanzen in einem privaten Subnetz ohne Internetzugang.

Erstellen Sie VPC-Schnittstellenendpunkte (powered by PrivateLink) für die Dienste `ssm`, `ssmmessages` und `ec2messages` in der VPC.

Warum: VPC-Endpunkte ermöglichen dem SSM-Agenten die Kommunikation mit dem Dienst vollständig innerhalb des AWS-Netzwerks und bieten das sicherste Zugriffsmuster, ohne dass ein NAT oder Internet-Gateway erforderlich ist.

Zentralisieren Sie Logs mit langfristiger Aufbewahrung und schützen Sie diese vor Löschung oder Änderung, selbst durch Administratoren.

Speichern Sie Logs in einem S3-Bucket mit S3 Object Lock im Compliance-Modus. Aktivieren Sie die Integritätsprüfung von CloudTrail-Logdateien.

Warum: Object Lock (Compliance-Modus) bietet WORM-Schutz, den selbst das Root-Konto nicht umgehen kann. Die Integritätsprüfung von Logdateien bietet eine kryptografische Überprüfung auf nachträgliche Manipulationen.

Bieten Sie Entwicklern eine Self-Service-Möglichkeit zur Bereitstellung von vorab genehmigten Infrastrukturmustern, ohne ihnen volle AWS-Service-Berechtigungen zu gewähren.

Verwenden Sie AWS Service Catalog. Erstellen Sie ein Portfolio genehmigter Produkte (definiert durch CloudFormation-Vorlagen). Verwenden Sie Launch-Constraints, damit Service Catalog Ressourcen über eine privilegierte IAM-Rolle bereitstellt, die vom Plattformteam verwaltet wird.

Warum: Service Catalog ist der speziell entwickelte AWS-Dienst zur Erstellung kuratierter Kataloge von IT-Services. Launch-Constraints sind das zentrale Governance-Feature, das es Entwicklern ermöglicht, komplexe Infrastruktur bereitzustellen, ohne selbst die zugrunde liegenden Berechtigungen zu besitzen.

Sichere Bereitstellung einzigartiger Secrets für verschiedene Microservices, die als ECS-Tasks laufen, um sicherzustellen, dass jeder Dienst nur auf seine eigenen Secrets zugreifen kann.

Erstellen Sie separate AWS Secrets Manager Secrets für jeden Dienst. Verweisen Sie in der ECS-Task-Definition auf die Secret-ARNs in der `secrets`-Eigenschaft der Container-Definition. Beschränken Sie die IAM-Rollenrichtlinie für die Task-Ausführung so, dass nur `secretsmanager:GetSecretValue` für den spezifischen Secret-ARN dieses Dienstes erlaubt ist.

Warum: Dies erzwingt das Prinzip der geringsten Rechte auf mehreren Ebenen: das Secret selbst, die IAM-Richtlinie und die ECS-Task-Definition. Secrets werden zur Laufzeit sicher injiziert.

Ermöglichen Sie einem GitHub Actions-Workflow den sicheren Zugriff auf AWS, ohne langlebige Anmeldeinformationen zu speichern.

Konfigurieren Sie einen IAM OIDC-Identitätsprovider für GitHub. Erstellen Sie eine IAM-Rolle mit einer Vertrauensrichtlinie, die den föderierten Prinzipal auf die spezifische GitHub-Organisation, das Repository und den Branch beschränkt. Verwenden Sie die Aktion `aws-actions/configure-aws-credentials` mit OIDC, um die Rolle anzunehmen.

Warum: Die OIDC-Föderation ist die sicherste Methode, die kurzlebige Anmeldeinformationen bereitstellt, die auf eine bestimmte Workflow-Ausführung beschränkt sind, wodurch das Risiko einer Offenlegung langlebiger Anmeldeinformationen eliminiert wird.

Überwachen Sie kontinuierlich alle IAM-Richtlinien in einer AWS Organization, um mit externen Entitäten geteilte Ressourcen zu identifizieren und darüber alarmiert zu werden.

Aktivieren Sie IAM Access Analyzer auf Organisationsebene und definieren Sie die Organisation als Vertrauenszone. Verwenden Sie EventBridge, um neue Findings zu erfassen und Benachrichtigungen auszulösen.

Warum: IAM Access Analyzer wurde speziell entwickelt, um automatisierte Argumentation zu nutzen, um extern geteilte Ressourcen zu finden. Das Ausführen auf Organisationsebene bietet eine kontinuierliche, zentralisierte Ansicht ohne benutzerdefinierte Skripte.

Reduzieren Sie den Fehlerbereich fehlgeschlagener CloudFormation-Updates in einer monolithischen oder verschachtelten Stack-Architektur.

Zerlegen Sie die Architektur in unabhängige Stacks mithilfe von Stack-übergreifenden Referenzen (CloudFormation Exports/Fn::ImportValue).

Warum: Ein Fehler in einem Stack (z.B. Datenbank) löst kein Rollback anderer erfolgreich aktualisierter Stacks (z.B. Netzwerke) aus, wodurch Fehlerdomänen isoliert werden.

Zentrales Management von kontoübergreifendem Patching mit unterschiedlichen Zeitplänen für Produktions- und Nicht-Produktionsumgebungen.

Verwenden Sie AWS Systems Manager Patch Manager mit benutzerdefinierten Patch-Baselines, separaten Wartungsfenstern für jede Umgebung und Systems Manager Explorer für die zentrale Compliance-Berichterstattung.

Warum: Unterstützt nativ alle Anforderungen: benutzerdefinierte Patch-Definitionen, flexible Zeitplanung über Wartungsfenster und kontoübergreifende Sichtbarkeit über Explorer.

Vorschau auf Infrastrukturänderungen in allen Zielkonten, bevor ein CloudFormation StackSet-Update ausgeführt wird.

Erstellen und überprüfen Sie ein CloudFormation-Change Set für den StackSet-Vorgang vor der Ausführung.

Warum: Change Sets sind der native CloudFormation-Mechanismus, um die genauen Ressourcenänderungen (hinzufügen, ändern, löschen), die ein Update durchführen wird, in der Vorschau anzuzeigen.

Stellen Sie sicher, dass CloudFormation auf den erfolgreichen Abschluss des UserData-Skripts einer EC2-Instanz wartet, bevor die Stack-Erstellung fortgesetzt wird.

Fügen Sie dem EC2-Instanz-Ressource eine `CreationPolicy` mit `ResourceSignal` hinzu. Rufen Sie das `cfn-signal`-Hilfsskript von UserData nach erfolgreichem Abschluss auf.

Warum: Dies ist der native CloudFormation-Mechanismus zur Koordination mit Konfigurationsskripten auf einer Ressource. Ein Nicht-Signalisieren innerhalb des Timeouts löst automatisch ein Stack-Rollback aus.

Erkennen, wenn manuell vorgenommene, außerbandliche Änderungen dazu führen, dass bereitgestellte Ressourcen von ihrer CloudFormation-Vorlagendefinition abweichen.

Führen Sie regelmäßig die CloudFormation-Drift-Erkennung auf dem Stack aus. Für eine kontinuierliche Erkennung verwenden Sie die AWS Config-Regel `cloudformation-stack-drift-detection-check`.

Warum: Drift-Erkennung ist die native Funktion zum Vergleich der Stack-Vorlage mit dem tatsächlichen Zustand seiner Ressourcen. Die Verwendung der Config-Regel automatisiert diese Überprüfung.

Schützen Sie zustandsbehaftete Ressourcen (z.B. einen S3-Bucket oder eine RDS-Datenbank) vor versehentlichem Löschen oder Ersetzen durch CloudFormation-Stack-Operationen.

Setzen Sie für die Ressource `DeletionPolicy: Retain` (oder `Snapshot` für RDS). Aktivieren Sie für den Stack `TerminationProtection`. Wenden Sie eine `StackPolicy` an, die `Update:Replace`- und `Update:Delete`-Aktionen auf der kritischen Ressource verweigert.

Warum: Bietet gestaffelte Verteidigung: Termination Protection verhindert das Löschen des Stacks, DeletionPolicy bewahrt die Ressource, wenn der Stack gelöscht wird, und die Stack Policy verhindert destruktive Updates.

Migrieren Sie ein CloudFormation StackSet von einem komplexen, selbstverwalteten IAM-Rollenmodell zu einem einfacheren Berechtigungsmodell für eine AWS Organization.

Aktualisieren Sie das StackSet, um serviceverwaltete Berechtigungen zu verwenden.

Warum: Serviceverwaltete Berechtigungen nutzen den vertrauenswürdigen Zugriff von Organizations, wodurch die Notwendigkeit entfällt, IAM-Rollen in jedem Zielkonto zu erstellen und zu verwalten. Sie ermöglichen auch die automatische Bereitstellung in neuen Konten, die zu gezielten OUs hinzugefügt werden.

Eine benutzerdefinierte CloudFormation-Ressource muss eine Aufgabe verwalten, die länger dauert als das 15-minütige Lambda-Funktions-Timeout.

Lösen Sie eine AWS Step Functions Zustandsmaschine von der Lambda-Funktion der benutzerdefinierten Ressource aus. Die Zustandsmaschine übernimmt die lang laufende Aufgabe unter Verwendung von Wait-Zuständen oder dem Task Token-Muster und sendet die Antwort an die S3-Pre-Signed-URL von CloudFormation zurück.

Warum: Step Functions ist darauf ausgelegt, lang laufende, mehrstufige Workflows zu orchestrieren, wodurch die Lambda-Timeout-Begrenzung effektiv umgangen und gleichzeitig die Integration mit CloudFormation aufrechterhalten wird.

Zentrales Erzwingen einer Richtlinie (z.B. alle S3-Buckets müssen Versionierung haben) über eine gesamte AWS CDK-Anwendung hinweg, unabhängig davon, wie Entwickler ihre Ressourcen definieren.

Erstellen Sie ein CDK-Aspekt, das die `IAspect`-Schnittstelle implementiert. Der Aspekt besucht alle Konstrukte im Anwendungsbaum, findet alle S3-Bucket-Konstrukte und wendet die erforderliche Konfiguration an oder fügt einen Validierungsfehler hinzu, falls diese fehlt.

Warum: Aspekte sind das offizielle CDK-Muster zum Anwenden von übergreifenden Belangen und zum zentralen Implementieren von Policy-as-Code-Validierungen, ohne einzelne Konstrukte zu ändern.

Verhindern Sie, dass automatisierte Operationen, wie das Patching über SSM Maintenance Windows, während bestimmter, sich ändernder Zeiträume (z.B. einem vierteljährlichen Finanz-Blackout) ausgeführt werden.

Verwenden Sie SSM Change Calendar, um Ereignisse zu definieren, die die Blackout-Perioden als "geschlossen" markieren. Verknüpfen Sie den Change Calendar mit dem Wartungsfenster.

Warum: Change Calendar fungiert als Gate für Automatisierungen. Es blockiert die Ausführung während "geschlossener" Perioden automatisch, ohne dass manuelle Änderungen am Wartungsfenster-Zeitplan erforderlich sind, was es sehr effizient für die Verwaltung dynamischer Blackout-Perioden macht.

Zentrales Management der Installation und Versionierung eines benutzerdefinierten Softwarepakets (z.B. eines Monitoring-Agenten) über eine Flotte von EC2-Instanzen hinweg.

Verpacken Sie die Software mit SSM Distributor. Verwenden Sie SSM State Manager, um eine Zuordnung zu erstellen, die das Distributor-Paket auf alle Zielinstanzen anwendet.

Warum: Distributor verwaltet den Paket-Lebenszyklus (einschließlich Versionen). State Manager stellt sicher, dass der gewünschte Zustand (z.B. "Version 1.2 des Agenten ist installiert") kontinuierlich durchgesetzt wird, indem Drift automatisch behoben und neue Instanzen konfiguriert werden.

Disaster Recovery mit niedrigem RPO (< 1 Min.) und RTO (< 5 Min.) für eine Aurora-Datenbank und Anwendungsschicht über Regionen hinweg.

Verwenden Sie eine Aurora Global Database für die Datenbankreplikation im Sub-Sekundenbereich. Für die Anwendungsschicht verwenden Sie einen "Warm Standby" mit einer Auto Scaling-Gruppe, die auf 0 gewünschte Kapazität eingestellt ist und bei einem Failover automatisiert hochskaliert wird.

Warum: Aurora Global Database bietet einen RPO im Sub-Sekundenbereich und einen RTO von < 1 Minute. Die Warm-Standby-Anwendungsschicht ist kostengünstig und erfüllt dennoch einen schnellen RTO.

Reduzieren Sie die Skalierungszeit einer Auto Scaling-Gruppe für Instanzen mit langen Bootstrap-/Initialisierungszeiten.

Erstellen Sie ein vorgebackenes "Golden AMI" mit installierten Abhängigkeiten. Konfigurieren Sie einen Warm-Pool für die Auto Scaling-Gruppe, um Instanzen vorab initialisiert zu halten.

Warum: Ein Golden AMI minimiert die Bootstrap-Zeit. Ein Warm-Pool minimiert die Startzeit (Start vs. Launch). Zusammen reduzieren sie die Zeit drastisch, die eine neue Instanz benötigt, um bereit zu sein, Traffic zu bedienen.

Ein ECS-Dienst skaliert seine Task-Anzahl hoch, kann aber keine neuen Tasks platzieren, weil dem zugrunde liegenden EC2-Cluster die Kapazität fehlt.

Aktivieren Sie ECS Cluster Auto Scaling, indem Sie einen Kapazitätsanbieter mit der EC2 Auto Scaling-Gruppe und dem ECS-Cluster verknüpfen.

Warum: Kapazitätsanbieter verknüpfen die Skalierung des ECS-Dienstes mit der Skalierung der EC2-Instanz. Wenn Tasks aufgrund unzureichender Cluster-Ressourcen nicht platziert werden können, skaliert der Kapazitätsanbieter die EC2 ASG automatisch hoch.

Skalieren Sie eine Flotte von EC2-Worker-Instanzen dynamisch basierend auf der Anzahl der Nachrichten in einer SQS-Warteschlange.

Verwenden Sie eine Zielverfolgungs-Auto Scaling-Richtlinie basierend auf der benutzerdefinierten Metrik: `ApproximateNumberOfMessagesVisible` / `GroupInServiceInstances` (d.h. Rückstand pro Instanz).

Warum: Dies ist das empfohlene Muster für SQS-basierte Skalierung. Es hält gerade genug Worker bereit, um den Rückstand innerhalb einer Zielzeit zu verarbeiten, und skaliert effizient mit der Warteschlangentiefe.

Erstellen Sie anwendungskonsistente (nicht nur absturzkonsistente) Snapshots von EBS-Volumes für zustandsbehaftete Anwendungen.

Verwenden Sie AWS Backup mit einem Backup-Plan. Verwenden Sie im Plan Systems Manager Run Command, um Pre-Snapshot-Skripte auszuführen, um die Anwendung in den Ruhemodus zu versetzen (oder VSS für Windows zu aktivieren).

Warum: AWS Backup orchestriert den gesamten Prozess. Das Stilllegen der Anwendung (Leeren der I/O-Puffer auf die Festplatte) vor dem Snapshot gewährleistet die Datenintegrität und einen wiederherstellbaren Anwendungszustand.

Stellen Sie sicher, dass kritische Ereignisse aus einer EventBridge-Regel nicht verloren gehen, wenn ein Zieldienst (z.B. Lambda) vorübergehend nicht verfügbar oder gedrosselt ist.

Konfigurieren Sie am EventBridge-Regelziel eine Wiederholungsrichtlinie (z.B. maximales Alter von 24 Stunden) und eine Dead-Letter Queue (DLQ) unter Verwendung einer SQS-Warteschlange.

Warum: Die Wiederholungsrichtlinie behandelt vorübergehende Fehler automatisch. Die DLQ dient als letztes Sicherheitsnetz, das Ereignisse abfängt, die alle Wiederholungsversuche erschöpfen, damit sie später erneut verarbeitet werden können, wodurch Datenverlust verhindert wird.

Lösen Sie Echtzeit-Alarme bei spezifischen Log-Mustern aus und fügen Sie Kontextinformationen (z.B. umgebende Log-Zeilen) in die Benachrichtigung ein.

Verwenden Sie einen CloudWatch Logs Abonnementfilter, um übereinstimmende Log-Ereignisse an eine Lambda-Funktion zu streamen. Die Lambda-Funktion formatiert und sendet eine detaillierte Benachrichtigung (z.B. an SNS oder Chime).

Warum: Abonnementfilter ermöglichen Echtzeit-Ereignis-Streaming. Lambda erlaubt eine benutzerdefinierte Logik, um Kontext zu extrahieren und zu formatieren, was einfache Metrikfilter nicht können.

Identifizieren Sie Latenz-Engpässe in einer verteilten, mikroservicebasierten Anwendung.

Aktivieren Sie AWS X-Ray-Tracing an Einstiegspunkten (z.B. API Gateway, ALB) und Compute-Ressourcen (z.B. Lambda, ECS). Verwenden Sie das X-Ray SDK für nachgelagerte Aufrufe. Analysieren Sie die Service-Map und die Traces.

Warum: X-Ray ist der speziell entwickelte AWS-Dienst für verteiltes Tracing. Die Service-Map visualisiert die Aufrufkette und hebt Dienste mit hoher Latenz und Fehlerraten hervor.

Erstellen Sie einen einzigen, übergeordneten Alarm, der den kombinierten Zustand einer mehrstufigen Anwendung darstellt, um Alarmrauschen zu reduzieren.

Erstellen Sie individuelle CloudWatch-Alarme für jede Schicht (z.B. ALB 5xx Rate, Anwendungs-CPU, RDS-Verbindungen). Kombinieren Sie diese dann mit einem CloudWatch Composite Alarm mit OR-Logik.

Warum: Composite-Alarme wurden entwickelt, um Alarmrauschen zu reduzieren, indem ein einziger, logischer Alarm basierend auf dem Zustand mehrerer zugrunde liegender Alarme erstellt wird.

Analysieren Sie Petabytes von Logs mit komplexen SQL-Abfragen (einschließlich Joins) und bewahren Sie sie über Jahre kostengünstig auf.

Streamen Sie Logs über Kinesis Data Firehose zu Amazon S3. Katalogisieren Sie die Daten mit AWS Glue. Fragen Sie mit Amazon Athena ab. Verwenden Sie S3 Lifecycle-Richtlinien, um Daten zur Langzeitarchivierung nach Glacier/Deep Archive zu überführen.

Warum: Dies ist die standardmäßige serverlose Data-Lake-Architektur. Athena bietet leistungsstarke SQL-Funktionen für S3-Daten, und S3/Glacier bietet die kostengünstigste Langzeitspeicherung.

Überwachen Sie eine Metrik mit vorhersehbaren zyklischen Mustern (z.B. tägliche/wöchentliche Spitzen) und lösen Sie einen Alarm nur bei echten Abweichungen vom Muster aus.

Konfigurieren Sie CloudWatch Anomaly Detection für die Metrik. Erstellen Sie einen Alarm, der ausgelöst wird, wenn der Metrikwert außerhalb des erwarteten Bereichs des Modells liegt.

Warum: Anomaly Detection verwendet maschinelles Lernen, um die normalen Muster der Metrik zu erlernen und einen dynamischen Schwellenwertbereich zu erstellen, der sich an Zyklen anpasst. Dies reduziert Fehlalarme bei vorhersehbaren Spitzen und verbessert das Signal-Rausch-Verhältnis.

Erzielen Sie umfassende Sichtbarkeit in CPU-, Speicher-, Festplatten- und Netzwerkmetriken auf Containerebene für Workloads auf EKS oder ECS, ohne Drittanbieter-Tools installieren und verwalten zu müssen.

Aktivieren Sie Amazon CloudWatch Container Insights für den EKS/ECS-Cluster.

Warum: Container Insights ist ein vollständig verwalteter Dienst, der detaillierte Leistungsmetriken für containerisierte Workloads automatisch sammelt, aggregiert und visualisiert und so eine tiefe Sichtbarkeit mit minimalem Betriebsaufwand bietet.

Überwachen Sie die Verfügbarkeit und Leistung einer internetorientierten Anwendung aus der Sicht von Endbenutzern und identifizieren Sie netzwerkbezogene Probleme auf ISP-Ebene und geografischer Ebene.

Aktivieren Sie Amazon CloudWatch Internet Monitor für die Anwendung.

Warum: Internet Monitor nutzt globale AWS-Netzwerkdaten, um Einblick in Internet-Wetter zu geben, das Ihre Endbenutzer betrifft, und hilft so, Probleme außerhalb Ihrer AWS-Umgebung zu diagnostizieren.

Messen Sie die reale Benutzererfahrung einer Webanwendung, indem Sie Seitenladezeiten, JavaScript-Fehler und andere clientseitige Leistungsmetriken sammeln.

Integrieren Sie das CloudWatch RUM (Real User Monitoring) JavaScript-Snippet in die Webanwendung.

Warum: RUM ist ein verwalteter Dienst, der clientseitige Leistungs- und Fehlerdaten direkt von Benutzerbrowsern sammelt und so einen echten Einblick in die reale Benutzererfahrung ohne synthetische Tests bietet.

Geben Sie benutzerdefinierte Anwendungsmetriken von einer AWS Lambda-Funktion mit hoher Auflösung und Dimensionen aus, ohne die Latenz und Kosten direkter CloudWatch API-Aufrufe zu verursachen.

Verwenden Sie das CloudWatch Embedded Metric Format (EMF), indem Sie speziell strukturiertes JSON in die Standardausgabe schreiben. Eine Client-Bibliothek kann dies vereinfachen.

Warum: CloudWatch Logs extrahiert Metriken automatisch und asynchron aus EMF-Logeinträgen, was keine zusätzliche Latenz in der Lambda-Funktion verursacht und die Kosten reduziert, indem PutMetricData-API-Aufrufe vermieden werden.

Automatische Behebung unverschlüsselter EBS-Volumes, die von AWS Config erkannt wurden, unter Gewährleistung der Datenkonsistenz während des Prozesses.

Verwenden Sie AWS Config Auto-Remediation mit einem Systems Manager Automation-Dokument. Das Runbook stoppt die Instanz, erstellt eine verschlüsselte Kopie des Volumes, tauscht die Volumes aus und startet die Instanz neu.

Warum: SSM Automation bietet einen robusten, mehrstufigen, auditierbaren Workflow. Das Stoppen der Instanz ist entscheidend, um einen datenkonsistenten Snapshot zu gewährleisten, bevor die verschlüsselte Kopie erstellt wird.

Führen Sie kontrollierte Chaos Engineering-Experimente (z.B. Injektion von Netzwerklatenz) mit automatischen Stoppbedingungen durch, um Auswirkungen auf die Produktion zu verhindern.

Verwenden Sie AWS Fault Injection Simulator (FIS) mit einer Experimentvorlage. Definieren Sie Stoppbedingungen basierend auf CloudWatch-Alarmen, die wichtige Anwendungsmetriken überwachen.

Warum: FIS ist der speziell entwickelte AWS-Dienst für Chaos Engineering, der Sicherheitsvorkehrungen (Stoppbedingungen) und einen Katalog von kontrollierten Fehlereinspeisungsaktionen bietet.

Ein CloudFormation-Stack steckt im Zustand `UPDATE_ROLLBACK_FAILED` fest, weil eine Ressource während eines fehlgeschlagenen Updates gelöscht oder geändert wurde, was ein sauberes Rollback verhindert.

Verwenden Sie die `ContinueUpdateRollback`-API-Aktion und geben Sie die logische ID der problematischen Ressource im Parameter `ResourcesToSkip` an.

Warum: Dies ist das Standard-Wiederherstellungsverfahren, um das Rollback zu erzwingen, indem CloudFormation angewiesen wird, die Ressource zu ignorieren, die es nicht mehr verwalten kann, und den Stack in einen stabilen Zustand zurückzuführen.

Erhalten Sie Benachrichtigungen innerhalb von Minuten nach dem Auftreten kritischer Sicherheitsereignisse, wie z.B. Root-Konto-Anmeldung, IAM-Richtlinienänderungen oder Sicherheitsgruppen-Modifikationen.

Erstellen Sie Amazon EventBridge-Regeln, die spezifische CloudTrail-Management-Ereignismuster abgleichen und diese zur Benachrichtigung an ein SNS-Topic weiterleiten.

Warum: EventBridge empfängt CloudTrail-Management-Ereignisse nahezu in Echtzeit und bietet die geringste Latenz für ereignisgesteuerte Sicherheitswarnungen im Vergleich zu Polling- oder Log-basierten Methoden.

Eine Lambda-Funktion mit hohem Traffic wird gedrosselt und erschöpft beim Skalieren auch RDS-Datenbankverbindungen.

Beantragen Sie eine Erhöhung des Lambda-Limits für gleichzeitige Ausführungen. Implementieren Sie Amazon RDS Proxy zwischen den Lambda-Funktionen und der RDS-Datenbank.

Warum: Erhöhte Parallelität löst Drosselung. RDS Proxy ist für serverlose Anwendungen unerlässlich, da es Datenbankverbindungen bündelt und wiederverwendet, wodurch verhindert wird, dass die Datenbank durch eine große Anzahl ephemerer Verbindungen überlastet wird.

Implementieren Sie ein automatisiertes DNS-Failover zwischen Regionen und lösen Sie ein automatisiertes Wiederherstellungs-Runbook für die fehlgeschlagene Region aus.

Verwenden Sie Route 53 Failover-Routing mit zugehörigen Health Checks. Erstellen Sie eine EventBridge-Regel, die das Statusänderungsereignis des Route 53 Health Checks erfasst und ein Systems Manager Automation-Runbook auslöst.

Warum: Diese Architektur kombiniert automatisiertes Traffic-Failover (Route 53) mit ereignisgesteuerter, automatisierter Incident Response (EventBridge + SSM Automation) für ein vollständiges Resilienz-Muster.

Verhindern Sie, dass einer RDS-Datenbank der Speicher ausgeht und eine Anwendungsstörung verursacht.

Aktivieren Sie RDS Storage Autoscaling, indem Sie einen maximalen Speicherschwellenwert festlegen. Als sekundäre Kontrolle erstellen Sie einen CloudWatch-Alarm für die Metrik `FreeStorageSpace`.

Warum: Storage Autoscaling ist eine proaktive, verwaltete Funktion, die den zugewiesenen Speicher automatisch erhöht. Der CloudWatch-Alarm bietet ein Sicherheitsnetz für Monitoring und Alarmierung.

Eine Charge von Ereignissen muss neu verarbeitet werden, die aufgrund eines temporären Fehlers in einem Consumer falsch verarbeitet wurden.

Konfigurieren Sie vorab ein EventBridge-Archiv auf dem Event Bus. Nach Behebung des Fehlers erstellen Sie ein Replay, um Ereignisse aus dem spezifischen Zeitfenster des Vorfalls erneut zu senden.

Warum: Archivieren und Wiedergeben ist die native EventBridge-Funktion zum Speichern und erneuten Verarbeiten historischer Ereignisse, entscheidend für die Wiederherstellung nach temporären Verarbeitungsfehlern.

Automatisieren Sie den gesamten Incident-Response-Prozess: Erstellen Sie einen Incident, binden Sie das Bereitschaftsteam ein, öffnen Sie einen Chat-Kanal und führen Sie ein Remediation-Runbook aus, wenn ein kritischer Alarm ausgelöst wird.

Erstellen Sie einen SSM Incident Manager-Antwortplan, der alle Engagement- und Behebungsschritte definiert. Konfigurieren Sie den CloudWatch-Alarm so, dass er diesen Antwortplan als Aktion auslöst.

Warum: Antwortpläne bieten eine einzige, kohärente Konfiguration zur Orchestrierung aller Aspekte der Incident Response, wodurch manueller Aufwand reduziert und konsistente Verfahren gewährleistet werden.