# AWS Well-Architected Framework
Veröffentlichungsdatum: **20. Oktober 2022** ([Dokumentversionen](document-revisions.md))
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, architektonische Best Practices für die Entwicklung und den Betrieb zuverlässiger, sicherer, effizienter und kosteneffektiver Systeme in der Cloud zu ermitteln.
## Einführung
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, architektonische Best Practices für den Entwurf und Betrieb zuverlässiger, sicherer, effizienter, kosteneffektiver und nachhaltiger Workloads in der AWS Cloud zu ermitteln. Es bietet Ihnen die Möglichkeit, Ihre Architekturen konsistent hinsichtlich der Einhaltung von Best Practices zu überprüfen und Optimierungsmöglichkeiten 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 architektonisch gute Systeme die Wahrscheinlichkeit des geschäftlichen Erfolgs signifikant beeinflussen.
AWS Solutions Architects entwerfen seit vielen Jahren Architekturen für unterschiedlichste Branchen und Anwendungsfälle. Wir waren am Design und 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 Best Practices 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. Und so wie unser Wissen anwächst, können wir immer wieder 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 Best Practices und Strategien für AWS kommen beim Design und der Nutzung von Cloud Workloads zum Einsatz. Die Links verweisen auf weitere Implementierungsdetails und Architekturmodelle. Weitere Informationen finden Sie auf der Homepage von [AWS Well-Architected-Homepage](https://aws.amazon.com/architecture/well-architected/?ref=wellarchitected-wp).
AWS bietet auch an, Ihre Workloads kostenfrei zu überprüfen. 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 AWS Well-Architected Framework bietet. Vom AWS WA Tool erhalten Sie Empfehlungen, wie Sie Ihre Workloads zuverlässiger, sicherer, effizienter und kostengünstiger machen.
Um Ihnen das Arbeiten nach bewährten Methoden zu erleichtern, haben wir [AWS Well-Architected Labs](https://www.wellarchitectedlabs.com/?ref=wellarchitected-wp)entwickelt. Der Code und die Dokumentation von Labs erlauben Ihnen, eigene Erfahrungen mit der Implementierung bewährter Methoden zu sammeln. Außerdem haben wir uns mit ausgewählten Partner aus dem AWS Partner Network (APN), die Mitglieder des [AWS Well-Architected-Partnerprogramms sind, zusammengetan.](https://aws.amazon.com/architecture/well-architected/partners/?ref=wellarchitected-wp). 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 mit bewährten Cloud-Methoden tagtäglich Kunden beim Entwerfen von Systemarchitekturen. 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: betriebliche Exzellenz, Sicherheit, Zuverlässigkeit, Leistungseffizienz, Kostenoptimierung und Nachhaltigkeit.
**Tabelle 1. Die Säulen des AWS Well-Architected Framework**
| **Name** | **Beschreibung** |
| --- | --- |
| Operational Excellence | Die Fähigkeit, die Entwicklung zu unterstützen und Workloads effektiv auszuführen, Einblicke in die Betriebsabläufe zu erhalten und für geschäftlichen Mehrwert unterstützende Prozesse und Verfahren fortlaufend zu verbessern. |
| Sicherheit | In der Säule der Sicherheit wird beschrieben, wie Sie Cloud-Technologien nutzen, um Daten, Systeme und Komponenten so zu schützen, dass sich Ihre Sicherheitslage verbessert. |
| Zuverlässigkeit | Die Säule „Zuverlässigkeit“ umfasst die Fähigkeit eines Workloads, die beabsichtigte Funktion erwartungsgemäß korrekt und konsistent auszuführen. Dies umfasst die Möglichkeit, den Workload während des gesamten Lebenszyklus zu betreiben und zu testen. Dieses Dokument bietet umfassende Informationen mit bewährte Methoden für die Implementierung zuverlässiger Workloads in AWS. |
| Leistungseffizienz | Die Fähigkeit, Rechenressourcen effizient entsprechend den Systemanforderungen zu nutzen und diese Effizienz aufrechtzuerhalten, während sich die Nachfrage ändert und die Technologie weiterentwickelt. |
| Kostenoptimierung | Die Fähigkeit, Systeme so auszuführen, dass sie geschäftlichen Wert bei geringstmöglichen Kosten liefern. |
| Nachhaltigkeit | Die Fähigkeit, die Auswirkungen auf die Nachhaltigkeit kontinuierlich zu verbessern, indem der Energieverbrauch reduziert und die Effizienz aller Komponenten eines Workloads erhöht wird, indem der Nutzen der bereitgestellten Ressourcen maximiert und die insgesamt erforderlichen Ressourcen minimiert werden. |
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 für zusammengehörige Komponenten, die geschäftlichen Mehrwert darstellen, verwendet. 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 das Zusammenwirken von Komponenten in einem Workload. Wie Komponenten kommunizieren und interagieren, ist häufig der Schwerpunkt von Architekturdiagrammen.
+ **Meilensteine** markieren wichtige Änderungen im Laufe der Entwicklung einer Architektur im Produktlebenszyklus (Entwurf, Implementierung, Tests, Inbetriebnahme und Produktionsbetrieb).
+ Innerhalb einer Organisation ist das **Technologieportfolio** die für den Geschäftsbetrieb erforderliche Sammlung an Workloads.
+ 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 Aufwand für die Organisation richtig einzuordnen.
+ **Hoch:** Die Arbeit dauert möglicherweise mehrere Wochen oder Monate. Dies könnte in mehrere Geschichten, Veröffentlichungen und Aufgaben aufgeteilt werden.
+ **Mittel:** Die Arbeit dauert möglicherweise mehrere Tage oder Wochen. Dies könnte in mehrere Veröffentlichungen und Aufgaben aufgeteilt werden.
+ **Niedrig:** Die Arbeit dauert möglicherweise mehrere Stunden oder Tage. Dies 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. Sie können optimieren, um die Nachhaltigkeitswirkung zu verbessern und die Kosten zulasten der Zuverlässigkeit in Entwicklungsumgebungen zu senken. Sie können bei unternehmenskritischen Lösungen auch die Zuverlässigkeit mit höheren Kosten und höherer Nachhaltigkeitswirkung optimieren. Bei E-Commerce-Lösungen kann sich die Leistung auf die Einnahmen und die Kauflust der Kunden auswirken. Sicherheit und betriebliche Exzellenz haben in der Regel keine Wechselwirkung mit den anderen Säulen.
# Architektur-Überlegungen
In On-Premise-Umgebungen setzen Kunden oft ein Zentralteam für Technologiearchitektur ein. Dieses ist anderen Produkt- oder Feature-Teams vorgeschaltet, damit 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. Diese Teams arbeiten oft nach dem [TOGAF-Modell](http://pubs.opengroup.org/architecture/togaf9-doc/arch/?ref=wellarchitected-wp) oder dem [Zachman Framework](https://www.zachman.com/about-the-zachman-framework?ref=wellarchitected-wp) – als Teil eines Kompetenzbereichs für Enterprise-Architektur.
AWS verteilt Fähigkeiten lieber auf einzelne Teams, anstatt die Kompetenz 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. Zum einen arbeiten wir mit *Praktiken* (Vorgehensweisen, Prozessen, Standards und gemeinhin anerkannte Normen), die darauf abzielen, jedes Team mit dieser Fähigkeit auszustatten. Dazu setzen wir Experten ein, die dafür sorgen, dass die Teams die vorgegebenen Standards ü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 (automatisierte) Mechanismen ersetzen, die kontrollieren, ob Regeln oder Prozesse eingehalten werden. Hinter diesem breit aufgestellten Ansatz stehen die [Führungsprinzipien von Amazon](https://www.amazon.jobs/en/principles?ref=wellarchitected-wp). Diese stellen sicher, dass in allen Aufgabenbereichen eine Kultur verankert wird, die *vom Kunden aus denkt* . Vom Kunden aus 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 Best Practices für 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 Best Practices für 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 Kapazität**: Wenn Sie bei der Bereitstellung eines Workloads eine schlechte Entscheidung zur Kapazität treffen, sitzen Sie anschließend möglicherweise auf nicht genutzten Ressourcen oder haben zu wenig Kapazität und müssen sich mit mangelnder Performance herumschlagen. 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.
+ **Systeme auf Produktionsbetrieb testen**: Sie können in der Cloud bei Bedarf eine Testumgebung in Produktionsgröße 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 lokalen Standort hätten.
+ **Automatisierung vereinfacht Architekturexperimente**: Wenn Sie automatisieren, können Sie Ihre Workloads kostengünstig erstellen und replizieren und vermeiden manuellen Aufwand. Sie können an der Automatisierung vorgenommene Änderungen nachverfolgen, die Auswirkungen nachprüfen und ggf. auf die vorherigen Parameter zurücksetzen.
+ **Voraussetzungen für evolutionäre Architekturen schaffen**: In herkömmlichen Umgebungen sind architekturrelevante Entscheidungen oft als statische, einmalig auftretende Ereignisse implementiert. Dementsprechend gibt es während der Lebensdauer des Systems einige wenige große Versionen. 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. Dieses System kann sich im Laufe der Zeit weiterentwickeln. Unternehmen können dann wie selbstverständlich Innovationen für sich nutzen.
+ **Mit Daten Architekturen weiterentwickeln**: Sie können in der Cloud Daten zu der Frage sammeln, wie Ihre architekturrelevanten Entscheidungen auf das Verhalten Ihres Workloads durchschlagen. 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 mit Hilfe von Ernstfallübungen**: Simulieren Sie an regelmäßigen Gamedays Vorfälle in der Produktion, um das Verhalten Ihrer Architektur und Prozesse zu simulieren. So können Sie nachvollziehen, wo nachgebessert werden kann. Zudem üben Sie dabei ein, wie Ihre Organisation mit Ereignissen umgeht.