Einführung

In diesem AWS-Grundlagenkurs werden Ihnen die Kernkonzepte vermittelt, die Sie benötigen, um effektiv innerhalb von AWS zu arbeiten.

Am Anfang kann AWS überwältigend wirken. Ein cloud-natives Paradigma für die Erstellung von Infrastruktur kann eine radikale Abkehr von der traditionellen On-Premises-Vorgehensweise darstellen. Und unabhängig davon, ob Sie zum ersten Mal mit der Infrastruktur arbeiten oder ob Sie das letzte Jahrzehnt lang Linux-Kernel optimiert haben, kann es bei der Auswahl der über 175 AWS-Services schwierig sein herauszufinden, wo man beginnen soll.

Der AWS-Grundlagenkurs soll Ihnen unabhängig von Ihrer Erfahrung den Einstieg in AWS erleichtern. In diesem Kurs vermitteln wir Ihnen die fünf Säulen von AWS, mentale Modelle, die Sie bei Ihren Überlegungen zur Cloud anwenden können, und wichtige Konzepte, die für jeden letztendlich von Ihnen genutzten Service anwendbar sind.

 

Aufbau

Der AWS-Grundlagenkurs ist in fünf Module unterteilt. Jedes Modul entspricht dem folgenden Format:

  • Einführung: Eine kurze Beschreibung der Säule, mit der wir uns beschäftigen werden
  • Mentales Model: Ein begleitendes mentales Modell, das Ihnen hilft, die in jeder Säule eingeführten Konzepte zu verstehen
  • Konzepte: Wichtige Konzepte, die umfassende fundamentale Themen für jede Säule behandeln
  • Fazit: Zusammenfassung des Besprochenen
  • Weitere Lektüre: Zusätzliche Links und Ressourcen
 

Die fünf Säulen

Die im AWS-Grundlagenkurs beschriebenen fünf Säulen stammen aus dem AWS Well-Architected Framework. Das Well-Architected Framework beruht auf über einem Jahrzehnt an Erfahrungen in der Entwicklung skalierbarer Anwendungen in der Cloud.

Die fünf Säulen setzen sich aus folgenden Bereichen zusammen:

  1. Sicherheit
  2. Leistung und Effizienz
  3. Zuverlässigkeit
  4. Operational Excellence
  5. Kostenoptimierung
 

Sicherheit

Die Säule Sicherheit befasst sich damit, wie Sie Ihre Infrastruktur in der Cloud sichern können. Sicherheit und Compliance stellen eine geteilte Verantwortlichkeit zwischen AWS und dem Kunden dar. In diesem Modell der geteilten Verantwortung ist AWS für die Sicherheit der Cloud verantwortlich. Dazu gehören die physische Infrastruktur, die Software und Netzwerkfunktionen der AWS Cloud-Services. Der Kunde ist verantwortlich für die Sicherheit innerhalb der Cloud. Dazu gehört die Konfiguration bestimmter Cloud-Dienste, die Anwendungssoftware und der Umgang mit sensiblen Daten.

Wenn Ihre Workloads FedRAMP, DoD SRG, ITAR, CJIS oder andere strenge Compliance-Anforderungen erfüllen muss, oder wenn es Daten enthält, die als kontrollierte unklassifizierte Informationen (CUI) klassifiziert sind, lesen Sie bitte den Abschnitt AWS GovCloud (USA) des Kurses.

 

Mentales Modell

Beschäftigt man sich mit der Sicherheit in der Cloud, dann empfiehlt es sich, das Zero-Trust-Modell anzuwenden.

Nach diesem Modell werden alle Anwendungskomponenten und Services als diskrete und potenziell bösartige Einheiten betrachtet. Dazu gehören die zugrunde liegende Netzwerkstruktur, alle Agenten, die Zugriff auf die Ressourcen haben, sowie die Software, die innerhalb des Services ausgeführt wird.

 

Konzepte

