Szenarien zu hoher Performance und Kostenoptimierung

Szenario: Die RDS-MySQL-Datenbank einer Nachrichtenwebsite verarbeitet 90 % Leseverkehr für Artikelinhalte, die höchstens einmal pro Stunde geändert werden. Die durchschnittliche Datenbank-CPU-Auslastung beträgt 80 %, die Kosten steigen und die Latenz pro Abfrage liegt bei 200 ms. Lösung: Fügen Sie vor RDS einen ElastiCache-Redis-Cluster hinzu und verwenden Sie das Muster Lazy Loading (Cache-Aside). Die Anwendung prüft zuerst den Cache – bei einem Cache-Treffer wird der zwischengespeicherte Artikel in <1 ms zurückgegeben. Bei einem Cache-Fehlversuch fragt sie RDS ab, gibt das Ergebnis zurück und schreibt es mit einer TTL von 1 Stunde in den Cache. Erwartetes Ergebnis: 90 % Cache-Trefferrate, eine auf unter 20 % sinkende RDS-CPU-Auslastung und eine auf unter 5 ms sinkende Latenz für zwischengespeicherte Antworten.

Szenario: Nutzer im asiatisch-pazifischen Raum benötigen 2–4 Sekunden zum Laden einer Webanwendung, die auf EC2 in us-east-1 gehostet wird. Die Anwendung stellt große statische Assets (Bilder, JS, CSS) bereit. Lösung: Platzieren Sie eine CloudFront-Distribution vor dem ALB. Konfigurieren Sie für den Pfad /static/* ein Cache-Verhalten mit einer langen TTL (z. B. 1 Woche), damit statische Dateien an CloudFront-Edge-Standorten in der Nähe der Nutzer in Asien zwischengespeichert werden. Dynamische API-Anfragen umgehen das Caching mit TTL=0. Asiatische Nutzer laden statische Assets in weniger als 100 ms von einem Edge-Standort in Singapur oder Tokio, statt auf Roundtrips nach us-east-1 zu warten.

Szenario: Ein Unternehmen verfügt über 500 EC2-Instances, von denen viele vor 3 Jahren mit großen Instance-Typen bereitgestellt wurden. Die AWS-Rechnung ist hoch, aber das Unternehmen weiß nicht, welche Instances überdimensioniert sind. Lösung: Aktivieren Sie AWS Compute Optimizer (kostenlos; verwendet 14 Tage CloudWatch-Metriken). Compute Optimizer analysiert die tatsächliche CPU-, Arbeitsspeicher-, Netzwerk- und Festplattenauslastung jeder Instance und gibt Empfehlungen zur richtigen Dimensionierung. Für eine mit durchschnittlich 8 % CPU-Auslastung laufende t3.xlarge würde eine Verkleinerung auf t3.small empfohlen. Die Umsetzung der Empfehlungen für 500 Instances reduziert die EC2-Kosten typischerweise um 20–40 %.

Szenario: Ein Genomikunternehmen führt nächtliche Batch-Jobs aus, die 8 Stunden dauern und bei einer Unterbrechung erneut ausgeführt werden können. EC2-On-Demand kostet für diese Jobs 10.000 $ pro Monat. Lösung: Verwenden Sie für die Batchverarbeitung EC2 Spot Instances. Spot Instances sind ungenutzte EC2-Kapazitäten, die mit einem Rabatt von bis zu 90 % verfügbar sind. Für unterbrechungstolerante Batch-Jobs verwenden Sie AWS Batch, das fehlgeschlagene Spot-Jobs automatisch erneut in die Warteschlange stellt und eine gemischte Flotte aus Spot Instances und einem minimalen On-Demand-Ersatz verwendet. Erwartete Einsparung: eine Reduzierung der Rechenkosten um 70–90 % – von 10.000 $ auf 1.000–3.000 $ pro Monat.

Szenario: Eine Gaming-Rangliste verwendet DynamoDB mit bereitgestelltem Durchsatz. Bei Spieleveröffentlichungen steigt der Datenverkehr um das 50-Fache und die Tabelle drosselt Anfragen. Außerhalb dieser Veröffentlichungen liegt der Durchsatz nahezu bei null – die bereitgestellte Kapazität bleibt ungenutzt. Lösung: Wechseln Sie DynamoDB in den On-Demand-Kapazitätsmodus. On-Demand skaliert ohne manuelle Kapazitätsplanung sofort auf jeden Durchsatz und berechnet die Kosten pro Anfrage statt pro bereitgestellter Einheit. Sie zahlen nur für die tatsächlich gestellten Anfragen – zwischen Veröffentlichungen entstehen keine Kosten für ungenutzte Kapazität. On-Demand tauscht geringfügig höhere Kosten pro Anfrage gegen garantierte Drosselfreiheit und keinen Verwaltungsaufwand für Kapazitäten ein.

Szenario: Ein Unternehmen speichert Millionen von benutzergenerierten Bildern in S3 Standard. Die Zugriffsmuster sind unvorhersehbar – auf einige Bilder wird täglich zugegriffen, auf andere monatelang nicht. Das Unternehmen möchte die Speicherkosten senken, ohne Lifecycle-Richtlinien manuell verwalten zu müssen. Lösung: Verwenden Sie S3 Intelligent-Tiering. Der Dienst verschiebt Objekte automatisch abhängig von den Zugriffsmustern zwischen verschiedenen Speicherklassen: Frequent Access (Standard), Infrequent Access (seit mindestens 30 Tagen nicht abgerufen), Archive Instant Access (seit mindestens 90 Tagen) und Archive Access (seit mindestens 90 Tagen, optional aktivierbar). Innerhalb von Intelligent-Tiering fallen keine Abrufgebühren an. Die Überwachungsgebühr beträgt 0,0025 $ pro 1.000 Objekte und Monat – bei großen Datenmengen vernachlässigbar.

Szenario: Ein Startup möchte Tabellen in einem S3-Datenlake abfragen. Es führt etwa 10 Ad-hoc-Abfragen pro Woche aus. Ein Anbieter schlägt einen Amazon-Redshift-Cluster des Typs dc2.large vor. Lösung für ein Startup: Beginnen Sie mit Amazon Athena – keine Infrastrukturkosten, Sie zahlen nur für die gescannten Daten (etwa 5 $/TB). 10 Abfragen pro Woche auf gut partitionierten Parquet-Daten könnten weniger als 5 $ pro Monat kosten. Redshift des Typs dc2.large kostet bei durchgehendem Betrieb etwa 180 $ pro Monat. Redshift wird erst dann kosteneffizient, wenn eine hohe Abfragekonkurrenz besteht (mehr als 50 Abfragen pro Tag) oder Antworten im Subsekundenbereich erforderlich sind. Das Schlüsselwort „Ad-hoc, selten“ weist eindeutig auf Athena hin.

Szenario: Ein relationaler Datenbankserver benötigt 64.000 IOPS bei konstant niedriger Latenz. Das aktuelle gp3-EBS-Volume stößt an seine IOPS-Grenze. Lösung: Führen Sie ein Upgrade auf io2 Block Express durch (ein EBS-Volume-Typ für datenintensive Datenbanken). io2 Block Express unterstützt bis zu 256.000 IOPS pro Volume und Latenzen von unter einer Millisekunde. Der Dienst ist teurer als gp3 (0,125 $/GB plus 0,065 $ pro bereitgestelltem IOPS und Monat), aber die einzige EBS-Option, die Anforderungen von mindestens 64.000 IOPS erfüllt. Für latenzkritische Datenbank-Workloads, bei denen die Obergrenze von 16.000 IOPS bei gp3 nicht ausreicht, ist io2 die einzige praktikable EBS-Wahl.

Szenario: Ein Unternehmen betreibt für eine Produktionsanwendung kontinuierlich 20 EC2-Instances des Typs r6i.4xlarge und erwartet, dass sich die Anforderungen drei Jahre lang nicht ändern. Die aktuellen On-Demand-Kosten für diese Instances betragen 80.000 $ pro Jahr. Lösung: Kaufen Sie Standard Reserved Instances mit einer Laufzeit von 3 Jahren (oder Compute Savings Plans) und leisten Sie eine vollständige Vorauszahlung, um den maximalen Rabatt zu erhalten. Standard Reserved Instances bieten gegenüber On-Demand einen Rabatt von bis zu 72 %. Die Instances laufen rund um die Uhr bei einem vorhersehbaren Workload – das klassische Einsatzprofil für Reserved Instances. Erwartete Kostensenkung: 80.000 $ × 0,72 = 22.400 $ pro Jahr gegenüber 80.000 $ pro Jahr bei On-Demand – eine Einsparung von 57.600 $ pro Jahr.

Szenario: Ein Unternehmen betreibt eine REST-API auf einer t3.micro-EC2-Instance, die 8 $ pro Monat kostet. Die API empfängt 1 Million Anfragen pro Monat, wobei die Verarbeitung jeder Anfrage 100 ms dauert. Das Team möchte wissen, ob Lambda günstiger wäre. Analyse: Lambda-Preisberechnung: 1.000.000 Anfragen × 0,0000002 $ = 0,20 $ (Anfragekosten) + 1.000.000 × 0,1 s × 128 MB Arbeitsspeicher × Tarif = etwa 1,67 $ (Rechenkosten) = etwa 1,87 $ pro Monat. Für diese API mit geringem Datenverkehr ist Lambda günstiger als EC2. Wenn der Datenverkehr auf mehr als etwa 40 Millionen Anfragen pro Monat steigt, wird EC2 günstiger. Verwenden Sie den Lambda Cost Calculator, um für jeden Workload den Break-even-Punkt zu ermitteln.

Szenario: Eine globale API für Benutzer in Europa, den USA und Asien weist eine uneinheitliche Latenz auf, weil der Datenverkehr unvorhersehbare Wege über das Internet nimmt. CloudFront wurde in Betracht gezogen, aber die API-Antworten sind dynamisch und können nicht zwischengespeichert werden. Lösung: Verwenden Sie AWS Global Accelerator. Der Dienst stellt weltweit zwei statische Anycast-IP-Adressen bereit. Der Datenverkehr der Benutzer gelangt am nächstgelegenen AWS-Edge-Standort in das globale AWS-Backbone und wird über das private AWS-Netzwerk zur Origin in der Zielregion weitergeleitet – die überlastete mittlere Strecke des öffentlichen Internets wird dabei vermieden. Global Accelerator verbessert die Antwortzeit dynamischer APIs um 20–60 % und ermöglicht einen sofortigen Failover, wenn ein Regionsendpunkt nicht mehr fehlerfrei funktioniert.

Testen Sie Ihr Verständnis der AWS-Solutions-Architect-Konzepte (SAA-C03) aus dieser Lektion.

In dieser Lektion haben Sie Szenarien zu folgenden Themen bearbeitet: Lazy Loading mit ElastiCache zur Senkung der RDS-CPU-Auslastung von 80 % auf 20 %, Spot Instances und AWS Batch für 70–90 % Kosteneinsparungen bei Batch-Jobs, Athena für seltene Ad-hoc-Abfragen im Vergleich zu Redshift für Analysen mit hoher Parallelität und S3 Intelligent-Tiering für unvorhersehbare Zugriffsmuster ohne Abrufgebühren. Als Nächstes folgt die abschließende Praxisprüfung: eine zeitlich begrenzte Mini-Prüfung mit gemischten Themenbereichen, um Ihre Prüfungsbereitschaft zu messen.