AWS Solutions Architect — Cost-Optimized Architectures: 60 Übungsfragen

Step 1: Klassifizieren des Zugriffsverhaltens — Bei unregelmäßigen, schwer vorhersehbaren Zugriffen ist eine automatische Klassifikation und Transition vorteilhaft: verkauftes oder aktives Material bleibt schnell zugänglich, inaktive Daten wandern in günstigere Klassen.

Step 2: Automatisches Tiering als primäre Maßnahme — S3 Intelligent‑Tiering verschiebt Objekte automatisch zwischen Zugriffs‑Tierklassen basierend auf Zugriffsmustern ohne Retrieval‑Gebühren für die Migration zwischen den Tierklassen, was bei unvorhersehbaren Zugriffen teure Fehlentscheidungen vermeidet.

Step 3: Ergänzende Lifecycle‑Regeln für eindeutig inaktive Daten — Für Objekte mit klarer Langzeitinaktivität (z. B. 365 Tage) können Lifecycle‑Regeln eine Transition zu Glacier/Deep‑Archive planen, wo sehr niedrige Speicherkosten angezeigt sind und seltene Retrievals toleriert werden. Trap: Der Prüfungsfehler ist zu denken, dass das billigste Storage‑Tier (Glacier Deep Archive) immer die beste Wahl ist — bei unvorhersehbaren Zugriffen können Retrieval‑Kosten und Latenz hohe operative Kosten oder SLA‑Brüche verursachen. Warum jede falsche Option versagt: Option 1 (Intelligent‑Tiering) ist korrekt: es minimiert Kosten bei unvorhersehbaren Zugriffsmustern automatisch. Option 3 (Lifecycle → Glacier nach 365 Tagen) ist korrekt für eindeutig inaktive Daten und reduziert langfristige Kosten weiter. Option 2 (sofort alle Daten nach Glacier Deep Archive): falsch/praktisch problematisch — zwar minimale Speicherkosten, aber hohe und teils langsame Retrieval‑Kosten und Latenzen; zudem ungeeignet, wenn einige Objekte doch häufiger gebraucht werden. Option 4 (alle in Standard‑IA und manuell prüfen): Standard‑IA kann teurer sein als Intelligent‑Tiering bei unbekanntem Verhalten und manuelle Prüfungen sind nicht skalierbar für Petabyte‑Umgebungen; außerdem fehlen automatische Transitions für echte Archivierung. Fazit: Automatisierung (Intelligent‑Tiering) + gezielte Lifecycle‑Archivierung bietet bestes Kosten‑/Leistungs‑Resilienz‑Verhältnis.

Step 1: Analyse des Workloads — Bei vorhersehbarer Basislast mit kurzen, starken Spitzen ist es wirtschaftlich, eine Basiskapazität zu provisionieren, statt dauerhaft On-Demand zu zahlen. DynamoDB bietet Auto Scaling, das die eingestellte Provisioned Capacity automatisiert nach oben und unten anpasst. Adaptive Capacity hilft zusätzlich bei Hot Partitions.

Step 2: Bewertung der Optionen — Provisioned Capacity mit Auto Scaling erlaubt es, eine Basiskapazität zu einem geringeren Preis zu halten und während Spitzen die Kapazität zu erhöhen. Adaptive Capacity sorgt dafür, dass einzelne Partitionen mit überdurchschnittlicher Last nicht zum Engpass werden.

Step 3: Umsetzungsempfehlung — Konfigurieren Sie eine realistische minimale Provisioned Capacity zur Deckung der Basislast, setzen Sie Auto Scaling mit einem sinnvollen Zielauslastungswert (z. B. 60-70 %) und aktivieren Sie Adaptive Capacity. Überwachen Sie CloudWatch-Metriken (Throttles, ConsumedCapacity) und passen Sie die Richtlinien an. Trap: Ein häufiger Prüfungsfehler ist zu glauben, On-Demand sei immer die sicherste und günstigste Option bei variablen Lasten. On-Demand ist ideal für unvorhersehbare, sporadische Workloads, kann aber teurer sein, wenn eine dauerhafte Basislast existiert. Why each wrong answer fails: - Option 1 (On-Demand): On-Demand ist sehr flexibel, aber bei dauerhaft vorhandener Basislast kostenintensiver als provisionierte Kapazität mit Auto Scaling. Bei regelmäßigen Spitzen zahlt man für alle Anfragen ohne Basisrabatt. - Option 3 (Globale Tabellen): Globale Tabellen lösen Latenz- und Regionalisierungsprobleme, helfen aber nicht primär Kosten zu senken; sie erhöhen Kosten, da Replikation und zusätzlicher Write-Verkehr anfallen. - Option 4 (DAX): DAX reduziert Lese-Latenz und kann Kosten pro Anfrage senken, ist aber nur für leseintensive Patterns sinnvoll; es adressiert nicht Write-Spitzen und ist ein zusätzlicher Service mit eigenem Kosten- und Betriebsaufwand. DAX allein löst nicht das Problem von Provisioned Writes oder sprunghafter Schreiblast. Zusammenfassend ist Provisioned Capacity mit Auto Scaling und Adaptive Capacity die kosteneffizienteste und resilienteste Wahl für vorhersehbare Basislast mit wiederkehrenden Spitzen.

