Blog

So überprüft ihr euer AWS Well-Architected Framework: Ein kurzer Leitfaden

DEC 9, 2022

Ist euch aufgefallen, dass die Cloud nicht so einfach ist, wie uns oft glauben gemacht wird?

Butrint Ferole

Butrint is a Cloud Architect at Eficode. Has worked in and around IT for more than 10 years. Started off helping his brother set up IT infrastructure for public schools and more recently working with various known companies and organizations and financial institutions designing and implementing their AWS solutions.

Viele Unternehmen lassen sich mitreißen und stürmen in die Cloud, voller Erwartung auf all die offensichtlichen Vorteile, die sie sich davon versprechen. Es ist ein Goldrausch – doch viele Unternehmen gehen leer aus.

Als erfahrener „Goldsucher“ möchte ich mit euch teilen, was ihr über das Well-Architected Framework wissen und wie ihr es nutzen solltet. Richtig eingesetzt, ist es eine hervorragende Möglichkeit, das Beste aus AWS herauszuholen.

Zunächst drei unbequeme Wahrheiten:

  • Es ist schwierig, eine gute Sicherheit aufrechtzuerhalten und Entwicklern sowie Administratoren gleichzeitig einfachen Zugriff auf Cloud-Ressourcen zu ermöglichen.

  • Dinge gehen schief. Wenn ihr keine solide Strategie für Datensicherungen habt oder euch Pläne für die Wiederherstellung im Katastrophenfall fehlen, leidet euer gesamtes Unternehmen, wenn es unweigerlich zu einem Ausfall kommt.

  • Selbst bei einer soliden technischen Umsetzung – mit hoher Verfügbarkeit, guter Performance und passendem Monitoring – kann die monatliche Rechnung unnötig hoch, ja geradezu erschreckend hoch ausfallen.

Unternehmen aller Arten und Größen kommen irgendwann an den Punkt, an dem sie sich fragen: „Machen wir das wirklich richtig? Gibt es einen einfacheren, besseren oder günstigeren Weg, unsere Cloud effektiv zu betreiben?“

Um diese Fragen zu beantworten, veröffentlicht und verfeinert AWS seit 2015 kontinuierlich sein „Well-Architected Framework“ – eine aktuelle, übersichtliche Sammlung von Best Practices, die allen kostenlos zur Verfügung steht.

Lest weiter und erfahrt mehr über:

  1. Was dieses Best-Practice-Framework ist

  2. Warum es relevant ist und wie es euch helfen kann

  3. Wie ihr die wichtigsten Änderungen bewertet und umsetzt, um Best Practices einzuhalten

Was dieses Best-Practice-Framework ist

Warum es relevant ist und wie es euch helfen kann

Wie ihr die wichtigsten Änderungen bewertet und umsetzt, um Best Practices einzuhalten

Beginnen wir also mit einer einfachen Einführung in das AWS Well-Architected Framework.

Das Well-Architected Framework

2015 veröffentlichte AWS ein Whitepaper mit dem Titel „AWS Well-Architected Framework“. Ziel war es, alle Best Practices und Architekturherausforderungen herauszuarbeiten und die wichtigsten Fragen zu beantworten, die mit dem Aufschwung von Cloud Computing und Cloud-Services entstanden.

Die gesammelten Erfahrungen wurden in fünf Säulen – inzwischen sechs – dargestellt. Sie sollten alle Architekturentscheidungen abdecken und das bestmögliche Ergebnis für den Betrieb von Workloads in der Cloud sicherstellen.

Die sechs Säulen definieren einen umfassenden Katalog an Fragen und Überlegungen, der technische und geschäftliche Aspekte gleichermaßen berücksichtigt.

Diese sechs Säulen sind:

  • Operative Exzellenz

  • Sicherheit

  • Zuverlässigkeit

  • Performance-Effizienz

  • Kostenoptimierung

  • Nachhaltigkeit

Operative Exzellenz

Sicherheit

Zuverlässigkeit

Leistungseffizienz

Kostenoptimierung

Nachhaltigkeit

Jede Säule umfasst Definitionen, Designprinzipien und Best Practices, die euch dabei helfen:

  1. Bereiche zu identifizieren, deren Verbesserung den größten Nutzen bringt

  2. Verschiedene Aspekte eurer Geschäftsstrategie im Hinblick auf das technische Design und die Implementierung zu betrachten und umzusetzen

Warum ihr Well-Architected Reviews durchführen solltet

Wenn Unternehmen erstmals in die Cloud migrieren oder dort neue Workloads bereitstellen, wünschen sie sich in der Regel Agilität und möchten einfach loslegen.

Vorbei sind die Zeiten, in denen ein Unternehmen vorab in Hardware und Infrastruktur investieren musste – eine hohe Hürde, insbesondere für Startups mit ungewisser Zukunft.

Mit der Cloud könnt ihr Infrastruktur einfach nach Bedarf bereitstellen und skalieren und bezahlt nur, was ihr nutzt. Wenn ihr den Betrieb einstellen müsst, schaltet ihr einfach alle Cloud-Ressourcen ab und zahlt nichts mehr.

