Kapitelprojekt: Delivery-Baseline
Dieses Projekt verbindet die Ideen des Kapitels zu einem überprüfbaren Delivery-Design. Du sollst keine große Anwendung bereitstellen. Entscheidend ist, dass Anforderungen, Konten, Identitäten, Artefakte, Pipeline-Stufen, Nachweise und Rollback ein schlüssiges Gesamtsystem bilden.
Das Ergebnis muss für Entwicklung, Security Review und Betrieb verständlich sein. Wenn ein Diagramm oder eine Tabelle erst nach einer langen mündlichen Erklärung Sinn ergibt, überarbeite das Artefakt.
Szenario
Example Retail betreibt eine containerisierte Bestell-API. Der Quellcode liegt in einem zentralen Tooling-Konto, während Entwicklungs- und Produktions-Workloads in getrennten AWS-Konten laufen.
Derzeit wird die Anwendung in jeder Umgebung separat gebaut und manuell in Produktion ausgerollt. Daraus entstehen drei Probleme:
- Das Produktions-Image ist möglicherweise nicht dasselbe Image, das die Tests bestanden hat.
- Administratoren benötigen für Releases weitreichende Berechtigungen.
- Bei fehlgeschlagenen Releases hängt die Wiederherstellung davon ab, dass eine Person den Ablauf kennt.
Entwirf eine Delivery-Baseline, die diese Schwächen behebt.
Feste Anforderungen
Dein Design muss alle folgenden Anforderungen erfüllen:
- Ein Commit auf den Main-Branch startet den Delivery-Prozess.
- Die Anwendung wird einmal gebaut; dasselbe unveränderliche Image wird weitergereicht.
- Entwicklung und Produktion befinden sich in getrennten AWS-Konten.
- Das Tooling-Konto darf keine dauerhaften Administrator-Zugangsdaten für Workload-Konten erhalten.
- Unit-, Security-, Integrations- und Production-Readiness-Prüfungen müssen Nachweise erzeugen.
- Die Produktion verwendet eine Deployment-Strategie mit schrittweiser Traffic-Verschiebung.
- Ein fehlgeschlagener Production Health Check startet automatisch den Rollback.
- Jedes Deployment muss einer Source Revision und einer Pipeline-Ausführung zugeordnet werden können.
- In der ersten Einführungsphase ist eine Produktionsfreigabe erforderlich.
- Artefakte müssen verschlüsselt und nur für benötigte Delivery-Identitäten zugänglich sein.
- Das Design muss Kostenkontrolle und Cleanup erläutern.
Zulässige Annahmen
Nutze diese Annahmen, sofern du keine begründete Alternative dokumentierst:
- AWS CodePipeline orchestriert den Workflow.
- AWS CodeBuild führt Build- und Testbefehle aus.
- Amazon ECR speichert Container-Images.
- Amazon ECS betreibt den Service.
- AWS CodeDeploy steuert ein ECS-Blue/Green-Deployment.
- Amazon CloudWatch liefert Alarme und Betriebsmetriken.
- AWS CloudTrail zeichnet API-Aktivitäten auf.
- Das Tooling-Konto besitzt den Pipeline-Artefakt-Bucket und den zugehörigen kundenverwalteten KMS-Schlüssel.
Die genaue Service-Auswahl ist weniger wichtig als die Qualität deiner Begründung. Ein anderer Service ist akzeptabel, wenn er dieselben Randbedingungen erfüllt und du den Trade-off erklärst.
Lernziele
Nach Abschluss des Projekts kannst du:
- Anforderungen aus Fließtext in Architektureigenschaften übersetzen;
- Orchestrierungs-, Build-, Deployment- und Runtime-Identitäten unterscheiden;
- ein unveränderliches Artefakt von der Source Revision bis zur Produktion verfolgen;
- messbare Eintritts- und Austrittskriterien für jede Stufe definieren;
- kontenübergreifenden Zugriff ohne langlebige Zugangsdaten entwerfen;
- Health-Nachweise mit einer automatischen Rollback-Entscheidung verbinden;
- das Design im Normal-, Fehler- und Wiederherstellungsfall erklären;
- die wahrscheinlichste Ursache eines fehlgeschlagenen Cross-Account-Deployments ermitteln.
Vorbereitung
Wiederhole die ersten vier Lektionen und lege einen Arbeitsordner für deine Artefakte an. Ein Diagrammwerkzeug ist hilfreich, aber ein sorgfältig beschriftetes Markdown-Diagramm genügt.
Beginne nicht mit AWS-Service-Icons. Extrahiere zuerst die Anforderungen. Architektur ist eine Antwort auf Randbedingungen, keine Sammlung von Services.
Phase 1: Anforderungsregister erstellen
Erstelle eine Tabelle mit einer Zeile pro fester Anforderung. Ordne jeden Punkt als Ziel, harte Randbedingung, Präferenz oder Betriebsannahme ein. Übersetze ihn anschließend in eine Eigenschaft, die im Design sichtbar sein muss.
Nutze dieses Beispiel als Ausgangspunkt:
| Anforderung | Einordnung | Erforderliche Eigenschaft | Nachweis |
|---|---|---|---|
| Einmal bauen und weiterreichen | Harte Randbedingung | Ein Image-Digest durchläuft alle Umgebungen | Manifest und ECR-Digest |
| Keine dauerhaften Workload-Zugangsdaten | Harte Randbedingung | Rollenübernahme über STS | CloudTrail-Event AssumeRole |
| Schrittweiser Produktions-Traffic | Ziel | Blue/Green- oder Canary-Traffic-Shifting | Deployment-Konfiguration |
| Automatischer Rollback | Harte Randbedingung | Alarm ist mit Deployment verbunden | Fehlgeschlagener Health-Drill |
| Menschliche Freigabe in Phase eins | Betriebsbedingung | Approval Action vor Produktion | Pipeline-Ausführungshistorie |
Beantworte für jede Anforderung zwei Fragen:
- Wo wird sie durchgesetzt?
- Welcher Nachweis belegt, dass sie funktioniert hat?
Kannst du nicht beides beantworten, ist die Anforderung bisher nur eine Absicht.
Phase 2: Architektur zeichnen
Dein Diagramm muss Sicherheits- und Artefaktgrenzen zeigen, nicht nur Service-Namen.
Mindestens enthalten sein müssen:
- die Grenzen von Tooling-, Entwicklungs- und Produktionskonto;
- Source, Pipeline, Build, Artefakt-Bucket, KMS-Schlüssel und Image-Repository;
- kontenübergreifende Deployment-Rollen;
- ECS-Services für Entwicklung und Produktion;
- Test- und Freigabe-Gates;
- Produktions-Listener oder Load Balancer;
- CloudWatch-Alarme und das Rollback-Signal;
- CloudTrail als Audit-Quelle.
Ein gültiger Ablauf auf hoher Ebene könnte so aussehen:
Developer-Commit
|
v
Tooling-Konto
Source -> Build/Test -> ECR-Image per Digest -> Pipeline-Artefakt
| |
| STS AssumeRole | mit KMS verschlüsselt
v v
Entwicklungskonto Nachweise und Manifest
Deployment -> Integrationstests -> Promotion-Entscheidung
|
| STS AssumeRole + Freigabe
v
Produktionskonto
Green-Ersatzumgebung -> Traffic-Shift -> Alarme -> voller Traffic oder Rollback auf Blue
Beschrifte jeden kontenübergreifenden Pfeil mit der übernommenen Rolle. Beschrifte jeden Artefaktpfeil mit Artefaktkennung und Verschlüsselungsgrenze.
Fragen für den Architektur-Review
- Welches Konto besitzt die jeweilige Ressource?
- Welche Identität führt den jeweiligen API-Aufruf aus?
- Welche Resource Policies müssen einer externen Identität vertrauen?
- Kann die Produktion genau den in Entwicklung getesteten Image-Digest abrufen?
- Wo wird die Deployment-Gesundheit bewertet?
- Was passiert, wenn die Pipeline nach einer teilweisen Traffic-Verschiebung unterbrochen wird?
Phase 3: Identitäten und Verschlüsselung definieren
Erstelle eine Konten- und Rollenmatrix. Vermeide Formulierungen wie „die Pipeline-Rolle hat Zugriff“. Benenne Principal, Aktion, Ressource und Vertrauensbeziehung.
| Identität | Heimatkonto | Wird übernommen von / übernimmt | Benötigte Aktionen | Explizit ausgeschlossen |
|---|---|---|---|---|
| Pipeline Service Role | Tooling | Übernimmt Deployment-Rollen | Artefakte lesen, Stufen aufrufen, STS verwenden | Zugriff auf Anwendungsdaten |
| Build-Rolle | Tooling | CodeBuild-Service | Source lesen, Tests ausführen, ein ECR-Image pushen | Produktions-Deployment |
| Entwicklungs-Deployment-Rolle | Entwicklung | Vertraut Pipeline-Rolle | Entwicklungsressourcen aktualisieren | Produktionsressourcen |
| Produktions-Deployment-Rolle | Produktion | Vertraut Pipeline-Rolle | Freigegebenes Deployment starten und prüfen | IAM-Administration |
| ECS Task Role | Workload-Konto | ECS-Tasks | Anwendungsspezifische API-Aufrufe | Pipeline- und Deployment-Aktionen |
Dokumentiere für jede Cross-Account-Rolle beide Seiten der Autorisierung:
- Die Trust Policy der Zielrolle erlaubt der Tooling-Pipeline-Rolle
sts:AssumeRole. - Die Permissions Policy der Tooling-Pipeline-Rolle erlaubt
sts:AssumeRoleauf die ARN der Zielrolle.
Dokumentiere danach die Ressourcenebene:
- S3 Bucket Policy für Pipeline-Artefakte;
- KMS Key Policy und KMS-Berechtigungen des Aufrufers;
- ECR Repository Policy oder Replikationsstrategie;
- Berechtigungen zum Weitergeben von Deployment- und Task-Rollen;
- Conditions zur Einschränkung unerwarteter Principals oder Kontexte.
Checkliste zur Verschlüsselung
- Der Artefakt-Bucket blockiert öffentlichen Zugriff.
- Artefakte verwenden bei Cross-Account-Zugriff einen kundenverwalteten KMS-Schlüssel.
- Die KMS Key Policy nennt die vorgesehenen kontenübergreifenden Principals.
- Caller Policies erlauben nur die benötigten KMS-Operationen.
- ECR-Scanning und Image-Tag-Mutability sind dokumentiert.
- Logs haben eine explizite Aufbewahrungsdauer.
- Secrets werden aus einem verwalteten Store referenziert und erscheinen weder in Build-Logs noch in Artefakten.
Phase 4: Delivery-Ablauf spezifizieren
Erstelle für jede Stufe einen Stage Contract. Er beschreibt, was bereits gelten muss, welche Arbeit die Stufe ausführt, welche Nachweise sie erzeugt und unter welcher Bedingung die Ausführung fortgesetzt wird.
| Stufe | Eintrittskriterien | Hauptarbeit | Ergebnis/Nachweis | Austrittskriterien |
|---|---|---|---|---|
| Source | Main-Branch-Event empfangen | Commit auflösen | Commit-ID | Revision protokolliert |
| Build | Source verfügbar | Kompilieren, Unit-Test, Scan, Image bauen | Reports, Image-Digest | Pflichtprüfungen bestanden |
| Entwicklungs-Deployment | Manifest verfügbar | Rolle übernehmen und Digest deployen | Deployment-ID | Service stabil |
| Integrationstest | Entwicklungs-Endpunkt gesund | API-Tests ausführen | Testbericht | Schwellwert erfüllt |
| Produktionsfreigabe | Alle automatischen Nachweise vorhanden | Reviewer bewertet Risiko | Identität und Zeitpunkt | Vor Timeout freigegeben |
| Produktions-Deployment | Freigegebener Digest verfügbar | Blue/Green-Traffic verschieben | Deployment- und Alarmhistorie | Voller Traffic und stabile Alarme |
Das Artefaktmanifest
Das Manifest bildet die Beweiskette eines Releases. Definiere ein maschinenlesbares Format mit mindestens folgenden Daten:
{
"sourceRevision": "<commit-sha>",
"pipelineExecution": "<execution-id>",
"imageRepository": "<repository-uri>",
"imageDigest": "sha256:<digest>",
"buildProject": "<project-name>",
"buildNumber": "<build-number>",
"testReports": ["unit", "security", "integration"],
"createdAt": "<UTC timestamp>"
}
Verwende keinen veränderlichen Tag wie latest als Release-Identität. Ein lesbarer Tag darf Menschen helfen, das Deployment muss jedoch auf den getesteten Digest auflösen.
Phase 5: Feedback und Rollback entwerfen
Wähle wenige Signale, die sowohl Deployment-Gesundheit als auch Auswirkungen auf Benutzer beschreiben. Mehr Alarme bedeuten nicht automatisch mehr Sicherheit; verrauschte Alarme machen automatische Rollbacks unzuverlässig.
Geeignete Signale sind beispielsweise:
- Target Health und fehlgeschlagener Task-Start;
- HTTP-5xx-Fehlerrate;
- Latenz an einem relevanten Perzentil;
- Anzahl von Anwendungsfehlern;
- ein fachliches Signal wie erfolgreich erstellte Bestellungen;
- Dauer von Deployment und Rollback.
Definiere für jedes Signal Datenquelle, Auswertungszeitraum, Schwellwert, Umgang mit fehlenden Daten und verantwortliche Person oder Team.
Rollback-Entscheidungsbaum
Dein Design muss diese Abfolge beantworten:
Wurde das neue Task Set gesund?
nein -> Deployment stoppen und zurückrollen
ja -> ersten Traffic-Anteil verschieben
Ist ein Deployment-Alarm in ALARM gewechselt?
ja -> Traffic-Shift stoppen und zurückrollen
nein -> gemäß Deployment-Konfiguration fortfahren
Blieb der volle Traffic während der Bake Time gesund?
nein -> zurückrollen, solange das vorherige Task Set verfügbar ist
ja -> Deployment abschließen und Nachweise behalten
Dokumentiere außerdem Fälle, die die Automation nicht lösen kann. Eine fehlerhafte Datenbankmigration kann zum Beispiel eine Vorwärtskorrektur erfordern, statt den Application Traffic lediglich auf das vorherige Task Set zurückzustellen.
Phase 6: Drei Tabletop-Drills durchführen
Gehe jeden Fehler vom ersten Symptom bis zum abschließenden Nachweis durch. Beende die Analyse nicht mit „IAM prüfen“ oder „Logs ansehen“.
Drill A: Entwicklungs-Deployment liefert AccessDenied
Verfolge die Anfrage in dieser Reihenfolge:
- Bestätige, dass die Pipeline Action die erwartete ARN der Zielrolle verwendet hat.
- Bestätige, dass die Pipeline-Rolle
sts:AssumeRoleauf diese ARN erlaubt. - Bestätige, dass die Trust Policy der Zielrolle dem Pipeline-Principal vertraut.
- Prüfe CloudTrail in beiden relevanten Konten.
- War die Rollenübernahme erfolgreich, prüfe die Deployment-Berechtigungen der temporären Session.
- Prüfe S3, KMS, ECR und
iam:PassRolenur dort, wo die fehlgeschlagene API sie benötigt.
Notiere die genaue fehlgeschlagene API, Caller-ARN, Ressourcen-ARN, das Konto und die betroffene Policy-Ebene.
Drill B: Integrationstests schlagen fehl
Die Produktionsstufe darf nicht starten. Bewahre fehlgeschlagene Reports auf, markiere die Ausführung als fehlgeschlagen und halte die aktuell laufenden Entwicklungs- und Produktionsrevisionen eindeutig fest. Entscheide, ob ein neuer Commit eine neue Ausführung startet oder ob die fehlgeschlagene Ausführung erneut versucht werden darf.
Drill C: Produktionsfehlerrate steigt während des Traffic-Shifts
Der konfigurierte Alarm wechselt in ALARM. CodeDeploy stoppt das Deployment und leitet den Traffic zurück auf das vorherige Task Set. Erfasse Alarmhistorie, Deployment-ID, Image-Digest, Source Revision, Rollback-Ergebnis und Incident Owner.
Erkläre, wie du einen ebenfalls fehlgeschlagenen Rollback erkennen würdest.
Phase 7: Delivery-System messen
Nimm mindestens diese Metriken auf:
| Metrik | Aussage | Sinnvolle Dimension |
|---|---|---|
| Lead Time for Changes | Delivery-Geschwindigkeit | Repository oder Service |
| Deployment Frequency | Batch-Größe und Fluss | Umgebung |
| Change Failure Rate | Release-Qualität | Service und Deployment-Typ |
| Mean Time to Restore | Wiederherstellungsfähigkeit | Incident-Schweregrad |
| Stage Duration | Engpässe | Pipeline-Stufe |
| Gate Rejection Rate | Qualität des Feedbacks | Gate-Typ |
Definiere, wo jede Metrik berechnet wird und wer sie prüft. Metriken ohne Owner oder Entscheidungsrhythmus sind Dekoration.
Phase 8: Kostenkontrolle und Cleanup
Dein Plan muss sowohl laufende Kostenkontrolle als auch die Bereinigung einer Laborumgebung abdecken.
Berücksichtige:
- S3 Lifecycle Rules für alte Pipeline-Artefakte;
- ECR Lifecycle Rules für nicht mehr referenzierte Images;
- eine zu den Audit-Anforderungen passende Log-Aufbewahrung;
- Build-Compute-Größe und Timeout-Grenzen;
- Abschalten ungenutzter Entwicklungsservices, sofern vertretbar;
- Bereinigung von Testressourcen nach fehlgeschlagenen Ausführungen;
- Aufbewahrung von Manifesten und Audit-Nachweisen für den vorgeschriebenen Zeitraum;
- Löschreihenfolge für Rollen, Policies, Buckets, Schlüssel, Repositories und Workload-Ressourcen.
Lösche keine Nachweise, die die Organisation aufbewahren muss. „Cleanup“ ist eine Lifecycle Policy, kein bedingungsloses Löschen.
Pflichtabgaben
Reiche ein kompaktes Designpaket mit folgenden Bestandteilen ein:
- Anforderungsregister mit Durchsetzung und Nachweisen.
- Architekturdiagramm mit Konten, Rollen, Artefaktfluss und Rollback-Signal.
- Konten-, Identitäts- und Rollenmatrix.
- IAM- und Verschlüsselungsdesign.
- Stage Contracts und Schema des Artefaktmanifests.
- Normal-, Fehler- und Rollback-Flüsse.
- Metriken, Alarme, Ownership und Review-Rhythmus.
- Kostenkontroll- und Cleanup-Plan.
- Ergebnisse der drei Tabletop-Drills.
- Antworten auf den Projekt-Selbstcheck.
Bewertungsraster
Bewerte das Projekt mit maximal 100 Punkten.
| Bereich | Punkte | Nachweis für volle Punktzahl |
|---|---|---|
| Anforderungen und Begründung | 15 | Jede harte Randbedingung ist mit Durchsetzung und Nachweis verknüpft |
| Architektur und Grenzen | 15 | Konten, Vertrauen, Artefakte und Fehlersignale sind sichtbar |
| IAM und Verschlüsselung | 20 | Beide Seiten der Rollenübernahme und Resource Policies sind erklärt |
| Delivery-Ablauf | 20 | Ein unveränderlicher Digest durchläuft messbare Stage Contracts |
| Fehler und Rollback | 15 | Automatische und manuelle Recovery-Pfade sind testbar |
| Betrieb und Metriken | 10 | Signale haben Schwellwerte, Owner und Aktionen |
| Kosten und Cleanup | 5 | Aufbewahrung und Cleanup sind explizit und sicher |
Einordnung:
- 90-100: review-fähige professionelle Baseline;
- 75-89: solides Design mit wenigen fehlenden Betriebsdetails;
- 60-74: plausible Architektur, aber wichtige Kontrollen bleiben implizit;
- unter 60: Kapitel wiederholen und Anforderungen, Identitäten sowie Nachweise explizit machen.
Projekt-Selbstcheck
Beantworte jede Frage, bevor du die Musterantworten öffnest.
- Warum ist ein ECR-Tag allein ein schwacher Nachweis dafür, dass in Produktion das getestete Image läuft?
- Welche zwei IAM-Policy-Entscheidungen sind erforderlich, bevor eine Tooling-Rolle eine Produktionsrolle übernehmen kann?
- Warum können Artefakt-Bucket und KMS-Schlüssel getrennte Cross-Account-Berechtigungen benötigen?
- Wo sollte die Produktionsfreigabe liegen, und welche Nachweise sollte der Reviewer prüfen?
- Welche Signale eignen sich für einen automatischen Rollback, und wann ist ein Signal unsicher?
- Was muss mit der Produktion geschehen, wenn Integrationstests in Entwicklung fehlschlagen?
- Warum unterscheidet sich die ECS Task Role von der Produktions-Deployment-Rolle?
- Welche Nachweise verbinden einen Produktions-Incident mit einer Source-Änderung?
- Wann reicht der Rollback auf die vorherige Anwendungsversion nicht aus?
- Welche Designentscheidung begrenzt den Blast Radius kompromittierter Build-Zugangsdaten am direktesten?
Musterantworten anzeigen
1. Image-Identität
Tags können verschoben oder überschrieben werden. Ein Digest identifiziert den Inhalt des Images. Das Manifest muss diesen Digest mit Source Revision, Build, Tests und Pipeline-Ausführung verknüpfen; das Deployment verwendet den verifizierten Digest.
2. Kontenübergreifende Rollenübernahme
Die Trust Policy der Produktionsrolle muss dem Tooling-Pipeline-Principal vertrauen. Gleichzeitig muss dessen Identity Policy sts:AssumeRole auf die ARN der Produktionsrolle erlauben. Nach der Rollenübernahme benötigt die Session weiterhin Berechtigungen für die aufgerufenen Deployment-APIs.
3. S3- und KMS-Autorisierung
Das Lesen eines verschlüsselten Objekts umfasst zwei Autorisierungsentscheidungen: Zugriff auf das S3-Objekt und Nutzung des KMS-Schlüssels zum Entschlüsseln. Die Bucket Policy kann keine Nutzung des Schlüssels gewähren, und die Key Policy keinen Zugriff auf das Objekt.
4. Freigabenachweise
Die Freigabe liegt nach allen automatisierten Vorproduktionsnachweisen und vor jeder Änderung an der Produktion. Der Reviewer prüft Revision und Digest, Test- und Scan-Ergebnisse, geplante Deployment-Strategie, aktuelle Betriebsstabilität und Rollback-Bereitschaft. Identität und Zeitpunkt der Entscheidung werden aufbewahrt.
5. Rollback-Signale
Signale müssen zeitnah, dem Deployment zuordenbar und eng mit Benutzer- oder Service-Gesundheit verknüpft sein. Fehlerrate, ungesunde Targets und eine kritische fachliche Transaktion können geeignet sein. Eine verrauschte Metrik, ein zu kurzer Zeitraum oder uneindeutiges Verhalten bei fehlenden Daten kann unsichere Rollbacks auslösen.
6. Fehlgeschlagene Integrationstests
Die Produktion bleibt unverändert. Die Pipeline stoppt vor der Produktion, bewahrt die Fehlernachweise auf und hält die letzte funktionierende Revision fest. Eine Korrektur muss dieselben Kontrollen bestehen, statt das fehlgeschlagene Gate zu umgehen.
7. Runtime- und Deployment-Rollen
Die Task Role autorisiert den Anwendungscode zur Laufzeit. Die Deployment-Rolle ändert Deployment-Ressourcen und Traffic. Eine Zusammenlegung gäbe der Anwendung unnötige Kontrolle über ihr eigenes Delivery-System und vergrößerte den Blast Radius.
8. Incident-Nachverfolgbarkeit
Manifest und Ausführungshistorie verbinden Produktions-Deployment-ID und Image-Digest mit Pipeline-Ausführung, Build, Testberichten, Source Commit, freigebender Person und Zeitstempeln. CloudTrail liefert Nachweise über die aufrufende Identität auf API-Ebene.
9. Grenzen des Rollbacks
Eine inkompatible oder destruktive Datenbankmigration, bereits sichtbare externe Nebenwirkungen, beschädigte Daten oder irreversible Events bleiben möglicherweise trotz Anwendungs-Rollback bestehen. Solche Änderungen benötigen rückwärtskompatible Migrationen, Vorwärtskorrektur oder ein separates Wiederherstellungsverfahren.
10. Blast Radius der Build-Rolle
Die Build-Rolle erhält ausschließlich Build-Berechtigungen und darf weder Produktion deployen noch IAM administrieren. Eine getrennte Pipeline-Identität übernimmt eng begrenzte Deployment-Rollen nur in den erforderlichen Stufen.
Abschlusscheckliste
- Jede Anforderung besitzt eine Durchsetzung und einen Nachweis.
- In Entwicklung und Produktion wird derselbe Image-Digest verwendet.
- Jeder Cross-Account-Aufruf nennt Caller und Zielrolle.
- S3-, KMS-, ECR- und
iam:PassRole-Berechtigungen sind berücksichtigt. - Pipeline-Stufen haben messbare Eintritts- und Austrittskriterien.
- Produktionsalarme steuern einen getesteten Rollback-Pfad.
- Normal-, Fehler- und Recovery-Flüsse sind dokumentiert.
- Metriken haben Owner und Review-Aktionen.
- Kosten- und Aufbewahrungsregeln sind explizit.
- Alle zehn Selbstcheck-Antworten lassen sich ohne auswendig gelernte Schlagwörter erklären.