Wenn wir die Sicherheit im Rahmen von Zero Trust betrachten, bedeutet dies, dass wir auf allen Ebenen unseres Systems Sicherheitsmaßnahmen anwenden müssen. Hier sind drei wichtige Konzepte, die bei der Sicherung von Systemen mit Zero Trust in der Cloud eine Rolle spielen:

  1. Identity and Access Management (IAM)
  2. Netzwerksicherheit
  3. Datenverschlüsselung

 

  • Identity and Access Management (IAM)

    IAM ist der Service, der für die Überwachung von Identitäten und Zugriffen im System verantwortlich ist. Er wird auf AWS durch den passend benannten IAM-Service verwaltet. Der Zugriff wird mit Hilfe von IAM-Richtlinien verwaltet, die Zugriffsbeschränkungen für Agenten innerhalb von AWS festlegen. Es gibt drei grundlegende Komponenten für eine IAM-Richtlinie:

    • der PRINZIPAL gibt an, WER die Berechtigungen erhält
    • die AKTION gibt an, WAS ausgeführt wird
    • die RESSOURCE gibt an, auf WELCHE Eigenschaften zugegriffen wird

    Die Anwendung des Zero-Trust-Modells auf IAM erfordert die Umsetzung des Prinzips der geringsten Rechte. Demnach sollte jeder Agent nur über die minimalen, zur Erfüllung seiner Funktion erforderlichen Berechtigungen verfügen.

    Eine IAM-Richtlinie kann auf einen AWS-Prinzipal oder eine AWS-Ressource angewandt werden. Richtlinien, die sich auf einen Prinzipal beziehen, werden als identitätsbasierte Richtlinien bezeichnet. Richtlinien, die sich auf eine Ressource beziehen, werden als ressourcenbasierte Richtlinien bezeichnet. Beachten Sie, dass nur bestimmte Services (z.B. S3, KMS, SES) ressourcenbasierte Richtlinien haben.

    Ob ein Prinzipal die Erlaubnis hat, eine Aktion für eine bestimmte Ressource durchzuführen, hängt davon ab, ob die identitätsbasierte Richtlinie des Prinzipals dies zulässt und ob die ressourcenbasierte Richtlinie der Ressource (falls vorhanden) dies nicht untersagt.

    Beachten Sie, dass es sich hierbei um eine erhebliche Vereinfachung des IAM-Berechtigungsmodells handelt. Es gibt viele weitere Richtlinien, die darüber entscheiden, ob ein Zugriff gewährt werden kann. Dazu können Berechtigungsgrenzen, Service-Kontrollrichtlinien der Organisation, Zugriffskontrolllisten und Session-Richtlinien gehören. Diese zusätzlichen Richtlinien gehen über den Rahmen dieses Kurses hinaus. Weitere Informationen dazu finden Sie im Abschnitt Weitere Lektüre dieses Moduls.

    Erkenntnisse

    • IAM-Richtlinien definieren die Zugriffsbeschränkungen für Entitäten innerhalb von AWS
    • IAM-Richtlinien umfassen PRINZIPALE, AKTIONEN und RESSOURCEN
    • IAM-Richtlinien können zur Durchsetzung des Prinzips der geringsten Rechte verwendet werden
    • IAM umfasst viele verschiedene Richtlinien – identitätsbasierte und ressourcenbasierte sind zwei Beispiele dafür
    • IAM bewertet den Zugriff anhand der Bewertung aller Richtlinien, die für eine bestimmte Ressource anwendbar sind
     

    Weitere Lektüre

  • Netzwerksicherheit

    Die Netzwerksicherheit umfasst jedes System, jede Konfiguration oder jedes Verfahren, das den Zugriff und die Nutzbarkeit des Netzwerks und der im Netzwerk zugänglichen Ressourcen gewährleistet. AWS bietet eine breite Palette an Funktionen zur Sicherung des Netzwerks, sowohl auf Netzwerk- als auch auf Ressourcenebene.

    Der Zero-Trust-Ansatz für die Netzwerksicherheit bedingt einen Defense-in-Depth-Ansatz, bei dem Sicherheitskontrollen auf allen Ebenen des Netzwerks angewendet werden (statt nur auf der äußersten Schicht).

    Sicherheit auf Netzwerkebene

    Bei AWS ist das grundlegende Primitiv auf Netzwerkebene die Amazon Virtual Private Cloud (VPC). Dabei handelt es sich um ein logisches Netzwerk, das Sie definieren und in dem Sie Ressourcen bereitstellen können.

    Hier sind einige Komponenten, aus denen sich die VPC zusammensetzt:

    • Subnetze: ein Reihe von IP-Adressen innerhalb der VPC
    • Routing-Tabellen: eine Reihe von Regeln, die festlegen, wohin der Verkehr geleitet wird
    • Internet-Gateway: eine Komponente, die eine Kommunikation zwischen Ressourcen innerhalb der VPC und dem Internet ermöglicht

    Um den Datenverkehr in der VPC zu schützen, können Sie Ihre Ressourcen in öffentlich zugängliche Ressourcen und interne Ressourcen unterteilen. Um die Angriffsfläche zu verringern, können Sie einen Proxy-Service wie den Application Load Balancer (ALB) verwenden, um den gesamten internetseitigen Datenverkehr abzuwickeln. Alle internen Services wie Server und Datenbanken können dann innerhalb interner Subnetze bereitgestellt werden, die vom direkten öffentlichen Internetzugang abgeschnitten sind.

    Zusätzlich zu den VPCs können Sie auch die AWS-Firewall für Webanwendungen (FWA) verwenden, um den Datenverkehr im Netzwerk weiter einzuschränken.

    Sicherheit auf Ressourcenebene

    Individuelle AWS-Ressourcen verfügen ebenfalls über konfigurierbare Kontrollen für die Netzwerksicherheit. Die gängigste Kontrollmöglichkeit ist die Sicherheitsgruppe. Sicherheitsgruppen sind virtuelle Firewalls, mit denen Sie den Datenverkehr in die Ressource hinein und aus ihr heraus festlegen können. Mit Sicherheitsgruppen können Sie festlegen, dass nur der Datenverkehr von bestimmten Ports und vertrauenswürdigen Quellen zur Instance zugelassen wird. Sie können Sicherheitsgruppen mit Ressourcen wie EC2-Instances, RDS-Instances und Lambda verknüpfen.

    Erkenntnisse

    • Die Netzwerksicherheit umfasst Mechanismen, die dazu dienen den Zugriff und die Nutzbarkeit des Netzwerks und der im Netzwerk zugänglichen Ressourcen zu gewährleisten
    • Der Zero-Trust-Ansatz für die Netzwerksicherheit bedingt die Implementierung von Defense in Depth auf allen Ebenen des Netzwerks
    • VPCs und WAFs ermöglichen die Anwendung von Sicherheitsmaßnahmen auf Netzwerkebene
    • Sicherheitsgruppen ermöglichen die Anwendung von Sicherheitsmaßnahmen auf Ressourcenebene

    Weitere Lektüre

  • Datenverschlüsselung

    Bei der Datenverschlüsselung werden Informationen so verschlüsselt, dass sie für Dritte, die nicht über den zur Entschlüsselung der Daten erforderlichen Schlüssel verfügen, unverständlich sind.

    Die Einführung eines Zero-Trust-Modells für Daten bedeutet, dass unsere Daten überall verschlüsselt werden, sowohl bei der Übertragung als auch im Ruhezustand.

    Verschlüsselung während der Übertragung

    Bei der Verschlüsselung während der Übertragung werden die Daten auf dem Weg zwischen den Systemen verschlüsselt. Alle Speicher- und Datenbankservices innerhalb von AWS bieten HTTPS-Endpunkte, die eine Verschlüsselung von Daten während der Übertragung unterstützen. AWS bietet auch Netzwerkservices an, die dabei helfen eine Verschlüsselung während der Übertragung für Ihre eigenen Services festzulegen. Beispielsweise können Sie mit dem Application Load Balancer (ALB) eine Verbindung über HTTPS zu Ihren Endpunkten herstellen.

    Verschlüsselung im Ruhezustand

    Bei der Verschlüsselung im Ruhezustand werden die Daten innerhalb von Systemen verschlüsselt. Alle AWS-Speicher- und Datenbankservices unterstützen die Verschlüsselung im Ruhezustand. Bei den meisten dieser Services ist die Verschlüsselung standardmäßig aktiviert. Für die Verschlüsselung der Daten fallen keine zusätzlichen Kosten an und der zusätzliche Leistungsaufwand ist unerheblich.

    Die meisten Speicher- und Datenbankservices können auch direkt mit dem Amazon Key Management Service (KMS) verknüpft werden. Hierbei handelt es sich um einen zentralen Key Management Service, der die Möglichkeit bietet, Customer Managed Keys (CMK) zur Verschlüsselung von Daten zu erstellen.

    Die Verwendung eines CMK bietet Ihnen neben der Verschlüsselung noch weitere Funktionen. Sie haben die Möglichkeit einen eigenen benutzerdefinierten Schlüsselspeicher zu verwenden, können durch die Integration mit AWS CloudTrail einen Prüfpfad für die verschlüsselte Ressource erstellen und können die automatische Schlüsselrotation festlegen.

    Erkenntnisse

    • Bei der Datenverschlüsselung werden Informationen so verschlüsselt, dass nur Parteien mit dem passenden Schlüssel die Informationen entschlüsseln können
    • Durch die Verschlüsselung während der Übertragung und im Ruhezustand können Daten geschützt werden
    • Alle AWS-Speicher- und Datenbankservices unterstützen die Verschlüsselung im Ruhezustand und während der Übertragung
    • Mithilfe von AWS-Netzwerkservices wie dem ALB können Sie für Ihre eigenen Dienste eine Verschlüsselung während der Übertragung festlegen
    • Mit einem CMK können erweiterte Funktionen freigeschaltet werden, z. B. die Erstellung von Prüfpfaden, die Verwendung eigener benutzerdefinierter Schlüssel und die automatische Schlüsselrotation

    Weitere Lektüre

    Funktionen

     

    Services

     

    Referenzen

     

     

Fazit

In diesem Modul haben Sie die Säule „Sicherheit“ von AWS kennen gelernt. Sie haben das mentale Modell von Zero Trust kennen gelernt. Sie haben IAM und das Prinzip der geringsten Rechte kennen gelernt. Sie haben sich eingehend mit der Netzwerksicherheit von AWS und dem Prinzip der Verteidigung befasst. Sie haben die Datenverschlüsselung und ihre Anwendung bei der Übertragung und Speicherung kennen gelernt.

 

Weitere Lektüre

Leistung und Effizienz

Die Säule Leistung und Effizienz befasst sich damit, wie Sie Services in der Cloud effizient und skalierbar ausführen können. Die Cloud bietet Ihnen zwar die Möglichkeit jede beliebige Menge an Datenverkehr zu verarbeiten, erfordert jedoch, dass Sie die Services unter Berücksichtigung der Skalierbarkeit auswählen und konfigurieren.

 

Mentales Modell

Beschäftigt man sich mit Leistung und Effizienz in der Cloud, dann empfiehlt es sich, die Services als Vieh und nicht als Haustiere zu betrachten.

Beim On-Premises-Modell waren die Server teuer und wurden oft manuell bereitgestellt und konfiguriert. Es konnte mehrere Wochen dauern, bis ein Server tatsächlich geliefert und physisch an das Rechenzentrum angeschlossen wurde. Aus diesem Grund wurden Server wie Haustiere behandelt, denn jeder davon war einzigartig und erforderte einen hohen Wartungsaufwand. Manche hatten sogar einen Namen.