Doch diese Agilität hat für viele Unternehmen ihren Preis:

Das Problem, das typischerweise entsteht, sobald ihr in der Cloud seid

Typischerweise passiert Folgendes:

Mit der Agilität der Cloud wollen Unternehmen ihre Time-to-Market verkürzen. Deshalb machen sie Abstriche bei der Sicherheit, im Betrieb und in anderen wichtigen Bereichen. Mit der Zeit verschärfen sich diese Probleme. Denn mit steigender Nachfrage wachsen auch Umfang und Komplexität der bestehenden technischen Lösungen.

Wie sich dieses Problem mit einem Well-Architected Review am besten lösen lässt

Da eure technischen Lösungen immer komplexer werden, ist es wichtig, so früh wie möglich eine solide Grundlage aus Best Practices aufzubauen oder zu verbessern – sowohl im Design als auch in Richtlinien. Das gilt besonders für kritische Workloads und Betriebsabläufe wie Playbooks und Runbooks.

Denkt jedoch daran: Das ist keine einmalige Aufgabe.

Mit der Zeit kommt es zu Abweichungen bei Konfiguration und Betrieb. Deshalb ist es wichtig, euren Well-Architected Review nach seinem Abschluss regelmäßig erneut durchzuführen.

AWS empfiehlt außerdem, einen Review im Zusammenhang mit wichtigen Meilensteinen im Entwicklungszyklus durchzuführen und anschließend bewährte Routinen zu etablieren, um eine Verschlechterung des Workload-Designs zu verhindern. Als Faustregel gilt: alle 12 bis 18 Monate.

Die 3 wichtigsten Gründe für einen Well-Architected Review

  1. Sorgt dafür, dass eure Workloads sicher, zuverlässig und gegen Fehler und Ausfälle abgesichert sind

  2. Senkt Kosten – manchmal erheblich –, indem ihr intelligente Sparpläne nutzt oder Ressourcen außerhalb der Betriebszeiten abschaltet

  3. Identifiziert Verbesserungspotenziale in eurem Betrieb und in den Lebenszyklen eurer Ressourcen, um die Leistungseffizienz zu steigern

Sorgt dafür, dass eure Workloads sicher, zuverlässig und gegen Fehler und Ausfälle abgesichert sind

Senkt Kosten – manchmal erheblich –, indem ihr intelligente Sparpläne nutzt oder Ressourcen außerhalb der Betriebszeiten abschaltet

Identifiziert Verbesserungspotenziale in eurem Betrieb und in den Lebenszyklen eurer Ressourcen, um die Leistungseffizienz zu steigern

Um AWS optimal zu nutzen, solltet ihr das Well-Architected Framework bei der Gestaltung eurer Architektur berücksichtigen. Im folgenden Abschnitt erfahrt ihr, wie ihr Best Practices mithilfe eines einfachen Tools unkompliziert umsetzt.

Das Well-Architected Tool

Das „Well-Architected Tool“ von AWS ist über die AWS-Konsole kostenlos verfügbar und unterstützt euch dabei, die Best Practices des Well-Architected Framework anzuwenden.

Es sammelt keine Daten aus den tatsächlichen Workloads. Stattdessen bietet es allen Beteiligten – Architekten sowie Kunden und Stakeholdern – eine einheitliche Checkliste mit Best Practices und Notizen. Diese können sowohl vom Kunden als auch vom Service Provider, beispielsweise Eficode, über AWS-Konten hinweg geteilt werden.

Mit dem Tool betrachten der Architekt und der Verantwortliche für den Workload diesen aus der Perspektive der sechs Säulen.

Jede Säule beleuchtet unterschiedliche Aspekte des Workloads, stellt Fragen aus technischer Sicht und prüft, wie gut die technische Lösung mit den individuellen Geschäftszielen und wichtigen Ergebnissen des Verantwortlichen übereinstimmt. Die Fragen unterscheiden sich in ihrer Komplexität und sind nicht alle relevant. Wird eine Frage als irrelevant eingestuft, wird sie in den zusammengefassten Ergebnissen und der Gesamtbewertung am Ende des Reviews einfach nicht berücksichtigt.

Die finalen Ergebnisse heben Probleme mit mittlerem bis hohem Risiko hervor. Probleme mit hohem Risiko sollten möglichst schnell behoben werden, während Probleme mit mittlerem Risiko möglicherweise gar nicht angegangen werden müssen.

Was ihr in einem Well-Architected Review betrachtet: die sechs Säulen

Die sechs Säulen bilden die Grundlage des gesamten Reviews. Ihr analysiert und diskutiert jede von ihnen ausführlich. Im Folgenden findet ihr eine kurze Einführung und Zusammenfassung der Säulen sowie der zentralen Konzepte, die sie definieren.

1. Operative Exzellenz

Unabhängig davon, wie klein ein Workload ist, ist immer ein gewisser Betriebsaufwand erforderlich. Jemand muss verfügbar sein, wenn etwas schiefläuft, geändert werden muss oder am Ende eines Ressourcenlebenszyklus entfernt wird. Entscheidend ist dabei die Exzellenz: Workloads wie eine gut geölte Maschine zu betreiben, spart langfristig Zeit, Aufwand und Kosten.

