Einzelne landing zone mit mehreren Konten im Vergleich zu landing zone mit mehreren Konten FAQs - AMS-Benutzerhandbuch für Fortgeschrittene

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Einzelne landing zone mit mehreren Konten im Vergleich zu landing zone mit mehreren Konten FAQs

Einige häufig gestellte Fragen bei der Einrichtung einer einzelnen landing zone mit mehreren Konten oder mehrerer Landezonen mit mehreren Konten:

Frage 1: Kann ich mit einer einzigen Landingzone für mehrere Konten beginnen und dann zu einer landing zone mit mehreren Konten wechseln, wenn Kontolimits oder geschäftliche Einschränkungen auftreten?

A: Ja. Sie können jederzeit eine weitere landing zone für mehrere Konten einrichten:

  • Es muss ein neues Konto für Rechnungszahler eingerichtet werden (derzeit unterstützt AWS keine Konten mit mehreren Zahlern in einer einzigen AWS-Organisation).

  • Der Aufbau der Basisbasis für mehrere Konten dauert bis zu 2 Wochen, sobald der Fragebogen zur landing zone für mehrere Konten ausgefüllt ist.

  • Jede landing zone mit mehreren Konten bedeutet zusätzliche Betriebskosten von ~3.000 USD/Monat.

  • Für die Einrichtung eines neuen MALZ ist eine Integration von N/W, AD, DNS und SSO erforderlich.

  • Alle Reserved Instances (RIs) und Kostensparpläne müssen für die neue landing zone mit mehreren Konten eingerichtet werden (RIs sind nicht übertragbar).

  • Die AMS-Landingzone mit mehreren Konten unterstützt keine Migration eines Kontos zwischen Landingzone-Konten mit mehreren Konten, z. B. zwischen AWS-Organisationen. Das Verschieben von Anwendungen von einem Konto auf ein anderes ist jedoch mithilfe von Standardmigrationsmethoden möglich.

Frage 2: Welchen Ansatz verfolgt AMS gegenüber MALZ in Bezug updates/changes auf underlying/shared Infrastruktur und Quantifizierung des Risikos für Kunden? Geben Sie detailliert an, welche Zusicherungen im Prozess enthalten sind. Wie können sich Kunden darauf verlassen, dass MALZ keine Auswirkungen auf updates/changes die Kunden hat? Gibt es Maßnahmen, die der Kunde ergreifen muss, um Störungen zu verhindern?

A: AMS folgt einer strikten Änderungsmethodik und verwendet interne Tools, die es uns ermöglichen, Änderungen an den Kundenumgebungen zu definieren, zu überprüfen, zu planen und durchzuführen.

Der Prozess zur Veröffentlichung von Updates setzt Code-Reviews, Integrationstests, die Bereitstellung in Gamma- und Beta-Umgebungen sowie zusätzliche Backzeit und Tests in Beta- und Gamma-Umgebungen vor der Veröffentlichung in Kundenumgebungen durch. Alle Versionen beinhalten Rollback-Verfahren und werden vom Release-Team und dem Team, das die Änderung erstellt und angefordert hat, genau überwacht. Der Umfang der Releases beschränkt sich auf Stacks, die AMS gehören und von AMS bereitgestellt werden. Im Durchschnitt führen wir mindestens eine Veröffentlichung pro Woche durch.

Darüber hinaus gilt:

  • AMS SLA sind anwendbar. Gemäß der AMS-Servicebeschreibung unterliegt jeder Vorfall, der nach einer gemeinsamen Wartung der Infrastruktur auftritt, der entsprechenden Vereinbarung zur Lösung oder Gutschrift.

  • Kunden benötigen keine besonderen Präventivmaßnahmen, um Störungen der gemeinsamen Infrastruktur zu verhindern. Kunden haben nur Leseberechtigungen für AWS Org- oder Core OU-Konten, sodass Kunden keine zerstörerischen Änderungen an der MALZ-Kernumgebung vornehmen können. Alle Kundenanfragen an die Core-Infrastruktur müssen von AMS geprüft und genehmigt werden.

  • Kunden können bestimmte Änderungen auf Organisationsebene testen, z. B. SCPs/Roles auf Ebene einzelner Konten, die keine Produkte sind, bevor sie Änderungen auf Ebene der App-Organisationseinheit weitergeben. Es steht auf der AMS-Roadmap, mehrere Apps zuzulassen OUs (Q2 2020), wodurch das Risiko einiger Änderungen auf ORGANISATIONSEBENE weiter verringert würde. Das MALZ-Team hat bereits eine separate Organisationseinheit für Konten im „Build-Modus“ veröffentlicht, um eine klare Trennung der Kundenrechte und separate Kontrollen zu gewährleisten.

  • Bei den meisten dieser Änderungen handelt es sich um Änderungen, die es AMS ermöglichen, die Arbeitslast effektiv und effizient zu verwalten, ohne dass sie sich unbedingt auf die Arbeitslast der Kunden auswirken. Wenn AMS der Ansicht ist, dass eine Änderung der gemeinsamen Infrastruktur Auswirkungen auf die Arbeitslast der Kunden haben kann, werden sie dann auf das Änderungsfenster der Kunden abgestimmt.

Allgemeine Empfehlung: Beginnen Sie mit mehreren Landezonen für mehrere Konten, wenn:

  • Wenn es Ihnen hilft, eine bestimmte Konformität zu erreichen.

  • Wenn Sie Multi-Region verwenden müssen.

  • Wenn Sie unterschiedliche lokale Workloads ADs und Netzwerke für Workloads und für externe Prod/Material Workloads haben. Prod/Non-Material workloads, to clearly segregate b/w