Step 1: Analyse der Nutzung und Kostenbasis — Ermitteln Sie mit CloudWatch, Cost Explorer und eventuell Compute Optimizer den stabilen Baseline‑Verbrauch (vCPU, Stunden). Eine Baseline ist prädestiniert für langfristige Rabatte (Savings Plans / RIs).

Step 2: Optimierung der Baseline — Abschließen eines Compute Savings Plans (oder gezielte RIs) reduziert die Kosten des dauerhaft laufenden Kapazitätsanteils, bleibt dabei flexibler als starr gebundene RIs.

Step 3: Flexible, kosteneffiziente Skalierung für Spitzen — Eine Auto Scaling Group mit MixedInstancesPolicy erlaubt den Einsatz von Spot‑Instances für zusätzliche, kostengünstige Kapazität während Spitzen und nutzt On‑Demand‑Instances als Fallback bei Spot‑Interruptions, wodurch Verfügbarkeit erhalten bleibt. Trap: Häufiger Prüfungsirrtum ist zu glauben, dass maximale Einsparung (Spot‑only) immer richtig ist — aber Spot kann unterbrechbar sein und ist ungeeignet für kritische Pfade ohne Fallback. Ebenso wird Reserved Instances (RI) manchmal fälschlich als immer besser angesehen als Savings Plans; Savings Plans sind meist flexibler und decken mehr Use‑Cases ab. Warum jede falsche Option versagt: Option 3 (Spot‑only): Zwar sehr günstig, aber Spot‑Instances können jederzeit unterbrochen werden; Produktions‑Webserver ohne robuste Fallbacks würden Verfügbarkeit opfern. Für kurze, wiederkehrende Spitzen ist Spot alleine ein zu hohes Risiko. Option 4 (Standard 5‑Jahres RIs für alle): 5‑Jahres RIs reduzieren Kosten deutlich, sind aber sehr unflexibel (Festlegung auf AZ/Region/Instance‑Family je nach Typ) und binden Kapital langfristig; bei sich ändernden Anforderungen kann das zu Over‑ oder Under‑Provisioning führen. Zudem ist es oft kosteneffizienter, erst nach Rightsizing und Stabilisierung Savings Plans oder Convertible RIs zu wählen. Option 1 (Savings Plans) ist korrekt, weil sie Kosten bei gleichzeitiger Flexibilität senken. Option 2 (ASG MixedInstancesPolicy) ist korrekt, weil sie geringere Kosten (Spot) mit verfügbaren Fallbacks (On‑Demand) kombiniert, sodass Spitzen gehalten werden können ohne Ausfälle. Zusammen: Messen → Baseline mit Savings Plans decken → Spitzen mit einer Mixed ASG aus Spot + On‑Demand abfangen.

Step 1: Anforderungen und Constraints verstehen — Es muss sichergestellt werden, dass sowohl aktuelle als auch frühere Versionen von Objekten nach 365 Tagen unwiderruflich gelöscht werden. Die Lösung sollte skalierbar, kosteneffizient und automatisiert sein, ohne hohen Verwaltungsaufwand oder manuelle Eingriffe.

Step 2: AWS-Mechanismen anwenden — S3-Lifecycle-Richtlinien unterstützen sowohl Expiration (zum Löschen der aktuellen Objektversion) als auch NoncurrentVersionExpiration (zum Löschen früherer Versionen) und funktionieren nativ mit Versioned Buckets. Der richtige Weg ist, die Versionierung aktiviert zu lassen (um Compliance bzgl. Versionsverfolgung und Audit-Trail zu garantieren) und eine Lifecycle-Regel zu erstellen, die beide Aktionen nach 365 Tagen ausführt. Dies skaliert automatisch bei Millionen von Objekten, verursacht minimale zusätzliche Kosten und ist robust.