Im Kern geht es bei dieser Säule darum, wie ihr eure betrieblichen Aufgaben so gestaltet, dass ihr auf möglichst effiziente Weise Spitzenleistungen erzielt. Sie umfasst vier Bereiche mit Best Practices:

  • Organisation: Versteht die Prioritäten und Struktur eurer Organisation und macht sichtbar, wie sie ihre Teammitglieder unterstützt.

  • Vorbereiten: Versteht eure aktuellen Workloads und ihr erwartetes Verhalten. Ihr erhaltet Einblicke in ihren Status und die Prozesse, die sie unterstützen.

  • Betreiben: Macht den Zustand eures Workloads und eures Betriebs sichtbar. Erkennt außerdem, wo ein bestimmter Workload gefährdet sein könnte und wie ihr angemessen reagiert.

  • Weiterentwickeln: Erkennt, wo ihr euch verbessern könnt, und definiert Erkenntnisse aus früheren betrieblichen Aktivitäten sowie deren Erfolgsquote für künftige schrittweise Veränderungen.

Organisation: Versteht die Prioritäten und Struktur eurer Organisation und macht sichtbar, wie sie ihre Teammitglieder unterstützt.

Vorbereiten: Versteht eure aktuellen Workloads und ihr erwartetes Verhalten. Ihr erhaltet Einblicke in ihren Status und die Prozesse, die sie unterstützen.

Betreiben: Macht den Zustand eures Workloads und eures Betriebs sichtbar. Erkennt außerdem, wo ein bestimmter Workload gefährdet sein könnte und wie ihr angemessen reagiert.

Weiterentwicklung: Erkennt, wo ihr euch verbessern könnt, und haltet Erkenntnisse aus früheren operativen Aktivitäten sowie deren Erfolgsquote fest, um künftige schrittweise Änderungen vorzunehmen.

Ein Beispiel dafür, wie die Zusammenfassung eurer Säule „Operational Excellence“ aussehen könnte

  • Nutzt Automatisierung, wo immer möglich.

  • Nehmt häufig kleine und rückgängig zu machende Änderungen vor.

  • Optimiert Betriebsprozesse regelmäßig.

  • Lernt aus allen operativen Fehlern.

  • Rechnet mit Fehlern.

  • Lernt aus allen operativen Fehlern.

2. Sicherheit

Diese Säule zeigt, wie ihr die neuesten Cloud-Technologien nutzen könnt, um eure Workloads sicherer zu machen. Sicherheit galt früher oft als eher trockenes Thema, ist heute jedoch umso wichtiger. Die Säule baut gewissermaßen auf Operational Excellence auf und behandelt, wie ihr eine gute Betriebshygiene und eine robuste technische Architektur sicher umsetzt.

Die Säule Sicherheit umfasst sechs Bereiche mit Best Practices:

  • Grundlage: Erfahrt, wie eine Grundlage aufgebaut sein sollte, damit ihr mit euren Ressourcen möglichst sicher arbeiten könnt.

  • Identitäts- und Zugriffsmanagement: Erfahrt, wie ihr Nutzern einen robusten und sicheren Zugriff auf Ressourcen in euren Workloads ermöglicht. Es besteht aus:

  • Erkennung: Macht sichtbar, wo potenzielle Bedrohungen, Fehlkonfigurationen und/oder unerwartete Verhaltensweisen eure Workloads beeinträchtigen könnten.

  • Infrastrukturschutz: Nutzt verschiedene Best-Practice-Methoden, um eure Infrastruktur so sicher wie möglich zu halten. Schützt eure Ressourcen vor Sicherheitsbedrohungen – sowohl unbeabsichtigten als auch unbefugtem Zugriff – und findet potenzielle Schwachstellen.

  • Datenschutz: Macht sichtbar, wie ihr eure Daten verschlüsseln und kategorisieren solltet, beispielsweise durch Verschlüsselung sowohl im Ruhezustand als auch bei der Übertragung, und wie ihr sie klassifiziert.

  • Reaktion auf Vorfälle: Implementiert verschiedene Mechanismen, um auf künftige Sicherheitsvorfälle zu reagieren und ihre Auswirkungen zu mindern.

Grundlage: Erfahrt, wie eine Grundlage aufgebaut sein sollte, damit ihr mit euren Ressourcen möglichst sicher arbeiten könnt.

Identitäts- und Zugriffsmanagement: Erfahrt, wie ihr Nutzern einen robusten und sicheren Zugriff auf Ressourcen in euren Workloads ermöglicht. Es besteht aus:

  • Identitätsmanagement: Wie ihr Identitäten von Mitarbeitern und Workloads verwaltet, etwa von Anwendungen, Betriebssystemtools und Komponenten, die Anfragen an eure AWS-Ressourcen stellen müssen.

  • Berechtigungsmanagement: Wie ihr Sicherheit mit Richtlinien, Grenzen, Attribute-based access control (ABAC) und Service Control Policies (SCP) verwaltet.

Identitätsmanagement: Wie ihr Identitäten von Mitarbeitern und Workloads verwaltet, etwa von Anwendungen, Betriebssystemtools und Komponenten, die Anfragen an eure AWS-Ressourcen stellen müssen.

