# AWS Well-Architected Framework
Veröffentlichungsdatum: **10. April 2023** ([Dokumentversionen](document-revisions.md))
Das AWS-Well-Architected-Framework unterstützt Sie dabei, die Vor- und Nachteile der Entscheidungen nachzuvollziehen, die Sie beim Aufbau von Systemen in AWS treffen. Das Framework hilft Ihnen, bewährte Architekturmethoden für die Entwicklung und den Betrieb zuverlässiger, sicherer, effizienter, kostengünstiger und nachhaltiger Systeme in der Cloud zu ermitteln.
## Einführung
Das AWS-Well-Architected-Framework unterstützt Sie dabei, die Vor- und Nachteile der Entscheidungen nachzuvollziehen, die Sie beim Aufbau von Systemen in AWS treffen. Das Framework hilft Ihnen, bewährte Architekturmethoden für den Entwurf und Betrieb zuverlässiger, sicherer, effizienter, kostengünstiger und nachhaltiger Workloads in der AWS Cloud zu ermitteln. Es bietet Ihnen die Möglichkeit, Ihre Architekturen konsistent auf die Einhaltung bewährter Methoden zu prüfen und Verbesserungspotenzial zu identifizieren. Die Überprüfung einer Architektur ist kein Audit. Vielmehr ist es eine konstruktive Konversation, in der es um architektonische Entscheidungen geht. Wir sind davon überzeugt, dass eine durchdachte Systemarchitektur maßgeblich zu Ihrem künftigen geschäftlichen Erfolg beiträgt.
AWS Solutions Architects entwerfen seit vielen Jahren Lösungen für unterschiedlichste Branchen und Anwendungsfälle. Wir waren am Design und an der Überprüfung Tausender Kundenarchitekturen auf AWS beteiligt. Daher kennen wir die bewährten Methoden und Kernstrategien für erfolgreiche Systemarchitekturen in der Cloud.
Das AWS-Well-Architected-Framework dokumentiert grundlegende Fragen, mit denen Sie klären, ob eine Architektur einwandfrei mit bewährten Methoden für die Cloud vereinbar ist. Über das Framework erhalten Sie eine einheitliche Herangehensweise zur Bewertung der Eigenschaften, die Sie von modernen Cloud-basierten Systemen erwarten, sowie Vorschläge zur Realisierung dieser Eigenschaften. AWS entwickelt sich ständig weiter, und auch wir lernen durch die Arbeit mit unseren Kunden ständig dazu. Mit diesem wachsenden Wissen können wir immer noch genauer definieren, wodurch sich eine gute architektonische Struktur auszeichnet.
Dieses Framework richtet sich an Technologiefachleute, z. B. Chief Technology Officers (CTO), Architekten, Entwickler und Operations-Mitarbeiter. Die darin enthaltenen bewährten Methoden und Strategien für AWS kommen bei der Gestaltung und Nutzung von Cloud-Workloads zum Einsatz. Die Links verweisen auf weitere Implementierungsdetails und Architekturmodelle. Weitere Informationen finden Sie auf der [AWS-Well-Architected-Homepage](https://aws.amazon.com/architecture/well-architected/?ref=wellarchitected-wp).
AWS bietet auch eine kostenfreie Prüfung Ihrer Workloads an. Das [AWS-Well-Architected Tool](https://aws.amazon.com/well-architected-tool/?ref=wellarchitected-wp) (AWS WA Tool) ist ein Service in der Cloud, der einen einheitlichen Prozess zum Überprüfen und Messen Ihrer Architektur mit dem AWS-Well-Architected-Framework bietet. Vom AWS WA Tool erhalten Sie Empfehlungen, wie Sie Ihre Workloads zuverlässiger, sicherer, effizienter und kostengünstiger machen können.
Um Sie bei der Anwendung von bewährten Methoden zu unterstützen, haben wir [AWS Well-Architected Labs](https://www.wellarchitectedlabs.com/?ref=wellarchitected-wp) entwickelt. Diese stellen Ihnen ein Repository mit Code und Dokumentation zur Verfügung, damit Sie praktische Erfahrungen mit der Implementierung von bewährten Methoden sammeln können. Wir haben uns auch mit ausgewählten Partnern aus dem AWS-Partnernetzwerk (APN) zusammengetan, die Mitglieder des [AWS-Well-Architected-Partnerprogramms](https://aws.amazon.com/architecture/well-architected/partners/?ref=wellarchitected-wp) sind. Diese AWS-Partner sind bestens mit AWS vertraut und können Sie beim Überprüfen und Verbessern Ihrer Workloads unterstützen.
# Definitionen
Die Experten von AWS unterstützen Kunden tagtäglich beim Entwerfen von Systemarchitekturen, die ihnen eine optimale Nutzung bewährter Methoden in der Cloud ermöglichen. Während wir zusammen mit Ihnen die Architektur entwerfen, wägen wir die Anforderungen ab und treffen die richtigen Kompromisse. Wenn Sie die Systeme dann in Live-Umgebungen bereitstellen, beobachten wir, wie gut diese Systeme laufen und welche Auswirkungen die Kompromisse haben.
Unsere bisherigen Erkenntnisse sind die Grundlage von AWS Well-Architected Framework. Das Framework enthält einheitlich zusammengestellte bewährte Methoden, mit denen Kunden und Partner Architekturen bewerten. Anhand verschiedener Fragen können sie beurteilen, wie gut eine Architektur auf die bewährten Methoden von AWS ausgerichtet ist.
Das AWS-Well-Architected-Framework basiert auf sechs Säulen: operative Exzellenz, Sicherheit, Zuverlässigkeit, Leistungseffizienz, Kostenoptimierung und Nachhaltigkeit.
**Tabelle 1: Die Säulen des AWS Well-Architected Framework**
| **Name** | **Beschreibung** |
| --- | --- |
| Operative Exzellenz | The ability to support development and run workloads effectively, gain insight into their operations, and to continuously improve supporting processes and procedures to deliver business value. |
| Sicherheit | The security pillar describes how to take advantage of cloud technologies to protect data, systems, and assets in a way that can improve your security posture. |
| Zuverlässigkeit | The reliability pillar encompasses the ability of a workload to perform its intended function correctly and consistently when it’s expected to. This includes the ability to operate and test the workload through its total lifecycle. This paper provides in-depth, best practice guidance for implementing reliable workloads on AWS. |
| Leistungseffizienz | The ability to use computing resources efficiently to meet system requirements, and to maintain that efficiency as demand changes and technologies evolve. |
| Kostenoptimierung | The ability to run systems to deliver business value at the lowest price point. |
| Nachhaltigkeit | The ability to continually improve sustainability impacts by reducing energy consumption and increasing efficiency across all components of a workload by maximizing the benefits from the provisioned resources and minimizing the total resources required. |
In Zusammenhang mit dem AWS-Well-Architected-Framework verwenden wir diese Bezeichnungen:
+ Eine **Komponente** besteht aus dem Code, der Konfiguration und den AWS-Ressourcen, die für eine Anforderung bereitgestellt werden. Eine Komponente ist häufig die Einheit technischen Eigentums und von anderen Komponenten losgelöst.
+ Der Begriff **Workload** wird verwendet, um eine Reihe von Komponenten zu identifizieren, die gemeinsam einen geschäftlichen Mehrwert bieten. Ein Workload ist in vielen Fällen der Detaillierungsgrad, von dem Führungskräfte aus Wirtschaft und Technik häufig sprechen.
+ Wir betrachten **Architektur** als die Art und Weise, wie Komponenten in einem Workload zusammenarbeiten. Wie Komponenten kommunizieren und interagieren, ist häufig der Schwerpunkt von Architekturdiagrammen.
+ **Meilensteine** markieren wichtige Änderungen einer Architektur im Laufe des Produktlebenszyklus (Entwurf, Implementierung, Tests, Inbetriebnahme und Produktionsbetrieb).
+ Bei einer Organisation ist das **Technologieportfolio** die Sammlung von Workloads, die für den Geschäftsbetrieb erforderlich sind.
+ Der **Grad des Aufwands** bezeichnet die Zeitspanne, den Aufwand und die Komplexität, die für die Implementierung einer Aufgabe benötigt werden. Jede Organisation muss die Größe und das Fachwissen des Teams sowie die Komplexität des Workloads berücksichtigen, um den Grad des Aufwands für die Organisation richtig einzuordnen.
+ **Hoch:** Die Arbeit dauert möglicherweise mehrere Wochen oder Monate. Sie könnte in mehrere Abschnitte, Veröffentlichungen und Aufgaben aufgeteilt werden.
+ **Mittel:** Die Arbeit dauert möglicherweise mehrere Tage oder Wochen. Sie könnte in mehrere Veröffentlichungen und Aufgaben aufgeteilt werden.
+ **Gering:** Die Arbeit dauert möglicherweise mehrere Stunden oder Tage. Sie könnte in mehrere Aufgaben aufgeteilt werden.
Beim Entwerfen von Workloads stellen Sie eine Kosten-Nutzen-Abwägung zwischen Säulen abhängig von Ihrem Geschäftskontext an. Diese Geschäftsentscheidungen können Ihre technischen Prioritäten beeinflussen. In Entwicklungsumgebungen könnten Sie im Hinblick auf eine Verbesserung der Nachhaltigkeitswirkung und eine Verringerung der Kosten zulasten der Zuverlässigkeit optimieren. Bei unternehmenskritischen Lösungen könnten Sie dagegen die Zuverlässigkeit optimieren und dafür höhere Kosten und stärkere Auswirkungen auf die Nachhaltigkeit in Kauf nehmen. Bei E-Commerce-Lösungen kann sich die Leistung auf die Einnahmen und die Kauflust der Kunden auswirken. Sicherheit und operative Exzellenz haben in der Regel keine Wechselwirkung mit den anderen Säulen.
# Architektur-Überlegungen
In On-Premises-Umgebungen setzen Kunden oft ein zentrales Technologiearchitektur-Team ein. Dies dient als Überlagerung für Produkt- oder Feature-Teams, um sicherzustellen, dass diese nach bewährten Methoden arbeiten. Technologiearchitektur-Teams setzen sich üblicherweise aus Fachleuten mit unterschiedlichen Aufgabengebieten zusammen, z. B.: Technical Architect (Infrastruktur), Solutions Architect (Software), Data Architect, Networking Architect und Security Architect. Oft verwenden diese Teams [TOGAF](http://pubs.opengroup.org/architecture/togaf9-doc/arch/?ref=wellarchitected-wp) oder das [Zachman Framework](https://www.zachman.com/about-the-zachman-framework?ref=wellarchitected-wp) als Teil einer Enterprise-Architekturfunktion.
Bei AWS werden die Fähigkeiten lieber auf einzelne Teams verteilt, als sie in einem Zentralteam zu konzentrieren. Wenn die Entscheidungsbefugnis auf mehrere Teams verteilt wird, geht das mit Risiken einher. So muss beispielsweise sichergestellt sein, dass die Teams internen Standards gerecht werden. Um diese Risiken aufzufangen, verwenden wir zwei Methoden. Erstens verfügen wir über *Praktiken* (Vorgehensweisen, Prozesse, Standards und anerkannte Normen), die darauf abzielen, jedes Team mit dieser Fähigkeit auszustatten. Zudem setzen wir Experten ein, die dafür sorgen, dass die Teams die vorgegebenen Standards sogar noch übertreffen. Zweitens implementieren wir *Mechanismen*, die automatisch kontrollieren, ob Standards eingehalten werden.
****
„Gut gemeinte Absichten funktionieren nicht. Wer etwas erreichen will, braucht gute Mechanismen“ – Jeff Bezos.
Das bedeutet konkret, dass wir das Bestmögliche, das Menschen leisten können, durch (oftmals automatisierte) Mechanismen ersetzen, die kontrollieren, ob Regeln oder Prozesse eingehalten werden. Dieses verteilte Konzept wird durch die [Führungsprinzipien von Amazon](https://www.amazon.jobs/en/principles?ref=wellarchitected-wp) unterstützt und etabliert eine Kultur für alle Rollen, bei der es darum geht, *vom Kunden aus zu denken*. Vom Kunden aus zu denken, ist ein grundlegender Bestandteil unseres Innovationsprozesses. Unsere Arbeit richtet sich ganz nach dem Kunden und dessen Wünschen. Kundenfixierte Teams richten die Produktentwicklung auf Kundenwünsche aus.
In Zusammenhang mit Architekturen bedeutet das: Wir erwarten von jedem Team, dass es Architekturen erstellen und nach bewährten Methoden arbeiten kann. Um neuen Teams zu diesen Fähigkeiten zu verhelfen bzw. um bestehende Teams leistungsfähiger zu machen, nehmen wir sie in eine virtuelle Community auf, in der Principal Engineers ihre Entwürfe begutachten und sie an die bewährten Methoden von AWS heranführen. Die Community der Principal Engineers hat die Aufgabe, bewährte Methoden sichtbar und verständlich zu machen. Dies geschieht beispielsweise durch Mittagsvorträge, in denen es um die Anwendung bewährter Methoden an praktischen Beispielen geht. Die Vorträge werden aufgezeichnet und können für das Onboarding neuer Teammitglieder eingesetzt werden.
Wir haben bislang mehrere Tausende internetähnliche Systeme eingerichtet und dabei einen Erfahrungsschatz aufgebaut, aus dem sich die bewährten Methoden von AWS herauskristallisiert haben. Wir bevorzugen, bewährte Methoden mit Hilfe von Daten zu definieren. Wir setzen dafür aber auch Fachexperten (z. B. Principal Engineers) ein. Principal Engineers sind direkt dabei, wenn sich neue bewährte Methoden abzeichnen. Als Community können sie sicherstellen, dass die Teams danach arbeiten. Im Laufe der Zeit werden diese bewährten Methoden in unsere internen Prüfprozesse sowie in Compliance-Mechanismen aufgenommen. Das Well-Architected Framework ist die kundenseitige Implementierung unseres internen Prüfprozesses. Darin ist die Denkweise der Principal Engineers für Zuständigkeitsbereiche vor Ort (z. B. Solutions Architecture, interne Engineering-Teams) festgeschrieben. Das Well-Architected Framework ist ein skalierbarer Mechanismus, mit dem Sie von diesen Erkenntnissen profitieren können.
Wenn so vorgegangen wird wie in einer Community aus Principal Engineers (mit verteilten Architekturzuständigkeiten), kann unserer Ansicht nach eine Well-Architected Enterprise-Architektur zustande kommen, die auf die Kundenwünsche ausgerichtet ist. Technologievordenker (z. B. CTO oder Entwicklungsleiter), die all Ihre Workloads nach den Prinzipien des Well-Architected-Ansatzes prüfen, können die Risiken Ihres Technologieportfolios aufzeigen. Sie identifizieren teamübergreifende Themen, die Ihre Organisation mit Hilfe von Mechanismen, Training oder Mittagsvorträgen angehen könnte. Allesamt Gelegenheiten für Ihre Principal Engineers, ihr Wissen zu bestimmten Themen an mehrere Teams weiterzugeben.
# Allgemeine Designprinzipien
Das Well-Architected Framework fasst allgemeine konzeptionelle Grundsätze zusammen, die gutes Design in der Cloud fördern:
+ **Keine Ungewissheit mehr über die benötigte Kapazität**: Wenn Sie bei der Bereitstellung eines Workloads eine falsche Entscheidung bezüglich der Kapazität treffen, führt dies oft zu teuren, nicht genutzten Ressourcen oder zu Leistungsproblemen aufgrund von zu wenig Kapazitäten. Beim Cloud-Computing gibt es diese Probleme nicht. Sie arbeiten mit so viel oder so wenig Kapazität wie nötig. Das System wird automatisch hoch- oder herunterskaliert.
+ **Testen von Systemen im Produktionsmaßstab**: Sie können in der Cloud bei Bedarf eine Testumgebung im Produktionsmaßstab einrichten, Ihre Tests abschließen und die Ressourcen dann wieder außer Betrieb nehmen. Weil Sie für die Testumgebung nur dann zahlen, wenn sie genutzt wird, können Sie Ihre Live-Umgebung zu einem Bruchteil der Kosten testen, die Sie an einem On-Premises-Standort hätten.
+ **Automatisierung für einfachere Architekturexperimente**: Durch die Automatisierung können Sie Ihre Workloads kostengünstig erstellen und replizieren und manuellen Aufwand vermeiden. Sie können an der Automatisierung vorgenommene Änderungen nachverfolgen, die Auswirkungen nachprüfen und ggf. auf die vorherigen Parameter zurücksetzen.
+ **Möglichkeit evolutionärer Architekturen**: In herkömmlichen Umgebungen werden architekturbezogene Entscheidungen oft in Form von statischen, einmaligen Ereignissen implementiert. Dementsprechend gibt es während der Lebensdauer des Systems einige wenige große Versionen des Systems. Geschäftsvoraussetzungen und ihr Kontext entwickeln sich stetig weiter. Diese anfangs getroffenen Entscheidungen könnten die Fähigkeit des Systems beeinträchtigen, sich auf neue Geschäftsvoraussetzungen einzustellen. In der Cloud können Sie jederzeit automatisieren und testen. Dadurch wird weniger wahrscheinlich, dass sich Änderungen am Design negativ auswirken. Systeme können sich somit im Laufe der Zeit weiterentwickeln. Unternehmen können dann wie selbstverständlich Innovationen für sich nutzen.
+ **Weiterentwicklung von Architekturen mithilfe von Daten**: Sie können in der Cloud Daten dazu sammeln, wie sich Ihre architekturrelevanten Entscheidungen auf das Verhalten Ihres Workloads auswirken. Sie können also mit faktenbasierten Entscheidungen Ihren Workload verbessern. Ihre Cloud-Infrastruktur ist Code. Das bedeutet, dass Sie diese Daten im Laufe der Zeit in architekturrelevante Entscheidungen und Verbesserungsmaßnahmen einfließen lassen können.
+ **Verbesserung mithilfe von Ernstfallübungen**: Simulieren Sie in regelmäßigen Ernstfallübungen Vorfälle in der Produktion, um das Verhalten Ihrer Architektur und Ihrer Prozesse zu testen. So können Sie nachvollziehen, wo nachgebessert werden kann. Zudem üben Sie dabei ein, wie Ihre Organisation mit Ereignissen umgeht.