Step 3: Betrieb, Sicherheit und Trade-offs — Kosten: Lifecycle automatische Löschung reduziert Speicher- und Versioning-Kosten langfristig. Performance: Keine Laufzeit-Performance-Auswirkungen. Sicherheit/Compliance: S3 Lifecycles sind auditable (CloudTrail für Lifecycle-Aktionen) und garantieren Durchsetzung. Resilienz: Die Regel entfernt Daten dauerhaft; stellen Sie sicher, dass keine Lebensdauerkonflikte mit Object Lock oder rechtlichen Aufbewahrungspflichten bestehen. Trap: Ein häufiger Prüfungsfehler ist die Annahme, dass Policies oder manuelle Skripte sicherer oder „besser kontrollierbar“ sind. Manuelle Lösungen sind jedoch fehleranfällig und skaliere schlecht. Why each wrong answer fails: - Einen täglichen Lambda-Job, der Objekte und alle Versionen nach 365 Tagen manuell löscht: Das funktioniert zwar, ist aber operational aufwändig, skaliert schlecht über Millionen von Objekten, erhöht die Betriebs- und Fehleranfälligkeit und kann zu Kosten durch Lambda-Ausführung und List/Storage-Operationen führen. Außerdem sind Ratenbegrenzungen und Inkonsistenzen möglich. - Bucket-Policy verwenden, die Objekte nach 365 Tagen automatisch löscht: Bucket-Policies steuern Zugriff (IAM-Berechtigungen), nicht Lifecycle-Management. Sie können Objekte nicht zeitbasiert löschen. - MFA Delete aktivieren und Administratoren anweisen, ältere Versionen manuell zu entfernen: MFA Delete erhöht die Sicherheit gegen unbeabsichtigtes Löschen, verhindert aber nicht das automatische Entfernen nach 365 Tagen; manuelle Entfernung ist fehleranfällig und widerspricht dem Ziel der Automatisierung und Skalierbarkeit. Fazit: Die kombinierte Nutzung von S3-Versionierung plus einer Lifecycle-Regel mit Expiration und NoncurrentVersionExpiration ist die kosteneffizienteste, skalierbarste und sicherste Methode, um sowohl aktuelle als auch alte Versionen nach 365 Tagen unwiderruflich zu löschen.

Step 1: Datengrundlage schaffen — Right-Sizing braucht valide, representative Metriken über CPU, Memory (via Agent), Netzwerk, EBS I/O sowie Lastprofile über verschiedene Zeiträume (Tage, Wochen, Saisonalität). CloudWatch Basic bietet 5‑Minute-Metriken, während Detailed Monitoring (1‑Minute-Auflösung) und zusätzliche benutzerdefinierte Metriken wichtig sind, um Spitzen und Baseline sauber zu erfassen.

Step 2: Automatisierte Analyse nutzen — AWS Compute Optimizer analysiert historische Leistungsdaten (z. B. CPU, Memory, EBS) und erstellt Empfehlungen (größer, kleiner, family change). Er kombiniert CloudWatch- und CloudTrail-Daten, bietet zu erwartende Kosteneinsparungen und Schätzungen zum Performance-Impact. In Kombination mit CloudWatch können Sie so fundierte, risikoarme Änderungen planen.