Berechtigungsmanagement: Wie ihr Sicherheit mit Richtlinien, Grenzen, Attribute-based access control (ABAC) und Service Control Policies (SCP) verwaltet.

Erkennung: Macht sichtbar, wo potenzielle Bedrohungen, Fehlkonfigurationen und/oder unerwartete Verhaltensweisen eure Workloads beeinträchtigen könnten.

Infrastrukturschutz: Nutzt verschiedene Best-Practice-Methoden, um eure Infrastruktur so sicher wie möglich zu halten. Schützt eure Ressourcen vor Sicherheitsbedrohungen – sowohl unbeabsichtigten als auch unbefugtem Zugriff – und findet potenzielle Schwachstellen.

Datenschutz: Visualisiert, wie ihr eure Daten verschlüsseln und kategorisieren solltet (zum Beispiel durch Verschlüsselung sowohl ruhender als auch übertragener Daten) und wie ihr sie klassifiziert.

Reaktion auf Sicherheitsvorfälle: Implementiert verschiedene Mechanismen, um auf zukünftige Sicherheitsvorfälle zu reagieren und ihre Auswirkungen zu minimieren.

Ein Beispiel dafür, wie eure Zusammenfassung der Säule „Sicherheit“ aussehen könnte

  • Trennt verschiedene Workloads nach Konto anhand ihrer Funktion, Compliance-Anforderungen oder Anforderungen an die Datensensibilität.

  • Benutzerzugriffe sollten nach dem Prinzip der geringsten Berechtigung und nach Best Practices gewährt werden, einschließlich Passwortanforderungen und verpflichtender MFA.

  • Es ist entscheidend, Logs zu analysieren und darauf zu reagieren, damit ihr potenzielle Sicherheitsvorfälle erkennen könnt. Ein wirksamer Informationssicherheitsplan erfordert den Schutz von Grenzen, die Überwachung von Ein- und Austrittspunkten sowie umfassendes Logging, Monitoring und Alerting.

  • Stellt sicher, dass ihr eurem Sicherheitsteam schnell Zugriff gewähren könnt, und automatisiert die Isolierung von Instanzen sowie die Erfassung von Daten und Zuständen für forensische Untersuchungen.

3. Zuverlässigkeit

Hier analysiert ihr Workloads eingehend und bewertet, ob sie ihre vorgesehenen Funktionen wie gewünscht erfüllen. Ist der Workload selbstheilend? Führt ihr während seines gesamten Lebenszyklus kontinuierlich Tests durch? Erfüllen der Workload und die Daten die Anforderungen an Verfügbarkeit und Redundanz?

Zuverlässigkeit konzentriert sich auf vier Bereiche mit Best Practices:

  • Grundlagen: Erfahrt, wie ihr ein solides Fundament schafft, das über einen einzelnen Workload hinausgeht.

  • Workload-Architektur: Ein zuverlässiger Workload beginnt mit frühzeitigen Designentscheidungen für Software und Infrastruktur. Eure Architekturentscheidungen beeinflussen das Verhalten eures Workloads über alle Well-Architected-Säulen hinweg. Für die Zuverlässigkeit gibt es spezifische Muster, die ihr befolgen müsst.

  • Änderungsmanagement: Beschreibt, wie ihr eure Ressourcen überwacht, Änderungen umsetzt und eure Workloads so gestaltet, dass sie möglichst offen für Änderungen sind.

  • Fehlermanagement: Erfahrt beispielsweise, was ihr tun müsst, um euren Workload resilient zu gestalten, wie ihr Backups und Tests verwaltet und wie ihr die Disaster Recovery plant.

Grundlagen: Erfahrt, wie ihr ein solides Fundament schafft, das über einen einzelnen Workload hinausgeht.

Workload-Architektur: Ein zuverlässiger Workload beginnt mit frühzeitigen Designentscheidungen für Software und Infrastruktur. Eure Architekturentscheidungen beeinflussen das Verhalten eures Workloads über alle Well-Architected-Säulen hinweg. Für die Zuverlässigkeit gibt es spezifische Muster, die ihr befolgen müsst.

Änderungsmanagement: Beschreibt, wie ihr eure Ressourcen überwacht, Änderungen umsetzt und eure Workloads so gestaltet, dass sie möglichst offen für Änderungen sind.

Fehlermanagement: Erfahrt beispielsweise, was ihr tun müsst, um euren Workload resilient zu gestalten, wie ihr Backups und Tests verwaltet und wie ihr die Disaster Recovery plant.