Im Rahmen der Cloud werden Server wie Vieh betrachtet. Server sind Standardressourcen, die innerhalb von Sekunden automatisch bereitgestellt werden können. Die Ausführung eines Service sollte nicht von nur einem Server abhängig sein.

 

Konzepte

Wenn wir Server als Vieh betrachten, haben wir viele leistungsbezogene Vorteile. Im „Haustier-Modell“ für die Serververwaltung ist es durchaus üblich, den gleichen Servertyp (oder sogar den gleichen Server) für mehrere Workloads zu verwenden. Es ist zu umständlich verschiedene Maschinen zu bestellen und bereitzustellen. Im „Vieh-Modell“ erfolgt die Bereitstellung schnell und günstig, was uns die Freiheit gibt, den Servertyp zu wählen, der unserem Workload am ehesten entspricht.

Das „Vieh-Modell“ erleichtert es uns auch unseren Service zu skalieren. Da jeder Server austauschbar ist und schnell bereitgestellt werden kann, ist es möglich die Kapazität durch das Hinzufügen weiterer Server schnell zu skalieren.

Im Rahmen von Leistung und Effizienz werden wir uns mit den folgenden zwei Konzepten beschäftigen:

  1. Auswahl
  2. Skalierung
 
  • Auswahl

    Auswahl steht bei AWS für die Möglichkeit, den Service zu wählen, der am ehesten der Verarbeitungslast entspricht. Mit mehr als 175 Services, die sich auf über zwei Dutzend Kategorien verteilen, verfügt AWS über die größte Auswahl an Services. Durch Auswahl Leistung zu erreichen, bedeutet das passende Tool für die jeweilige Aufgabe auswählen zu können.

    Eine typische Verarbeitungslast erfordert in der Regel die Auswahl aus einigen der vier wichtigsten Servicekategorien von AWS: Datenverarbeitung, Speicherung, Datenbank und Netzwerk.

    • Datenverarbeitung beschreibt den Service, der die Daten verarbeiten wird (z.B. virtuelle Maschine)
    • Speicherung beschreibt die statische Speicherung von Daten (z.B. Objektspeicher)
    • Datenbank beschreibt die organisierte Speicherung von Daten (z.B. relationale Datenbank)
    • Netzwerk beschreibt, wie sich die Daten bewegen (z.B. Content Delivery Network)

    In diesem Modul gehen wir darauf ein, wie man in den ersten drei Kategorien die richtige Auswahl trifft. Bitte beachten Sie den Abschnitt Weitere Lektüre mit Leitfäden zur Auswahl der verschiedenen Netzwerkoptionen.

    Unabhängig von der gewählten Servicekategorie gibt es drei Dinge, die Sie beachten sollten.

    1. Service-Typ
    2. Verwaltungsgrad
    3. Konfiguration

    Service-Typ

    Wenn Sie in einer Kategorie eine Auswahl treffen, bietet AWS zahlreiche Optionen für den Typ des verfügbaren Service. Der Typ ist für jede Kategorie einzigartig.

    Entscheiden Sie bei der Auswahl eines Datenverarbeitungs-Service, ob Sie die Datenverarbeitung basierend auf VM, Containern oder serverlos bevorzugen.

    • Die VM-basierte Datenverarbeitung stellt für die meisten Menschen das geläufigste mentale Modell dar, kann aber teurer und wartungsintensiver sein
    • Die containergestützte Datenverarbeitung ermöglicht eine präzisere Unterteilung der Arbeitslast und kann schnell skaliert werden, allerdings geht sie mit zusätzlicher Konfigurations- und Orchestrierungskomplexität einher
    • Die serverlose Datenverarbeitung abstrahiert den größten Teil der Verwaltungs- und Skalierungskomplexität, hat jedoch harte Systemgrenzen und erfordert die Einführung neuer Toolchains und Prozesse

    Entscheiden Sie sich bei der Auswahl eines Speicher-Service, ob Sie einen Dateispeicher, Blockspeicher, Objektspeicher oder Archivspeicher benötigen.

    • Blockspeicher-Services wie EBS eignen sich besonders gut, um Daten aus einer einzelnen EC2-Instance aufzubewahren
    • Dateisysteme wie EFS eignen sich besonders gut, um mehreren Clients Zugriff auf die gleichen Daten zu geben
    • Objektspeicher wie S3 eignen sich besonders gut für große Datenmengen, auf die eine Vielzahl von Clients zugreifen müssen
    • Archivspeicher wie S3 Glacier eignen sich besonders gut für große Datenmengen, auf die nur gelegentlich zugegriffen werden muss

    Entscheiden Sie bei der Auswahl eines Datenbank-Service, ob Sie eine relationale Datenbank, eine nicht-relationale Datenbank, eine Data-Warehouse-Lösung oder eine Datenindizierungs- und Suchlösung benötigen.

    • Relationale Datenbanken ermöglichen Joins und ACID-Eigenschaften, haben aber eine Obergrenze für Leistung und Datenspeicherung
    • Nicht-relationale Datenbanken verfügen über flexiblere Schemata und sind viel höher skalierbar als ihre relationalen Gegenstücke, sie verfügen jedoch üblicherweise nicht über Joins und volle ACID-Fähigkeiten
    • Data-Warehouse-Lösungen ermöglichen groß angelegte Analysen durch den schnellen Zugriff auf strukturierte Daten im Petabyte-Bereich
    • Datenindizierungs- und Suchlösungen ermöglichen die Indizierung und Suche von Daten aus zahlreichen Quellen
     

    Verwaltungsgrad

    Sobald Sie sich für einen Servicetyp entschieden haben, müssen Sie sich auf einen bestimmten Service beschränken. In manchen Fällen bietet AWS mehrere Lösungen für bestimmte Servicetypen an. Der wesentliche Unterschied zwischen verschiedenen AWS-Services desselben Typs liegt im Verwaltungsgrad.

    Wenn Sie Datenverarbeitungs-Services nutzen und sich für den VM-Typ entscheiden, müssen Sie zwischen EC2, Lightsail und Elastic Beanstalk wählen. Mit EC2 haben Sie direkt die meiste Kontrolle und die geringste Verwaltung, wohingegen Sie mit Lightsail gewisse individuelle Anpassungen vornehmen können und so eine wesentlich verwaltetere Lösung erhalten. Elastic Beanstalk liegt dazwischen – es bietet einen verbindlichen Rahmen für die Service-Architektur, lässt sich aber durch Konfigurationen anpassen.

    Wenn Sie Speicher-Services nutzen ist die Auswahl eines Services einfacher, da es in der Regel nur einen Service für einen bestimmten Typ gibt (z. B. S3 für Objektspeicher, EFS für Dateispeicher).

    Wenn Sie Datenbank-Services nutzen und sich für den relationalen Typ entscheiden, müssen Sie zwischen RDS und Aurora wählen. RDS gibt Ihnen mehr Kontrolle über die zugrunde liegende Datenbank und ist für die meisten relationalen Datenbanken verfügbar. Aurora unterstützt nur bestimmte Versionen von MySQL und PostgreSQL, kümmert sich aber um die Verwaltung des zugrunde liegenden Speichers und verfügt über eine integrierte Clustering-Unterstützung.

    Letztendlich hängt die Entscheidung für einen bestimmten Service weitgehend davon ab, ob Sie mit der zugrunde liegenden Technologie vertraut sind und ob Sie eine mehr oder weniger verwaltete Lösung bevorzugen.

     

    Konfiguration

    Sobald Sie sich für einen Service entschieden haben, müssen Sie entscheiden, wie Sie ihn konfigurieren möchten. Die Konfiguration hängt von den spezifischen Leistungsmerkmalen ab, die Sie erreichen möchten und die für jede Servicekategorie unterschiedlich sind.

    Für die Ermittlung der Leistungsmerkmale für Datenverarbeitungs-Services empfiehlt es sich, zunächst den Speicher- und Datenverarbeitungsbedarf zu betrachten:

    • Wenn Sie die VM-basierte Datenverarbeitung verwenden, werden Speicher und CPU von der Größe der Instance (z. B. t3.small vs. t3.xlarge) und der Instance-Familie (z. B. r3.small vs. c5.small) beeinflusst
    • Wenn Sie die Container-basierte Datenverarbeitung verwenden, können Speicher und CPU individuell eingestellt werden
    • Wenn Sie die serverlose Datenverarbeitung verwenden, kann nur der Speicher direkt eingestellt werden – der Wert für die Datenverarbeitung (wie auch für andere Systemressourcen) steigt linear mit der Menge des verfügbaren Speichers

    Beachten Sie, dass es je nach Verarbeitungslast zusätzliche Ressourcenbeschränkungen gibt, die eventuell relevant für Sie sein könnten, wie z.B. die Netzwerkkapazität und die Verfügbarkeit bestimmter Ressourcen wie dem Instance-Speicher.

    Für die Ermittlung der Leistungsmerkmale für Speicher-Services sollten Sie Ihre Anforderungen an Latenz, Durchsatz und IOPS berücksichtigen:

    • Bei Verwendung eines Blockspeicher-Service
      • wird die Latenz durch die Auswahl des Volume-Typs beeinflusst (z. B. Solid-State-Laufwerk vs. Festplatte)
      • ist der Durchsatz bei den meisten Volume-Typen proportional zur Volume-Größe
      • ist die IOPS-Kapazität bei den meisten Volume-Typen proportional zur Volume-Größe
    • Bei Verwendung eines Dateisystem-Service
      • werden Latenz und IOPS durch die Wahl der Leistungsmodi beeinflusst
      • wird der Durchsatz durch die Entscheidung zur Nutzung des bereitgestellten Durchsatzes beeinflusst
    • Bei Verwendung eines Objektspeichers
      • wird die Latenz durch die geografische Entfernung zum Bucket-Endpunkt beeinflusst
      • wird der Durchsatz durch die Verwendung von durchsatzoptimierten APIs wie mehrteiligen Uploads beeinflusst
      • ist IOPS nicht konfigurierbar
    • Bei Verwendung eines Archivspeichers
      • wird die Latenz durch die geografische Entfernung zum Bucket-Endpunkt und die Wahl der Abrufmethode beeinflusst
      • wird der Durchsatz durch die Verwendung von durchsatzoptimierten APIs wie mehrteiligen Uploads beeinflusst
      • ist IOPS nicht konfigurierbar

    Für die Ermittlung der Leistungsmerkmale für Datenbank-Services sollten Sie die Ressourcenanforderungen (z. B. CPU, Arbeitsspeicher, Speicher usw.) berücksichtigen:

    • Bei Verwendung einer relationalen Datenbank
      • werden die Ressourcenkapazitäten durch die Wahl der EC2-Instance bestimmt
    • Bei Verwendung einer nicht relationalen Datenbank wie DynamoDB
    • Bei Verwendung einer Data-Warehouse-Lösung wie Redshift
      • werden die Ressourcenkapazitäten durch die Wahl der zugrunde liegenden EC2-Instance bestimmt
    • Bei Verwendung einer Indizierungslösung wie Elasticsearch Service
      • werden die Ressourcenkapazitäten durch die Wahl der EC2-Instance bestimmt

     

    Erkenntnisse

    • AWS bietet viele Services und Möglichkeiten, um ein Ziel zu erreichen
    • Die Implementierung einer Verarbeitungslast für AWS erfordert die Auswahl von Services in den Kategorien Datenverarbeitung, Speicherung, Datenbank und Netzwerk
    • Innerhalb jeder Kategorie können Sie je nach Anwendungsfall den passenden Service-Typ auswählen
    • Innerhalb jedes Typs können Sie den spezifischen Service auf Grundlage des gewünschten Verwaltungsgrades auswählen
    • Innerhalb jedes Service können Sie die spezifische Konfiguration auf Grundlage der spezifischen Leistungsmerkmale auswählen, die Sie erreichen möchten
     

    Weitere Lektüre

  • Skalierung

    Während die Wahl des geeigneten Service ausschlaggebend für den Einstieg ist, ist die Wahl der Skalierbarkeit für die fortlaufende Leistung von Bedeutung.

    AWS bietet zwei wesentliche Möglichkeiten zur Skalierung:

    1. Vertikale Skalierung
    2. Horizontale Skalierung


    Vertikale Skalierung

    Bei der vertikalen Skalierung wird die zugrunde liegende Datenverarbeitung auf einen größeren Instance-Typ aufgerüstet. Nehmen wir beispielsweise an Sie führen eine t3.small-Instance aus. Eine vertikale Skalierung dieser Instance könnte in Form eines Upgrades auf eine t3.large-Instance erfolgen.

    Normalerweise ist eine vertikale Skalierung einfacher zu implementieren, da dies ohne das vorherige Clustern des Services möglich ist. Der Nachteil ist, dass die Obergrenze (entspricht der maximalen Größe der Datenverarbeitungs-Instance) im Vergleich zur horizontalen Skalierung bedeutend niedriger ist. Außerdem stellt sie einen Single Point of Failure dar, da eine Unterbrechung der Instance dazu führen kann, dass der Service gänzlich ausfällt.

     

    Horizontale Skalierung

    Bei der horizontalen Skalierung wird die Anzahl der zugrunde liegenden Instances erhöht. Nehmen wir beispielsweise an Sie führen eine t3.small-Instance aus. Eine horizontale Skalierung dieser Instance würde die Bereitstellung von zwei zusätzlichen t3.small-Instances erfordern.

    Die horizontale Skalierung erfordert einen höheren Aufwand bei der Implementierung. Das liegt daran, dass man einen Proxy-Service benötigt, um den Datenverkehr zu den Services zu leiten. Außerdem müssen Sie Systemdiagnosen durchführen, um schlechte Instances aus dem Routing-Pool zu entfernen und einen bestimmten Routing-Algorithmus festlegen, der optimal auf die Verarbeitungslast abgestimmt ist. Dafür haben Sie einen wesentlich widerstandsfähigeren Service, der weitaus höher skaliert werden kann als sein vertikal skalierendes Gegenstück.


    Erkenntnisse

    • Die vertikale Skalierung ist operativ einfacher, birgt jedoch ein Verfügbarkeitsrisiko und hat niedrigere Obergrenzen
    • Die horizontale Skalierung ist aufwändiger, dafür aber bedeutend zuverlässiger und hat wesentlich höhere Obergrenzen
     

    Weitere Lektüre

