AWS Solutions Architect — High-Performing Architectures: 75 Übungsfragen

Step 1: Anforderungen analysieren — Das Schlüsselwort ist "gemeinsamer POSIX-Zugriff" und "gleichzeitiger Zugriff von Hunderten von Servern" sowie hoher Durchsatz. Ein verteiltes Dateisystem mit POSIX-Semantik ist erforderlich, das horizontal skaliert und für parallelen Zugriff optimiert ist.

Step 2: Abwägen der AWS-Storage-Services — Amazon EFS wurde für genau solche Szenarien entworfen: POSIX-kompatibel, NFS-basiert, kann von vielen EC2-Instances gleichzeitig gemountet werden, skaliert automatisch in Kapazität und unterstützt configurable throughput (Bursting vs. Provisioned Throughput) um hohe Bandbreiten zu liefern. Alternativ sind EBS-Volumes blockorientiert und primär an eine Instance gebunden; Multi-Attach unterstützt nur bestimmte Szenarien (lesend-schreibend für spezielle Cluster-Dateisysteme) und hat Einschränkungen. S3 ist ein Objektstore, nicht POSIX-nativ; S3FS-Workarounds bringen Konsistenz- und Performance-Probleme. FSx for Windows File Server ist für SMB/Windows-Workloads optimiert (nicht Linux/NFS/POSIX).

Step 3: Architekturempfehlung — Verwenden Sie Amazon EFS in einem passenden Performance-Mode (General Purpose vs. Max I/O) und wählen Sie Provisioned Throughput, wenn Ihr Workload konstant hohen Durchsatz benötigt oder der Durchsatz nicht linear mit Kapazität wachsen soll. Platzieren Sie EC2-Instances in denselben AZs oder über AZs (EFS ist AZ-redundant) und nutzen Sie Security Groups/NFS-Client-Auth. Überwachen Sie CloudWatch-Metriken (BurstCreditBalance, ThroughputBytes) und passen Sie den Modus an. Trap: Viele Kandidaten glauben, "EBS Multi-Attach" würde EBS für mehrere gleichzeitige Writer wie ein Netzwerk-Dateisystem machen; das ist eine Falle: Multi-Attach hat spezielle Einschränkungen, unterstützt nicht alle Dateisystemtypen und ist nicht äquivalent zu EFS für hunderte Clients. Why each wrong answer fails: - Amazon EBS (gp3) mit Multi-Attach: EBS ist blockbasiert und primär für einzelne Instance-Anbindung ausgelegt. Multi-Attach ist auf bestimmte Instance-Typen und Nutzungsfälle beschränkt, bietet keine POSIX-kompatible, gleichzeitige Dateisystem-Shared-Access-Experience für hunderte Server und skaliert nicht automatisch in Kapazität wie EFS. - Amazon S3 mit S3FS-FUSE: S3 ist ein Objektstore, kein POSIX-Dateisystem; FUSE-basierte Lösungen leiden unter hohen Latenzen, inkonsistenter Konsistenzsemantik (situationbedingt), Problem bei Dateisperren/Locks und schlechter Performance für Dateisystem-Workloads. - Amazon FSx for Windows File Server: FSx for Windows ist für Windows/SMB-Workloads gedacht und bietet nicht das POSIX/NFS-Verhalten, das Linux-basierte Anwendungen typischerweise benötigen; außerdem ist es nicht optimal, wenn Ihr Stack auf Linux/NFS basiert. Fazit: Amazon EFS ist die standardkonforme, skalierbare Lösung für gemeinsam genutztes POSIX-Dateisystem mit hohem Durchsatz und Hunderten von gleichzeitigen EC2-Clients.

Step 1: Zieldefinition und Mechanik – Um Latenz global zu reduzieren und das Origin-Load zu senken, setzt man ein CDN (CloudFront) ein. Ein CDN cached Inhalte an Edge-Standorten nahe zum Nutzer; Cache-Control-Header steuern TTL, Cacheability und Validierung. Origin Shield fügt eine zusätzliche Cache-Ebene innerhalb AWS hinzu, die Anfragen aus Edge-Standorten konsolidiert bevor sie zum Origin gehen.

Step 2: Konfigurationsempfehlungen – Setze CloudFront mit dem S3-Bucket als Origin und konfiguriere Cache-Control / Expires-Header korrekt bei der Asset-Erstellung (z. B. lange TTLs für statische Assets, Versionierung der Objektnamen bei Deployment). Nutze CloudFront-Behaviours für dynamische Endpunkte und setze Cache Keys und Query-String-Behandlung gezielt. Aktiviere Origin Shield für die Region, in der dein S3-Region-Endpoint liegt, um die Anzahl der direkten Origin-Requests zu reduzieren und Cold-Edge-Requests besser zu bündeln.

