Change Sets, Rollback und Stack Policies
Prüfungsbezug: Domain 2 zu wiederverwendbarer Infrastruktur, automatisiertem Onboarding und Configuration Management.
Lernziel
Replacement-Risiko, Previews, Rollback-Recovery und Ressourcenschutz wiederholbar, sicher und betrieblich skalierbar entwerfen, implementieren und untersuchen.
Berufliches Szenario
Eine wachsende Organisation besitzt viele Teams, AWS-Konten und Regionen. Manuelle Provisionierung und Konfiguration erzeugen Drift, inkonsistente Kontrollen, unklare Ownership und langsames Onboarding. Das Plattformteam muss standardisieren, ohne zum manuellen Engpass zu werden.
Kernkonzepte
- Einen klaren Desired State definieren und versionieren.
- Control-Plane- und Execution-Berechtigungen trennen.
- Managed, Organizations-fähige Funktionen gegenüber großen eigenen Skripten bevorzugen, wenn sie die Anforderungen erfüllen.
- Zuerst in kleinem Scope testen.
- Failure Tolerance, Concurrency, Rollback und Ausnahmebehandlung ausdrücklich definieren.
- Nachweise für auditierbare Governance-Entscheidungen erfassen.
Architektur-Schrittfolge
- Standard und Owner definieren.
- Standard als IaC, Konfiguration, Policy oder genehmigtes Product paketieren.
- Syntax, Verhalten, Berechtigungen und Replacement-Risiken validieren.
- In Sandbox oder kleiner OU deployen.
- Events, Compliance und Betriebsmetriken beobachten.
- In kontrollierten Wellen erweitern.
- Drift erkennen und Ausnahmen bearbeiten.
- Standard versionieren und verbessern.
Entscheidungshilfe
| Anforderung | Bevorzugte Richtung | Warum |
|---|---|---|
| Wiederverwendbare Infrastruktur | Versionierte Komponente mit stabiler Schnittstelle | Weniger Duplikate |
| Multi-Account-Deployment | Organizations-fähige Managed-Verteilung | Zentrale Kontrolle |
| Große Flotte | Rate Controls und gestufte Wellen | Begrenzter Blast Radius |
| Temporäre Ausnahme | Owner, Grund, Freigabe und Ablauf | Kein permanenter versteckter Drift |
| Sensitive Ausführung | Begrenzte Rolle und geschützte Konfiguration | Least Privilege |
Fehlerbilder und Fehlersuche
- IAM erlaubt eine Aktion, aber SCP, Resource Policy, KMS Key Policy oder Permissions Boundary verweigert sie.
- Ein breiter Rollout überschreitet Concurrency oder Failure Tolerance.
- Eine Komponente ändert sich ohne Versionierung und bricht Consumer.
- Retained oder importierte Ressource besitzt keinen Cleanup-Owner.
- Drift wird erkannt, aber genehmigter Zustand ist unklar.
- Automatische Remediation wiederholt eine destruktive Aktion.
Sicherheit und Betrieb
- Begrenzte Deployment- und Automation-Rollen verwenden.
- Parameter, Secrets, Logs, Templates und Kontometadaten schützen.
- Policy-, Baseline-, Product- und Control-Änderungen auditieren.
- Keine Secrets direkt in Templates oder Source.
- Backup, Recovery und Cleanup stateful Ressourcen testen.
Praxislabor
Ziel: Ein kontrolliertes Design oder eine kleine Umsetzung für Change Sets, Rollback und Stack Policies erstellen.
Aufgaben
- Funktionale, Sicherheits- und Betriebsanforderungen notieren.
- Control Plane, Zielkonten oder Nodes und Execution Roles zeichnen.
- Minimales Template, Construct, Document, Rule oder Policy bauen.
- Einen kontrollierten Fehler einführen.
- Mit Service Events und Logs diagnostizieren.
- Gestuften Rollout und Rollback definieren.
- Kosten und Cleanup dokumentieren.
Validierung
- Workflow ist wiederholbar und idempotent.
- Ergebnis ist auditierbar.
- Fehler werden durch Scope, Concurrency oder Tolerance begrenzt.
- Kein Secret wird offengelegt.
- Cleanup-Ownership ist klar.
Kostenkontrolle: Für organisationsweite Dienste Designsimulation bevorzugen. Deployments klein halten und Testressourcen löschen.
Aufräumen
- Test-Stacks, Rules, Associations, Products, Documents und Rollen löschen.
- Retained Ressourcen erst nach Abhängigkeitsprüfung entfernen.
- Temporäre Logs und Artefakte nach Policy löschen.
Prüfungsfallen
- Guardrail mit Berechtigungsvergabe verwechseln.
- Eigenen Lambda-Workflow wählen, obwohl StackSets, Systems Manager, Config oder Control Tower genügen.
- Drift immer sofort überschreiben.
- Alle Konten gleichzeitig aktualisieren.
- Replacement-, Retention- oder Cleanup-Verhalten ignorieren.
Wichtigste Erkenntnisse
- Configuration Management ist kontinuierlich.
- Wiederverwendbare Standards brauchen Schnittstellen, Ownership und Versionierung.
- Organizations-Automation benötigt kontrolliertes Fehlerverhalten.
- Governance kombiniert preventive, detective und corrective Mechanismen.
Wiederholungsfragen
- Was ist der Desired State?
- Welcher Dienst oder Baustein führt aus?
- Welche Berechtigungsebenen wirken?
- Wie wird der Rollout begrenzt?
- Wie wird Drift erkannt?
- Wie werden Ausnahmen governiert?
- Was ist der Recovery-Pfad?
- Welche Nachweise belegen Erfolg?
Antworten
- Die genehmigte versionierte Konfiguration.
- Eine begrenzte Managed-Service-Rolle oder Automation.
- IAM, Resource Policies, SCPs, Permissions Boundaries und gegebenenfalls KMS.
- Über OUs, Regionen, Wellen, Concurrency und Failure Tolerance.
- Durch CloudFormation, AWS Config, Control Tower oder Zustandsvergleich.
- Mit Owner, Grund, Freigabe, Scope und Ablauf.
- Managed Change zurücksetzen, State wiederherstellen oder vorherige Version verwenden.
- Events, Compliance-Ergebnisse, Outputs, Logs und Change History.