Stefan Christoph & Tufan Özduman 02. Februar 2021

Well-Architected? Architekturreviews für moderne Cloudanwendungen

Das AWS Well-Architected Framework basiert auf 5 Säulen, die verschiedene Aspekte betrachten. © Adobe: AndSus / stock.adobe.com / 322315214 — © Adobe: AndSus

Im Rahmen der Anwendungsentwicklung und auch beim späteren Betrieb kommt hin und wieder die Frage auf: "Mache ich das eigentlich richtig"? Um festzustellen, ob Best Practices befolgt werden und ggf. Risiken in der Architektur bestehen, bietet sich ein Architekturreview an.

Das AWS Well-Architected Framework unterstützt Cloud-Architekten bei der Entwicklung sicherer, leistungsstarker, ausfallsicherer und effizienter Infrastrukturen für ihre Anwendungen. In diesem Artikel wird aufgezeigt, wie die Konzepte aus dem Well-Architected Framework in der Praxis umgesetzt werden können. Dabei werden die Autoren anhand von Anekdoten und Best Practices aus der Industrie auch die Sorgen der IT-Leiter aus dem deutschen Mittelstand adressieren.

Architekturbewertungen haben sich als ein wirksames Instrument bewährt, um Schwachstellen zu identifizieren. Unter dem Begriff Architektur verstehen wir dabei den Verbund aus Software- und Infrastruktur-Architektur. Durch gezielte Fragen können Risiken entdeckt werden, die den Erfolg des Projekts gefährden können. Wir können ferner feststellen, ob Industrie-Best-Practices angewandt, Qualitäts- und Compliance-Kriterien eingehalten wurden und gewinnen ein realistisches Gesamtbild über den Status des Projekts.

Architekturen können je nach Projektgröße sehr groß und komplex werden. Nicht selten sind mehrere Teams involviert, die eine Architektur aus mehreren Services zusammenstellen. In solchen Umgebungen ist es umso wichtiger, mit Architekturbewertungen vordefinierte qualitative, fachliche und funktionale Ziele des Projektes zu prüfen. Hierfür sind unterschiedliche Bewertungsansätze möglich.

Eine möglicher Ansatz ist die Architektur-Tradeoff-Analyse-Methode (ATAM [1]), die an der Carneige Mellon Universität im Jahr 2000 vorgestellt wurde. Diese Methode, zur Analysierung von hauptsächlich Softwarearchitekturen beruht auf der Erkenntnis, dass in jedem Großprojekt Tradeoffs vorkommen. Das Ziel dieser Methode ist, die Konsequenzen der Architekturentscheidungen in Bezug auf die Qualitätsanforderungen des Systems zu verstehen.

Formalisierte Architekturbewertungen ernten aber auch Kritik in Teilen nicht für reale Projekte geeignet zu sein. Insbesondere wenn Projekte sich ständig ändernde technologische oder geschäftliche Anforderungen haben, von kleinen Teams betreut werden und somit auf bestimmte Kompromisse angewiesen sind (z. B. fehlende interne Dokumentation, Architekturdiagramme etc.) wird es schwierig, die Architekturen mit formalisierten Architekturbewertungsmethoden zu untersuchen. Diese Punkte adressierten Neil B. Harrison und Paris Avgeriou im Jahr 2012 mit ihrem Vorschlag "Musterbasierte Architekturbewertungen" (Pattern-Based Architecture Reviews (PBAR) [2]). Angelehnt an die aus der Softwareentwicklung bekannten Entwurfsmuster, versuchen Harrison und Avgeriou in PBAR die Beziehungen der Muster zu Qualitätsmerkmalen zu nutzen, um eine "leichtgewichtige, einfache aber fokussierte" Form von Architekturbewertungen zu erreichen.

Viele Organisationen arbeiten traditionell mit Architekturteams, die sehr oft Produkt- und/oder Featureteams vorgeschaltet sind. Die Architekturteams, die in der Regel aus interdisziplinären Fachleuten bestehen, setzen oft TOGAF oder das Zachman Framework ein [3]. Moderne Methoden zur Softwareentwicklung versprechen Vorteile durch Dezentralisierung der Verantwortung und der Kompetenzen. Allerdings bringt das Verteilen der Entscheidungsbefugnisse auf einzelne Teams auch Risiken. So muss sichergestellt werden, dass die Teams internen Standards gerecht werden und sie im besten Fall übertreffen.