Step 3: Operative Maßnahmen und Monitoring – Überwache CloudFront-Metriken (Cache Hit Ratio, 4xx/5xx Raten, Origin-Requests) sowie S3-Messdaten; implementiere Objektversionierung für aggressive Caching-Strategien; bei dynamischen Inhalten erwäge Lambda@Edge oder Cache-Invalidation-Strategien. Teste Hotspots und optimiere TTLs je nach Content-Typ. Trap: Viele glauben, dass S3 Transfer Acceleration CloudFront ersetzt; Transfer Acceleration hilft bei direkten Uploads/Downloads zu S3 über das Edge-Netzwerk, aber es bietet kein globales, performantes Caching und reduziert nicht die Anzahl der Origin-Requests wie CloudFront mit Origin Shield. Ebenso ist Standard-IA nicht für Performance optimiert; es dient primär zur Kostensenkung bei seltenen Zugriffen. Why each wrong answer fails: - S3 Transfer Acceleration: Verbessert Performance für direkte Client-zu-S3 Transfers (insbesondere Uploads von entfernten Standorten) durch Nutzung des Edge-Netzwerks zum nächsten AWS-PoP, ist aber kein CDN und verringert nicht die Häufigkeit, mit der Nutzer Assets laden, wenn kein CloudFront vorgebaut ist. Es entlastet nicht nachhaltig den Origin für wiederholte Lesezugriffe. - Alle Inhalte in S3 Standard-IA speichern: Standard-IA senkt Kosten für seltenen Zugriff, hat aber gleiche Latenz wie Standard bei Zugriffen (nicht optimiert für häufige Hot-Reads) und ist nicht dafür gedacht, Performance oder Cache-Hit-Ratios zu verbessern. Zudem können Zugriffskosten bei häufigen Reads höher ausfallen als Standard. Warum die richtigen Antworten passen: - CloudFront + Cache-Control: CloudFront cached Content am Edge; mit richtigen Cache-Control-Headern lässt sich TTL und Validierung steuern, was Cache-Hit-Raten deutlich verbessert und Latenzen reduziert. - Origin Shield: Fügt eine zentrale Origin-PoP-Layer hinzu, konsolidiert Edge-Requests und reduziert dadurch die Last auf S3 und die Zahl der Origin-Anfragen, was besonders bei plötzlichen Lastspitzen die Origin-Stabilität verbessert.

Step 1: Verständnis des Ziels: Bei HPC/MPI-Workloads ist die wichtigste Anforderung niedrige Inter-Node-Latenz und hohe Bandbreite innerhalb derselben AZ/Physikdomäne. AWS bietet spezielle Funktionen (Cluster Placement Groups, Nitro/ENA, EFA), um den Netzwerkpfad zu optimieren und CPU-NIC-Offload zu nutzen.

Step 2: Konkrete Maßnahmen: Ein Cluster Placement Group erhöht die Wahrscheinlichkeit, dass die gewählten Instances auf derselben physischen Netzwerk-Switch-Infrastruktur platziert werden, wodurch Latenz und Jitter reduziert werden. Nitro-basierte Instanzen mit ENA bieten niedrige Latenz und hohe Netzwerkkapazität; EFA liefert zusätzliche Unterstützung für niedrige Latenz und geringe CPU-Overhead für HPC-Messaging (z. B. MPI). Zusammen maximieren sie Durchsatz und minimieren Latenz.

Step 3: Trade-offs & Resilienz: Cluster Placement Groups beschränken Sie meist auf eine einzelne AZ, was die Ausfallsicherheit bei AZ-Ausfällen reduziert — Sie müssen daher zusätzliche Ausfallsicherungsstrategien planen (z. B. periodische Snapshots, Multi-AZ-Failover-Strategien). Kostenlich können Nitro-Instanzen mit hoher Netzwerkausprägung teurer sein, liefern aber deutlich bessere Leistung pro Dollar für HPC-Anforderungen. Trap: Ein häufiger Prüfungsfehler ist, Cluster Placement Groups automatisch mit Multi-AZ-Redundanz zu verwechseln. Cluster-Placement optimiert Latenz, opfert aber typischerweise AZ-Isolation; Spread- oder Partition-Groups adressieren Ausfalldomänen, nicht Latenz. Why each wrong answer fails: - Spread Placement Group: Spread-Groups verteilen Instances über Hardware-Domänen, um gleichzeitige Hardware-Ausfälle zu minimieren. Sie optimieren nicht die niedrige Latenz zwischen allen Instanzen und können die Inter-Node-Latenz sogar verschlechtern, weil die Instances physisch weiter auseinander liegen können. - Partition Placement Group: Partition-Groups isolieren Workloads in Partitionen für kontrollierte Ausfalldomänen (nützlich für große verteilte Systeme). Sie sind nicht für maximale Netzwerkdichte und Mindestlatenz zwischen vielen Knoten gedacht. - Instances in verschiedenen AZs + NLB: Das Verteilen über AZs erhöht die Latenz (Cross-AZ-Kommunikation) und NLB hilft nur beim Load Balancing, nicht bei der Minimierung der Latenz zwischen Compute-Knoten. Außerdem unterstützt NLB nicht die semantischen Anforderungen von MPI für Peer-to-Peer-Konnektivität. Fazit: Für MPI-ähnliche, latenzkritische Clusterszenarien ist die Kombination aus Cluster Placement Group + ENA/Nitro-Instanzen und EFA die richtige Wahl; beachten Sie jedoch den Trade-off zwischen Performance und AZ-Resilienz.

