0Pricing
AWS Solutions Architect · Lektion

Säulen der Zuverlässigkeit und Performance-Effizienz

Entwerfen Sie Systeme für automatische Wiederherstellung, horizontale Skalierung und Kapazitätsmanagement; wählen Sie die passenden Ressourcentypen und überwachen Sie die Systeme, um die Performance langfristig aufrechtzuerhalten.

Säulen der Zuverlässigkeit und Performance-Effizienz ist eine kostenlose AWS Solutions Architect-Lektion auf CoddyKit. Dies ist Lektion 2 von 4. Du kannst die komplette Lektion unten kostenlos lesen – dann übst du sie direkt im Browser mit einem integrierten Code-Editor und einem KI-Tutor rund um die Uhr. Sie ist Teil des AWS Solutions Architect-Lernpfads, und dein Fortschritt wird über Web und CoddyKit-App synchronisiert. Der AWS Solutions Architect-Kurs umfasst insgesamt 4 Lektionen.

Überblick über die Säule Reliability

Die Säule Reliability des Well-Architected Framework stellt sicher, dass ein Workload seine vorgesehene Funktion erwartungsgemäß korrekt und konsistent erfüllt. Reliability umfasst drei Bereiche: Grundlagen (Service-Limits, Netzwerktopologie), Workload-Architektur (verteilte Systeme, Vermeidung einzelner Fehlerpunkte) sowie Änderungs- und Fehlermanagement (Überwachung, Skalierung und Wiederherstellung nach Fehlern). Ziel ist es, Systeme zu entwickeln, die sich automatisch von Infrastruktur- oder Serviceunterbrechungen erholen.

# Reliability design principles:
# 1. Automatically recover from failure
# 2. Test recovery procedures
# 3. Scale horizontally to increase availability
# 4. Stop guessing capacity (use auto scaling)
# 5. Manage change in automation (IaC + CI/CD)

# Key AWS services for reliability:
# - Auto Scaling Groups
# - Elastic Load Balancing
# - Route 53 health checks
# - AWS Backup

Service-Limits und Kontingente

AWS setzt für Ressourcen Servicekontingente (früher Limits genannt) durch, um alle Kunden zu schützen. Beispiele sind standardmäßige Limits für EC2-Instances pro Region, VPC-Limits und die Anzahl gleichzeitiger Lambda-Ausführungen. Wenn Ihr Workload unerwartet ein Kontingent erreicht, werden Anfragen gedrosselt oder abgelehnt, was zu Zuverlässigkeitsproblemen führt. Verwenden Sie die Service-Quotas-Konsole oder die CLI, um aktuelle Limits anzuzeigen und Erhöhungen zu beantragen, bevor Sie sie benötigen. Überwachen Sie Nutzungsmetriken, um zu erkennen, wann Sie sich Limits nähern, bevor diese die Verfügbarkeit beeinträchtigen.

# List service quotas for EC2
aws service-quotas list-service-quotas \
  --service-code ec2 \
  --query 'Quotas[?QuotaName==`Running On-Demand Standard (A, C, D, H, I, M, R, T, Z) instances`]'

# Request quota increase
aws service-quotas request-service-quota-increase \
  --service-code ec2 \
  --quota-code L-1216C47A \
  --desired-value 500

Automatische Wiederherstellung nach Fehlern

Die Säule Reliability legt den Schwerpunkt auf automatische Wiederherstellung ohne menschliches Eingreifen. AWS bietet mehrere Mechanismen zur automatischen Selbstheilung: EC2 Auto Recovery stellt eine Instance automatisch auf derselben Hardware wieder her oder verschiebt sie auf funktionsfähige Hardware, wenn sie zugrunde liegende Prüfungen nicht besteht. ASG-Health-Checks beenden fehlerhafte Instances und starten Ersatz-Instances. RDS Multi-AZ führt automatisch einen Failover auf die Standby-Instance durch. Entwerfen Sie Ihre Architektur so, dass die meisten Fehlerszenarien automatische Wiederherstellungsaktionen auslösen, die in CloudWatch-Alarmen hinterlegt sind.

# CloudWatch alarm to auto-recover a specific EC2 instance
aws cloudwatch put-metric-alarm \
  --alarm-name EC2-auto-recover \
  --metrics '[{"Id":"m1","MetricStat":{"Metric":{"Namespace":"AWS/EC2","MetricName":"StatusCheckFailed_System","Dimensions":[{"Name":"InstanceId","Value":"i-12345"}]},"Period":60,"Stat":"Maximum"}}]' \
  --comparison-operator GreaterThanThreshold \
  --threshold 0 \
  --evaluation-periods 2 \
  --alarm-actions 'arn:aws:automate:us-east-1:ec2:recover'