Ein Beispiel dafür, wie eure Zusammenfassung der Säule „Zuverlässigkeit“ aussehen könnte

  • Entwerft einen Workload so, dass er Ressourcen abhängig vom Bedarf automatisch hinzufügt und entfernt. Das erhöht nicht nur die Zuverlässigkeit, sondern stellt auch sicher, dass geschäftlicher Erfolg nicht zur Belastung wird.

  • Mit einem etablierten Monitoring wird euer Team automatisch benachrichtigt, wenn KPIs von den erwarteten Werten abweichen.

  • Die automatische Protokollierung von Änderungen an eurer Umgebung ermöglicht euch Audits und hilft euch, Maßnahmen schnell zu identifizieren, die die Zuverlässigkeit beeinträchtigt haben könnten.

  • Kontrollen im Änderungsmanagement stellen sicher, dass ihr die Regeln durchsetzen könnt, die die benötigte Zuverlässigkeit gewährleisten.

  • Sichert eure Daten regelmäßig und testet eure Backup-Dateien, damit ihr euch sowohl von logischen als auch von physischen Fehlern erholen könnt.

  • Ein wichtiger Aspekt des Fehlermanagements ist das häufige automatisierte Testen von Workloads, bei dem gezielt Fehler ausgelöst und anschließend beobachtet wird, wie sie sich davon erholen.

Entwerft einen Workload so, dass Ressourcen je nach Bedarf automatisch hinzugefügt und entfernt werden. Das erhöht nicht nur die Zuverlässigkeit, sondern stellt auch sicher, dass geschäftlicher Erfolg nicht zur Belastung wird.

Mit einem eingerichteten Monitoring wird euer Team automatisch benachrichtigt, wenn KPIs von den erwarteten Normwerten abweichen.

Die automatische Protokollierung von Änderungen in eurer Umgebung ermöglicht euch Audits und hilft euch, Aktionen, die die Zuverlässigkeit beeinträchtigt haben könnten, schnell zu identifizieren.

Kontrollen im Änderungsmanagement stellen sicher, dass ihr die Regeln durchsetzen könnt, die die benötigte Zuverlässigkeit gewährleisten.

Sichert eure Daten regelmäßig und testet eure Sicherungsdateien, um sicherzustellen, dass ihr euch sowohl von logischen als auch von physischen Fehlern erholen könnt.

Ein Schlüssel zum Umgang mit Ausfällen ist, Workloads regelmäßig und automatisiert gezielt zum Ausfall zu bringen und anschließend zu beobachten, wie sie sich erholen.

4. Leistungseffizienz

Im Pfeiler der Leistungseffizienz betrachtet ihr, wie ihr AWS-Ressourcen und -Services effizient nutzt und die Effizienz langfristig aufrechterhaltet, wenn der Bedarf des Workloads steigt und sich neue technische Lösungen weiterentwickeln.

Die Leistungseffizienz umfasst vier Bereiche mit Best Practices:

  • Auswahl: Stellt sicher, dass ihr die richtige Lösung für eure geschäftlichen Anforderungen ausgewählt habt. Dazu bewertet ihr die vorhandenen Ressourcen, die ihr für euren Workload ausgewählt habt, anhand folgender Kriterien:

  • Überprüfung: Stellt euch einige wichtige Fragen dazu, wie euer Prozess zur Leistungsüberprüfung funktioniert. Zum Beispiel: Nutzt ihr noch veraltete Ressourcen und Services? Habt ihr einen Prozess zur Verbesserung der Workload-Performance?

  • Monitoring: Legt fest, wie ihr Monitoring und Alarme optimal nutzt und einrichtet.

  • Kompromisse: Überlegt, welche Kompromisse ihr für einen leistungsfähigeren Workload eingehen möchtet, etwa Konsistenz gegen Zeit und Latenz einzutauschen.

Auswahl: Stellt sicher, dass ihr die richtige Lösung für eure geschäftlichen Anforderungen ausgewählt habt. Dazu bewertet ihr die vorhandenen Ressourcen, die ihr für euren Workload ausgewählt habt, anhand folgender Kriterien:

  • Performance-Architektur

  • Compute-Architektur

  • Speicherarchitektur

  • Datenbankarchitektur

  • Netzwerkarchitektur

Performance-Architektur

Compute-Architektur

Speicherarchitektur

Datenbankarchitektur

Netzwerkarchitektur

Überprüfung: Stellt euch einige wichtige Fragen dazu, wie euer Prozess zur Leistungsüberprüfung funktioniert. Zum Beispiel: Nutzt ihr noch veraltete Ressourcen und Services? Habt ihr einen Prozess zur Verbesserung der Workload-Performance?

Monitoring: Ermittelt, wie ihr Monitoring und Alarme optimal nutzt und einrichtet.

Kompromisse: Überlegt, welche Kompromisse ihr für einen leistungsfähigeren Workload eingehen möchtet, etwa Konsistenz zugunsten von Zeit und Latenz.