Step 1: Anforderungen analysieren — Die Anwendung benötigt ein gemeinsames, POSIX-kompatibles Dateisystem mit niedrigem Latenzverhalten und gleichzeitigen Zugriffen von mehreren EC2-Instanzen in verschiedenen AZs. Verwaltung sollte einfach, skalierbar und hochverfügbar sein.

Step 2: AWS-Optionen abwägen — Amazon EFS ist ein verwaltetes NFS-Dateisystem, das mehrere EC2-Clients gleichzeitig bedienen kann. EFS bietet zwei Performance-Modi: General Purpose (Standard) und Max I/O. General Purpose ist für die meisten latenzempfindlichen, POSIX-konformen Workloads vorgesehen und bietet geringere Latenz; Max I/O bietet höhere Aggregate-Throughput- und IOPS-Skalierbarkeit, geht aber mit etwas erhöhter Latenz einher. EBS ist Block-Storage, kann nur von einer Instanz gleichzeitig im regulären Mode gemountet werden (außer über spezielle Cluster/Shared-Storage-Software), und ist AZ-gebunden. S3 ist objektbasiert, nicht POSIX-konform; FUSE-Mounts auf S3 sind experimentell/nicht performant und bieten keine konsistente POSIX-Semantik.

Step 3: Umsetzung und Kosten/Resiliency-Trade-offs — Wählen Sie EFS im General Purpose Performance Mode und konfigurieren Sie durchsatzorientiert (Burst- oder Provisioned-Throughput) je nach Lastprofil. EFS skaliert automatisch, unterstützt Multi-AZ-Failover und reduziert Verwaltungsaufwand. Kosten: EFS kann teurer pro GB sein als S3, aber bietet die notwendige Datei-Semantik. Wenn die Last sehr stark parallelisiert ist und Aggregate-Throughput wichtiger als minimale Latenz ist, wäre Max I/O zu prüfen. Überwachen Sie Latenz- und Durchsatzmetriken via CloudWatch und passen Sie gegebenenfalls Provisioned Throughput an. Trap: Ein häufiger Fehler ist, Max I/O automatisch als das „beste“ für Performance zu wählen — Max I/O erhöht zwar den Durchsatz, erhöht aber die Latenz, was für latenzempfindliche Anwendungen kontraproduktiv ist. Ebenso ist das Verwenden von EBS oder S3-FUSE oft eine vereinfachte, aber ungeeignete Lösung für echte POSIX-, Mehr-Client- und Latenz-Anforderungen. Warum jede falsche Antwort fehlschlägt: - Amazon EFS in Max I/O Performance Mode (für maximale Skalierbarkeit): Max I/O skaliert besser bei extrem parallelisierten Workloads, aber das Design führt zu leicht höheren Latenzen und einer anderen Locking/Concurrency-Performance. Für niedrige Latenz und typische POSIX-Workloads ist General Purpose meist geeigneter. - EBS-Volumes, jeweils ein Volume pro EC2 und ein Hintergrund-Replikationsmechanismus zur Synchronisation: EBS ist ein Block-Device, normalerweise an genau eine EC2-Instanz gebunden (Multi-Attach ist eingeschränkt und nicht für alle Dateisysteme geeignet). Eine selbstgebaute Replikation erhöht Komplexität, ist fehleranfällig, skaliert schlechter über AZs hinweg und erzeugt Konsistenzprobleme. - Amazon S3 mit einem FUSE-basierten Mount auf allen EC2-Instanzen: S3 ist objektbasiert, bietet keine native POSIX-Semantik; FUSE-basierte Lösungen (z. B. s3fs) haben hohe Latenz, inkonsistente POSIX-Verhalten, Probleme mit Locking und sind generell nicht für hochperformante, konsistenzsensible Mehr-Client-Anwendungen geeignet. Fazit: Für ein gemeinsam genutztes, POSIX-kompatibles Dateisystem mit niedriger Latenz und einfachem Management ist Amazon EFS im General Purpose-Modus die richtige Wahl. Bei speziellen extremen Parallelitätsanforderungen sollte Max I/O erwogen werden, wobei die erhöhte Latenz berücksichtigt werden muss.

Step 1: Anforderungen segmentieren - Workload A (Key‑Value, Multi‑Region‑Writes): benötigt Multi‑Master‑Fähigkeit über Regionen hinweg, deterministisches Conflict‑Handling und niedrige Latenz weltweit. - Workload B (relationale Transaktionen): benötigt vollständige ACID‑Transaktionen und meist Single‑Primary‑Writes, aber globale Lesezugriffe mit geringer Latenz.

