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. # Priorisierte Bewertung von Bewerbungen Eines der wichtigsten Ergebnisse der vorherigen Phase, der [Portfoliofindung und der ersten Planung, bestand darin](portfolio-discovery-initial-planning.md), [einer Teilmenge von Anwendungen für eine detaillierte Bewertung Priorität einzuräumen](prioritization-and-migration-strategy.md#prioritizing-applications). In diesem Abschnitt wird die detaillierte Bewertung von Anträgen untersucht. Wenn Sie sich frühzeitig die Details einiger Anwendungen ansehen, wird dies zu einer Beschleunigung führen. Der Prozess der Bewertung und des zukünftigen Architekturentwurfs deckt potenzielle Hindernisse auf und klärt wichtige Aufgaben, die der Migration in größerem Umfang vorausgehen. Zu diesen Aufgaben gehören die Erfassung von Anforderungen für die Errichtung von AWS Fundamenten, z. B. der landing zone AWS, oder die Erweiterung und Validierung der bestehenden landing zone. Diese Bewertung ist auch der richtige Zeitpunkt, um die Schritte und die Strategie für die Migration zu erörtern. Die wichtigsten Ergebnisse dieser Phase sind die folgenden: + Validierte Liste der priorisierten Anwendungen + Dokumentierte Architektur mit aktuellem Status + Dokumentierte anfängliche Zielarchitektur und Migrationsstrategie für Migrationskandidaten + Identifizierte Migrationsmuster und Tools + Dokumentierte Plattformanforderungen (Sicherheit, AWS Infrastruktur und Betrieb) + Dokumentierte Überlegungen zur Umstellung bei der Migrationsplanung + Geschätzte AWS Ausführungsrate # Grundlegendes zu den Anforderungen an die detaillierten Bewertungsdaten In der folgenden Tabelle werden die Informationen beschrieben, die erforderlich sind, um einen vollständigen Überblick über das Portfolio der migrierten Anwendungen und der zugehörigen Infrastruktur zu erhalten. In den Tabellen werden die folgenden Abkürzungen verwendet: + R, für erforderlich + O, für optional + N/A, für nicht zutreffend **Anwendungen** | **Attributname** | **Beschreibung** | **Entdeckungs-, Design- und Migrationsstrategie** | **Geschätzte Ausführungsrate** | **Empfohlene Treuestufe (mindestens)** | | --- |--- |--- |--- |--- | | Eindeutige Kennung | Zum Beispiel Anwendungs-ID. In der Regel in bestehenden CMDBs oder anderen internen Inventaren und Kontrollsystemen verfügbar. Erwägen Sie die Erstellung einzigartiger IDs Produkte, wann immer diese in Ihrer Organisation nicht definiert sind. | R | O | Hoch | | Anwendungsname | Name, unter dem diese Anwendung Ihrer Organisation bekannt ist. Geben Sie gegebenenfalls den Handelsnamen off-the-shelf (COTS) und den Produktnamen an. | R | R | Hoch | | Ist COTS? | Ja oder Nein. Ob es sich um eine kommerzielle Anwendung oder eine interne Entwicklung handelt | R | R | Hoch | | COTS-Produkt und Version | Name und Version des kommerziellen Softwareprodukts | R | R | Hoch | | Description | Primäre Anwendungsfunktion und Kontext | R | O | Hoch | | Kritikalität | Zum Beispiel eine strategische oder umsatzgenerierende Anwendung oder die Unterstützung einer wichtigen Funktion | R | O | Hoch | | Typ | Zum Beispiel Datenbank, Kundenbeziehungsmanagement (CRM), Webanwendung, Multimedia, gemeinsam genutzter IT-Service | R | O | Hoch | | Umgebung | Zum Beispiel Produktion, Vorproduktion, Entwicklung, Test, Sandbox | R | R | Hoch | | Einhaltung gesetzlicher Vorschriften und Vorschriften | Für den Workload geltende Frameworks (z. B. HIPAA, SOX, PCI-DSS, ISO, SOC, FedRAMP) und regulatorische Anforderungen | R | O | Hoch | | Abhängigkeiten | Upstream- und Downstream-Abhängigkeiten zu internen und externen Anwendungen oder Diensten | R | – | Hoch | | Abbildung der Infrastruktur | Zuordnung zu physischen and/or virtuellen Ressourcen, aus denen die Anwendung besteht | R | R | Hoch | | License | Lizenztyp für Standardsoftware (z. B. Microsoft SQL Server Enterprise) | R | R | Hoch | | Cost (Kosten) | Kosten für Softwarelizenzen, Softwarebetrieb und Wartung | – | R | Mittel-Hoch | | Geschäftseinheit | Zum Beispiel Marketing, Finanzen, Vertrieb | R | O | Hoch | | Angaben zum Eigentümer | Kontaktinformationen für den Inhaber der Anwendung | R | O | Hoch | | Art der Architektur | Zum Beispiel Webanwendung, zweistufig, dreistufig, Microservices, serviceorientierte Architektur (SOA) | R | R | Hoch | | Recovery Point Objective (RPO), Recovery Time Objective (RTO) und /Service Level Agreement (SLA) | Aktuelle Servicemanagement-Attribute | R | R | Hoch | | Umsatzgenerierende Anwendung oder geschäftsstrategische Anwendung? | Ja, wenn die Anwendung direkt oder indirekt den Umsatz des Unternehmens beeinflusst oder vom Unternehmen als strategisch angesehen wird. | R | O | Mittel-Hoch | | Anzahl der Benutzer (gleichzeitig) | Zum Beispiel interne oder externe Benutzer oder interne and/or externe Benutzer/Kunden | R | R | Mittel-Hoch | | User location (Benutzerstandort) | Herkunft der Benutzersitzungen | R | R | Mittel-Hoch | | Risiken und Probleme | Bekannte Risiken und Probleme | R | O | Mittel-Hoch | | Überlegungen zur Migration | Alle zusätzlichen Informationen, die für die Migration relevant sein könnten | R | R | Mittel-Hoch | | Migrationsstrategie | Zum Beispiel einer der AWS 6 Rs für Migration | R | R | Mittel-Hoch | | Angaben zur Datenbank | Zum Beispiel Partitionierung, Verschlüsselung, Replikation, Erweiterungen, Secure Sockets Layer (SSL) -Unterstützung | R | R | Hoch | | Unterstützungsteams | Zum Beispiel der Name des Teams für den Anwendungsbetrieb | R | O | Mittel-Hoch | | Lösung zur Überwachung | Produkt, das zur Überwachung dieser Anwendung verwendet wurde | R | O | Mittel-Hoch | | Backup-Anforderungen | Erforderlicher Backup-Zeitplan in AWS | R | R | Mittel-Hoch | | DR-Informationen | Zum Beispiel Disaster Recovery-Komponenten für diese Anwendung | R | R | Mittel-Hoch | | AWS Zielanforderungen | Zum Beispiel Komponenten, Kontoplatzierung, Netzwerke, Sicherheit | R | R | Hoch | **Infrastruktur** | | | | | | | --- |--- |--- |--- |--- | | **Name des Attributs** | **Beschreibung** | **Entdeckungs-, Entwurfs- und Migrationsstrategie** | **Geschätzte Ausführungsrate** | **Empfohlene Treuestufe (mindestens)** | | Eindeutige Kennung | Zum Beispiel Server-ID. In der Regel in bestehenden CMDBs oder anderen internen Inventar- und Kontrollsystemen verfügbar. Ziehen Sie es in Betracht IDs, einzigartige Produkte zu erstellen, wann immer diese in Ihrer Organisation nicht definiert sind. | R | O | Hoch | | Name des Netzwerks | Assetname im Netzwerk (z. B. Hostname) | R | O | Hoch | | DNS-Name (vollqualifizierter Domänenname oder FQDN) | DNS-Name | O | O | Mittel-Hoch | | IP-Adresse und Netzmaske | Interne and/or öffentliche IP-Adressen | R | R | Hoch | | Asset type (Objekttyp) | Zum Beispiel physischer oder virtueller Server, Hypervisor, Container, Gerät, Datenbankinstanz | R | R | Hoch | | Product Name (Produktname) | Kommerzieller Anbieter und Produktname (z. B. IBM Power Systems VMware ESXi, Exadata) | R | R | Hoch | | Betriebssystem | Zum Beispiel REHL 8, Windows Server 2019, AIX 6.1 | R | R | Hoch | | Konfiguration | Zugewiesene CPU, Anzahl der Kerne, Threads pro Kern, Gesamtspeicher, Netzwerkkarten | R | R | Hoch | | Nutzung | Spitzenwert und Durchschnitt von CPU, Arbeitsspeicher und Speicher. Durchsatz der Datenbankinstanz. | R | R | Hoch | | License | Art der Warenlizenz (z. B. RHEL Standard) | R | R | Hoch | | Ist eine gemeinsam genutzte Infrastruktur? | Ja oder Nein, um Infrastrukturdienste zu bezeichnen, die gemeinsam genutzte Dienste wie Authentifizierungsanbieter, Überwachungssysteme, Backup-Dienste und ähnliche Dienste bereitstellen | R | O | Hoch | | Zuordnung von Anwendungen | Anwendungen oder Anwendungskomponenten, die in dieser Infrastruktur ausgeführt werden | R | O | Hoch | | Kommunikationsdaten | Zum Beispiel Server zu Server auf Prozessebene | R | – | Mittel-Hoch | | AWS Zielanforderungen | Zum Beispiel Instanztypen, Konten, Subnetze, Sicherheitsgruppen, Routing | R | R | Hoch | | Migrationsstrategie, Muster und Tools | Zum Beispiel eines der 6 Rs für Migration, spezifisches technisches Muster, Migrationstools | R | O | Hoch | | Risiken und Probleme | Bekannte Risiken und Probleme | R | O | Mittel-Hoch | # Detaillierte Bewertung des Antrags Ziel einer detaillierten Anwendungsbeurteilung ist das vollständige Verständnis der Zielanwendung und der zugehörigen Infrastruktur (Rechenleistung, Speicher und Netzwerk). Daten mit hoher Genauigkeit sind erforderlich, um Fallstricke zu vermeiden. Beispielsweise gehen Unternehmen häufig davon aus, dass sie die Anwendung vollständig verstehen. Das ist natürlich und in vielen Fällen auch wahr. Um das Risiko für das Unternehmen zu minimieren, ist es jedoch wichtig, institutionelles Wissen und statische Unterlagen zu validieren, indem so viele programmatische Daten wie möglich abgerufen werden. Auf diese Weise wird der Forschungsprozess erheblich erleichtert. Sie können sich auf die Datenelemente konzentrieren, die aus alternativen Quellen stammen, z. B. geschäftsspezifische Informationen, strategische Roadmaps und andere. Der Schlüssel liegt darin, Änderungen in letzter Minute während und nach der Migration zu vermeiden. Bei der Migration ist es beispielsweise wichtig, Änderungen zu vermeiden, die auf unbekannten Abhängigkeiten beruhen und die Einbeziehung eines Servers in eine laufende Migrationswelle erfordern könnten. Kurz nach der Migration ist es wichtig, Änderungen aufgrund der damit verbundenen Plattformanforderungen zu vermeiden, um Datenverkehr zuzulassen oder zusätzliche Dienste bereitzustellen. Solche ungeplanten Änderungen erhöhen das Risiko von Sicherheits- und Betriebsproblemen. Wir empfehlen dringend, bei der Durchführung detaillierter Anwendungsbewertungen Tools zur programmatischen Erkennung zu verwenden, um Datenverkehrsmuster und Abhängigkeiten zu überprüfen. Zu Beginn der Bewertung müssen Sie die Stakeholder der Anwendung identifizieren. In der Regel handelt es sich dabei um die folgenden: + Leiter der Geschäftseinheit + Inhaber der Anwendung + Architekten + Betrieb und Support + Teams für Cloud-Unterstützung + Spezifische Plattformteams wie Computer-, Speicher- und Netzwerkteams Es gibt zwei Ansätze für eine detaillierte Entdeckung. Die Top-down-Erkennung beginnt bei der Anwendung oder sogar beim Benutzer und reicht bis hinunter zur Infrastruktur. Dies ist der empfohlene Ansatz, wenn die Identifizierung der Anwendung eindeutig ist. Umgekehrt beginnt die Erkennung von unten nach oben bei der Infrastruktur und reicht bis hin zur Anwendung oder dem Dienst und seinen Benutzern. Dieser Ansatz ist nützlich, wenn Migrationsprogramme von Infrastrukturteams geleitet werden und wenn die application-to-infrastructure Zuordnung unklar ist. Im Allgemeinen werden Sie wahrscheinlich eine Kombination aus beidem verwenden. Um tief in eine Anwendung einzutauchen, sind bestehende Architekturdiagramme ein guter Anfang. Wenn diese nicht verfügbar sind, erstellen Sie eines, das auf dem aktuellen Wissensstand basiert. Unterschätzen Sie nicht die Bedeutung dieser Aufgabe, auch nicht für einfache Strategien zur Umstellung oder Verlagerung von Standorten. Das Plotten von Architekturdiagrammen hilft Ihnen dabei, Ineffizienzen zu identifizieren, die in der Cloud mit geringfügigen Änderungen schnell behoben werden können. Je nachdem, ob Sie einen Top-down- oder Bottom-up-Ansatz verfolgen, werden im ersten Diagramm Anwendungskomponenten und Dienste oder Infrastrukturkomponenten wie Server und Load Balancer dargestellt. Nachdem die Hauptkomponenten und Schnittstellen identifiziert wurden, validieren Sie sie mit programmgesteuerten Daten aus Erkennungstools und Tools zur Überwachung der Anwendungsleistung. Die Tools müssen die Abhängigkeitsanalyse unterstützen und Kommunikationsinformationen zwischen den Komponenten bereitstellen. Jede Komponente, aus der diese Anwendung besteht, muss identifiziert werden. Dokumentieren Sie als Nächstes Abhängigkeiten zu anderen internen und externen Anwendungen und Diensten. In Ermangelung von Tools zur Validierung von Abhängigkeiten und Zuordnungen ist ein manueller Ansatz erforderlich. Sie können sich beispielsweise bei Infrastrukturkomponenten anmelden und Skripts ausführen, um Kommunikationsinformationen wie offene Ports und hergestellte Verbindungen zu sammeln. Ebenso können Sie laufende Prozesse und installierte Software identifizieren. Unterschätzen Sie nicht den Aufwand, der für die manuelle Erkennung erforderlich ist. Mit programmatischen Tools können die meisten Abhängigkeiten innerhalb weniger Tage erfasst und gemeldet werden, mit Ausnahme derjenigen, die in größeren Intervallen auftreten (in der Regel ein kleiner Prozentsatz). Die manuelle Erkennung kann Wochen in Anspruch nehmen, um alle Datenpunkte zu sammeln und zusammenzuführen, und es kann immer noch anfällig für Fehler und fehlende Daten sein. Fahren Sie fort, um die im Abschnitt mit den [Datenanforderungen](understanding-detailed-assessment-data-requirements.md) angegebenen Informationen für jede priorisierte Anwendung und die zugeordnete Infrastruktur abzurufen. Verwenden Sie anschließend den folgenden Fragebogen, der Sie durch den detaillierten Bewertungsprozess führt. Treffen Sie sich mit den identifizierten Stakeholdern, um die Antworten auf diese Fragen zu besprechen. ## General + Wie hoch ist der Kritikalitätsgrad dieser Anwendung? Generiert sie Einnahmen? Handelt es sich um eine geschäftsstrategische oder unterstützende Geschäftsanwendung? Handelt es sich um einen zentralen Infrastrukturdienst, der von anderen Systemen gemeinsam genutzt wird? + Gibt es ein laufendes Transformationsprojekt für diese Anwendung? + Handelt es sich um eine intern oder extern ausgerichtete Anwendung? ## Architektur + Was ist der aktuelle Architekturtyp (z. B. SOA, Microservices, Monolith)? Wie viele Stufen hat die Architektur? Ist sie fest oder lose gekoppelt? + Was sind die Komponenten (z. B. Rechenleistung, Datenbanken, Remotespeicher, Load Balancer, Caching-Dienste)? + Was sind die APIs? Beschreiben Sie diese, einschließlich API-Namen, Operationen URLs, Ports und Protokolle. + Was ist die maximale Latenz, die zwischen Komponenten und zwischen diesen und anderen Anwendungen oder Diensten toleriert wird? ## Operationen + An welchen Standorten wird diese Anwendung betrieben? + Wer betreibt die Anwendung und die Infrastruktur? Werden diese von internen Teams oder von AWS Partnerteams betrieben? + Was passiert, wenn diese Anwendung ausfällt? Wer ist betroffen? Was sind die Auswirkungen? + Wo befinden sich Benutzer oder Kunden? Wie greifen sie auf die Anwendung zu? Wie hoch ist die Anzahl der gleichzeitigen Benutzer? + Wann fand die letzte Technologie-Aktualisierung statt? Ist in future eine Aktualisierung geplant? Wenn ja, wann? + Was sind die bekannten Risiken und Probleme bei dieser Anwendung? Was ist die Geschichte von Ausfällen und Zwischenfällen mittlerer und hoher Schwere? + Was ist der Nutzungszyklus (in Geschäftszeiten)? Was ist die Betriebszeitzone? + Was sind die Sperrfristen für Änderungen? + Welche Lösung wird zur Überwachung dieser Anwendung verwendet? ## Leistung + Was zeigen die gesammelten Leistungsinformationen? Ist die Nutzung stark oder konstant und vorhersehbar? Was ist der Zeitrahmen, das Intervall und das Datum der verfügbaren Leistungsdaten? + Gibt es geplante Batch-Jobs, die Teil dieser Anwendung sind oder mit dieser interagieren? ## Lebenszyklus der Software + Wie hoch ist die aktuelle Änderungsrate (wöchentlich, monatlich, vierteljährlich oder jährlich)? + Was ist der Entwicklungszyklus (z. B. Test, Entwicklung, Qualitätssicherung, UAT, Vorproduktion, Produktion)? + Was sind die Bereitstellungsmethoden für Anwendung und Infrastruktur? + Was sind die Bereitstellungstools? + Nutzt diese Anwendung oder Infrastruktur Continuous Integration (CI) /Continuous Delivery (CD)? Wie hoch ist der Automatisierungsgrad? Was sind die manuellen Aufgaben? + Was sind die Lizenzanforderungen für die Anwendung und die Infrastruktur? + Was ist das Service Level Agreement (SLA)? + Was sind die aktuellen Testmechanismen? Was sind die Testphasen? ## Migration + Was sind die Überlegungen zur Migration? Beachten Sie an dieser Stelle alle Überlegungen, die bei der Migration dieser Anwendung zu beachten sind. Für eine vollständigere und genauere Bewertung holen Sie sich Antworten auf diese Frage von den verschiedenen Interessenträgern ein. Stellen Sie dann ihr Wissen und ihre Meinungen gegenüber. ## Ausfallsicherheit + Was ist die aktuelle Backup-Methode? Welche Produkte werden für Backups verwendet? Was ist der Backup-Zeitplan? Was ist die Richtlinie zur Aufbewahrung von Backups? + Was sind das aktuelle Recovery Point Objective (RPO) und Recovery Time Objective (RTO)? + Verfügt diese Anwendung über einen Disaster-Recovery-Plan (DR)? Wenn ja, was ist die DR-Lösung? + Wann war der letzte DR-Test? ## Sicherheit und Compliance + Welche Compliance- und regulatorischen Rahmenbedingungen gelten für diese Anwendung? Was sind die letzten und nächsten Prüfungstermine? + Hostet diese Anwendung sensible Daten? Was ist die Datenklassifizierung? + Werden die Daten während der Übertragung oder im Ruhezustand oder beides verschlüsselt? Was ist der Verschlüsselungsmechanismus? + Verwendet diese Anwendung SSL-Zertifikate? Was ist die ausstellende Behörde? + Was ist die Authentifizierungsmethode für Benutzer, Komponenten und andere Anwendungen und Dienste? ## Datenbanken + Welche Datenbanken verwendet diese Anwendung? + Was ist die typische Anzahl gleichzeitiger Verbindungen zur Datenbank? Was sind die minimale und maximale Anzahl von Verbindungen? + Was ist die Verbindungsmethode (zum Beispiel JDBC, ODBC)? + Sind Verbindungszeichenfolgen dokumentiert? Wenn ja, wo? + Was sind die Datenbankschemas? + Verwendet die Datenbank benutzerdefinierte Datentypen? ## Abhängigkeiten + Was ist die Abhängigkeit zwischen Komponenten? Beachten Sie alle Abhängigkeiten, die nicht aufgelöst werden können und für die eine gemeinsame Migration der Komponenten erforderlich ist. + Sind die Komponenten auf mehrere Standorte aufgeteilt? Wie ist die Konnektivität zwischen diesen Standorten (z. B. WAN, VPN)? + Was sind die Abhängigkeiten dieser Anwendung von anderen Anwendungen oder Diensten? + Was sind die betrieblichen Abhängigkeiten? Zum Beispiel Wartungs- und Release-Zyklen wie das Patchen von Fenstern. # AWS Anwendungsdesign und Migrationsstrategie Das Entwerfen und Dokumentieren des future Zustands Ihrer Anwendung ist ein wichtiger Erfolgsfaktor für die Migration. Wir empfehlen, ein Design für jede Art von Migrationsstrategie zu erstellen, unabhängig davon, wie einfach oder komplex sie ist. Bei der Erstellung des Designs werden potenzielle Hindernisse, Abhängigkeiten und Möglichkeiten zur Optimierung der Anwendung selbst in Fällen aufgedeckt, in denen keine Änderung der Architektur zu erwarten ist. Wir empfehlen außerdem, den future Status der Anwendung unter Berücksichtigung AWS einer Migrationsstrategie zu betrachten. Stellen Sie zu diesem Zeitpunkt sicher, dass Sie definieren, wie die Anwendung AWS als Ergebnis dieser Migration aussehen wird. Das daraus resultierende Design wird als Grundlage für die weitere Entwicklung nach der Migration dienen. Die folgende Liste enthält Ressourcen zur Unterstützung des Entwurfsprozesses: + [AWS Das Architecture Center](https://aws.amazon.com/architecture/) kombiniert Tools und Anleitungen wie das AWS Well-Architected Framework. Außerdem bietet es Referenzarchitekturen, die Sie für Ihre Anwendung verwenden können. + [Die Amazon Builders' Library](https://aws.amazon.com/builders-library/) enthält mehrere Ressourcen darüber, wie Amazon Software entwickelt und betreibt. + AWS Die [Solutions Library](https://aws.amazon.com/solutions/) bietet eine Sammlung von Cloud-basierten Lösungen, die von uns geprüft wurden AWS, für Dutzende von technischen und geschäftlichen Problemen. Sie umfasst eine große Sammlung von Referenzarchitekturen. + [AWS Prescriptive Guidance](https://aws.amazon.com/prescriptive-guidance/) bietet Strategien, Leitfäden und Muster, die den Entwurfsprozess und bewährte Verfahren für die Migration unterstützen. + [AWS Documentation](https://docs.aws.amazon.com/)enthält Informationen zu AWS Diensten, einschließlich Benutzerhandbüchern und API-Referenzen. + Das [Ressourcencenter für die ersten Schritte](https://aws.amazon.com/getting-started/) bietet mehrere praktische Tutorials und ausführliche Informationen zum Erlernen der Grundlagen, sodass Sie sofort darauf aufbauen können. AWS Je nachdem, wo Sie sich auf dem Weg zur Cloud befinden, gibt es möglicherweise bereits AWS Grundlagen. Zu diesen AWS Grundlagen gehören die folgenden: + AWS-Regionen wurden identifiziert. + Konten wurden erstellt oder können auf Anfrage angefordert werden. + Allgemeine Netzwerke wurden implementiert. + Innerhalb der Konten wurden grundlegende AWS Dienste bereitgestellt. Umgekehrt befinden Sie sich möglicherweise noch in einem frühen Stadium des Prozesses, und die AWS Grundlagen sind noch nicht geschaffen. Ein Mangel an fundierten Grundlagen könnte den Umfang Ihres Anwendungsentwurfs einschränken oder weitere Arbeiten zu deren Definition erfordern. In diesem Fall empfehlen wir, das grundlegende Design der landing zone parallel zum Anwendungsdesign zu definieren und umzusetzen. Das Anwendungsdesign hilft dabei, Anforderungen wie AWS-Konto Struktur, Netzwerk, virtuelle private Cloud (VPCs), Classless Inter-Domain Routing (CIDR) -Bereiche, gemeinsame Dienste, Sicherheit und Cloud-Betrieb zu identifizieren. [AWS Control Tower](https://aws.amazon.com/controltower/)bietet die einfachste Möglichkeit, eine sichere AWS Umgebung mit mehreren Konten einzurichten und zu verwalten, die als landing zone bezeichnet wird. AWS Control Tower erstellt Ihre landing zone mithilfe AWS Organizations, die eine kontinuierliche Kontoverwaltung und -steuerung sowie die Implementierung von AWS Best Practices auf der Grundlage von Erfahrungen mit Tausenden von Kunden bei der Umstellung auf die Cloud bietet. ## future Status der Anwendung Legen Sie zunächst die anfängliche Migrationsstrategie für diese Anwendung fest. Zum jetzigen Zeitpunkt gilt die Strategie als initiativ, da sie sich im Rahmen der future Staatsgestaltung ändern könnte, wodurch potenzielle Einschränkungen aufgedeckt werden können. Informationen zur Bestätigung der ursprünglichen Annahmen finden Sie im [Entscheidungsbaum mit 6 Rs](prioritization-and-migration-strategy.md#migration-r-type). Dokumentieren Sie auch mögliche Migrationsphasen. Wird diese Anwendung beispielsweise in einem einzigen Ereignis migriert (alle Komponenten werden gleichzeitig migriert)? Oder handelt es sich um eine schrittweise Migration (einige Komponenten werden später migriert)? Beachten Sie, dass die Migrationsstrategien für eine bestimmte Anwendung möglicherweise nicht eindeutig sind. Dies liegt daran, dass mehrere R-Typen verwendet werden könnten, um die Anwendungskomponenten zu migrieren. Der erste Ansatz könnte beispielsweise darin bestehen, die Anwendung ohne Änderungen nach oben zu verschieben. Die Komponenten einer Anwendung können sich jedoch in unterschiedlichen Infrastrukturressourcen befinden, für die möglicherweise unterschiedliche Behandlungen erforderlich sind. Eine Anwendung besteht beispielsweise aus drei Komponenten, die jeweils auf einem separaten Server ausgeführt werden, und auf einem der Server läuft ein veraltetes Betriebssystem, das in der Cloud nicht unterstützt wird. Für diese Komponente ist ein Replattform-Ansatz erforderlich, während die anderen beiden Komponenten, die in unterstützten Serverversionen ausgeführt werden, erneut gehostet werden können. Es ist wichtig, jeder Anwendungskomponente und der zugehörigen Infrastruktur, die migriert wird, eine Migrationsstrategie zuzuweisen. Dokumentieren Sie als Nächstes den Kontext und das Problem und verknüpfen Sie vorhandene Artefakte, die den aktuellen Status definieren: + Warum wird diese Anwendung migriert? + Was sind die vorgeschlagenen Änderungen? + Was sind die Vorteile? + Gibt es irgendwelche größeren Risiken oder Hindernisse? + Was sind die aktuellen Nachteile? + Was ist im Geltungsbereich und was außerhalb des Geltungsbereichs? ## Wiederholbarkeit Denken Sie während der gesamten Entwurfsarbeit darüber nach, wie diese Lösung und Architektur für diese Anwendung für andere Anwendungen wiederverwendet werden können. Kann diese Lösung verallgemeinert werden? ## Voraussetzungen Dokumentieren Sie die funktionalen und nichtfunktionalen Anforderungen für diese Anwendung, einschließlich der Sicherheit. Dies beinhaltet aktuelle und future staatliche Anforderungen, abhängig von der gewählten Migrationsstrategie. Orientieren Sie sich bei diesem Prozess an den Informationen, die im Rahmen der ausführlichen Bewerbungsbeurteilung gesammelt wurden. ## Architektur der Zukunft Beschreiben Sie die future Architektur für diese Anwendung. Erwägen Sie, eine wiederverwendbare Schemavorlage zu erstellen, die Bausteine für Ihre Quellumgebung (lokal) und AWS Zielumgebung (z. B. Ziel- AWS-Region VPCs, Konto- und Availability Zones) enthält. Erstellen Sie eine Tabelle mit Komponenten, die migriert werden, und Komponenten, die neu sein werden. Schließen Sie andere Anwendungen und Dienste (entweder vor Ort oder in der Cloud) ein, die mit dieser Anwendung interagieren. In der folgenden Tabelle sind Beispielkomponenten aufgeführt. Sie stellt keine Referenzarchitektur oder geprüfte Konfiguration dar. | **Name** | **Beschreibung** | **Details** | | --- |--- |--- | | Anwendung | Externer Dienst (eingehende Verbindung) | Der Dienst verwendet Daten aus der exponierten API. | | DNS | Namensauflösung (intern) | Amazon Route 53 wurde als Teil der Basiskontoeinstellungen bereitgestellt | | Application Load Balancer | Verteilt den Verkehr auf die Back-End-Dienste | Ersetzt den lokalen Load Balancer. Migrieren Sie Pool A. | | Anwendungssicherheit | DDoS-Schutz | Implementiert mit AWS Shield | | Sicherheitsgruppe | Virtuelle Firewall | Beschränken Sie den Zugriff auf Anwendungsinstanzen auf Port 443 (eingehend). | | Server A | Frontend | Rehosten Sie mithilfe von Amazon Elastic Compute Cloud (Amazon EC2). | | Server B | Frontend | Rehosten Sie mit Amazon EC2. | | Server C | Anwendungslogik | Rehosten Sie mit Amazon EC2. | | Server D | Anwendungslogik | Rehosten Sie mit Amazon EC2. | | Amazon Relational Database Service (Amazon RDS) — Amazon Aurora | Datenbank | Ersetzt die Server E und F | | Überwachen und Warnen | Steuerung ändern | Amazon CloudWatch | | Audit-Protokollierung | Kontrolle ändern | AWS CloudTrail | | Patchen und Fernzugriff | Wartung | AWS Systems Manager | | Resource access (Ressourcenzugriff) | Sichere Zugriffskontrolle | AWS Identity and Access Management (IAM) | | Authentifizierung | Benutzerzugriff | Amazon Cognito | | Zertifikate | SSL/TLS | AWS Certificate Manager | | API 1 | Externe API | Amazon API Gateway | | Objektspeicher | Hosting von Bildern | Amazon Simple Storage Service (Amazon-S3) | | Anmeldeinformationen | Verwaltung und Hosting von Anmeldeinformationen | AWS Secrets Manager | | AWS Lambda Funktion | Abrufen von Datenbankanmeldedaten und API-Schlüsseln | AWS Lambda | | Internet-Gateway | Ausgehender Internetzugang | Internet-Gateway zu einer VPC | | Privates Subnetz 1 | Backend und DB | Verfügbarkeitszone 1 — VPC 1 | | Privates Subnetz 2 | Backend und DB | Verfügbarkeitszone 2 — VPC 1 | | Öffentliches Subnetz 1 | Frontend | Verfügbarkeitszone 1 — VPC 1 | | Öffentliches Subnetz 2 | Frontend | Verfügbarkeitszone 2 — VPC 1 | | Backup-Dienste | Datenbanken und EC2-Instanz-Backup | AWS Backup | | DR | Resilienz von Amazon EC2 | AWS Elastic Disaster Recovery | Nachdem die Komponenten identifiziert wurden, zeichnen Sie sie mit Ihrem bevorzugten Tool in einem Diagramm auf. Teilen Sie den ursprünglichen Entwurf mit den wichtigsten Stakeholdern der Anwendung, einschließlich Anwendungseigentümern, Unternehmensarchitekten und den Plattform- und Migrationsteams. Erwägen Sie, die folgenden Fragen zu stellen: + Ist das Team generell mit dem Design einverstanden? + Können die Betriebsteams es unterstützen? + Kann das Design weiterentwickelt werden? + Gibt es andere Optionen? + Entspricht das Design den Architekturstandards und Sicherheitsrichtlinien? + Fehlen Komponenten (z. B. Code-Repositorys, CI/CD Tools, VPC-Endpunkte)? ## Architektonische Entscheidungen Im Rahmen des Entwurfsprozesses werden Sie wahrscheinlich mehr Optionen für die Gesamtarchitektur oder bestimmte Teile davon finden. Dokumentieren Sie diese Optionen zusammen mit der Begründung für eine bevorzugte oder ausgewählte Option. Diese Entscheidungen können als architektonische Entscheidungen dokumentiert werden. Stellen Sie sicher, dass die wichtigsten Optionen so detailliert aufgeführt und beschrieben werden, dass ein neuer Leser die Optionen und Gründe für die Entscheidung, eine Option einer anderen vorzuziehen, verstehen kann. ## Umgebungen im Softwarelebenszyklus Dokumentieren Sie alle Änderungen an aktuellen Umgebungen. Beispielsweise werden Test- und Entwicklungsumgebungen in neu erstellt AWS und nicht migriert. ## Tagging Beschreiben Sie die obligatorische und empfohlene Kennzeichnung für jede Infrastrukturkomponente sowie den Tagging-Wert für diesen Entwurf. ## Migrationsstrategie Zu diesem Zeitpunkt des Entwurfs sollten die ursprünglichen Annahmen zur Migrationsstrategie validiert sein. Bestätigen Sie, dass ein Konsens über die gewählte R-Strategie besteht. Dokumentieren Sie die allgemeine Strategie zur Anwendungsmigration und die Strategien für einzelne Anwendungskomponenten. Wie bereits erwähnt, benötigen verschiedene Anwendungskomponenten möglicherweise unterschiedliche R-Typen für die Migration. Darüber hinaus sollten Sie die Migrationsstrategie an den wichtigsten Geschäftsfaktoren und Ergebnissen ausrichten. Beschreiben Sie außerdem alle schrittweisen Migrationsansätze, z. B. die Verschiebung von Komponenten im Rahmen verschiedener Migrationsereignisse. Weitere Informationen zur Bestimmung Ihrer 6 Rs finden Sie in den [AWS Migration Hub Strategieempfehlungen](https://aws.amazon.com/blogs/aws/new-strategy-recommendations-service-helps-streamline-aws-cloud-migration-and-modernization/). ## Migrationsmuster und Tools Mit einer definierten Migrationsstrategie für die Anwendungs- und Infrastrukturkomponenten können Sie nun spezifische technische Muster untersuchen. Eine Rehost-Strategie kann beispielsweise durch Migrationstools wie umgesetzt werden. [AWS Application Migration Service](https://aws.amazon.com/application-migration-service/) Wenn Sie den Status oder die Daten nicht replizieren müssen, können Sie dasselbe Ergebnis erzielen, indem Sie die Anwendung mithilfe eines Amazon Machine Image (AMI) und einer Anwendungsbereitstellungspipeline erneut bereitstellen. In ähnlicher Weise können Sie Tools wie, (), (), verwenden, um eine Anwendung auf eine neue Plattform oder ein Refactoring [AWS Database Migration Service (Re-Architect AWS DMS)](https://aws.amazon.com/dms/) umzustellen. [AWS App2Container[AWS Schema Conversion ToolAWS SCT[AWS DataSync](https://aws.amazon.com/datasync/)](https://aws.amazon.com/dms/schema-conversion-tool/)](https://aws.amazon.com/app2container/) Für die Containerisierung können Sie [Amazon Elastic Container Service (Amazon ECS), Amazon](https://aws.amazon.com/ecs/) [Elastic Kubernetes Service (Amazon EKS](https://aws.amazon.com/eks/)) oder verwenden. [AWS Fargate](https://aws.amazon.com/fargate/) Beim Rückkauf können Sie ein AMI für ein bestimmtes Produkt oder eine SaaS-Lösung (Software as a Service) von [AWS Marketplace](https://aws.amazon.com/marketplace/)verwenden. Bewerten Sie die verschiedenen Muster und Optionen, die zur Erreichung des Ziels zur Verfügung stehen. Berücksichtigen Sie die Vor- und Nachteile sowie die Einsatzbereitschaft der Migration. Verwenden Sie die folgenden Fragen, um Ihnen bei Ihrer Analyse zu helfen: + Können Migrationsteams diese Muster unterstützen? + Wie ist das Gleichgewicht zwischen Kosten und Nutzen? + Kann diese Anwendung, dieser Dienst oder diese Komponente in einen verwalteten Dienst verschoben werden? + Wie hoch ist der Aufwand, dieses Muster zu implementieren? + Gibt es Vorschriften oder Compliance-Richtlinien, die die Verwendung eines bestimmten Musters verhindern? + Kann dieses Muster wiederverwendet werden? Wiederverwendbare Muster werden bevorzugt. Manchmal wird ein Muster jedoch nur einmal verwendet. Erwägen Sie das Gleichgewicht zwischen dem Aufwand eines Einwegmusters und einem alternativen wiederverwendbaren Muster. [AWS Prescriptive Guidance](https://aws.amazon.com/prescriptive-guidance/) umfasst eine Vielzahl von Migrationsmustern und -techniken. ## Servicemanagement und Betrieb Bei der Erstellung von Anwendungsentwürfen für die Migration zu AWS sollten Sie die Betriebsbereitschaft berücksichtigen. Berücksichtigen Sie bei der Bewertung der Bereitschaftsanforderungen mit Ihren Anwendungs- und Infrastrukturteams die folgenden Fragen: + Sind sie bereit, es in Betrieb zu nehmen? + Sind Verfahren zur Reaktion auf Vorfälle definiert? + Was ist das erwartete Service Level Agreement (SLA)? + Ist eine Aufgabentrennung erforderlich? + Sind die verschiedenen Teams bereit, die Unterstützungsmaßnahmen zu koordinieren? + Wer ist wofür verantwortlich? ## Überlegungen zur Umstellung Was ist angesichts der Migrationsstrategie und der Migrationsmuster wichtig zu wissen, wenn die Anwendung migriert wird? Die Umstellungsplanung ist eine Aktivität, die erst nach dem Entwurf erfolgt. Dokumentieren Sie jedoch alle Überlegungen zu Aktivitäten und Anforderungen, die erwartet werden können. Dokumentieren Sie beispielsweise die Anforderung, gegebenenfalls einen Machbarkeitsnachweis durchzuführen, und skizzieren Sie die Test-, Audit- oder Validierungsanforderungen. ## Risiken, Annahmen, Probleme und Abhängigkeiten Dokumentieren Sie alle offenen Risiken, Annahmen und potenziellen Probleme, die noch nicht gelöst sind. Weisen Sie diesen Punkten klare Zuständigkeiten zu und verfolgen Sie die Fortschritte, sodass der Gesamtentwurf und die Strategie für die Umsetzung genehmigt werden können. Dokumentieren Sie außerdem die wichtigsten Abhängigkeiten bei der Implementierung dieses Entwurfs. ## Schätzung der Betriebskosten Verwenden Sie den [AWS Preisrechner](https://calculator.aws/), um die Kosten Ihrer AWS Zielarchitektur zu schätzen. Fügen Sie Ihre Infrastrukturkomponenten wie in Ihrem Entwurf definiert hinzu und erhalten Sie eine Schätzung der Betriebskosten. Berücksichtigen Sie Softwarelizenzen, die für Ihre Anwendungskomponenten erforderlich sind und die nicht bereits in den AWS Diensten enthalten sind, die Sie nutzen werden.