Ein Beispiel dafür, wie eure Zusammenfassung der Säule „Leistungseffizienz“ aussehen könnte

  • Nutzt bei der Architektur für hohe Leistung die verfügbaren Elastizitätsmechanismen, damit ausreichend Kapazität vorhanden ist, um die Leistung bei wechselnder Nachfrage aufrechtzuerhalten.

  • Bei der Wahl einer Speicherlösung ist es entscheidend, dass sie zu euren Zugriffsmustern passt, um die gewünschte Leistung zu erreichen.

  • Datenbanken werden häufig nach organisatorischen Standards ausgewählt statt auf Basis eines datenbasierten Ansatzes. Wie bei Speicherlösungen ist es entscheidend, die Zugriffsmuster eures Workloads zu berücksichtigen und zu prüfen, ob andere Lösungen ohne Datenbank das Problem effizienter lösen könnten, etwa Graph-, Zeitreihen- oder In-Memory-Datenbanken.

  • Durch die Nutzung von Regions, Placement Groups und Edge Services könnt ihr die Netzwerkleistung deutlich verbessern. Netzwerke in der Cloud lassen sich im Laufe der Zeit einfach optimieren, da sie schnell neu aufgebaut oder angepasst werden können.

  • Für eine effektive Monitoring-Lösung ist es entscheidend, Fehlalarme zu vermeiden. Automatisierte Auslöser verhindern menschliche Fehler und können die Zeit bis zur Behebung von Problemen verkürzen.

  • Nutzt einen systematischen Ansatz wie Lasttests, um zu prüfen, ob eure Kompromisse die Leistung verbessern.

Nutzt bei der Architektur für hohe Leistung die verfügbaren Elastizitätsmechanismen, damit ausreichend Kapazität vorhanden ist, um die Leistung bei wechselnder Nachfrage aufrechtzuerhalten.

Bei der Wahl einer Speicherlösung ist es entscheidend, dass sie zu euren Zugriffsmustern passt, um die gewünschte Leistung zu erreichen.

Datenbanken werden häufig nach organisatorischen Standards ausgewählt statt auf Basis eines datenbasierten Ansatzes. Wie bei Speicherlösungen ist es entscheidend, die Zugriffsmuster eures Workloads zu berücksichtigen und zu prüfen, ob andere Lösungen ohne Datenbank das Problem effizienter lösen könnten, etwa Graph-, Zeitreihen- oder In-Memory-Datenbanken.

Durch die Nutzung von Regions, Placement Groups und Edge Services könnt ihr die Netzwerkleistung deutlich verbessern. Netzwerke in der Cloud lassen sich im Laufe der Zeit einfach optimieren, da sie schnell neu aufgebaut oder angepasst werden können.

Für eine effektive Monitoring-Lösung ist es entscheidend, Fehlalarme zu vermeiden. Automatisierte Auslöser verhindern menschliche Fehler und können die Zeit bis zur Behebung von Problemen verkürzen.

Nutzt einen systematischen Ansatz wie Lasttests, um zu prüfen, ob eure Kompromisse die Leistung verbessern.

5. Kostenoptimierung

Kosten sind oft ein Grund für die Migration in die Cloud. Der bedarfsgerechte Zugriff auf Rechenressourcen und die Möglichkeit, nur für die tatsächlich genutzten Ressourcen zu zahlen, können entscheidend für den Geschäftserfolg sein. Mit der Zeit und steigender Nachfrage wachsen auch die Workloads – und damit zwangsläufig die Kosten. Deshalb ist es wichtig, die aktuellen Ausgaben genau zu verstehen und Verbesserungsmöglichkeiten zu finden, die oft schnell umsetzbar sind.

Die Kostensäule umfasst fünf verschiedene Best-Practice-Bereiche:

  • Cloud Financial Management (CFM) anwenden: Erkennt, wo euer geschäftlicher Mehrwert liegt und wie ihr eure Finanzen durch Kostenoptimierung verbessern könnt.

  • Transparenz bei Ausgaben und Nutzung: Versteht, wie ihr eure Kosten und Nutzung möglichst effektiv steuert.

  • Kosteneffiziente Ressourcen: Bewertet, welche Ressourcen, Services und Konfigurationen ihr nutzen solltet, um Kosten zu senken.

  • Nachfrage und Ressourcenangebot verwalten: Analysiert die Anforderungen eures Workloads, etwa ob ihr Ressourcen dynamisch statt statisch bereitstellen könnt.

  • Im Laufe der Zeit optimieren: Entwickelt einen Prozess zur Überprüfung von Workloads, um neue kostensparende AWS Services in eure bestehenden Workloads einzubinden.

Cloud Financial Management (CFM) anwenden: Erkennt, wo euer geschäftlicher Mehrwert liegt und wie ihr eure Finanzen durch Kostenoptimierung verbessern könnt.

Transparenz bei Ausgaben und Nutzung: Versteht, wie ihr eure Kosten und Nutzung möglichst effektiv steuert.

Kosteneffiziente Ressourcen: Bewertet, welche Ressourcen, Services und Konfigurationen ihr einsetzen solltet, um Kosten zu senken.

Bedarfs- und Bereitstellungsressourcen verwalten: Analysiert die Anforderungen eurer Workloads, beispielsweise ob ihr Ressourcen dynamisch statt statisch bereitstellen könnt.

Kontinuierlich optimieren: Entwickelt einen Prozess zur Überprüfung eurer Workloads, um neue kostensparende AWS-Services in bestehende Workloads einzubinden.