Step 2: Dienstauswahl basierend auf AWS‑Eigenschaften - DynamoDB Global Tables: Bietet Multi‑Region Replikation und ermöglicht Multi‑Master Writes (regionale Schreiboperationen werden asynchron repliziert). Global Tables eignet sich für Key‑Value‑Objekte, die geringe Latenzen und eine schemalose Struktur brauchen. Konfliktlösung erfolgt über last‑writer‑wins oder anwendungsspezifische Logiken; dies ist designentscheidend. - Amazon Aurora Global Database: Diese Architektur hat einen primären Cluster für Writes in der Primary Region und sekundäre Lesereplikate in anderen Regionen mit sehr geringer Latenz für Reads (asynchrone Replikation). Aurora ist ideal für relationale, transaktionale Workloads, die primär in einer Region schreiben, aber global gelesen werden müssen.

Step 3: Kosten/Performance/Security/Resiliency Abwägungen - DynamoDB Global Tables: Skalierbar, verwaltet, niedrige Betriebsaufwände; Kosten steigen mit Replikation und Datenübertragung zwischen Regionen. Eignet sich hervorragend, wenn Ihre Anwendung mit eventual consistency oder region‑lokaler Strong Consistency umgehen kann (strong consistency ist regionspezifisch). - Aurora Global Database: Bietet relationale Features, schnelle Cross‑Region Read‑Latency durch optimierte physische Replikation; jedoch sind globale Writes nicht möglich (Writes müssen in Primary Region erfolgen). Aurora unterstützt Multi‑AZ, Backups, Verschlüsselung und IAM. Für extreme globale Writes ist Aurora nicht geeignet. Trap: übliche Prüfungsfalle - Viele Kandidaten glauben, Aurora Global Database könne Multi‑Master Writes über Regionen leisten — das ist falsch. Aurora Global Database ist primär für primäre Writes + globale Read‑Replicas konzipiert. Wenn Multi‑Region Writes benötigt werden, ist DynamoDB Global Tables die richtige Wahl. Why each wrong answer fails: - Option 3 (RDS Read Replicas cross‑region für Multi‑Region Multi‑Master Writes): RDS Cross‑Region Read Replicas bieten asynchrone Replikation und sind in der Regel read‑only in der Zielregion; sie unterstützen keine Multi‑Master Writes. Daher kann diese Lösung keine regional verteilten Schreiboperationen mit konsistenter Multi‑Master‑Semantik abdecken. - Option 4 (selbstverwaltete MySQL‑binlog Spiegelung in jeder Region): Selbstverwaltete Replikation erhöht Verwaltungsaufwand, Fehleranfälligkeit und Latenz; Konfliktlösung und Failover müssen selbst implementiert werden. Für Unternehmensumgebungen ist das ein hohes Risiko im Vergleich zu verwalteten Diensten. Außerdem ist binlog‑basierte Replikation oft asynchron und nicht für Multi‑Master über Regionen ohne komplexe Konfliktresolution geeignet. Fazit: Verwenden Sie DynamoDB Global Tables für verteilte, Multi‑Region‑writes Key‑Value Workloads und Aurora Global Database für relationale Workloads mit primären Writes und globalen Reads — jeweils unter Berücksichtigung von Konsistenzmodell, Kosten und betrieblichen Anforderungen.

Step 1: Workload und Ziele erfassen: Batch-Jobs sind CPU-intensiv, laufen in festen Zeitfenstern, sind checkpoint-fähig (können Unterbrechungen tolerieren) und das Ziel ist maximale Kosteneffizienz bei akzeptabler Resilienz.

Step 2: Bewertung der Optionen: Spot-Instances bieten erhebliche Kostenvorteile (bis zu 90% Rabatt), sind aber interruptible; da die Jobs checkpoint-fähig sind, können Unterbrechungen akzeptiert werden. Eine capacity-optimized Spot-Allocation reduziert die Wahrscheinlichkeit von Unterbrechungen durch Auswahl von Instance-Kapazitäten mit geringerer Unterbrechungswahrscheinlichkeit. Kombiniert man Spot mit einem kleinen Anteil On-Demand (Mixed-Instances-Policy) hat man automatische Fallback-Kapazität, um SLAs zu halten, falls Spot-Kapazität reduziert wird. ECS Fargate ist einfach zu betreiben, aber für sehr große CPU-gebundene Batch-Jobs oft teurer als EC2 Spot. EKS mit Managed Node Groups bietet Kubernetes-Features, aber reine On-Demand-Nutzung ist kostenintensiv; plus mehr Betriebsaufwand, wenn man Spot integrieren will. Reine On-Demand-EC2 gewährleistet Verfügbarkeit, ist aber teuer.