AWS entwickelt und betreibt Cloud-Services, die von Millionen von Nutzern verwendet werden. In AWS arbeiten wir mit dezentralen Entwicklungsteams und erwarten von jedem Team, dass es Architekturen erstellen und nach bewährten Methoden arbeiten kann. Um die zuvor erwähnten Risiken zu mitigieren, definierten wir mit Hilfe von Daten Best Practices. Die internen Entwicklungsteams sind jedoch nur eine Erfahrungsquelle. Darüber hinaus arbeiten wir aktiv mit den Nutzern der AWS Cloud Platform, sammeln Feedback vom kleinen Start-up bis Global Enterprise und generieren daraus zusätzliche Best Practices. Über die Jahre formalisierten wir diese Best Practices und entwickelten Prüfmechanismen, die die Grundlage zum Well-Architected-Framework bilden. Das Framework enthält einheitlich zusammengestellte, bewährte Methoden, mit denen Kunden und Partner Architekturen bewerten. Das AWS Well-Architected Framework existiert bereits seit mehr als 8 Jahren und wird ständig weiterentwickelt. Aktuell ist es bereits in der Version 8 verfügbar.

Einführung in das AWS Well-Architected-Framework

Das AWS Well-Architected Framework macht diese Best Practices durch einen Fragenkatalog greifbar. Durch die Beantwortung der Fragen kann erkundet werden, wie gut eine Architektur mit den bewährten Methoden für die Cloud übereinstimmt. Darüber hinaus bietet das Framework detaillierte Anleitungen zur Verbesserungen von gefundenen Schwachstellen.

Das AWS Well-Architected Framework basiert auf 5 Säulen, die verschiedene Aspekte betrachten. Im einzelnen sind dies: Operational Excellence, Sicherheit, Zuverlässigkeit, Leistungseffizienz und Kostenoptimierung. Im Folgenden betrachten wir etwas näher, was sich hinter den verschiedenen Säulen verbirgt.

Die Säule Operational Excellence befasst sich mit der Ausführung und Überwachung der bereitgestellten Systeme. Ziel sind die Generierung eines tatsächlichen Mehrwerts für das Geschäft sowie die beständige Optimierung der Prozesse und Verfahren. Wichtige Aspekte dabei sind Automatisierung von Änderungen, der effiziente Umgang mit Störungen im Betrieb und die Definition von Standards für die Verwaltung des täglichen Betriebs. Darauf aufbauend werden in dieser Säule die Themen effektive Organisation von Teams und Mittel zur Förderung von Innovation betrachtet.
Die Säule Sicherheit befasst sich mit dem Schutz von Informationen und Systemen. Zu den wichtigsten Themen zählen Vertraulichkeit und Datenintegrität, Rechteverwaltung inklusive Festlegen und Verwalten individueller Berechtigungen, der Schutz von Systemen und die Einrichtung von Kontrollen zur Erkennung von Sicherheitsvorfällen.
Die Säule Zuverlässigkeit konzentriert sich darauf, sicherzustellen, dass der Workload seine vorgesehene Funktion zur richtigen Zeit korrekt und konsistent ausführt. Ein ausfallsicherer Workload erholt sich schnell von Ausfällen, um den Unternehmens- und Kundenansprüchen gerecht zu werden. Wichtige Aspekte hierbei sind ein verteiltes Systemdesign, Wiederherstellungsplanung und die Handhabung von Veränderungen.
Die Säule Leistung und Effizienz befasst sich mit der effizienten Nutzung von IT- und Rechenressourcen. Zu den wichtigsten Themen zählen die Auswahl der richtigen Ressourcen auf Basis der Arbeitslast, die Überwachung der Leistung sowie fundierte Entscheidungen zur Aufrechterhaltung der Effizienz auch bei wachsenden Geschäften.
Die Säule Kostenoptimierung befasst sich mit der Vermeidung unnötiger Kosten. Der Schlüssel zum Erfolg dabei ist Sichtbarkeit auf die Kosten herzustellen, Budgets zu definieren und Ausgaben regelmäßig zu analysieren und darauf basierend kontinuierlich zu optimieren.