Fazit

In diesem Modul haben Sie die Säule „Leistung und Effizienz“ von AWS kennen gelernt. Sie haben das mentale Modell kennen gelernt, Server nicht als Haustiere, sondern als Vieh zu betrachten. Sie haben gelernt, wie Sie auf Basis von Leistungszielen die richtigen Services und die entsprechende Konfiguration auswählen. Sie haben Skalierungsservices und die Vor- und Nachteile der vertikalen und horizontalen Skalierung kennen gelernt.

 

Weitere Lektüre

Zuverlässigkeit

Die Säule Zuverlässigkeit befasst sich damit, wie Sie Services erstellen, die Service- und Infrastrukturunterbrechungen standhalten. Ähnlich wie bei der Leistung und Effizienz bietet Ihnen die Cloud zwar die Möglichkeit, ausfallsichere Services zu erstellen, die Unterbrechungen standhalten, aber sie erfordert auch, dass Sie Ihre Services unter Berücksichtigung der Zuverlässigkeit entwickeln.


Mentales Modell

Beschäftigt man sich mit der Zuverlässigkeit in der Cloud, dann empfiehlt es sich, sie unter dem Gesichtspunkt des Auswirkungsradius zu betrachten. Man kann sich den Auswirkungsradius als die maximale Wirkung vorstellen, die im Falle eines Systemausfalls auftreten kann. Um zuverlässige Systeme zu erstellen, sollte der Auswirkungsradius jeder einzelnen Komponente minimiert werden.

 