Ein Beispiel dafür, wie die Zusammenfassung eurer Säule „Kostenoptimierung“ aussehen könnte

  • Wie bei den anderen Säulen gibt es auch hier Zielkonflikte zu berücksichtigen. Zum Beispiel, ob ihr Time-to-Market oder Kosten optimieren möchtet. In manchen Fällen ist es besser, auf Geschwindigkeit zu optimieren – also schnell auf den Markt zu kommen, neue Funktionen bereitzustellen oder einfach eine Frist einzuhalten –, statt vorab in Kostenoptimierung zu investieren.

  • Designentscheidungen werden manchmal eher von Zeitdruck als von Daten bestimmt. Zudem besteht immer die Versuchung, vorsorglich zu viel einzuplanen, statt Zeit in Benchmarking für das kosteneffizienteste Deployment zu investieren. Das kann zu überdimensionierten und nicht ausreichend optimierten Deployments führen.

  • Wenn ihr von Anfang an den richtigen Aufwand in eine Strategie zur Kostenoptimierung investiert, könnt ihr die wirtschaftlichen Vorteile der Cloud schneller nutzen. Denn ihr stellt so sicher, dass Best Practices konsequent eingehalten und unnötige Überdimensionierung vermieden werden.

Wie bei den anderen Säulen gibt es auch hier Zielkonflikte zu berücksichtigen. Zum Beispiel, ob ihr Time-to-Market oder Kosten optimieren möchtet. In manchen Fällen ist es besser, auf Geschwindigkeit zu optimieren – also schnell auf den Markt zu kommen, neue Funktionen bereitzustellen oder einfach eine Frist einzuhalten –, statt vorab in Kostenoptimierung zu investieren.

Designentscheidungen werden manchmal eher von Zeitdruck als von Daten bestimmt. Zudem besteht immer die Versuchung, vorsorglich zu viel einzuplanen, statt Zeit in Benchmarking für das kosteneffizienteste Deployment zu investieren. Das kann zu überdimensionierten und nicht ausreichend optimierten Deployments führen.

Wenn ihr von Anfang an den richtigen Aufwand in eine Strategie zur Kostenoptimierung investiert, könnt ihr die wirtschaftlichen Vorteile der Cloud schneller nutzen. Denn ihr stellt so sicher, dass Best Practices konsequent eingehalten und unnötige Überdimensionierung vermieden werden.

6. Nachhaltigkeit

Diese 2021 ergänzte Säule zeigt, wie sich eure Geschäftsaktivitäten auf Umwelt, Wirtschaft und Gesellschaft auswirken. Sie beschreibt außerdem, welche Cloud-Prozesse und Best Practices euren ökologischen Fußabdruck minimieren können. Die Säule Nachhaltigkeit lässt sich auf drei zentrale Bereiche reduzieren.

  • Nachhaltigkeit in der Cloud: Versteht das Modell der geteilten Verantwortung: AWS ist dafür zuständig, die Nachhaltigkeit der Cloud zu optimieren, während ihr als Kunde eure Workloads und die Ressourcennutzung darin optimiert.

  • Verbesserungsprozesse: Prüft, wie ihr euren ökologischen Fußabdruck durch die Neugestaltung von Lösungen minimieren könnt. Beseitigt Verschwendung, verwaltet Ressourcen mit geringer Auslastung und schöpft den größtmöglichen Mehrwert aus euren aktuellen Cloud-Ressourcen.

  • Best Practices für Nachhaltigkeit in der Cloud: Versteht die Best Practices, um die Energieeffizienz zu steigern und die Auslastung von Ressourcen zu maximieren.

Nachhaltigkeit in der Cloud: Versteht das Modell der geteilten Verantwortung: AWS ist dafür zuständig, die Nachhaltigkeit der Cloud zu optimieren, während ihr als Kunde eure Workloads und die Ressourcennutzung darin optimiert.

Verbesserungsprozesse: Prüft, wie ihr euren ökologischen Fußabdruck durch die Neugestaltung von Lösungen minimieren könnt. Beseitigt Verschwendung, verwaltet Ressourcen mit geringer Auslastung und schöpft den größtmöglichen Mehrwert aus euren aktuellen Cloud-Ressourcen.

Best Practices für Nachhaltigkeit in der Cloud: Versteht die Best Practices, um die Energieeffizienz zu steigern und die Auslastung von Ressourcen zu maximieren.

Ein Beispiel dafür, wie die Zusammenfassung eurer Säule „Nachhaltigkeit“ aussehen könnte

Nachhaltigkeit in der Cloud ist eine kontinuierliche Aufgabe, die sich vor allem auf Energieeinsparungen und Energieeffizienz über alle Komponenten eines Workloads hinweg konzentriert. Dazu nutzt ihr bereitgestellte Ressourcen bestmöglich und minimiert den gesamten Ressourcenbedarf. Dies kann bei der anfänglichen Auswahl einer effizienten Programmiersprache beginnen und den Einsatz moderner Algorithmen, effizienter Datenspeichertechniken, das Deployment auf passend dimensionierter und effizienter Compute-Infrastruktur sowie die Minimierung der Anforderungen an leistungsstarke Endnutzer-Hardware umfassen.

So führt ihr einen Well-Architected Review durch

Nachdem ihr nun mit den sechs Säulen vertraut seid, sehen wir uns an, wie ihr den Review in der Praxis durchführt.