Step 3: Maßnahmen planen und validieren — Erstellen Sie einen Testplan: zuerst nicht-produktive Umgebungen anpassen, Lasttests durchführen, schrittweise in Produktion umsetzen mit Canary-Deployments und Monitoring/Alarmierung zur Erkennung von Performanceproblemen. Ergänzen Sie die Analyse durch Kostenprojektionen (Cost Explorer) bevor Sie Commit-Entscheidungen (Savings Plans / RIs) treffen. Trap: Ein häufiger Fehler ist, sofort RIs oder Savings Plans zu kaufen ohne ausreichende Messdaten. Commit-Entscheidungen ohne valide Nutzungsbasis führen zu Overcommit oder verpassten Einsparungen. Warum jede falsche Antwort fehlschlägt: - On-Demand-Instanzen abschaffen und alles auf 3-jährige Standard RIs umstellen: Das ist ein zu radikaler Schritt. Ohne Right-Sizing und stabile Nutzungsmuster riskieren Sie, falsche Commitments einzugehen. Standard RIs eignen sich nur, wenn die Workload absolut vorhersehbar und stabil ist. - Savings Plans automatisiert kaufen, ohne zuvor Workload-Messungen durchzuführen: Savings Plans reduzieren Kosten, aber ein blindes Commitment kann zu Engpässen oder Überzahlungen führen. Sie sollten Messdaten und Empfehlungen aus Compute Optimizer / Cost Explorer heranziehen, um die richtige Commit-Höhe zu bestimmen. Zusammenfassung: Sammeln Sie granularere Metriken mit CloudWatch Detailed Monitoring und nutzen Sie Compute Optimizer für datengetriebene Right-Sizing-Empfehlungen; erst dann sollten Sie Commit-Optionen bewerten.

Step 1: Zugriffsmuster bewerten — Das Muster ist deterministisch: intensiv in den ersten 30 Tagen, danach selten. Damit lassen sich gezielte Lifecycle-Regeln effizient einsetzen.

Step 2: Kostenfaktoren berücksichtigen — S3 Standard bietet niedrige Latenz für aktive Daten; S3 Standard-IA (Infrequent Access) hat geringere Speicherkosten, aber Aufruf-/Abrufkosten und mindestens 30 Tage Mindestablage. Wenn Sie Daten genau nach 30 Tagen verschieben, vermeiden Sie die Strafkosten der Mindesthaltung und reduzieren Speichergebühren, ohne unnötige Abrufkosten in den ersten 30 Tagen zu erzeugen.

Step 3: Umsetzung und Operation — Erstellen Sie eine Lifecycle-Regel, die Objekte mit Alter >= 30 Tage zu Standard-IA verschiebt. Überwachen Sie Zugriffsmuster regelmäßig; falls Muster sich ändert, kann ein angepasstes Intervall oder Intelligent-Tiering sinnvoll werden. Trap: Viele glauben, Intelligent-Tiering sei immer die beste Wahl. Intelligent-Tiering ist nützlich bei unbekannten oder wechselnden Zugriffsmustern, weil es automatisch verschiebt, hat aber eine geringe monatliche Verwaltungsgebühr pro Objekt und kann teurer sein, wenn das Zugriffsmuster bereits bekannt und stabil ist. Why each wrong answer fails: - Directes Verschieben zu Glacier Instant Retrieval: Glacier Instant Retrieval hat zwar niedrige Speicherpreise, aber Archive-Klassen können strengere Mindestaufenthaltsdauern, Abrufkosten und evtl. Einschränkungen haben; für Daten, die nach 30 Tagen nur selten, aber gelegentlich gelesen werden, ist Standard-IA oftmals günstiger und einfacher im Abruf. - S3 Intelligent-Tiering: Automatisch und sicher bei unbekannten Mustern, aber es gibt eine geringe monatliche Überwachungsgebühr und in Fällen mit klar bekanntem Zeitfenster (30 Tage) ist eine gezielte Lifecycle-Regel meist günstiger. - S3 One Zone-IA: Günstiger Speicherpreis, aber geringere Verfügbarkeit und fehlender AZ-Redundanz. Für Unternehmensdaten, die weiterhin zuverlässig verfügbar sein müssen, ist One Zone-IA ein Risiko (keine Multi-AZ-Durability). Daher nicht die beste Wahl, wenn Daten nicht als rein rekonstruktiv betrachtet werden können. Empfehlung: Bei klar definiertem Muster ist Standard → Standard-IA nach 30 Tagen kosteneffizient und operational einfach umsetzbar.

Step 1: Diagnose mit Metriken und Recommender: Zuerst sammeln Sie verlässliche Daten — CloudWatch (CPU, Memory über benutzerdefinierte Metriken, Netzwerkauslastung, EBS I/O) und AWS Compute Optimizer liefern konkrete Größenempfehlungen für Instance-Type/Größe basierend auf historischen Lastprofilen. Das identifiziert, ob die aktuelle Instanz überdimensioniert ist und ob ein kleinerer Instance‑Typ geeignet ist.