Konzepte

Wenn man den Auswirkungsradius betrachtet, ist die Frage nicht mehr ob ein Fehler auftritt, sondern wann ein Fehler auftritt. Im Falle eines Ausfalls können die folgenden Techniken zur Begrenzung des Auswirkungsradius eingesetzt werden:

  1. Fehlerisolierung
  2. Einschränkungen


  • Fehlerisolierung

    Die Isolierung des Fehlers begrenzt den Auswirkungsradius eines Vorfalls durch den Einsatz redundanter, unabhängiger Komponenten, die durch Fehlerisolierungszonen getrennt sind. Fehlerisolierungszonen beschränken die Wirkung von Ausfällen auf das Gebiet innerhalb der Zone.

    AWS verfügt über Fehlerisolierungszonen auf drei Ebenen:

    1. Ressource und Anfrage
    2. Availability Zone
    3. Region

     

    Ressource und Anfrage

    AWS-Services partitionieren alle Ressourcen und Anfragen auf eine bestimmte Dimension wie die Ressourcen-ID. Diese Partitionen werden als Zellen bezeichnet. Zellen sind so konzipiert, dass sie unabhängig sind und Ausfälle auf eine einzige Zelle beschränken. Im Hintergrund verwendet AWS Methoden wie Shuffle Sharding, um den Auswirkungsradius zu begrenzen. All dies geschieht jedes Mal, wenn Sie eine Anfrage stellen oder eine Ressource erstellen, auf transparente Weise und erfordert keine zusätzlichen Maßnahmen Ihrerseits.


    Availability Zone

    Eine AWS Availability Zone (AZ) ist eine völlig unabhängige Einrichtung mit dedizierter Stromversorgung, dediziertem Service und dedizierten Netzwerkfähigkeiten. Sie sind geographisch von anderen AZs entfernt, um übergreifende Ausfälle durch Umweltgefahren wie Brände und Überschwemmungen zu vermeiden.

    Auf AZ-Ebene wird die Fehlerisolierung durch die Bereitstellung redundanter Instances Ihres Services über mehrere AZs erreicht. Auf diese Weise wird ein Stromversorgungsereignis in einer AZ Ihren Datenverkehr in einer anderen AZ nicht beeinträchtigen.

    Ein Hinweis zur Latenz: Trotz geografischer Trennung liegen die AZs nahe genug beieinander, damit die Netzwerklatenz zwischen den AZs minimal ist. Dadurch werden bestimmte Funktionen zwischen AZs ermöglicht wie beispielsweise die synchrone Datenreplikation.


    Region

    Eine AWS-Region bietet die optimale Isolierung. Jede Region stellt ein vollständig autonomes Datenzentrum dar, das aus zwei oder mehr AZs besteht. Auf der Regionsebene wird die Fehlerisolierung durch die Bereitstellung redundanter Kopien der Services in verschiedenen AWS-Regionen erreicht (genau das gleiche macht AWS mit seinen eigenen Services).

    Erwägen Sie die Bereitstellung in mehreren Regionen, wenn Sie ein sehr hohes Maß an Verfügbarkeit benötigen. Beachten Sie aber auch, dass der Betrieb eines Services über mehrere Regionen hinweg einen erheblichen Mehraufwand verursacht, da es zwischen den Regionen keine gemeinsame Infrastruktur gibt. Es gibt Services und Funktionen, die Sie beim Aufbau mehrerer Regionen unterstützen können. Beispielsweise können Sie den skalierbaren AWS-DNS-Service Route53 verwenden, um Datenverkehr zwischen verschiedenen Regionen umzuleiten. Zudem können Sie Funktionen wie DynamoDB Global Tables und S3 Cross-Region Replication verwenden, um Ihre Daten regionsübergreifend zu replizieren.


    Erkenntnisse

    • Die Verwendung von Fehlerisolierungszonen beschränkt den Auswirkungsradius von Server- oder Infrastrukturausfällen
    • Auf der Ressourcen- und Anfrageebene ist die Fehlerisolierung in jeden AWS-Service integriert und erfordert keine zusätzlichen Maßnahmen Ihrerseits
    • Auf AZ-Ebene wird die Fehlerisolierung durch die Bereitstellung der Services über mehrere AZs hinweg erreicht, was mit minimalen Auswirkungen auf die Latenz erfolgt
    • Auf Regionsebene wird die Fehlerisolierung durch die Bereitstellung der Services in mehreren Regionen erreicht, was einen erheblichen operativen Aufwand erfordert


    Weitere Lektüre

  • Einschränkungen

    Einschränkungen können angewendet werden, um Services vor übermäßigen Belastungen zu schützen. Sie sind ein wirksames Mittel zur Begrenzung des Auswirkungsradius bei externen (z.B. DDoS-Angriff) und internen (z.B. Software-Fehlkonfiguration) Vorfällen.

    AWS-Services haben spezifische Einschränkungen pro Konto und pro Region. Diese Einschränkungen werden auch als Service Quotas bezeichnet. Dabei handelt es sich um Höchstwerte für bestimmte Ressourcen, Aktionen und Posten in Ihrem AWS-Konto.

    Es gibt zwei Arten von Einschränkungen:

    • weiche Einschränkungen, die erhöht werden können, indem dies bei AWS beantragt wird
    • harte Einschränkungen, die nicht erhöht werden können

    Jeder Service hat andere Einschränkungen. Zur Überwachung der Einschränkungen und zur Beantragung von Erhöhungen können Sie den Service Quotas-Service nutzen.

    Es ist wichtig, Service Limits zu überwachen und zu wissen, wann Sie sich einem Limit nähern, damit Serviceunterbrechungen vermieden werden. Für manche Ressourcen wie gleichzeitige Lambda-Ausführungen ist eine Überwachung per CloudWatch möglich. Andere Ressourcen, wie die Anzahl der EC2-Instances, müssen manuell oder durch Skripte überwacht werden. Wenn Sie einen Business Support oder Enterprise Support-Plan haben, können Sie den AWS Trusted Advisor-Service nutzen, um die Einschränkungen zu überwachen. Um den Prozess zu automatisieren, können auch Open-Source-Tools wie awslimitchecker verwendet werden.


    Erkenntnisse

    • Einschränkungen können angewendet werden, um einen Service vor übermäßigen Belastungen zu schützen
    • AWS Service Limits können mit Hilfe des Service Quota-Services überwacht und verwaltet werden
    • Es gibt weiche Einschränkungen, die erhöht werden können, und harte Einschränkungen, die nicht erhöht werden können
    • Um Serviceunterbrechungen zu vermeiden, sollten Sie alle Einschränkungen für die von Ihnen genutzten Services überwachen und Limiterhöhungen entsprechend planen


    Weitere Lektüre

Fazit

In diesem Modul haben Sie die Säule „Zuverlässigkeit“ von AWS kennen gelernt. Sie haben das mentale Modell kennen gelernt den Auswirkungsradius zu betrachten. Sie haben gelernt, wie man den Auswirkungsradius mit Fehlerisolierungszonen begrenzen kann. Sie haben gelernt, was Service Limits sind und wie Sie diese erhöhen können, um Serviceunterbrechungen zu vermeiden.

 

Weitere Lektüre

