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 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 | Planung ä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 | ||
| Vorfall- 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 aufgrund der strengeren AMS-Richtlinien in diesem Modus möglicherweise die geeignetere Option. Die Schutzmaßnahmen werden in Form von präventiven Kontrollen wie der RFC-basierten Änderungssteuerung für IAM-Updates und auf der Ebene der Anwendungs-OU durchgesetzt. SCPs 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 diesen Konten erstellt wurden, OUs unterliegt dem spezifischen AMS-Modus, der von diesen Basiskonten angeboten wird. OUs Es ist üblich, in demselben Anwendungskonto eine Mischung aus zwei oder mehr Modi vorzufinden. 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 S3 und SQS für EC2 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 in der Grundversion von AMS angeboten werden. OUs 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 Grundlagen, die auf den bewährten Methoden von AWS OUs basieren, um Konten mithilfe von Service Control Policies () logisch zu verwalten. SCPs Auf diese Weise kann das Governance-Framework in jedem AMS-Modus durchgesetzt werden. Alle Governance- und Sicherheitsvorkehrungen (in Form von SCPs), die auf das Fundament angewendet werden, werden automatisch OUs auch auf das Fundament angewendet. custom/child OUs Zusätzliche SCPs können für das Kind angefordert werden. OUs 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 für diese Programme benutzerdefinierte Richtlinien anfordern können. Diese werden von AMS genehmigt OUs, damit sichergestellt ist, dass sie die Fähigkeit von AMS, optimale Betriebsabläufe zu gewährleisten, nicht beeinträchtigen. case-by-case Eine ausführliche Liste der AMS-Leitplanken finden Sie unter AMS Guardrails im Benutzerhandbuch.