Step 2: Validierung und Testen: Erstellen Sie eine Test-/Staging-Umgebung oder führen Sie Rolling-Updates mit Canary-Instanzen aus, um die empfohlene Instanzgröße unter realen Lastbedingungen zu prüfen (Startzeit, Boot-Verhalten, Garbage Collection, Burst-Verhalten bei T‑Instanzen). Achten Sie auf Workload-spezifische Kriterien (z. B. spitzen Lasten, IO-Bursts), damit Performance nicht leidet.

Step 3: Schichtweise Migration und Monitoring: Nach erfolgreichem Test schalten Sie schrittweise Produktion um (Autoscaling-Gruppen, Blue/Green, oder Rolling-Replacement) und überwachen eng mit CloudWatch Alarms. Ergänzend können Savings Plans/RI nach Validierung Kosten weiter optimieren. Trap: Häufige Prüfungsfalle ist die Annahme, dass man sofort auf den billigsten Instance-Typ wechseln kann (z. B. T‑Instanzen) oder sofort RIs kauft. Ohne Daten und Tests riskieren Sie Performance-Einbrüche (Burst-Modelle, IO-Engpässe) oder binden sich langfristig an falsche Kapazität. Warum jede falsche Antwort scheitert: Antwort 1 (sofort auf t3.medium umstellen): Direkter Wechsel auf T‑Instances (Burst-Modelle) kann kurzfristig Kosten sparen, führt aber bei konstantem Bedarf oder bei Workloads mit sporadischen CPU-Spitzen zu Throttling oder Credits-Exhaustion; außerdem fehlt die Datengrundlage und Tests – daher riskant. Antwort 3 (sofort Reserved Instances kaufen): RIs oder Savings Plans reduzieren Kosten, sind aber langfristige Bindungen. Wenn die Instanz überdimensioniert ist, binden Sie sich an zu teure Kapazität. Erst Right-Sizing, dann Commit (RI/Savings Plan) kaufen. Antwort 4 (EBS-Volumes vergrößern): Die Metriken zeigen niedrige Netzwerk-/IO-Auslastung; Storage-Erweiterung erhöht Kosten und hilft nicht dem CPU-basierten Overprovisioning. Das adressiert nicht die beobachtete Ineffizienz. Gesamtbegründung: Kostenoptimierung beginnt mit Monitoring + Compute Optimizer, gefolgt von Validierung, Testen und schrittweiser Umstellung; erst danach sind langfristige Commit‑Entscheidungen (RIs/Savings) sinnvoll.

Step 1: Charakterisierung der Jobs — Die Jobs sind fehlertolerant und können nach Unterbrechung neu gestartet. Das macht sie ideal für Spot Instances, da Spot extrem niedrige Preise bietet, aber Unterbrechungen vorkommen.

Step 2: Optimierungsschritte — Verwenden Sie EC2 Spot Instances mit der Kapazitäts-optimierten Allocation oder Spot Fleets, um die Wahrscheinlichkeit einer stabilen Spot-Kapazität zu erhöhen. Kombinieren Sie dies mit einer Auto Scaling-Gruppe, die Mixed-Instances-Policy unterstützt, sodass verschiedene Instance-Typen genutzt werden können und die ASG einen kleinen On-Demand-Baseline-Anteil hält, um eine Mindestkapazität zu garantieren.