Step 3: Umsetzung: Verwenden Sie Auto Scaling Groups mit Mixed-Instances-Policy, capacity-optimized Spot Allocation und On-Demand-Fallback. Implementieren Sie Checkpointing und Job-Orchestrierung (z. B. AWS Batch oder Kubernetes Job-Controller), Monitoring, und Preemption-Handling (Spot Interruption Notices). Testen Sie Failover-Szenarien und Kostenprofil. Trap: Ein häufiger Trugschluss ist, dass Spot-Instances niemals für Produktionsarbeitslasten geeignet seien — das ist falsch für checkpoint-fähige Batchjobs, wo Spot exzellent ist. Warum jede falsche Antwort fehlschlägt: ECS Fargate: Einfach zu managen, aber typischerweise teurer bei großen, langfristigen CPU-lastigen Batchläufen; begrenztere Kontrollmöglichkeiten hinsichtlich Spot-ähnlicher Preisoptimierung. EKS On-Demand: Bietet Kubernetes-Vorteile, aber On-Demand allein ignoriert erhebliche Kosteneinsparungen; zudem höherer Betriebsaufwand im Vergleich zur ASG-Mix-Strategie. EC2 On-Demand: Maximale Verfügbarkeit, geringe Unterbrechungswahrscheinlichkeit, aber teuer — nicht kosteneffizient für planbare Batch-Fenster, wenn Spot mit Checkpointing verwendet werden kann. Deshalb ist die Mixed-Instance-Policy mit capacity-optimized Spot und On-Demand-Fallback die beste Balance aus Kosten, Leistung und Resilienz.

Step 1: Anforderungen und Einschränkungen verstehen — Die API ist auth-basiert (personalisiert), aber hat wiederholbare Teile, die sich für 30 Sekunden nicht ändern. Ziel: Latenz reduzieren für Endnutzer weltweit, Origin-Last auf EC2 reduzieren, und Sicherheit (keine unautorisierte Datenfreigabe) beibehalten.

Step 2: Evaluierung der Optionen — CloudFront als globales CDN kann API-Antworten am Edge cachen. Mit Cache-Policies und Origin-Request-Funktionen (CloudFront Functions oder Lambda@Edge) können Sie den Cache-Key so anpassen, dass nur die stabilen/gleichartigen Teile gecacht werden oder spezifische Header/Cookies für die Authentifizierung zur Origin-Weiterleitung genutzt werden, während dynamische Teile direkt vom Origin geladen werden. CloudFront ermöglicht kurze TTLs (z. B. 30 Sekunden) und zugleich Sicherheit durch Signaturen, WAF und Origin-Access.

Step 3: Umsetzungsempfehlung — Implementieren Sie CloudFront vor dem API (EC2/ALB Origin). Erstellen Sie Cache-Behaviors mit kurzen TTLs; nutzen Sie CloudFront Functions/Lambda@Edge, um Anfragen zu normalisieren, den Cache-Key selektiv zu verändern (z. B. basierend auf URL-Teilen, Query-Parameter, einem Hash für nicht-personalisierte Segmente) und sensible Authorization-Header nicht in den Cache-Key zu übernehmen. Authentifizierung kann am Edge geprüft (z. B. JWT-Verifikation in Lambda@Edge) oder an Origin delegiert werden; wenn JWT sicher am Edge validiert wird, können Sie personalisierte Inhalte teilweise auscachen oder gezielt weiterleiten. Trap: Ein häufiger Fehler ist anzunehmen, dass man einfach "Authorization" komplett im Cache-Key einschließen kann — das führt zu Cache-Explosion (praktisch kein Cache-Hit). Ebenso ist es riskant, personalisierte Inhalte ohne sorgfältige Trennung der wiederholbaren Teile zu cachen, da dies zu Datenleaks führen kann. Why each wrong answer fails: - API Gateway Cache: API Gateway bietet Caching, aber ist regional (nicht global) und bietet weniger Edge-Präsenz als CloudFront; für weltweite Latenzverbesserung ist CloudFront besser geeignet. API Gateway-Caching skaliert außerdem anders und kann teuer/komplex werden bei globalen Verteilungen. - Direktes In-Memory-Caching in EC2: Reduziert Origin-Latenz nur lokal, aber hilft nicht bei globalen Nutzern; Edge-Caching würde entfernte Latenz viel stärker reduzieren. Außerdem skaliert In-Memory-Caching pro-Instanz und hat Konsistenz-/Invalidierungsherausforderungen. - S3 als Proxy-Cache: S3 ist ein Objektstore, kein geeignetes Cache-Proxy für dynamische API-Antworten mit kurzer TTL; Operationen sind nicht so niedrig-latent wie Edge-Caching und S3 bietet keine flexible Request-Manipulation oder Header-basierte Cache-Policies wie CloudFront. Fazit: CloudFront zusammen mit CloudFront Functions oder Lambda@Edge erlaubt feinkörniges Edge-Caching (kurze TTLs), Anpassung des Cache-Keys für wiederholbare Teile und sichere Handhabung von Authentifizierungsmechanismen — somit reduziert es Latenz und Origin-Last am effektivsten.

Step 1: Problem- und Ursachebestimmung — Hohe GET-Last und Latenz in entfernten Regionen entstehen durch Entfernung zum Origin und begrenzte Netzpfade; wiederholte Origin-Zugriffe erhöhen Kosten und Latenz.

Step 2: Edge-Caching implementieren — CloudFront verteilt Objekte in Edge-Standorte weltweit, reduziert RTT und verringert origin-seitigen Durchsatz, weil wiederholte GETs lokal beantwortet werden; Origin Shield kann zusätzlich den Origin-Traffic zentralisieren.