Jede Organisation ist anders, und was funktioniert, funktioniert. Wir bei Eficode führen solche Reviews jedoch regelmäßig für unsere Kunden durch, und unser Prozess funktioniert sehr gut. Deshalb teile ich ihn jetzt mit euch als Inspiration.

Der Prozess ist recht unkompliziert.

Schritt 1: Vorbereitung

Wir benötigen von den Verantwortlichen für den Workload Folgendes:

  • Den Workload, der überprüft werden soll. Um am Ende für AWS Credits berechtigt zu sein, muss es sich um einen Produktions-Workload handeln (mehr dazu später).

  • Ein Architekturdiagramm der aktuellen Architektur (falls vorhanden)

  • Die AWS-Konto-ID, in der sich der Workload befindet

  • Die AWS-Konto-ID, für die das Review freigegeben wird (dies kann jedes Konto sein. Wenn es jedoch innerhalb einer Control-Tower-Struktur ein Audit-Konto gibt, kann dieses ein gutes Ziel sein)

  • Die Region, in der der Workload betrieben wird

Schritt 2: Kickoff

Wir vereinbaren ein Kickoff-Meeting, in dem wir den gesamten Prozess durchgehen und Zeitfenster für alle Workshop-Sessions festlegen.

Schritt 3: Workshops

Für jede Säule gibt es ein eigenes zweistündiges Review. Das mag etwas lang erscheinen, erweist sich aber oft als genau die richtige Dauer. Manche Säulen benötigen mehr Zeit als andere, andere weniger.

Nach den Säulen sind zwei weitere Workshops erforderlich, um das Review abzuschließen. Sobald alle Säulen überprüft wurden und mit dem W-A-Tool ein Bericht erstellt wurde, bitten wir euch, das Review für die anstehenden Workshops zu prüfen.

In einem Priorisierungsworkshop bewerten wir jedes HRI (High-Risk Issue) anhand eines Diagramms. Dieses zeigt, wie einfach sich ein Problem im Verhältnis zu seinen Auswirkungen beheben lässt. Am Ende ordnen wir jedes Problem mit der vorgeschlagenen Maßnahme einem abgestimmten Zeitplan zu.

Diese Struktur eignet sich hervorragend für die Workshops:

  • Kickoff-Meeting: Alle Workshops buchen und gemeinsam passende Zeitfenster finden.

  • Säulen 1–6 (insgesamt 12 Std.)

  • Priorisierungsworkshop: Die HRIs anhand ihrer Auswirkungen und der einfachen Umsetzbarkeit priorisieren. (2 Std.)

  • Workshop zu Maßnahmen und Roadmap: Alle HRIs und die vorgeschlagenen Maßnahmen in einen klar abgegrenzten Zeitplan einordnen. (2 Std.)

Kickoff-Meeting: Alle Workshops buchen und gemeinsam passende Zeitfenster finden.

Säulen 1–6 (insgesamt 12 Std.)

Priorisierungsworkshop: Die HRIs anhand ihrer Auswirkungen und der einfachen Umsetzbarkeit priorisieren. (2 Std.)

Workshop zu Maßnahmen und Roadmap: Alle HRIs und die vorgeschlagenen Maßnahmen in einen klar abgegrenzten Zeitplan einordnen. (2 Std.)

Gesamtdauer der Workshops: 16 Std.

Schritt 4: Behebung und Finanzierung

Nach den Workshops verfügt der Verantwortliche für den Workload über eine konkrete Liste der zu behebenden Probleme, eine Liste vorgeschlagener Maßnahmen zu deren Behebung sowie einen Zeitplan mit der besten Reihenfolge für die Umsetzung dieser Maßnahmen. Im Grunde eine Blaupause für alles, was zu tun ist – einschließlich Reihenfolge und Zeitplan.

Wenn ihr mit einem Partner wie Eficode zusammenarbeitet, ist dieser nun bestens darauf vorbereitet, diese Behebungsmaßnahmen umzusetzen.

Wenn wir gemeinsam 45 % aller HRIs beheben (Probleme mit mittlerem Risiko nicht mitgerechnet), ist der Aufwand für einen AWS-Gutschein im Wert von 5.000 US-Dollar berechtigt. Damit würden sich höchstwahrscheinlich die gesamten Kosten des Reviews und möglicherweise sogar noch mehr decken lassen.

Zusammenfassung

Jetzt habt ihr mehr Kontext zu den Herausforderungen rund um die Cloud, wisst aber auch, wie ihr die wichtigsten davon bewältigt. AWS hat proaktiv Tools entwickelt, um Schwachstellen zu erkennen, sowie Best Practices, um sie zu beheben.

Doch genau wie euer Unternehmen verändern sich die Cloud und eure Architektur darin ständig. Deshalb müsst ihr euer Wissen und die verfügbaren Tools nutzen, um zuverlässig, sicher, kosteneffizient und effizient zu bleiben. Ob ihr es allein angeht oder mit einem erfahrenen Partner zusammenarbeitet: Ihr kennt jetzt die Grundlagen des Well-Architected Framework und habt mit dem Well-Architected Review einen Aktionsplan.

Jetzt seid ihr dran.

  • Cloud

Subscribe to our newsletter