Das AWS Well-Architected Framework basiert auf generellen Designprinzipien, die helfen, ein gutes Design einer Applikation in der Cloud zu erreichen. Ein solches Prinzip ist zum Beispiel, Architekturen datengetrieben zu entwickeln. Es ist möglich geworden, Einfluss von Architekturentscheidungen zu messen und darauf basierend eine faktenbasierte Weiterentwicklung der Architektur zu betreiben. Jede neue Version der Architektur liefert neue Datenpunkte auf denen man eine kontinuierliche Evolution aufbauen kann.

Basierend auf den generellen Designprinzipien werden für jede der Säulen spezifische Prinzipien abgeleitet. Durch geeignete Fragen kann nun der Umsetzungsgrad einer zu prüfenden Architektur gemessen und daraus dann das Ergebnis des Reviews abgeleitet werden.

Wie führt man ein Well-Architected Framework Review am effektivsten?

Um ein erfolgreiches Review durchzuführen, muss man zunächst sicherstellen, dass alle Beteiligten über das Gleiche sprechen. Zunächst erscheint dies trivial, aber in der Praxis zeigt sich, dass es viele verschiedene Sichten auf einen scheinbar eindeutigen Gegenstand eines Reviews gibt. Zum Beispiel fasst der eine Teilnehmer des Reviews unter einem E-Commerce-Stack möglicherweise nur die Applikationen auf, die den Onlineshop bereitstellen, während andere Teilnehmer auch die Laufzeitumgebung, beispielsweise eine Container-Runtime dazu zählen. Wieder andere würden gegebenenfalls auch noch das Lagerbestandssystem mit unter den Begriff E-Commerce-Stack summieren. Keine der Sichten ist falsch, aber es ist extrem wichtig, gleich am Anfang des Reviews ein gemeinsame Sicht zu etablieren. Dazu definiert man gemeinsam den Workload der betrachtet werden soll. Hilfreich hierbei ist es, explizit aufzuschreiben, welche Komponenten wir als Workload betrachten und gegebenenfalls auch Beispiele aufzuführen, die illustrieren, was nicht zu einem Workload gehört.

Nachdem wir uns auf den zu analysierenden Workload geeinigt haben, ist ein weiterer wichtiger Schritt, sich auf eine gemeinsame Version des Workloads zu einigen. So mag der Entwickler seine letzte Codeänderung bereits in dem Ist-Zustand eines Workloads betrachten, während aus einer Betriebssicht diese Änderung noch gar nicht Realität ist. Der Architekt wiederum mag bereits entworfene, aber noch nicht implementierte Verbesserungen als Ist-Zustand betrachten. Hier stellt es sich als sinnvoll heraus, das aktuelle Produktionssystem als Grundlage für den Review zu definieren.

Wir haben bereits gesehen, dass verschiedene Teilnehmer unterschiedliche Sichten auf den Workload mitbringen. Neben einer gemeinsamen Sicht ist es ebenfalls unabdingbar, dass wir die richtigen Teilnehmer bei dem Review haben, die gemeinsam alle Aspekte des Well-Architected Framework Reviews abdecken können. Ebenso ist es ersichtlich, dass das durch die fünf Säulen des Well-Architected Frameworks definierte Themenspektrum sehr breit ist. Die Anzahl der Personen und der zu involvierenden Fachabteilungen kann je nach Organisation des Unternehmens recht breit sein. In einer funktional strukturierten Organisation müssen Teilnehmer aus den verschiedenen Fachbereichen zusammengebracht werden, damit gemeinsam Aspekte wie Entwicklung, Betrieb und Sicherheit abgedeckt werden können. In Organisationen, die auf agilen und eigenständigen Teams basieren, die alle Aspekte eines Workloads abdecken, reicht es in den meisten Fällen aus, das Team zu dem Review einzuladen. Unabhängig von der Organisationsstruktur des Unternehmens, ist es wichtig, die Business-Seite nicht zu vergessen. IT-Systeme werden ja nicht zum Selbstzweck gebaut und betrieben, sondern um Kunden zu bedienen und Mehrwert zu schaffen. Dies sind somit auch wichtige Aspekte, die bei einem Well-Architected Framework Review betrachtet werden sollen. Daher ist es wichtig, dass die Teilnehmer des Reviews auch diese Anforderung abdecken können. Bei agilen Teams ist es ausreichend, den Product Owner dabei zu haben, der die Kundensicht vertritt.

