Anwendungsfälle für AMS-Modi in der realen Welt - 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.

Anwendungsfälle für AMS-Modi in der realen Welt

Untersuchen Sie diese, um herauszufinden, wie AMS-Modi verwendet werden können.

  • Anwendungsfall 1: Geschäftliche Notwendigkeit zur Senkung der Kosten durch einen zeitkritischen Ausstieg aus dem Rechenzentrum: Ein Unternehmen mit einem wichtigen Geschäftsereignis, wie einem Ausstieg aus dem Rechenzentrum, ist daran interessiert, seine lokalen Anwendungen in der Cloud neu zu hosten. Der Großteil des lokalen Inventars besteht aus Windows- und Linux-Servern mit einer Mischung aus Betriebssystemversionen. Dabei möchte der Kunde auch die Kosteneinsparungen nutzen, die der Umstieg auf die Cloud mit sich bringt, und die technische und sicherheitstechnische Situation seiner Anwendungen verbessern. Der Kunde möchte schnell handeln, verfügt aber noch nicht über das nötige Fachwissen im Bereich Cloud-Betrieb. Der Kunde muss ein ausgewogenes Verhältnis zwischen Refactoring finden. Zu viel Refactoring kann angesichts eines engen Zeitrahmens riskant sein. Mit einigen Refaktorierungen, wie der Aktualisierung von Betriebssystemversionen und der Optimierung von Datenbanken, können Anwendungen jedoch das nächste Leistungsniveau erreichen. In diesem Beispiel kann der Kunde den AMS-verwalteten RFC-Modus wählen, um die meisten seiner Anwendungen neu zu hosten. AMS bietet den Betrieb der Infrastruktur und berät die Betriebsteams des Kunden gleichzeitig in Bezug auf bewährte Verfahren für den sicheren Betrieb in der Cloud.

    Der von AMS verwaltete AWS Service Catalog und der AMS-verwaltete Direct Change-Modus bieten dem Kunden zusätzliche Flexibilität und erreichen gleichzeitig dieselben Geschäftsergebnisse und Ziele. Darüber hinaus kann der Kunde das Angebot AMS Operations On Demand (OOD) nutzen, um über eigene AMS-Betriebstechniker zu verfügen, die die Ausführung von Änderungsanträgen priorisieren (). RFCs

    Während der Kunde die undifferenzierten betrieblichen Aufgaben der Infrastruktur (Patching, Backups, Kontoverwaltung usw.) an AMS auslagern kann, kann er sich weiterhin auf die Optimierung seiner Anwendung konzentrieren und seine internen Teams auf den Cloud-Betrieb ausweiten. AMS stellt dem Kunden monatliche Berichte über Kosteneinsparungen zur Verfügung und gibt Empfehlungen zur Ressourcenoptimierung. In diesem Anwendungsfall können end-of-life Anwendungen, die auf älteren Betriebssystemversionen wie Windows 2003 und 2008 gehostet wurden und die der Kunde nicht umgestaltet hat, auch zu AMS migriert und in einem Konto gehostet werden, das den vom Kunden verwalteten Modus nutzt.

  • Anwendungsfall 2, Aufbau eines Data Lake mit Lambda, Glue, Athena innerhalb der sicheren AMS-Grenzen: Ein Unternehmen möchte einen Data Lake einrichten, um die Berichtsanforderungen für mehrere AMS-Anwendungen zu erfüllen. Der Kunde möchte S3-Buckets für die Speicherung von Datensätzen und AWS Athena verwenden, um den Datensatz für jeden Bericht abzufragen. S3 und AWS Athena werden in separaten AMS Managed Accounts bereitgestellt. Das Konto bei S3 verfügt auch über andere Dienste wie Glue, Lambda und Step Functions zum Aufbau einer Datenerfassungspipeline. Glue, Lambda, Athena und Step Functions gelten in diesem Fall als Self-Service Provisioning (SSP) -Services. Der Kunde hat außerdem eine EC2 Instanz in dem Konto bereitgestellt, die als Ad-hoc-Server fungiert. tooling/scripting Der Kunde fordert AMS zunächst auf, die SSP-Dienste in seinem AMS-verwalteten Konto zu aktivieren. AMS stellt für jeden Service eine IAM-Rolle bereit, die der Kunde übernehmen kann, sobald die Rolle in die Verbundlösung des Kunden integriert ist. Zur Vereinfachung der Verwaltung kann der Kunde auch die Richtlinien für die einzelnen IAM-Rollen in einer benutzerdefinierten Rolle zusammenfassen, sodass beim Arbeiten zwischen den AWS-Services keine Rollen mehr gewechselt werden müssen. Sobald die Rolle im Konto aktiviert ist, kann der Kunde die Services gemäß seinen Anforderungen konfigurieren. Der Kunde muss jedoch mit dem AMS-Change-Management-System zusammenarbeiten, um je nach Anwendungsfall zusätzliche Berechtigungen anzufordern.

    Für den Zugriff auf Glue Crawlers benötigt Glue beispielsweise zusätzliche Berechtigungen. Zusätzliche Berechtigungen sind auch erforderlich, um Ereignisquellen für Lambda zu erstellen. Der Kunde wird mit AMS zusammenarbeiten, um die IAM-Rollen zu aktualisieren, sodass Athena kontenübergreifenden Zugriff hat, um S3-Buckets abzufragen. Aktualisierungen von Servicerollen oder serviceverknüpften Rollen werden ebenfalls über das AMS Change Management benötigt, damit Lambda den Step Functions Functions-Dienst aufruft, und Glue, um in alle S3-Buckets zu lesen und in sie zu schreiben. AMS arbeitet mit Kunden zusammen, um sicherzustellen, dass das Zugriffsmodell mit den geringsten Rechten eingehalten wird und die angeforderten IAM-Änderungen nicht zu freizügig sind und die Umgebung nicht unnötigen Risiken aussetzen. Das Data Lake-Team des Kunden verbringt Zeit damit, alle IAM-Berechtigungen zu planen, die für die spezifische Architektur des Kunden erforderlich sind, und bittet AMS, diese zu aktivieren. Dies liegt daran, dass alle IAM-Änderungen manuell verarbeitet und vom AMS-Sicherheitsteam überprüft werden. Die Zeit für die Bearbeitung dieser Anfragen sollte im Zeitplan für die Anwendungsbereitstellung berücksichtigt werden.

    Da die SSP-Dienste innerhalb des Accounts betriebsbereit sind, kann der Kunde über das AMS Incident Management und die Serviceanfragen Support anfordern und Probleme melden. AMS überwacht jedoch nicht aktiv die Leistungs- und Parallelitätskennzahlen für Lambda oder Job-Metriken für Glue. Es liegt in der Verantwortung des Kunden, sicherzustellen, dass für SSP-Dienste eine angemessene Protokollierung und Überwachung aktiviert ist. Die EC2 Instance und der S3-Bucket im Konto werden vollständig von AMS verwaltet.

  • Anwendungsfall 3, schnelle und flexible Einrichtung einer CICD-Bereitstellungspipeline in AMS: Ein Kunde möchte eine Jenkins-basierte CICD-Pipeline einrichten, um die Code-Pipeline für alle Anwendungskonten in AMS bereitzustellen. Für den Kunden ist es möglicherweise am geeignetsten, diese CICD-Pipeline im AMS-Managed Direct Change Mode (DCM) oder im AMS-Managed Developer-Modus zu hosten, da er so flexibel den Jenkins-Server mit der erforderlichen benutzerdefinierten Konfiguration einrichten kann EC2, mit den gewünschten IAM-Zugriffsberechtigungen CloudFormation und S3-Buckets, die das Artefakt-Repository hosten. Dies ist zwar auch im AMS-verwalteten RFC-Modus möglich, das Kundenteam müsste jedoch mehrere Handbücher RFCs für IAM-Rollen erstellen, um anhand der am wenigsten zulässigen Genehmigungen zu iterieren, die manuell von AMS überprüft werden. DCM ermöglicht es den Kunden, ihre betrieblichen Ziele auf AWS zu erreichen und gleichzeitig die Notwendigkeit zu vermeiden, mehrere Handbücher RFCs für IAM-Rollen zu erstellen, wenn der vom AMS verwaltete RFC-Modus verwendet wird, um die am wenigsten zulässigen Genehmigungen zu verwenden, die manuell von AMS überprüft werden. Dies würde sowohl Zeit als auch Schulung seitens des Kunden erfordern, um die AMS-Prozesse und -Tools auf den neuesten Stand zu bringen. Im Entwicklermodus kann der Kunde mit einer „Entwicklerrolle“ beginnen, um die Infrastruktur mithilfe von nativem AWS bereitzustellen APIs. Der schnellste und flexibelste Weg, diese Pipeline einzurichten, wäre die Verwendung des AMS Managed-Developer-Modus. Der Entwicklermodus bietet den schnellsten und einfachsten Weg, wobei er Kompromisse bei der Betriebsintegration eingeht, während DCM weniger flexibel ist, aber das gleiche Maß an Betriebsunterstützung bietet wie der RFC-Modus.

  • Anwendungsfall 4, maßgeschneidertes Betriebsmodell innerhalb der AMS-Stiftung: Ein Kunde steht vor einem terminbedingten Verlassen des Rechenzentrums und eine seiner Unternehmensanwendungen wird vollständig von einem Drittanbieter-MSP verwaltet, einschließlich Anwendungsbetrieb und Infrastrukturbetrieb. Unter der Annahme, dass der Kunde im Zeitplan keine Zeit hat, diese Anwendung so umzugestalten, dass sie von AMS betrieben werden kann, ist der Modus „Kundenverwaltung“ eine geeignete Option. Der Kunde kann die Vorteile der automatisierten und schnellen Einrichtung der von AMS verwalteten Landing Zone nutzen. Sie können die zentralisierte Kontoverwaltung nutzen, die den Verkauf und die Konnektivität der Konten über das zentrale Netzwerkkonto steuert. Es vereinfacht auch ihre Abrechnung, indem die Gebühren für alle vom Kunden verwalteten Konten über das AMS Payer-Konto konsolidiert werden. Der Kunde hat die Flexibilität, sein maßgeschneidertes Zugangsmanagementmodell einzurichten, wobei der MSP von der für AMS Managed Accounts verwendeten Standardzugriffsverwaltung getrennt ist. Auf diese Weise kann der Kunde im Modus „Kundenverwaltung“ eine von AMS verwaltete Umgebung einrichten und gleichzeitig seine Geschäftsanforderungen erfüllen, die sich aus der lokalen Umgebung ergeben. In diesem Fall ist der Kunde für die Erstellung eines Cloud-Betriebsmodells verantwortlich, wenn der Kunde auch über Windows-basierte Anwendungen verfügt, die er in die Cloud migriert, und diese in ein vom Kunden verwaltetes Konto verschieben möchte. Dies kann komplex, teuer und zeitaufwändig sein, je nachdem, ob der Kunde in der Lage ist, traditionelle IT-Prozesse zu transformieren und Mitarbeiter zu schulen. Der Kunde kann Zeit und Kosten sparen, indem er solche Workloads auf ein von AMS verwaltetes Konto überträgt und den Infrastrukturbetrieb an AMS auslagert.

    Anmerkung

    Kunden haben manchmal das Bedürfnis, Anwendungskonten zwischen dem Governance-Framework des RFC- oder SSP-Modus und dem Entwicklermodus zu verschieben. Beispielsweise können Kunden im Rahmen der ersten Lift-and-Shift-Migration eine Anwendung im AMS-verwalteten Modus hosten, möchten die Anwendung aber im Laufe der Zeit neu schreiben, um sie für Cloud-native AWS-Services zu optimieren. Sie könnten den Modus des Pre-Prod-Kontos von AMS-verwaltetem RFC in den AMS-verwalteten Entwicklermodus ändern, was ihnen die Flexibilität und Agilität für die Bereitstellung der Infrastruktur gibt. Sobald jedoch Änderungen an der Bereitstellung der Infrastruktur mithilfe der „Entwicklerrolle“ vorgenommen wurden, kann dieselbe Infrastruktur nicht mehr in den AMS-verwalteten RFC-Modus zurückversetzt werden. Dies liegt daran, dass AMS den Betrieb der Infrastruktur, die außerhalb des AMS-Change-Management-Systems bereitgestellt wurde, nicht garantieren kann. Kunden müssen möglicherweise ein neues Anwendungskonto erstellen, das den AMS-verwalteten RFC-Modus bietet, und dann die „optimierte“ Infrastrukturkonfiguration mithilfe von CloudFormation Vorlagen oder benutzerdefinierter Daten, die in ein von AMS verwaltetes Konto AMIs aufgenommen wurden, erneut bereitstellen. Dies ist eine saubere Methode, um eine produktionsbereite Konfiguration bereitzustellen. Nach der Bereitstellung unterliegt die Anwendung der vorgeschriebenen AMS-Verwaltung und dem Betrieb. Das Gleiche gilt für den Wechsel zwischen dem vom Kunden verwalteten Modus und dem AMS-verwalteten Modus.