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.
Arten von Modi und Konten in AMS
Die Modi von AWS Managed Services (AMS) können als die Art und Weise der Interaktion mit dem AMS-Service im Rahmen des spezifischen Governance-Frameworks für jeden Modus definiert werden. Die Unterschiede zwischen der landing zone, der landing zone mit mehreren Konten oder MALZ und der landing zone mit einem Konto oder SALZ, werden notiert.
Anmerkung
Einzelheiten zur Anwendungsbereitstellung und zur Auswahl des richtigen AMS-Modus finden Sie unter AMS-Modi und Anwendungen oder Workloads.
Praxisnahe Anwendungsfälle der verschiedenen Modi finden Sie unter Anwendungsfälle aus der Praxis für AMS-Modi
Die folgende Tabelle enthält Beschreibungen der Modi pro AMS-Dienst.
| AMS-Funktion | RFC-Modus (früher Standard-CM-Modus)/OOD * | Direkter Änderungsmodus | AWS Service Catalog | Self-service Bereitstellung/Entwicklermodus | Vom Kunden verwaltet |
|---|---|---|---|---|---|
| Konfiguration der Landezone | MALZ und SALZ | MALZ und SALZ | MALZ und SALZ | ||
| Änderungsmanagement | Terminplanung ändern, manuelle Änderungen überprüfen und Datensatz ändern | Entspricht dem RFC-Modus für Änderungen mit hohem Risiko wie IAM oder Sicherheitsgruppen | Keine | ||
| Protokollierung, Überwachung, Guardrails und Eventmanagement | Ja (unterstützte Ressourcen) | Nein | |||
| Kontinuitätsmanagement | Ja (unterstützte Ressourcen) | Nicht zutreffend/Nein | Nein | ||
| Sicherheitsmanagement | Sicherheitskontrollen auf Instanzebene und Kontrollen auf Kontoebene | Kontrollen auf Kontoebene | Kontrollen auf AWS-Organisationsebene | ||
| Patch-Management | Ja | Nicht zutreffend//Nein | Nein | ||
| Vorfalls- und Problemmanagement | SLA für Reaktion und Lösung für Ressourcen, die von AMS unterstützt werden | Antwort-SLA für die daraus resultierenden Ressourcen | Nein | ||
| Berichterstellung | Ja | Nein | |||
| Verwaltung von Serviceanfragen | Ja | Nur Support-Anfragen | Nein | ||
* Operations On Demand (OOD) bietet ein Angebot für Kunden, die den RFC-Modus verwenden, um ihre Änderungen mithilfe spezieller Ressourcen zu verwalten. Weitere Informationen finden Sie im Angebotskatalog für Operations on Demand und wenden Sie sich an Ihren Cloud Service Delivery Manager (CSDM).
Anmerkung
Self-Service-Bereitstellungsmodus in AMSund beide AMS Advanced-Entwicklermodus scheinen für eine Anwendung geeignet zu sein, deren komplexe Architektur auf nativen AWS-Services basiert. Bei der Architektur von Workloads gehen Sie je nach Ihrem Geschäftskontext Kompromisse zwischen betrieblicher Exzellenz und Agilität ein. Dies ist eine gute Möglichkeit, über die Auswahl des SSP-Modus oder des Entwicklermodus für Ihre Anwendung nachzudenken. Die Auswahl kann sich auch je nach der SDLC-Phase der Anwendung ändern. Beispiel: Wenn die Anwendung produktionsbereit ist, ist der SSP-Modus möglicherweise die geeignetere Option, da in diesem Modus strengere AMS-Richtlinien gelten. Die Schutzmaßnahmen werden in Form von präventiven Kontrollen wie der RFC-based Änderungskontrolle für IAM-Updates und SCPs auf der Ebene der Anwendungs-OU durchgesetzt. Diese Geschäftsentscheidungen können Ihre technischen Prioritäten beeinflussen. Sie könnten eine Optimierung vornehmen, um die Flexibilität der Anwendungseigentümer in der „Pre-Prod“ -Phase zu erhöhen, auf Kosten der Verwaltung und des betrieblichen Supports.
MALZ-Architektur und zugehörige AMS-Modi
Die AMS Multi-Account-Landing Zone (MALZ) bietet Ihnen die Möglichkeit, Anwendungskonten (oder Ressourcenkonten) automatisch unter den standardmäßigen Organisationseinheiten (OU) bereitzustellen: vom Kunden verwaltete OU, Managed OU oder Development OU. Die Infrastruktur, die in den Anwendungskonten bereitgestellt wird, die unter jeder dieser Organisationseinheiten erstellt wurden, unterliegt dem spezifischen AMS-Modus, der von diesen grundlegenden Organisationseinheiten angeboten wird. Es ist üblich, dass ein und dasselbe Anwendungskonto eine Mischung aus zwei oder mehr Modi enthält. Beispiel: RFC-Modus und SSP-Modus können in einem AMS-verwalteten Konto koexistieren, das eine Pipeline-Architektur hostet, die aus API Gateway und Lambda für Triggerfunktionen und EC2, S3 und SQS für Aufnahme und Orchestrierung besteht. In diesem Fall würde der SSP-Modus für Lambda und API Gateway gelten.
Abbildung 1 zeigt, wie verschiedene Modi über die grundlegenden Organisationseinheiten in AMS angeboten werden. Wenn Sie in AMS ein neues Anwendungskonto beantragen, müssen Sie die Organisationseinheit für das Konto auswählen.
MALZ-Architektur und zugehörige AMS-Modi
.png)
AMS nutzt die grundlegenden OUs, die auf den bewährten Methoden von AWS basieren, um Konten mithilfe von Service Control Policies (SCPs) logisch zu verwalten. Auf diese Weise kann das Governance-Framework in jedem AMS-Modus durchgesetzt werden. Alle Governance- und Sicherheitsvorkehrungen (in Form von SCPs), die auf die grundlegenden Organisationseinheiten angewendet werden, werden automatisch auch auf die Organisationseinheiten angewendet. custom/child Zusätzliche SCPs können für die untergeordneten Organisationseinheiten angefordert werden. Es ist wichtig zu verstehen, dass Anwendungskonten nicht dasselbe sind wie Modi. Modi werden auf die innerhalb der Konten bereitgestellte Infrastruktur angewendet und definieren die betrieblichen Verantwortlichkeiten zwischen AMS und den Kunden.
Abbildung 1: MALZ-Architektur und zugehörige AMS-Modi
Anmerkung
„Restriktiv“ bedeutet, dass Sie benutzerdefinierte Richtlinien für diese Organisationseinheiten anfordern können. Diese werden von AMS von Fall zu Fall genehmigt, um sicherzustellen, dass sie die Fähigkeit von AMS, operative Exzellenz zu gewährleisten, nicht beeinträchtigen. Eine ausführliche Liste der AMS-Guardrails finden Sie unter AMS Guardrails im Benutzerhandbuch.