Während es elementar ist, alle angesprochenen Bereiche des Well-Architected Framework Reviews mit den Teilnehmern abdecken zu können, ist es ebenso wichtig, die Teilnehmeranzahl zu begrenzen. In einer zu großen Gruppe ufern die wichtigen Diskussionen häufig zu sehr aus und es wird schwer, das Review in einer angemessenen Zeit umzusetzen. Setzt sich die Teilnehmergruppe aus verschiedenen Fachabteilungen zusammen, ist es meistens ausreichend, eine stellvertretende Person pro Abteilung mit in das Review zu nehmen. Vorausgesetzt, dass diese das Team im Kontext des Reviews auch vollständig und adäquat vertreten kann. Die Key-Player, die den Workload entwickeln und betreiben, müssen dabei sein. Zusätzlich ist die Terminfindung bei kleineren Gruppen häufig wesentlich leichter. Hier lässt sich die Two-Pizza-Regel gut anwenden [4]. Teams und Teilnehmergruppen von Besprechungen sollte nicht größer sein, als dass man sie mit zwei Pizzen sättigen könnte – Amerikanische Pizzen, also 8-10 Leuten. Weniger ist hier häufig mehr um ein effektives Review durchzuführen.

Diskussionen im Review-Meeting sind gewollt und wertvoll. Häufig ist ein solches Review-Meeting eine der wenigen Gelegenheiten, bei denen alle relevanten Sichten vereint werden. Was wir vermeiden wollen ist, in unproduktive, gegebenenfalls zu detailverliebte Diskussionen abzugleiten. Hier ist eine aktive Moderation gefragt, die auf ein gemeinsames Ziel hinarbeitet. Diese Moderation kann sehr gut von erfahrenen Personen, typischerweise Architekten, vorgenommen werden, die nicht unmittelbar an dem Workload beteiligt sind und damit unvoreingenommen durch das Review führen kann. Argumente und zusätzlich aufkommende Themen können notiert werden und zu einem späteren Zeitpunkt aufgegriffen werden. Sollte es nicht möglich sein, sich auf eine gemeinsame Beantwortung einer Frage zu einigen, kann auch das notiert werden. Bestehen Uneinigkeiten, ob eine bestimmte Methodik, ein Prozess oder Best Practice aktuell implementiert ist, sollten wir diese als nicht implementiert verzeichnen und im Nachgang noch einmal überprüfen. In den allermeisten Fällen ist eine Uneinigkeit ein gutes Indiz dafür, dass es zumindest keine ganzheitliche Implementierung gibt und von daher Optimierungspotenzial besteht. Sehr oft kommt es vor, dass durch die Diskussionen während des Well-Architected Framework Reviews Informationslücken sichtbar werden. Gerade in Reviews komplexerer Workloads, mit Beteiligung von teamübergreifenden Verantwortlichen stellen Teams beispielsweise immer wieder fest, dass doch Richtlinien zu einem bestimmten Thema definiert sind, dies aber noch nie bei dem Team angekommen ist. Nicht selten werden in solchen Fällen direkt interne Follow-up-Termine vereinbart um diese Lücken zu schließen.

Wie steht das Team der Idee des Reviews gegenüber? Gibt es Bedenken?

Es ist wichtig, vor dem eigentlichen Review zu definieren, zu welchem Zweck das Review durchgeführt werden soll. Motivationen können mannigfaltig sein. Es könnte beispielsweise sein, dass das für den Workload verantwortliche Team für sich selber analysieren möchte, welche Schwachstellen die aktuelle Architektur des Workloads hat. Mängel können dabei häufig schnell analysiert werden. Aber auch in diesem Fall ist sicherzustellen, dass keine beteiligte Person Scheu davor hat, Fehler einzugestehen oder versucht ist, die eigene Arbeit zu verteidigen oder in einem besseren Licht dastehen zu lassen. Dies erreicht man am einfachsten, wenn man vorab klärt, dass die Ergebnisse des Reviews nur im Kreis der unmittelbar Beteiligten verbleiben.

Eine andere Motivation könnte sein, gefundene Schwächen und die aus der Behebung anstehenden Aufwände zu dokumentieren, um darauf basierend zusätzliche Ressourcen, wie Mitarbeiter oder Zeit, einzufordern. Wenn dieses klar kommuniziert wird, können ebenfalls gute Ergebnisse erzielt werden.