Horizontale Skalierung für Reliability

Die Säule Reliability empfiehlt zur Verbesserung der Zuverlässigkeit die horizontale Skalierung (Hinzufügen weiterer kleinerer Instances) anstelle der vertikalen Skalierung (Hochskalieren auf größere Instances). Eine einzelne große Instance ist ein einzelner Fehlerpunkt. Viele kleinere Instances hinter einem Load Balancer sorgen dafür, dass der Ausfall einer einzelnen Instance nur minimale Auswirkungen hat. AWS Auto Scaling passt die Größe der Flotte automatisch an den Bedarf an. So verfügen Sie stets über ausreichende Kapazität und zahlen in ruhigen Zeiten nicht für ungenutzte Ressourcen.

# Horizontal scaling: 10 t3.medium vs 1 r5.4xlarge
# 10 t3.medium:
#   - Failure of 1 = loss of 10% capacity
#   - ASG launches replacement automatically
#   - 9 instances absorb load during replacement

# 1 r5.4xlarge:
#   - Failure = 100% downtime until instance recovered
#   - Much higher RTO (new instance launch: 1-3 min)

# Prefer horizontal scaling for stateless tiers

Tests für Reliability

Die Säule Reliability erfordert das Testen von Wiederherstellungsverfahren — gehen Sie nicht einfach davon aus, dass sie funktionieren. Verwenden Sie den AWS Fault Injection Simulator (FIS), um kontrolliert Fehler in Ihr System einzuschleusen: Beenden Sie zufällige EC2-Instances, drosseln Sie API-Aufrufe oder fügen Sie Netzwerklatenz ein. Führen Sie diese Experimente mit geeigneten Schutzmaßnahmen in der Produktion durch, um zu überprüfen, dass Ihre Überwachung Fehler erkennt, die automatische Skalierung reagiert und die Wiederherstellung innerhalb Ihres RTO abgeschlossen wird. Nicht getestete Wiederherstellungsverfahren versagen unter dem Stress eines echten Incidents häufig.

# AWS FIS experiment: terminate random instance
aws fis create-experiment-template \
  --description 'Chaos: terminate 1 of 5 instances' \
  --targets '{"instanceTargets":{"resourceType":"aws:ec2:instance","selectionMode":"COUNT(1)","resourceTags":{"Env":"production"}}}' \
  --actions '{"terminateInstance":{"actionId":"aws:ec2:terminate-instances","targets":{"Instances":"instanceTargets"}}}' \
  --stop-conditions '[{"source":"aws:cloudwatch:alarm","value":"arn:aws:cloudwatch::123:alarm:high-error-rate"}]'

Überblick über die Säule Performance Efficiency

Die Säule Performance Efficiency konzentriert sich darauf, Compute-Ressourcen effizient zur Erfüllung der Systemanforderungen einzusetzen und diese Effizienz bei wechselnder Nachfrage und der Weiterentwicklung von Technologien aufrechtzuerhalten. Zentrale Designprinzipien: Machen Sie fortschrittliche Technologien zugänglich — verwenden Sie verwaltete Services (RDS, SageMaker), anstatt sie von Grund auf selbst zu entwickeln. Werden Sie in Minuten global — stellen Sie mit CloudFormation in mehreren Regionen bereit. Verwenden Sie serverlose Architekturen — vermeiden Sie die Verwaltung von Infrastruktur. Experimentieren Sie häufiger — testen Sie verschiedene Instance-Typen und Konfigurationen.

# Performance Efficiency areas:
# Selection:   Right compute, storage, database, network
# Review:      Continuously evaluate new services
# Monitoring:  CloudWatch metrics guide decisions
# Trade-offs:  Consistency vs performance, latency vs cost

# Example: choosing between services
# RDS vs DynamoDB vs Aurora vs ElastiCache
# → depends on access patterns, consistency needs, scale

Die passende Compute-Option auswählen

Performance Efficiency beginnt mit der Auswahl des richtigen Compute-Typs für Ihren Workload. EC2 bietet Dutzende von Instance-Familien, die für unterschiedliche Anwendungsfälle optimiert sind: c-series für rechenintensive Aufgaben (Videokodierung, Batchverarbeitung), r-series für speicherintensive Aufgaben (In-Memory-Datenbanken, Caching), i-series für speicherintensive Aufgaben (NoSQL, Data Warehousing) und p/g-series für GPU-Workloads (ML-Training). Wenn Sie den falschen Instance-Typ verwenden, zahlen Sie für Kapazität, die Sie nicht nutzen können, oder beeinträchtigen die Performance.