Step 3: Robustheit und Kostenbalance — Die Mixed-Instances-Policy erhöht die Chance, Spot-Kapazität zu finden, und der On-Demand-Baseline reduziert die Gefahr, dass kritische Mindestverarbeitungen verlieren. Implementieren Sie Job-Checkpointing, Backoff-Strategien und Warteschlangen (z. B. SQS) zur Koordination. Monitoring von Spot-Interruption-Rate und Auto Scaling Events ist essenziell. Trap: Prüfungsfallen sind die Annahmen, dass Reserved Instances oder Dedicated Hosts per se immer günstiger oder sicherer sind. Dedicated Hosts beseitigen zwar ‚Noisy neighbor‘-Risiken, sind aber deutlich teurer und ungeeignet für Spot-ähnliche Preissenkungen. RIs sind für langfristig konstante Lasten sinnvoll, nicht für variable Batch-Workloads mit Unterbrechbarkeit. Warum jede falsche Antwort scheitert: EC2 Spot Instances mit einer Kapazitäts-optimierten Allocation verwenden (korrekt): Spot bietet die größten Kosteneinsparungen für unterbrechbare Workloads; kapazitätsoptimierte Zuweisung reduziert die Wahrscheinlichkeit häufiger Unterbrechungen. Eine Auto Scaling-Gruppe mit Mixed-Instances-Policy und einem kleinen On-Demand Baseline-Anteil einrichten (korrekt): Mixed-Instances erhöht Flexibilität beim Auffinden von günstiger Kapazität; ein kleiner On-Demand-Anteil stellt Mindestverfügbarkeit sicher, ohne die Kosten zu sehr zu erhöhen. Alle Jobs auf teuren Dedicated Hosts ausführen, um Unterbrechungen zu vermeiden (falsch): Dedicated Hosts sind teuer und nicht notwendig für fehlertolerante Batch-Jobs. Sie reduzieren nicht die Kosten und sind für dieses Szenario ineffizient. Immer nur Standard Reserved Instances verwenden, um maximale Einsparung zu garantieren (falsch): Standard RIs bringen Einsparungen bei vorhersehbarer, stetiger Nutzung, sind aber unflexibel und nicht geeignet, wenn Workloads variabel sind oder für kurzfristig intensive Batchfenster, die Spot deutlich günstiger bedienen könnten. Implementierungshinweis: Testen Sie Spot-Strategien in einer Staging-Umgebung, automatisieren Sie Wiederaufnahme-Logik und verwenden Sie CloudWatch/Cost Explorer, um tatsächliche Einsparungen und Unterbrechungsmuster zu beobachten.

Step 1: Anforderungen bewerten — Das Unternehmen nutzt mehrere Instance-Familien und erwartet wechselnde Typen über die Zeit; Ziel ist eine signifikante Kostenreduktion über mehrere Jahre bei gleichzeitiger Flexibilität.

Step 2: Gegenüberstellung der Kaufoptionen — Standard RIs (Option 1) bieten hohe Einsparungen, sind aber stark an Instance-Familie, Region und häufig an Betriebssystem gebunden; sie eignen sich für sehr vorhersehbare, konstante Nutzung. Convertible RIs (Option 2) erlauben zwar Änderungen der Attribute (z. B. Instance-Familie) und sind flexibler als Standard RIs, bieten aber in der Regel geringere Einsparungen und sind komplizierter in der Verwaltung. Compute Savings Plans (Option 3) bieten eine feste Verpflichtung auf eine stündliche Compute-Ausgabe (USD pro Stunde) und gewähren Rabatte für beliebige EC2-Instance-Familien, AWS Fargate und Lambda in einer Region (oder global für EC2-Instance Savings Plans), wodurch sie die beste Balance zwischen Flexibilität und Einsparung darstellen.

Step 3: Empfohlene Umsetzung — Wählen Sie Compute Savings Plans mit einer Verpflichtungsdauer (1 oder 3 Jahre) passend zur Budgetplanung; kombinieren Sie diese mit Monitoring (Cost Explorer, AWS Budgets) zur Überwachung der Nutzung. Für sehr stabile, langfristige Basiskapazität können zusätzlich Standard RIs ergänzt werden, falls diese eine bessere Kostenstruktur bieten. Trap: Ein häufiger Irrtum ist zu glauben, dass Convertible RIs immer die flexibelste und damit beste Wahl sind. In Realität sind Compute Savings Plans oft flexibler und einfacher in gemischten Umgebungen (inkl. Fargate/Lambda), während Convertible RIs eher für bestimmte Umstellungen nützlich sind. Warum die falschen Antworten fehlschlagen: - Standard RIs (Option 1): Bieten gute Einsparungen, aber geringe Flexibilität zwischen Familien/Regionen; schlecht, wenn sich die Infrastruktur häufig ändert. - Convertible RIs (Option 2): Flexibler als Standard RIs, aber oft teurer oder mit geringeren Einsparungen und komplexerer Umstellungslogik; nicht so universell wie Compute Savings Plans. - Dedicated Hosts (Option 4): Teuer und vorgesehen für spezielle Lizenz- oder Compliance-Anforderungen; keine Kostenoptimierung bei wechselnden Instance-Familien. Kosten/Leistung/Sicherheit/Resilienz-Abwägung: Compute Savings Plans maximieren Kosteneinsparungen bei gleichzeitiger Flexibilität (geringere Verwaltungsaufwände). Performance und Sicherheit bleiben unverändert; Resilienz wird nicht direkt beeinflusst, aber durch flexible Zuweisungsoptionen können Kosten optimiert werden, ohne Verfügbarkeitsanforderungen zu kompromittieren.