Operational Excellence

Die Säule Operational Excellence befasst sich damit, wie Sie Ihre Kapazitäten zum Betrieb von Systemen kontinuierlich verbessern können, bessere Verfahren schaffen und Erkenntnisse erlangen.


Mentales Modell

Beschäftigt man sich mit Operational Excellence in der Cloud, dann empfiehlt es sich, sie unter dem Gesichtspunkt der Automatisierung zu betrachten.

Menschliches Versagen ist die Hauptursache für Mängel und Betriebsstörungen. Je mehr Vorgänge automatisiert werden können, desto geringer ist das Risiko für menschliches Versagen.

Neben der Fehlervermeidung trägt die Automatisierung auch zur kontinuierlichen Verbesserung interner Prozesse bei. Dies begünstigt wiederholbare, bewährte Methoden, die in der gesamten Organisation angewendet werden können.


Konzepte

Wenn Sie Vorgänge als Automatisierung betrachten, sollten Sie Ihre Bemühungen auf die Bereiche konzentrieren, die derzeit die meiste manuelle Arbeit erfordern und daher möglicherweise das größte Fehlerpotenzial aufweisen. Außerdem sollten Sie über einen Prozess verfügen, mit dem Sie Ihre operativen Bemühungen erfassen, analysieren und verbessern können.

Wir werden uns auf die folgenden zwei Konzepte für Operational Excellence konzentrieren:

  1. Infrastruktur als Code
  2. Beobachtbarkeit


  • Infrastruktur als Code

    Infrastruktur als Code (IaC) beschreibt den Prozess der Verwaltung Ihrer Infrastruktur durch maschinenlesbare Konfigurationsdateien. IaC bildet die Grundlage für die Automatisierung Ihrer Infrastruktur.

    Anstatt Services manuell bereitzustellen, erstellen Sie Vorlagen, in denen die gewünschten Ressourcen beschrieben werden. Die IaC-Plattform übernimmt dann die Bereitstellung und Konfiguration der Ressourcen.

    IaC bietet Ihnen eine deklarative und automatisierte Methode zur Bereitstellung von Infrastruktur. Sie können die gleichen Tools (z.B. git) und Prozesse (z.B. Code-Überprüfung) für die Infrastruktur anwenden, die Sie bereits für den Code verwenden.

    IaC auf AWS wird üblicherweise mit dem CloudFormation-Service implementiert. CloudFormation erfordert die Deklaration der Ressourcen mittels JSON oder YAML. Falls diese Konfigurationssprachen nicht das Richtige für Sie sind, bietet AWS auch das Cloud Development Kit (CDK) an, mit dem Sie CloudFormation-Vorlagen mit nativen Programmiersprachen wie JavaScript, Python und Java erstellen können.

     

    Erkenntnisse

    • IaC beschreibt den Prozess der Verwaltung von Infrastruktur durch maschinenlesbare Konfigurationsdateien
    • IaC ist eine deklarative und automatisierte Methode zur Bereitstellung von Infrastruktur
    • Sie können die gleichen Tools und Prozesse für Ihre Infrastruktur anwenden, die Sie bereits für Ihren Code verwenden
    • Zur Implementierung von IaC auf AWS können Services wie CloudFormation und CDK verwendet werden
     

    Weitere Lektüre

  • Beobachtbarkeit

    Unter Beobachtbarkeit versteht man den Prozess der Feststellung des internen Zustands eines Systems. Dies wird normalerweise durchgeführt, um es auf einen gewünschten Endzustand hin zu optimieren.

    Im Zusammenhang mit Operational Excellence ist es nicht möglich etwas zu verbessern, das nicht gemessen wird. Der Aufbau einer soliden Grundlage für Beobachtungen ermöglicht es, die Auswirkungen einer Automatisierung zu erfassen und die Prozesse kontinuierlich zu verbessern.

    Die Implementierung der Beobachtbarkeit umfasst folgende Schritte:

    1. Sammlung
    2. Analysen
    3. Aktion


    Sammlung

    Die Sammlung beschreibt den Prozess der Zusammenführung aller Metriken, die zur Beurteilung des Zustands eines Systems erforderlich sind.

    Diese Metriken können in die folgenden Kategorien unterteilt werden:

    • Metriken auf Infrastrukturebene
      • Diese Metriken werden automatisch von AWS-Services ausgegeben und durch den CloudWatch-Service gesammelt
      • Einige Services geben auch strukturierte Protokolle aus, die über CloudWatch Logs aktiviert und gesammelt werden können
    • Metriken auf Anwendungsebene
      • Diese Metriken werden von der Software generiert und können durch benutzerdefinierte CloudWatch-Metriken gesammelt werden
      • Software-Protokolle können mit CloudWatch Logs gespeichert oder auf S3 hochgeladen werden
    • Metriken auf Kontoebene
      • Diese Metriken werden vom AWS-Konto protokolliert und können durch den CloudTrail-Service gesammelt werden


    Analysen

    Zur Analyse Ihrer gesammelten Metriken können Sie eine der vielen Datenbank- und Analyselösungen von AWS verwenden.

    Die Auswahl der passenden Lösung richtet sich nach Ihrem Anwendungsfall:

    • Zur Analyse von Protokollen, die in CloudWatch Logs gespeichert sind, können Sie CloudWatch Logs Insight verwenden – ein Service, mit dem Sie Cloudwatch-Protokolldaten interaktiv durchsuchen und analysieren können
    • Zur Analyse von Protokollen, die in S3 gespeichert sind, können Sie den serverlosen Abfrageservice Athena verwenden
    • Zur Analyse von Strukturdaten können Sie den verwalteten relationalen Datenbankservice RDS verwenden
    • Zur Analyse großer Mengen von Strukturdaten können Sie RedShift verwenden – ein verwalteter Data Warehouse-Service in Petabyte-Größe
    • Zur Analyse protokollbasierter Daten können Sie Elasticsearch Service verwenden – die verwaltete Version der beliebten Open-Source-Analyse-Engine Elasticsearch

     

    Aktion

    Nachdem Sie die Metriken gesammelt und analysiert haben, können Sie diese verwenden, um ein bestimmtes Ergebnis oder einen bestimmten Prozess zu realisieren.

    Im Folgenden sind Beispiele für Ergebnisse und Prozesse aufgeführt:

    • Überwachung & Alarmierung
      • Sie können CloudWatch-Warnungen nutzen, um benachrichtigt zu werden, sobald ein System die Sicherheitsschwelle für eine bestimmte Metrik überschritten hat
      • Diese Warnung kann entweder eine manuelle oder automatische Herabsetzung auslösen.
    • Dashboards
      • Mit Cloudwatch Dashboards können Sie Dashboards für die Metriken erstellen
      • Diese Dashboards können zur langfristigen Überwachung und Verbesserung der Serviceleistung genutzt werden
    • Datengesteuerte Entscheidungen
      • Sie können leistungs- und geschäftsbezogene KPIs überwachen, um datengesteuerte Produktentscheidungen zu treffen

     

    Erkenntnisse

    • Unter Beobachtbarkeit versteht man den Prozess der Feststellung des internen Zustands eines Systems, durch den ein gewünschter Endzustand erreicht werden soll
    • Beobachtbarkeit umfasst die Erfassung und Analyse von Metriken sowie die daraus abgeleiteten Maßnahmen
    • Sie können Metriken auf Service-, Anwendungs- und Kontoebene sammeln
    • Mit Hilfe von Services wie CloudWatch Log Insight, Athena, Elasticsearch Service, RDS und Redshift können Metriken analysiert werden
    • Sie können anhand der Metriken Handlungen ableiten, indem Sie Überwachungs- und Alarmierungsmaßnahmen und Dashboards einrichten oder leistungs- und geschäftsbezogene KPIs überwachen

     

    Weitere Lektüre