# AWS Compute Optimizer: get right-size recommendations
aws compute-optimizer get-ec2-instance-recommendations \
  --instance-arns arn:aws:ec2:us-east-1:123:instance/i-12345

# Output shows:
# - Current instance utilisation (CPU, memory, network)
# - Recommended instance type
# - Estimated monthly savings
# - Performance risk of changing

# Lambda: match memory to actual usage
# Use Lambda Power Tuning tool for memory optimisation

Caching für Performance Efficiency

Caching ist eine grundlegende Technik für Performance Efficiency, die Latenz und Datenbanklast reduziert. ElastiCache (Redis/Memcached) speichert Ergebnisse von Datenbankabfragen im Speicher zwischen und ermöglicht den Zugriff innerhalb von Millisekunden. CloudFront speichert HTTP-Antworten an Edge-Standorten in der Nähe der Benutzer zwischen. API-Gateway-Caching reduziert Lambda-Aufrufe, indem API-Antworten zwischengespeichert werden. DAX (DynamoDB Accelerator) stellt einen In-Memory-Cache im Mikrosekundenbereich vor DynamoDB bereit. Wählen Sie die passende Caching-Ebene abhängig davon, wo der Engpass liegt — in der Datenbank, der API oder bei der Edge-Auslieferung.

# DAX cluster for DynamoDB microsecond latency
aws dax create-cluster \
  --cluster-name my-dax \
  --node-type dax.r6g.large \
  --replication-factor 3 \
  --iam-role-arn arn:aws:iam::123:role/DAXRole \
  --subnet-group my-dax-subnet-group

# Application connects to DAX endpoint
# Cache hits: microseconds
# Cache misses: fetches from DynamoDB and caches result

Der passende Speicher für Performance

Die Wahl des Speichers hat erhebliche Auswirkungen auf die Performance. io2 Block Express EBS bietet bis zu 256.000 IOPS für Hochleistungsdatenbanken. gp3 ist für die meisten Workloads die Standardwahl und kostengünstiger. Der Instance Store bietet die höchsten IOPS (NVMe) für temporäre Daten. S3 skaliert bei der Objektspeicherung auf Tausende von Anfragen pro Sekunde. EFS stellt gemeinsamen POSIX-Dateizugriff bereit. Stimmen Sie Ihren Speicher auf das I/O-Muster ab: Sequenzielle Lesevorgänge profitieren von st1 (Throughput Optimised HDD), während zufällige I/O-Vorgänge SSD-Volumes erfordern.

# EBS volume performance characteristics:
# gp3: 3,000-16,000 IOPS, 125-1,000 MB/s
# io2: 100-64,000 IOPS (up to 256k with Block Express)
# st1: 40-500 MB/s sequential throughput (HDD)
# sc1: 12-250 MB/s (cheapest, cold workloads)

# Create high-performance io2 volume
aws ec2 create-volume \
  --availability-zone us-east-1a \
  --volume-type io2 \
  --size 500 \
  --iops 50000

Performance-Überwachung und kontinuierliche Verbesserung

Performance Efficiency ist keine einmalige Entscheidung — Sie müssen Performance-Metriken kontinuierlich überwachen und Ihre Auswahl neu bewerten, wenn AWS neue Services veröffentlicht. Verwenden Sie CloudWatch-Dashboards, um die Latenz-Perzentile p50, p90 und p99 zu verfolgen (nicht nur Durchschnittswerte, die die Latenz im Randbereich verschleiern). Verwenden Sie X-Ray-Traces, um die langsamsten Teile einer Anforderungskette zu identifizieren. Richten Sie die CloudWatch-Anomalieerkennung ein, um automatisch eine Baseline zu erstellen und bei ungewöhnlichen Performance-Abweichungen zu alarmieren. Prüfen Sie AWS-Ankündigungen regelmäßig — neuere Instance-Typen bieten häufig bessere Performance zu geringeren Kosten.

# CloudWatch: track API response latency percentiles
aws cloudwatch put-metric-alarm \
  --alarm-name 'API-P99-Latency' \
  --metric-name TargetResponseTime \
  --namespace AWS/ApplicationELB \
  --extended-statistic p99 \
  --dimensions Name=LoadBalancer,Value=app/my-alb/xxx \
  --period 60 \
  --evaluation-periods 5 \
  --threshold 2.0 \
  --comparison-operator GreaterThanThreshold