Step 3: Upload-/Transfer-Optimierung für große Objekte — Multipart Upload teilt große Objekte in parallel übertragbare Teile, was Netzdurchsatz verbessert und Resilienz bei Unterbrechungen erhöht. Für Downloads sind parallele Bereiche (Range GETs) bzw. CDN-Caching hilfreich. Trap: Eine typische Prüfungsfalle ist die konservative Nutzung alter Best Practices wie manuelles Sharding mittels zufälliger Prefixe; S3 hat inzwischen automatisches Skalierungsverhalten, sodass Prefix-Strategien meist nicht mehr erforderlich sind und falsch angewendet zusätzlichen Komplexität bringen. Warum falsche Antworten fehlschlagen: Antwort 3 (Prefix-Sharding): Früher war Prefix-Randomisierung sinnvoll, um S3-Request-Rate-Limits pro Partition zu umgehen; moderne S3-Architektur skaliert automatisch. Das manuelle Erzeugen vieler Prefixe erhöht Komplexität und hilft selten bei Latenz in entfernten Regionen. Antwort 4 (Transfer Acceleration für GET): Transfer Acceleration optimiert typischerweise Uploads (PUT) über das AWS Backbone mittels Edge-Standorten—für globale Downloads ist CloudFront die richtige Lösung; Transfer Acceleration wird nicht primär für GET-Latenztoleranz verwendet und verursacht zusätzliche Kosten. Praktische Empfehlung: CloudFront vor S3 platzieren, TTL/Cache-Control richtig setzen; Multipart Upload für große Objekt-Uploads und ggf. Origin Shield/Regional Edge Caches einsetzen, um Origin-Load weiter zu reduzieren.

Step 1: Workload-Charakteristik prüfen — Viele EC2-Clients mit gleichzeitigen, parallelen Zugriffen benötigen ein verteiltes POSIX-kompatibles Dateisystem, das sowohl hohe Parallelität als auch hohen Durchsatz unterstützt. Amazon EFS bietet genau das.

Step 2: EFS-Modi und Durchsatz anpassen — EFS bietet zwei Performance-Modi: 'General Purpose' (niedrigere Latenz, gut für <100 Instanzen/Clients) und 'Max I/O' (skaliert besser mit vielen parallelen Verbindungen und bietet höheren aggregierten Durchsatz, toleriert etwas höhere Latenz). Zusätzlich kann Provisioned Throughput unabhängig vom Speicherplatz zugewiesen werden, wenn die Standard-Tos/V-Skalierung nicht ausreicht.

Step 3: Betrieb optimieren — Mount-Optionen wie noatime reduzieren unnötige Schreibvorgänge, können Latenz und IOPS-Last senken. Kombination aus Max I/O + ggf. Provisioned Throughput + EC2-Instanzen mit optimiertem Netzwerk ergibt hohe Skalierbarkeit. Trap: Ein häufiger Fehler ist zu glauben, dass EBS-Einzelvolumes durch Replikation auf Applikationsebene oder S3-Filesysteme (s3fs) die bessere Wahl sind; das führt zu Konsistenz-/Performance-Problemen. Warum falsche Antworten fehlschlagen: Antwort 2 (EBS pro Instanz): EBS ist blockbasiert und an eine EC2-Instanz gebunden; es bietet keinen nativen geteilten POSIX-Zugriff und erfordert komplexe Applikationslogik zur Synchronisation/Replicierung, was Fehleranfälligkeit und Verwaltungsaufwand erhöht. Antwort 3 (S3/s3fs): S3 ist kein POSIX-Dateisystem; s3fs ist eine FUSE-Lösung mit hoher Latenz und schlechter Konsistenz für POSIX-Workloads, daher ungeeignet für hochparallelen, latenzsensitiven POSIX-Zugriff. Praktische Empfehlung: EFS Max I/O für sehr viele Clients, Provisioned Throughput nur wenn nötig, sowie Mount-Optionstuning und Netzwerkanforderungen der EC2-Instanzen beachten.

Step 1: Problemdefinition: Viele identische Leseanfragen gegen DynamoDB führen zu wiederholten Abfragen desselben Items bzw. derselben Queryergebnisse. Ziel ist es, Latenz zu reduzieren und Kosten für wiederholte Lese‑RCUs zu senken.

Step 2: Evaluierung der Optionen: DAX ist ein verwalteter In‑Memory Cache, der speziell für DynamoDB entwickelt wurde. Er bietet Mikrosekunden‑Latenz für wiederholte Lesezugriffe und kann sowohl GetItem als auch Query/Scan (teilweise) beschleunigen, abhängig vom Konsistenzmodus. Ein GSI erweitert Abfragemöglichkeiten, hilft aber nicht bei mehrfach wiederholten gleichen Reads derselben Keys und erhöht stattdessen Schreibkosten. Einfaches Erhöhen der Provisioned RCUs steigert Kosten linear und reduziert nicht die Latenz so effektiv wie ein Cache. Streams nach S3 sind für Replikation/Archivierung gedacht, nicht für Reduzierung der Leselatenz.