Fazit

In diesem Modul haben Sie die Säule „Operational Excellence“ kennen gelernt. Sie haben das mentale Modell kennen gelernt, Vorgänge als Automatisierung zu betrachten. Sie haben IaC kennen gelernt und erfahren, wie Sie Ihre Services mit den gleichen Tools und Prozessen, die Sie bereits für Code verwenden, automatisch bereitstellen können. Sie haben gelernt, was Beobachtbarkeit bedeutet und wie man Metriken erfasst, analysiert und entsprechende Maßnahmen ableitet, um Ihre operativen Bemühungen kontinuierlich zu verbessern.

 

Weitere Lektüre

Kostenoptimierung

Die Säule Kostenoptimierung unterstützt Sie bei der Erzielung von Geschäftsergebnissen bei gleichzeitiger Kostenminimierung.


Mentales Modell

Beschäftigt man sich mit der Kostenoptimierung in der Cloud, dann empfiehlt es sich, die Ausgaben in der Cloud in Form von OpEx statt CapEx zu betrachten. Während OpEx ein fortlaufendes, nutzungsabhängiges Modell ist, beschreibt CapEx ein Modell zum einmaligen Kauf.

Üblicherweise waren die IT-Kosten für lokale Rechenzentren meist CapEx. Sie zahlen im Voraus für die gesamte Kapazität, unabhängig davon, ob Sie diese am Ende nutzen. Die Anschaffung neuer Server konnte ein langwieriger Prozess sein, bei dem mehrere Parteien ihre Zustimmung geben mussten. Das liegt daran, dass die CapEx-Kosten oft erheblich waren und Fehler teuer zu stehen kamen. Nach dem Kauf konnte es noch einige Wochen dauern, bis die Server tatsächlich eintrafen.

Bei AWS sind die Kosten OpEx. Sie zahlen auf fortlaufender Basis für die tatsächlich genutzte Kapazität. Neue Server können ohne langwierige Genehmigungsverfahren in Echtzeit durch die Technik bereitgestellt werden. Das liegt daran, dass die OpEx-Kosten viel geringer sind und bei veränderten Anforderungen rückgängig gemacht werden können. Da Sie nur bezahlen, was Sie tatsächlich nutzen, kann jede überschüssige Kapazität einfach gestoppt und eingestellt werden. Wenn Sie sich für die Nutzung eines Services entscheiden, kann er innerhalb von wenigen Sekunden und Minuten bereitgestellt werden.


Konzepte

Wenn Sie von einem CapEx-Modell zu einem OpEx-Modell wechseln, ändert sich der Ansatz zur Kostenkalkulation Ihrer Infrastruktur grundlegend. Statt mit großen im Voraus zu zahlenden Fixkosten zu rechnen, denken Sie in kleinen, laufenden variablen Ausgaben.

Dieses nutzungsabhängige Modell beinhaltet folgende Änderungen für Ihren Kostenoptimierungsprozess:

  1. Nutzungsabhängige Bezahlung
  2. Lebenszyklus der Kostenoptimierung


  • Nutzungsabhängige Bezahlung

    AWS-Services basieren auf einem nutzungsabhängigen Modell, bei dem Sie nur für die tatsächlich genutzte Kapazität bezahlen. Hier sind vier gängige Methoden zur Optimierung Ihrer Cloud-Ausgaben bei nutzungsabhängiger Bezahlung:

    1. Bestimmung der passenden Größe
    2. Serverlos
    3. Reservierungen
    4. Spot-Instances


    Bestimmung der passenden Größe

    Die Bestimmung der passenden Größe bezieht sich auf die Anpassung der Service-Bereitstellung und Konfiguration an die Verarbeitungslast. Bei Services, die auf EC2 basieren, bedeutet dies, die passende Instance-Größe und Familie zu wählen. Wenn Ihre Ressourcen zur Datenverarbeitung überwiegend ungenutzt sind, können Sie die Verwendung einer kleineren EC2-Instance in Betracht ziehen. Erfordert Ihre Verarbeitungslast viele spezifische Systemressourcen, können Sie den Wechsel zu einer für diese Ressource optimierten Instance-Familie in Betracht ziehen.

    Zur Unterstützung dieses Prozesses können Sie AWS Compute Optimizer verwenden, um auf Grundlage vergangener Systemmetriken optimale EC2-Größenvorschläge zu erhalten.


    Serverlos

    Wenn Sie serverlose Technologien wie Lambda verwenden, zahlen Sie nur für das, was Sie tatsächlich nutzen. Wird Lambda nicht ausgeführt, müssen Sie auch nichts bezahlen. Serverlose Technologien sind das beste Beispiel für die nutzungsabhängige Bezahlung. Sofern Ihr Anwendungsfall dies zulässt, kann die Entscheidung für serverlose Technologien die kostengünstigste Möglichkeit darstellen, Ihren Service zu erstellen.


    Reservierungen

    Die Beantragung von Reservierungen erfordert die Verpflichtung zur Zahlung einer bestimmten Menge an Kapazität im Austausch gegen einen erheblichen Rabatt. Für EC2 kann dies einen Rabatt von bis zu 72 % für die Datenverarbeitung ergeben.

    Um Reservierungen für Ihre Datenverarbeitung vorzunehmen, können Sie Savings Plans verwenden. Sie können sich für eine 1- oder 3-jährige Laufzeit anmelden und sich verpflichten, eine bestimmte Rechenkapazität zu verwenden, um Einsparungen bei EC2, Fargate und Lambda zu erhalten.

    Beachten Sie, dass Reservierungen nicht nur für EC2 gelten. Sie können auch für andere Services wie RDS, DynamoDB und CloudFront beantragt werden.


    Spot-Instances

    Mit EC2-Spot-Instances können Sie ungenutzte EC2-Kapazitäten nutzen, um Instances im Vergleich zu On-Demand-Preisen mit bis zu 90 % Rabatt zu betreiben. Dies kann bei fehlertoleranten Verarbeitungslasten zu enormen Einsparungen führen.

    Der Kompromiss bei der Verwendung von Spot-Instances liegt darin, dass EC2 die Kapazität jederzeit zurückfordern kann. Ihre Anwendung erhält zwei Minuten vorher eine Benachrichtigung über die Beendigung.


    Erkenntnisse

    • AWS-Services beruhen auf einer nutzungsabhängigen Bezahlung – Sie zahlen für die tatsächlich genutzte Kapazität
    • Durch die Bestimmung der passenden Größe für Instances, können Sie Geld für Services sparen, die nicht Ihrer Verarbeitungslast entsprechen
    • Mit serverlosen Technologien können Sie sicherstellen, dass Sie nur dann bezahlen, wenn Kunden den Service verwenden
    • Reservierungen können genutzt werden, um Rabatte im Austausch gegen eine Vorabverpflichtung zu erhalten
    • Mit Spot-Instances können Sie Rabatte für fehlertolerante Verarbeitungslasten erhalten


    Weitere Lektüre

  • Lebenszyklus der Kostenoptimierung

    Der Lebenszyklus der Kostenoptimierung beschreibt den kontinuierlichen Prozess zur Verbesserung der Cloud-Ausgaben im Laufe der Zeit.

    Er umfasst den folgenden dreistufigen Ablauf:

    1. Prüfen
    2. Nachverfolgen
    3. Optimieren


    Prüfen

    Bevor Sie die Cloud-Ausgaben optimieren können, ist es notwendig, dass Sie zunächst verstehen, woher sie kommen.

    Mit AWS Cost Explorer können Sie Ihre Cloud-Ausgaben im Laufe der Zeit veranschaulichen und überprüfen. Sie können die Ausgaben nach verschiedenen Aspekten wie Service und Kategorie unterteilen. Verwenden Sie Cost Explorer, um einen umfassenden Überblick und detaillierte Berichte zur Rechnung zu erhalten.

    Wenn Sie detailliertere Daten benötigen, können Sie mit dem AWS-Kosten- und Nutzungsbericht stündliche Posten erhalten.


    Nachverfolgen

    Sobald Sie einen Überblick über die gesamten Cloud-Ausgaben haben, können Sie beginnen, diese nach den für Sie relevanten Dimensionen zu gruppieren. Dazu werden Kostenzuweisungs-Tags verwendet. Diese müssen für alle Tags, die Sie überwachen möchten, aktiviert werden.

    Hier finden Sie gängige Beispiele für Tag-Kategorien:

    • Anwendungs-ID – Identifiziert Ressourcen, die sich auf eine bestimmte Anwendung beziehen, um Ausgabenänderungen und das Abschalten am Ende von Projekten problemlos nachverfolgen zu können.
    • Automatisierungs-Opt-In/Opt-Out – Zeigt an, ob eine Ressource in eine automatisierte Aktivität wie das Starten, Stoppen oder die Größenanpassung von Instances einbezogen werden soll.
    • Kostenstelle/Geschäftseinheit – Ermittelt die mit einer Ressource verbundene Kostenstelle oder Geschäftseinheit, was üblicherweise zur Zuweisung und Überwachung von Kosten dient.
    • Besitzer – Gibt an, wer für die Ressource verantwortlich ist. In der Regel ist dies der technische Besitzer. Bei Bedarf kann ein separates Geschäftsinhaber-Tag hinzugefügt werden. Der Besitzer kann in Form einer E-Mail-Adresse angegeben werden. Durch die Verwendung einer E-Mail-Adresse werden bei Bedarf automatische Benachrichtigungen an den technischen Besitzer und den Geschäftsinhaber unterstützt (z. B. wenn die Ressource für Elastizität oder für die Größenanpassung in Frage kommt).

    Zusätzlich zu den Tags können Sie mit AWS-Budgets auch Budgetziele definieren. Mit Budgets können Sie die Ausgaben in den für Sie relevanten Dimensionen überwachen. Budgets überwacht und erstellt Prognosen für die aktuellen AWS-Ausgaben gemäß der von Ihnen festgelegten Filter.


    Optimieren

    Nachdem Sie Ihre Ausgaben überprüft und nachverfolgt haben, können Sie diese optimieren. Bei der Optimierung der Ausgaben werden die Methoden angewandt, mit denen wir uns bei der nutzungsabhängigen Bezahlung beschäftigt haben. In der Regel erfolgt die Optimierung im Rahmen eines übergreifenden Budgetziels.

    Hier sind Beispiele für Optimierungsziele:

    • Prozentualer Anteil der EC2-Instances, die durch einen Kosteneinsparungsplan abgedeckt sind – die Organisation sollte eine Abdeckung von 80-90 % anstreben
    • Prozentualer Anteil der ungenutzten Ressourcen – die Definition der ungenutzten Ressourcen und der genaue Prozentsatz sind je nach Unternehmen unterschiedlich


    Erkenntnisse

    • Der Lebenszyklus der Kostenoptimierung ist ein kontinuierlicher Prozess zur Verbesserung der Cloud-Ausgaben im Laufe der Zeit
    • Der Lebenszyklus der Kostenoptimierung umfasst das Prüfen, Nachverfolgen und Optimieren von Ausgaben
    • Die Prüfung der Ausgaben erfolgt mit Hilfe von Tools wie dem Cost Explorer und dem Kosten- und Nutzungsbericht, die dazu dienen, dass Sie die Ausgaben nachvollziehen können
    • Die Nachverfolgung der Ausgaben erfolgt unter Verwendung von Kostenzuweisungs-Tags und Budgets, die dazu dienen, die Daten nach den für das Unternehmen relevanten Dimensionen zu filtern
    • Die Optimierung der Ausgaben beinhaltet die Verwendung der Methoden aus dem vorherigen Abschnitt als Teil eines übergreifenden Budgetziels


    Weitere Lektüre