Step 1: Charakterisierung der I/O‑Profile — Erfassen Sie mit CloudWatch und dem EBS‑Metrics‑Set die durchschnittlichen und Spitzen‑IOPS, Latenzen und Durchsatzanforderungen, um zu entscheiden, ob entkoppelte IOPS sinnvoll sind.

Step 2: Auswahl des passenden EBS‑Typs — gp3 entkoppelt IOPS und Durchsatz von der Volume‑Größe, ermöglicht damit niedrigere Basiskosten und gezieltes Provisioning der IOPS nur wann nötig; io1/io2 sind nur bei konstant sehr hohem I/O‑Bedarf oder bei Bedarf an konsistenten sehr niedrigen Latenzen sinnvoll.

Step 3: Operationaler Kosten‑Hygiene und Skalierbarkeit — EBS Elastic Volumes erlaubt non‑disruptives Upsizing/Downsizing; automatisierte Snapshot‑Lifecycle‑Policies sichern Daten und die proaktive Entfernung nicht verwendeter Volumes reduziert laufende Kosten und Komplexität. Trap: Ein häufiger Fehler ist sofort io1/io2 auszuwählen weil sie maximale Performance garantieren; das ist teuer und oft unnötig, wenn Peaks nur gelegentlich auftreten. Warum jede falsche Option versagt: Option 1 (Wechsel zu gp3) ist korrekt — gp3 bietet bessere Kosteneffizienz durch getrennte IOPS/Throughput‑Provisionierung und sinkende Gesamtbetriebskosten für moderate Workloads mit gelegentlichen Peaks. Option 3 (Elastic Volumes + Snapshots + Entfernen ungenutzter Volumes) ist korrekt — verbesserte Verwaltung reduziert Kosten und die Fähigkeit zu dynamischem Anpassen vermindert Risiko bei Laständerungen. Option 2 (alle Volumes auf io1/io2) ist ungeeignet für generelle Kostenoptimierung — zwar garantierte Performance, aber sehr hohe Kosten; nur für kritische, latenzsensititve Datenbanken sinnvoll. Option 4 (lokaler Instanzspeicher): Lokaler Instanzspeicher bietet hervorragende Performance, ist aber ephemerisch (Datenverlust bei Reboot/Stop) und erschwert Hochverfügbarkeit/Resilienz; deshalb ungeeignet für persistente Produktionsdaten, außer in stark angepassten Architekturen mit Replikation. Zusammen: gp3 + gute Snapshot‑/Lifecycle‑Praxis und dynamische Volumenanpassung bieten das beste Kosten/Performance/Resilienz‑Profil.

Step 1: Workload-Charakteristika bestimmen — OLTP-MySQL mit stark variablen Lastspitzen benötigt schnelle Skalierung sowohl in Lese- als auch Schreibrichtung; die Reduktion von operationalem Overhead ist ein Ziel.

Step 2: Evaluierung der Optionen — Aurora Serverless v2 ist für relationale Anwendungen optimiert und bietet sehr feinkörnige, automatische Skalierung (Compute Capacity Units), nahezu transparenter Anpassung an Lastspitzen und automatische Übernahme von Managementaufgaben (Patchen, Failover). Im Gegensatz zu RDS mit Reserved Instances, die konstante Kapazität verbuchen, bietet Serverless Kostenoptimierung bei unregelmäßiger Nutzung, weil Sie nur für tatsächlich genutzte Kapazität bezahlen. Selbstverwaltete MySQL auf EC2-Spot (Option 3) erhöht den Management-Aufwand stark (Backup, Patching, HA-Design) und Spot ist ungeeignet für kritische OLTP-Datenbanken. Manuelles Vertikal/Horizontal Scaling (Option 4) erfordert viel Betriebsaufwand und kann bei plötzlichen Peaks zu Latenzproblemen führen.