Step 3: Betriebliche Aspekte und Trade‑offs: DAX unterstützt eventual consistency standardmäßig und bietet begrenzte Unterstützung für strongly consistent reads; für strikt konsistente Reads müssen Sie die Auswirkungen prüfen. Sicherheit: DAX integriert sich in VPCs, unterstützt IAM/AWS‑RBAC in Kombination mit Endpoint‑Konfiguration. Kosten‑Tradeoff: DAX erhöht Infrastrukturkosten (Cluster‑Instanzen), aber senkt die RCU‑Kosten und verbessert die Nutzererfahrung durch geringere Latenz. Für sehr große, frequentierte Caches müssen Sie Skalierung und Eviction‑Strategien beachten. Trap: Ein häufiger Fehler ist, GSI als Performance‑Optimierung für wiederholte identische Abfragen zu wählen — GSI hilft Abfrageflexibilität, nicht Caching. Ebenso denken Kandidaten, das einfache Erhöhen von RCUs sei ausreichend; das bewirkt höhere Kosten und nicht notwendigerweise niedrigere Latenz für sehr häufige Reads. Warum die falschen Antworten fehlschlagen: - Global Secondary Index: Er erweitert Abfragemuster und kann Latenz reduzieren, wenn er eine effizientere Zugriffsmethode bietet, aber er ersetzt kein In‑Memory‑Caching für wiederholte identische Requests und erhöht Schreibkosten/Komplexität. - Provisioned RCUs erhöhen: Führt zu höheren laufenden Kosten und reduziert nicht die Antwortzeit auf die Mikrosekundenebene; zudem skaliert es nicht ideal bei Bursts und dient nicht als Cache. - DynamoDB Streams → S3: Streams sind sinnvoll für ETL/Archiving und Replikation, aber nicht geeignet, um Online‑Lesezugriffe zu beschleunigen oder RCU‑Kosten direkt zu reduzieren. Fazit: Für wiederholte identische Lesezugriffe ist DAX die am besten geeignete Lösung, vorausgesetzt, Ihre Konsistenzanforderungen können mit den DAX‑Einschränkungen harmonieren.

Step 1: Globale Auslieferung statischer Inhalte: Amazon S3 kombiniert mit Amazon CloudFront ist die bewährte Architektur für globale Distribution großer statischer Assets. CloudFront bringt die Inhalte näher zum Nutzer (Edge Caches), reduziert Latenz und Kosten (weniger Origin-Traffic) und ermöglicht Cache-Hitrate-Steuerung über Cache-Control-Header, TTLs und Invalidation. Origin Shield kann als zusätzlicher Layer helfen, die Origin-Last weiter zu reduzieren.

Step 2: Gemeinsame, häufig aktualisierte POSIX-Daten: Wenn mehrere EC2-Instanzen Dateien lesen und schreiben müssen und die Anwendung POSIX-Funktionalität (z. B. Locks, Atomic rename) benötigt, ist Amazon EFS (Elastic File System) die richtige Wahl. EFS bietet Multi-AZ-Resilienz (je nach Mount-Targets/Region), POSIX-Semantik und kann für hohe Durchsatz- oder niedrige Latenz-Workloads im richtigen Leistungsmodus und mit Provisioned Throughput konfiguriert werden.

Step 3: Trade-offs und Betrieb: S3 + CloudFront ist kosteneffizient für öffentliche oder für differenziert autorisierte statische Inhalte; die Validierung und Cache-Control sorgt für konsistente Updates bei Content-Änderungen (z. B. Versionierung oder Cache-Busting). EFS bringt Kosten für Speichern und Throughput, ist aber notwendig, wenn Anwendungen POSIX erwarten. Für beste Konsistenz sollte man Objekt-Versionierung, Cache-Invalidation oder kurze TTLs für Assets in Kombination mit Deploy-Strategien verwenden. Trap: Ein häufiger Prüfungs-Trap ist, EBS als "einfachen Weg" für jede Datei-Storage-Anforderung zu wählen. EBS-Volumes sind per Design an eine Instanz gebunden und bieten kein natives Multi-Writer-POSIX-Filesystem über mehrere Instanzen – dafür ist EFS gedacht. Ein weiterer Trugschluss ist zu glauben, CloudFront allein löst Dateisystem-Konsistenzprobleme; CloudFront ist ein Cache und benötigt einen Origin mit persistenter Speicherung. Warum jede falsche Antwort versagt: - EBS gp3 an jede EC2 + CloudFront: EBS ist nicht für Multi-Writer-Szenarien geeignet; mehrere Instanzen können dasselbe EBS-Volume nicht gleichzeitig benutzen (außer spezielle Multi-Attach-Fälle, die eingeschränkt und nicht POSIX-kompatibel sind). Außerdem ist CloudFront typischerweise mit einem Objekt- oder HTTP-Origin verbunden (S3, ALB, EC2-HTTP-Server), nicht mit einem Block-Device. - Nur CloudFront ohne Origin: CloudFront ist ein CDN/Cache-Layer, kein persistenter Origin. Ohne S3/EFS/HTTP-Server gibt es keinen Speicherort für die Inhalte oder keinen Mechanismus, um konsistente Updates zu verwalten. Origin Shield reduziert Origin-Traffic, ersetzt aber nicht das Origin. AWS-Gründe und Detail: S3 skaliert praktisch unbegrenzt für hohe Request-Raten; CloudFront verteilt Last global. EFS skaliert mit parallelem Durchsatz, bietet POSIX und kann bei Bedarf Provisioned Throughput nutzen. Zusammen liefern sie Performance, Resilienz und passende Kosten-Profiles, während EBS hier kein passendes Multi-writer-Primitive bietet.