Am schwierigsten ist es, wenn ein Review von außen beauftragt wird, beispielsweise durch das Management oder gar mit der Motivation verbunden ist, Datenpunkte für ein externes Audit zu liefern. Hier muss man viel Aufwand darauf verwenden, trotz dieser potenziell unangenehmen Situation eine vertrauensvolle Umgebung zu schaffen, in der Probleme offen angesprochen werden können. Der Moderator eines solchen Reviews muss Antworten umso kritischer hinterfragen, um das Ziel eines realistischen Reviewergebnisses zu erreichen.

Ein wichtiger Aspekt ist es das Mindset der Teilnehmer zu justieren. Eine festgestellte Unzugänglichkeit – auch wenn sie mit einem hohen Risiko verbunden ist (High-Risk-Item) – dokumentiert kein Versagen, sondern die Möglichkeit, eine Verbesserung vorzunehmen. Dabei ist es gut, dies bereits in einem Review festzustellen und nicht erst dann, wenn das Risiko eintritt und gegebenenfalls einen Produktionsausfall provoziert.

Wie kann ich das AWS Well-Architected Framework auf meinen Workload anpassen?

Das Ziel des AWS Well-Architected Frameworks ist es, einheitliche Prinzipien und Best Practices zur Verfügung zu stellen, die auf viele verschiedene Workloads angewandt werden können. Dabei ist es unabdingbar, dass zum Einen nicht alle möglichen Aspekte eines speziellen Workloads abgedeckt werden können und zum Anderen, dass alle Aspekte in der für den spezifischen Workload notwendigen Tiefe abgehandelt werden.

Um die besten Ergebnisse zu erzielen, ist es hilfreich, dass verschiedene Aspekte, die auf den untersuchten Workload nicht zutreffen, aus dem Review ausgeblendet werden können. Die Erfahrung zeigt aber, dass in den allermeisten Fällen diese nach gründlichem Nachdenken doch zutreffen oder zu einem späteren Entwicklungsschritt des Workloads zutreffen werden. Dann macht es Sinn, diese Aspekte im Review zu belassen und gemäß des jetzigen Standes zu beantworten. Damit ist sichergestellt, dass diese nicht untergehen und eventuell erforderliche Maßnahmen geplant und zum richtigen Zeitpunkt getroffen werden können.

Nachdem wir nun sichergestellt haben, dass wir die Breite auf der wir einen Review ausführen, justieren können, müssen wir nun noch sicherstellen, dass wir auch die Tiefe des Reviews so modifizieren können, dass es für unseren Workload Sinn macht. Hier kommen die AWS Well-Architected Framework Lenses in Spiel. Diese sind Erweiterungen des AWS Well-Architected Frameworks. Dabei stehen verschiedene branchen- und technologiespezifischen Lenses zur Verfügung. Damit können zum Beispiel die Spezifika der Workloads, die Maschinelles Lernen beinhalten, detailliert betrachtet werden.

Welche Ergebnisse kann ich mit einem AWS Well-Architected Framework erreichen?

Die Ergebnisse eines AWS Well-Architected Framework Reviews können vielfältig sein und unterschiedlich genutzt werden. In den aller seltensten Fällen wird das Reviewergebnis lauten: Alles ist perfekt umgesetzt und es gibt keine weiteren Empfehlungen. Aber selbst dann ist ein solches Review extrem wertvoll, da man nun die Gewissheit hat, dass der Workload well-architected ist.

Bei dem Großteil der Well-Architected Framework Reviews ergeben sich eine Anzahl von festgestellten Risiken zusammen mit konkreten Lösungsvorschlägen und Empfehlungen. Dies ist ein idealer Startpunkt, um diese Aufgaben in die Planung für die nächsten Releases aufzunehmen und eine Priorisierung basierend der identifizierten Risiken vorzunehmen. In die Welt der agilen Methoden übersetzt ist das Ergebnis eines Well-Architected Framework Reviews eine Anzahl von User Stories, die bereits gut qualifiziert sind, um zur Priorisierung in das Backlog überführt werden zu können. Bildlich gesprochen verlässt das Team nach dem Review einen Tisch voll mit Post-its.

