← Cloud Infrastructure & Platform Engineering

Landing Zone & Topologie

Ein Pilotprojekt wird per Drag-and-drop von sandbox nach production verschoben — und verliert dabei ein geerbtes Recht, während zugleich strengere Standort- und Egressregeln wirksam werden. Dieses Modul zeigt, warum die Position eines Accounts, einer Subscription oder eines Projects ein laufender Steuerungsvertrag ist und wie Vending, Vererbung und Abnahme diesen Vertrag belastbar machen.

Einstieg · ~25 Min · 12 Abschnitte Einführung · 9 Übungen (davon 5 Missionen)

Modul starten →

Fortschritt wird gespeichert — du kannst das Modul später jederzeit fortsetzen.

Nur den Lehrtext lesen →

Das kannst du danach

  • ✓AWS-, Azure- und Google-Cloud-Hierarchieobjekte ihrer gemeinsamen Managementfunktion zuordnen, ohne sie technisch gleichzusetzen
  • ✓Container und Zwischenebenen nach Kontrollsatz, Ownership und Schadensradius statt nach Organigramm schneiden
  • ✓Vending und Hierarchieänderungen mit effektiver Policy, positiver und negativer Probe sowie dokumentiertem Rückweg abnehmen

Übungen

  • 1. EntscheidungEntlang welcher Linie schneidest du die neue Konten- bzw. Projektstruktur zuerst?
  • 2. EntscheidungWelcher Schnitt bildet dieses Betriebsmodell ab?
  • 3. MissionObjekte nach ihrer Hierarchierolle ordnen
  • 4. EntscheidungBekommt das Partnerportal eine eigene Grenze?
  • 5. MissionEine Landing-Zone-Bestellung vervollständigen
  • 6. DiagnoseGleiche Project-ID, anderer Vertrag
  • 7. MissionDer Plan, der Trennung nur behauptet
  • 8. ReihenfolgeVom Auftrag zur abgenommenen Workloadgrenze
  • 9. EntscheidungWie gehst du mit der Umhängung um?

Arbeitsartefakte

Quellen & Aktualität13 Primärquellen · zuletzt geprüft:
  1. 01AWS Organizations — Best practices for organizational units
  2. 02AWS Organizations — Service control policies
  3. 03AWS Control Tower — Provision accounts
  4. 04Microsoft Cloud Adoption Framework — What is an Azure landing zone
  5. 05Microsoft Cloud Adoption Framework — Management groups
  6. 06Microsoft Azure Architecture Center — Subscription vending
  7. 07Google Cloud Architecture Center — Decide a resource hierarchy
  8. 08Google Cloud Resource Manager — Move a project
  9. 09AWS: Benefits of using multiple AWS accounts — Limit scope of impact from adverse events, Distribute AWS Service Quotas and API request rate limits
  10. 10Google Cloud Architecture Center: Decide a resource hierarchy for your Google Cloud landing zone
  11. 11Microsoft Cloud Adoption Framework: Subscriptions als Verwaltungs-, Richtlinien- und Skalierungsgrenze
  12. 12docs.aws.amazon.com/controltower/latest/userguide/accounts.html
  13. 13Microsoft Cloud Adoption Framework: Management groups — Hierarchie flach halten, Policy-Zuweisung statt Abbild der Organisationsstruktur

Verfasst von Julian Zentgraf