Step 1: Anforderungen analysieren — Die Pipeline ist schemalos, sehr schreibintensiv, hat variable (Burst-)Last und benötigt Millisekunden-Latenzen. Wichtig sind elastische Skalierung, geringe Verwaltungsaufwände und Kostenkontrolle bei unvorhersehbaren Lastmustern.

Step 2: Service-Auswahl und Architektur­schritte — Amazon DynamoDB mit On‑Demand Capacity ist explizit dafür ausgelegt, bei unvorhersehbaren Zugriffsmustern automatisch und sofort zu skalieren, ohne dass Kapazitätsplanung (Provisioned Throughput) nötig ist. Für Telemetriedaten ist ein gut designtes Partitionsschema (sinnvoller Partition Key) entscheidend, um Hot-Partitonen zu vermeiden und niedrige Latenz zu erhalten. AWS Lambda als Ingest-Layer passt gut zu DynamoDB, weil Lambda automatisch skaliert und nur bei Nutzung Kosten verursacht; Lambda kann Events (z. B. API Gateway, Kinesis, or SQS) konsumieren, valide/transformieren und in DynamoDB schreiben.

Step 3: Betriebs-/Kostentrade-offs und Resilienz — DynamoDB On‑Demand kostet pro Anfrage, kann bei konstant sehr hohem Volumen teurer als Provisioned sein, ist jedoch ideal bei unvorhersehbaren Spitzen. Lambda hat Kaltstart-Überlegungen (insbesondere bei größeren Runtimes) und Limits (Parallelität), die mittels Provisioned Concurrency oder Reservierungen adressiert werden können. Zur Resilienz sollten Sie Backpressure (z. B. SQS/Kinesis), Dead‑Letter-Queues, Monitoring und Adaptive Error‑Handling implementieren. Außerdem sollten Sie Partitionskey-Design, TTL für alte Telemetriedaten und eventuell Lifecycle-Policies zur Archivierung in S3 beachten. Trap: Ein häufiger Fehler ist zu glauben, dass RDS oder große EC2-Instanzen einfacher sind, weil sie „stärker“ sind. Provisionierte relationale DBs skalieren vertikal oder mit komplexen Read/Write-Sharding-Designs, die nicht gut zu schemalosen, extrem variablen Telemetrie-Workloads passen. Ebenso verhindert eine einzelne große EC2-Instanz nicht das Skalierbarkeitsproblem oder Kostenineffizienz bei Bursts. Why each wrong answer fails: - Option 2 (Amazon RDS Provisioned MySQL mit Multi-AZ und Auto-Scaling von EC2): RDS ist relational und erwartet definierte Schemata; Auto-Scaling bezieht sich meist auf EC2-Ebene, nicht auf RDS selbst (RDS skaliert vertikal oder durch Read Replicas). Für extrem schreibintensive, schemalose Telemetrie ist RDS unflexibel, benötigt komplexe Sharding/Partitionierung und verursacht hohen Verwaltungsaufwand und potenziell hohe Kosten bei Bursts. - Option 4 (Amazon EC2 mit großer Instanzklasse für dauerhafte CPU-intensive Verarbeitung): Eine einzelne große EC2-Instanz kann kurzfristig hohe Last bewältigen, skaliert aber nicht automatisch bei vielen parallelen Bursts. Kosten werden auch bei Leerlauf anfallen (Overprovisioning), es besteht Single Point of Failure ohne Multi-AZ/AutoScaling-Architektur, und betrieblich sind Patching/Scaling aufwändig. Außerdem ist dies weniger kosteneffizient als serverlose Event-driven Ansätze bei variabler Last. Warum die richtigen Antworten passen: - Option 1 (DynamoDB On‑Demand): Bietet automatische Skalierung, niedrige Latenz für Key-Value-Zugriffe, und passt gut zu schemalosen Telemetriedaten; vermeidet Kapazitätsplanung. - Option 3 (AWS Lambda): Ermöglicht serverlose, ereignisgesteuerte Verarbeitung mit automatischer Skalierung und Abrechnung nach Nutzung; verringert Betriebsaufwand und erfüllt das Ziel kosteneffizient bei variablen Lasten. Zusammenfassung: Für eine schemalose, schreibintensive Telemetrie‑Pipeline mit unvorhersehbaren Lasten sind DynamoDB On‑Demand plus AWS Lambda die richtige Kombination für Latenz, Skalierbarkeit und Kostenkontrolle.