Zielkonflikte bei Performance Efficiency

Performance Efficiency erfordert mitunter Zielkonflikte mit anderen Säulen. Das Hinzufügen eines Caches (ElastiCache) verbessert die Performance, erhöht jedoch die betriebliche Komplexität (Zielkonflikt mit Operational Excellence) und die Kosten (Zielkonflikt mit Cost Optimisation). Die Verwendung von DynamoDB anstelle von RDS verbessert die Performance bei hoher Skalierung, erfordert jedoch eine Neugestaltung Ihres Datenmodells (Aufwand für Operational Excellence). Das Well-Architected Framework erkennt diese Zielkonflikte an und fordert Sie auf, bewusste Entscheidungen zu treffen und die Gründe dafür zu dokumentieren. Suchen Sie in Prüfungsfragen nach der Option, die die Performance-Ziele mit dem geringsten betrieblichen Aufwand erreicht.

# Common performance vs cost trade-offs:
# Cache:         +Performance, +Cost, +Complexity
# Read Replicas: +Read performance, +Cost
# SSD vs HDD:    +IOPS, +Cost
# Multi-region:  -Latency for users, +Cost, +Complexity

# Common performance vs consistency trade-offs:
# DynamoDB eventually consistent reads: +Throughput, -Consistency
# Aurora Reader endpoint: +Read scale, potential replication lag

Schnelltest

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

Zusammenfassung der Lektion

In dieser Lektion haben Sie gelernt: Reliability erfordert automatische Wiederherstellung, horizontale Skalierung und regelmäßige Fehlertests, Performance Efficiency erfordert die Auswahl des passenden Compute-, Speicher- und Datenbanktyps für jeden Workload und Caching auf mehreren Ebenen reduziert Latenz und Datenbanklast. Beide Säulen erfordern kontinuierliche Überwachung und die Bereitschaft, Architekturentscheidungen erneut zu prüfen. Als Nächstes sehen wir uns die Säulen Cost Optimisation und Sustainability an.

Häufig gestellte Fragen

Ist die Lektion „Säulen der Zuverlässigkeit und Performance-Effizienz“ kostenlos?

Ja — der vollständige Text von „Säulen der Zuverlässigkeit und Performance-Effizienz“ ist hier im Web kostenlos zu lesen. Um sie interaktiv zu üben (integrierter Code-Editor und 24/7 KI-Tutor) und den Rest des AWS Solutions Architect-Kurses freizuschalten, upgrade auf CoddyKit PRO. Der AWS Solutions Architect-Kurs umfasst insgesamt 4 Lektionen.

Was lerne ich in „Säulen der Zuverlässigkeit und Performance-Effizienz“?

Entwerfen Sie Systeme für automatische Wiederherstellung, horizontale Skalierung und Kapazitätsmanagement; wählen Sie die passenden Ressourcentypen und überwachen Sie die Systeme, um die Performance… Du übst AWS Solutions Architect mit praktischem Code, den du direkt im Browser ausführst, und ein 24/7 KI-Tutor beantwortet deine Fragen während du die Lektion bearbeitest.

Brauche ich Erfahrung, um AWS Solutions Architect zu starten?

Keine Vorkenntnisse erforderlich. AWS Solutions Architect auf CoddyKit ist für Anfänger bis fortgeschrittene Lernende strukturiert, sodass du hier starten oder von Anfang an beginnen und in deinem eigenen Tempo voranschreiten kannst. Dies ist Lektion 2 von 4.

Wie lange dauert die Lektion „Säulen der Zuverlässigkeit und Performance-Effizienz“?

Die meisten CoddyKit-Lektionen dauern etwa 5–10 Minuten. Jede ist kompakt und interaktiv, sodass du stetig Fortschritte machst und genau dort weitermachst, wo du aufgehört hast – im Web und in der App.

Kann ich in dieser AWS Solutions Architect-Lektion Code schreiben und ausführen?

Ja. Jede AWS Solutions Architect-Lektion enthält einen integrierten Code-Editor, sodass du echten Code direkt in deinem Browser schreibst und ausführst und sofort KI-Feedback erhältst — ohne lokale Einrichtung erforderlich.

Alle Lektionen in diesem Kurs

  1. Säulen der betrieblichen Exzellenz und Sicherheit
  2. Säulen der Zuverlässigkeit und Performance-Effizienz
  3. Säulen der Kostenoptimierung und Nachhaltigkeit
  4. Well-Architected Tool und Prüfprozess
← Zurück zu AWS Solutions Architect