Fazit

In diesem Modul haben Sie die Säule „Kostenoptimierung“ kennen gelernt. Sie haben gelernt, wie ein OpEx-orientiertes Modell für die Cloud-Ausgaben angewendet werden kann. Sie haben die Methoden der Kostenoptimierung wie die Bestimmung der passenden Größe, serverlose Technologien, Reservierungen und Spot-Instances kennen gelernt. Sie haben gelernt, Ihr Budget mit Hilfe von Services wie dem Cost Explorer, Tags und Budgets zu prüfen, nachzuverfolgen und zu optimieren.

 

Weitere Lektüre

AWS GovCloud (USA)

Dieser Abschnitt richtet sich an diejenigen, deren Workloads FedRAMP, DoD SRG, ITAR, CJIS oder andere strenge Anforderungen erfüllen müssen oder die Daten enthalten, die als kontrollierte unklassifizierte Informationen (CUI) klassifiziert sind.

AWS GovCloud (USA) hilft bei der Erfüllung der spezifischen Compliance- und Regulierungsanforderungen von US-Regierungsbehörden auf Bundes-, Landes- und kommunaler Ebene sowie von kommerziellen US-Organisationen in den Bereichen Luft- und Raumfahrt, Rüstungsproduktion, Strafverfolgung, Gesundheitswesen, Finanzdienstleistungen, Energie und anderen stark regulierten Branchen. Die AWS GovCloud (USA)-Regionen sind isolierte AWS-Regionen, die von Mitarbeitern mit US-Staatsbürgerschaft auf US-Boden betrieben werden und für das Hosting sensibler Daten und regulierter Workloads in der Cloud konzipiert sind.

AWS GovCloud (USA) bietet Regierungskunden und ihren Partnern die Flexibilität, sichere Cloud-Lösungen zu entwickeln, die mit der FedRAMP High-Baseline, der Sicherheitsrichtlinie für Strafrechtsinformationssysteme (CJIS) des DOJ, den ITAR (U.S. International Traffic in Arms Regulations), den EAR (Export Administration Regulations), dem Cloud Computing Security Requirements Guide (SRG) des Verteidigungsministeriums (DoD) für Impact Level 2, 4 und 5, FIPS 140-2, IRS-1075 und anderen Compliance-Regimen übereinstimmen.

Von kontrollierten unklassifizierten Informationen (CUI), personenbezogenen Daten (PII), sensiblen Patientenakten und Finanzdaten bis hin zu Strafverfolgungsdaten, exportkontrollierten Daten und anderen Formen von CUI können die AWS GovCloud (USA)-Regionen ihren Kunden helfen, in jeder Phase ihrer Cloud-Reise die Compliance zu gewährleisten.

 

Weitere Lektüre

Herzlichen Glückwunsch!

Sie haben den AWS-Grundlagenkurs abgeschlossen. In diesem Kurs haben Sie Folgendes gelernt:

  • Die 5 Säulen des AWS Well-Architected Framework
  • Wichtige mentale Modelle, die eine cloud-native Denkweise über die fünf Säulen darstellen
  • Kernkonzepte innerhalb jeder der fünf Säulen

Sie kennen nun die Grundlagen für die Erstellung sicherer, leistungseffizienter, zuverlässiger, betriebswirtschaftlich einwandfreier und kostenoptimierter Services in der Cloud. Trotzdem wir erst an der Oberfläche dessen gekratzt haben, was es zu wissen gibt, haben Sie jetzt einen soliden Ausgangspunkt für Ihren weiteren Weg mit AWS. Nachdem Sie nun den AWS-Grundlagenkurs abgeschlossen haben, können Sie das Gelernte anwenden, um Ihren nächsten Service auf AWS zu erstellen.