Eine elementare Idee des AWS Well-Architected Frameworks ist die Verwendung, die über ein einmaliges Review hinaus geht. Hier macht es Sinn, Reviews in regelmäßigen Zeitabständen zu machen, die es erlauben, den Fortschritt in Richtung eines Well-Architected Workloads sichtbar zu machen, während die gefundenen Schwachstellen nach und nach gemäß der Priorisierung basierend auf den generierten Empfehlungen abgearbeitet werden können. Damit vermeidet man, dass die potentiell überwältigende Masse an Dingen, die verbessert werden müssen, eine wirkliche Umsetzung verhindern. Teams können dies strukturiert angehen.

Eine weitere Anwendung ist es, AWS Well-Architected Framework Reviews in den eigenen Entwicklungsprozess einzubinden. Das Framework kann eine gute Inspiration zur Definition von Standardanforderungen für Neuentwicklungen sein. Tatsächlich ist es empfehlenswert, das Well-Architected Framework Review in die "Definition of Done" zu übernehmen. Über diese Klammer kann erreicht werden, dass neue Entwicklungen die Aspekte des Well-Architected Frameworks frühzeitig betrachten und gleich von Beginn in Design und Implementierung einbeziehen. Dadurch werden nachträgliche Fehlerkorrekturen bereits in der Entwicklungsphase vermieden; was dann einen signifikanten Einfluss auf die Produktivität des Service-Teams hat. Mängel im System führen, wie wir wissen, zu ungeplanter Arbeit, die uns von unserer eigentlicher Arbeit abhält [5].

Welche Werkzeuge kann ich benutzen um ein AWS Well-Architected Framework Review durchzuführen?

Ein weiterer wichtiger Aspekt ist eine gute Unterstützung durch Werkzeuge, die es ermöglichen, AWS Well-Architected Framework Reviews effizient durchzuführen. Dabei ist es wichtig einen guten Zugang zu dem Fragenkatalog zu haben, damit das Team diese bequem gemeinsam beantworten kann. Dazu kann das Well-Architected Tool [6] in der AWS Console genutzt werden. Hier kann das Team den zu betrachtenden Workload definieren und den Fragenkatalog ausfüllen. Dabei unterstützt das Tool aktiv mit Hilfestellungen zur Beantwortung der Fragen und detaillierten Beschreibungen.

Für jede gefundene Schwachstelle wird eine Priorität angezeigt und konkrete Maßnahmen zur Behebung vorgeschlagen, die es dem Team vereinfachen, die Reise in Richtung eines AWS Well-Architected Workloads zu planen und umzusetzen. Auch bei der Umsetzung dieser Maßnahmen gilt das Motto: "Probieren geht über Studieren". Mit dem AWS Well-Architected Labs [7] kann man bei Interesse in einer Laborumgebung wichtige Maßnahmen direkt ausprobieren und besser verstehen, bevor man diese auf den eigenen, potentiell komplexen, Workload anwendet.

Wie zuvor erwähnt, macht es Sinn einen gegebenen Workload nicht nur einmalig zu analysieren, sondern dies kontinuierlich zu tun. Dabei unterstützt das Tool die Serviceteams mit der Möglichkeit, mehrere Versionen eines Reviews anzulegen und zu verwalten. Auch Meilensteine können direkt im Tool definiert werden.

Durch den AWS Identity and Access Management (IAM) Dienst [8] können Zugriffsberechtigungen zu den Reviewdaten definiert und gesteuert werden, um diese sensitiven Daten bedarfsgerecht zu schützen.

Durch eine bereitgestellte API-Schnittstelle [9] kann das AWS Well-Architected-Tool in andere Systeme, wie z. B. zentralisierte Reporting-Tools, integriert werden; auch identifizierte Risiken können damit nahtlos in die bereits existierende Tool- und Prozesslandschaft überführt werden.

Wie geht es weiter?

Einen sehr guten Zugang zum AWS Well-Architected Framework erhält man, wenn man es tatsächlich auf einen existierenden Workload anwendet. Auf diese Weise baut man nicht nur ein tieferes Verständnis über den Workload und das AWS Well-Architected Framework auf, sondern auch für die zugrunde liegenden Design-Prinzipien, die damit Grundlage von zukünftigen Architekturentscheidungen werden können. Einen tieferen Einblick in das Framework bietet die ausführliche Online-Dokumentation [10].

Viel Spaß und Erfolg bei der Umsetzung von AWS Well-Architected Workloads!

Quellen