Step 3: Umsetzungsempfehlung — Planen Sie Migrationstests zu Aurora (kompatible MySQL-Edition), prüfen Sie Read Replicas in Aurora, konfigurieren Sie Cluster-Parameter für Failover und Recovery. Testen Sie Lastspitzen-Szenarien, messen Sie Kosten mit Cost Explorer und passen Sie den Einsatz an (z. B. kombinieren Sie Serverless für Spitzen mit Provisioned-Aurora-Replikas für dauerhafte Basiskapazität falls nötig). Trap: Häufig wird angenommen, dass Serverless immer teurer ist als Reservierungen. Bei unvorhersehbarer, stark variierender Last ist Serverless oft kosteneffizienter, weil es die Abrechnung granular an die tatsächliche Nutzung koppelt. Warum die falschen Antworten fehlschlagen: - Standard-RIs (Option 2): Gut für vorhersehbare Lasten, aber bei variablen Peaks zahlen Sie entweder zu viel (wenn sie überprovisionieren) oder haben nicht genug Kapazität (wenn unterprovisioniert). - Selbstverwaltetes MySQL auf EC2-Spot (Option 3): Erfordert erheblichen Operational-Overhead (Backup, Patching, HA) und Spot-Instanzen sind nicht geeignet für zustandskritische OLTP-Systeme wegen Unterbrechungsrisiken. - Reduzierung der Instance-Größe und manuelles Skalieren (Option 4): Führt zu Performance-Risiken bei Peaks und erhöht den Betriebsaufwand; ist weniger reaktionsschnell und oft nicht kosteneffizient ohne Automatisierung. Kosten/Leistung/Sicherheit/Resilienz-Abwägung: Aurora Serverless v2 reduziert Management-Aufwand, passt Kosten an tatsächliche Nutzung an (Kostenersparnis), bietet gute Performance und eingebaute HA/Failover-Funktionen (Resilienz) sowie Sicherheitsfunktionen wie Verschlüsselung und IAM-Integration. Bei dauerhaften hohen Lasten sollten Sie Kosten und Latenz mit Provisioned-Aurora vergleichen.

Step 1: Anforderungen verstehen — Die Workloads sind vorhersehbar, geschäftskritisch und brauchen eine Kapazitätsgarantie innerhalb einer bestimmten AZ. Damit sind Optionen gefragt, die sowohl maximale Kosteneinsparung als auch garantierte Kapazität liefern.

Step 2: Produkt-Auswahl und Kombination — Zonal (Availability Zone) Standard Reserved Instances bieten in der Regel die höchsten Rabatte, weil sie die geringste Flexibilität verlangen; zonale RIs können zudem Kapazitätsvorteile bieten (je nach Typ). Wenn Sie absolute Kapazitätsgarantie benötigen, können Sie zusätzlich eine Capacity Reservation für die benötigte Anzahl von vCPUs / Instanzen in der AZ erstellen. Capacity Reservations können mit RIs kombiniert werden — RIs senken Kosten, die Capacity Reservation sichert die Ressource für kritische Fälle.

Step 3: Umsetzung und Kostenmanagement — Kaufen Sie zonale Standard RIs für die Basis-Instanzen mit einer 3‑Jahresbindung und, falls erforderlich, All Upfront Zahlung, um den maximalen Rabatt zu realisieren. Parallel richten Sie Capacity Reservations für kurzfristige Peaks oder kritische SLAs ein. Überwachen Sie die Nutzung und planen Sie regelmäßige Reviews, um Änderungen in Lastprofilen oder Architektur (z. B. Migration zu AWS-managed Services) zu berücksichtigen. Trap: Ein häufiger Fehler ist die Annahme, dass Compute Savings Plans Kapazitätsgarantien bieten — sie reduzieren Kosten, sind aber kein Ersatz für zonale Kapazitätsreservierungen. Savings Plans sind eher für Flexibilität geeignet, nicht für Kapazitätssicherung in einer spezifischen AZ. Warum jede falsche Antwort fehlschlägt: - Regional Compute Savings Plans kaufen: Compute Savings Plans optimieren Kosten über Families und Regionen hinweg, sie garantieren jedoch keine Kapazität in einer bestimmten AZ. Wenn Kapazitätsgarantie erforderlich ist, bieten sie keine Lösung. - Convertible RIs kaufen: Convertible RIs sind flexibler (Familienwechsel möglich), haben aber in der Regel geringere Einsparungen als Standard RIs und bieten nicht zwangsläufig Kapazitätsgarantien; sie sind nicht die kosteneffizienteste Wahl, wenn Sie bereits wissen, dass die Workload über lange Zeit in einer AZ läuft. Zusammenfassung: Für vorhersehbare, in einer AZ gebundene, geschäftskritische Workloads ist die Kombination aus zonalen Standard RIs (für maximalen Rabatt) und Capacity Reservations (für explizite Kapazitätsgarantie) die richtige Lösung.