Magento AWS Hosting: Reference Architecture, Performance, Scaling, and Best Practices

Entscheidungskriterien: Wann AWS für Magento sinnvoll ist (und wann nicht)

Die erste harte Entscheidung ist das Betriebsmodell: stateless EC2 in einer Auto Scaling Group (ASG) oder „Server als Haustier“. Wenn PHP-FPM Nodes nicht entkoppelt sind, skaliert nichts. Dann bleibt AWS nur teurer Self-Managed Betrieb.

Ist AWS für Magento schneller als klassisches Managed Hosting? Nicht per se. AWS gewinnt nur, wenn Latenzpfade und Caches gezielt designt werden. Entscheidend sind ALB (Application Load Balancer), Varnish, ElastiCache Redis und eine saubere Datenhaltung in RDS MySQL oder Aurora MySQL. Ohne Cache-Hit-Rate und TTFB-Ziele ist „schneller“ eine Behauptung. Technisch gesehen: Managed Hosting kann bei gleicher Cache-Strategie identische TTFB liefern.

Zielmetriken müssen vor der Architektur feststehen. Sonst optimierst du Kosten gegen Zufall.

• TTFB: < 200 ms für Cache-Hits, < 800 ms für Cache-Misses (regionale Nutzerbasis).
• Cache-Hit-Rate: > 90% auf Varnish/CloudFront, > 95% Redis-Cache-Hits für Backend-Cache.
• Fehlerbudget: 5xx < 0,1% pro 30 Tage, getrennt nach ALB und App.
• Deploy-Frequenz: mindestens wöchentlich, mit Rollback-Zeit < 10 Minuten.

Das führt zum nächsten Problem: Wann rechtfertigt AWS die zusätzliche Komplexität? Die Matrix ist relativ objektiv.

Kriterium	AWS sinnvoll	Managed Hosting sinnvoll	Self-Managed sinnvoll
Traffic-Volatilität	Spikes, planbar oder unplanbar; ASG + Cache nötig	Stabil; vertikal skalieren reicht	Stabil, aber Spezialhardware/Netz nötig
Release-Frequenz	Hohe Frequenz; Blue/Green Deployment, IaC (Infrastructure as Code)	Niedrig; manuelle Wartungsfenster akzeptabel	Sehr niedrig; maximal kontrollierte Changes
Integrationslandschaft	Viele Events/Queues; Event-Driven, Retry-Strategie, Idempotenz	Wenig Integrationen; synchrone Calls tolerierbar	Legacy-Integrationen mit fixen IPs/VPNs
Compliance-Anforderungen	KMS, IAM, WAF, Audit-Trails, Segmentierung in VPC	Standard-Compliance, wenig Audit-Tiefe	Strikte Sondervorgaben, eigenes Rechenzentrum
Team-Reife (DevOps/On-Call)	24/7 On-Call, SLOs, Observability, Incident-Prozesse	Kleines Team ohne On-Call	Ops-Team stark, aber Tooling individuell

In der Praxis zeigt sich: Bestimmte Anti-Patterns zerstören die AWS-These sofort.

• „Lift-and-shift“ ohne stateless Design. Shared State auf EC2 verhindert ASG-Replacement.
• EFS als Default für Media und var/. Das erhöht Latenz und macht Throughput teuer.
• Single-AZ-DB. Ein AZ-Ausfall wird zum Full-Outage, RPO/RTO brechen.
• Fehlende Cache-Strategie. Ohne Varnish/Redis wird RDS zum Bottleneck.

Messbarkeit entscheidet. Für konkrete Metriken und Bottleneck-Methodik: Onlineshop-Performance messbar verbessern (TTFB, Caching, Bottlenecks).

# Zielwerte als „Contract“ für Monitoring/Alerting
TTFB_CACHE_HIT_P95_MS=200
TTFB_CACHE_MISS_P95_MS=800
ERROR_5XX_BUDGET_30D=0.001
CACHE_HIT_RATE_VARNISH_TARGET=0.90

# Anti-Pattern Check: State auf App-Node vermeiden
# var/session und pub/media dürfen nicht lokal „wichtig“ sein.
grep -R "session.save_path" -n app/etc/env.php

# Retry-Strategie: Idempotenz-Key für externe APIs erzwingen
Idempotency-Key: order-{increment_id}-{attempt}
Retry: exponential backoff, max 5 tries, jitter

# Blue/Green Traffic-Switch als Prinzip (schematisch)
ALB Listener Rule: / -> target-group-blue
Rollback: switch to target-group-green in < 10 minutes

Referenz-Architekturen auf AWS: 2‑Tier vs. 3‑Tier inkl. Netzwerk, Datenfluss und Sizing

Die Architekturentscheidung beginnt im Netzwerk. Der Rest folgt daraus. Ohne saubere Entkopplung werden Skalierbarkeit und Kostenkontrolle zufällig.

Netzwerk-Blueprint: Eine VPC pro Umgebung. Zwei Availability Zones (AZ) als Minimum. Drei AZs nur bei strengen RTO-Zielen.

Pro AZ je ein Public Subnet und ein Private Subnet. ALB (Application Load Balancer) und NAT Gateway liegen im Public Subnet. EC2, RDS MySQL und ElastiCache Redis liegen im Private Subnet.

Routing ist klar getrennt. Public Subnets routen zum Internet Gateway. Private Subnets routen ausgehend über NAT Gateway. Eingehend gibt es keine Route ins Internet. Security Groups sind das primäre Control-Plane. NACLs nur bei Compliance oder bei klaren East-West-Blockregeln. Sonst erhöhen sie die Fehlerrate.

Das führt zum nächsten Problem: Welche AWS-Services braucht man für eine Magento-2-Architektur? Minimal sind es VPC, ALB, EC2 in einer Auto Scaling Group (ASG), RDS MySQL oder Aurora MySQL, ElastiCache Redis, S3 und CloudFront. Ergänzend kommen WAF, Shield, IAM und KMS für Security und Schlüsselmanagement.

Referenz A: 2‑Tier. Zielgruppe: klein bis mittel, begrenzte Integrationen, moderates Traffic-Profil. Der App-Layer ist stateless. Sessions und Cache liegen in Redis. Media liegt in S3. Deployment liefert Media-Assets nach S3 aus.

Datenfluss: Client → CloudFront → ALB → NGINX auf EC2 → PHP-FPM → ElastiCache Redis / RDS MySQL / S3. CloudFront cached statische Assets.

Full Page Cache über CloudFront ist möglich. Cookies und Varianten begrenzen die Cache-Hit-Rate.

Start-Sizing für A: 2× EC2 c7g.large oder m7g.large in einer ASG. PHP-FPM Worker sind der Throughput-Hebel. Zu viele Worker erhöhen DB-Latenz. RDS MySQL als db.m7g.large, Storage als gp3 mit festem IOPS-Budget. ElastiCache Redis als cache.r7g.large, Multi-AZ bei Session-Kritikalität. Engpässe sind meist DB-CPU, DB-IOPS und Redis-Memory.

Technisch gesehen: Cron und Indexer gehören nicht auf die Web-Nodes. Sie erzeugen Lastspitzen. Sie brauchen Idempotenz und eine Retry-Strategie. Dafür laufen sie auf separaten Worker-Instanzen.

Referenz B: 3‑Tier. Zielgruppe: enterprise, viele Integrationen, hoher Peak-Traffic, harte TTFB-Ziele. Hier wird der Cache-Layer explizit. Zusätzlich wird der Worker-Layer getrennt. Optional kommt Search hinzu.

Datenfluss: Client → CloudFront → ALB → Varnish (Cache-Layer) → NGINX → PHP-FPM → ElastiCache Redis / Aurora MySQL oder RDS MySQL / S3. Varnish reduziert TTFB bei Hits drastisch.

Er entkoppelt Web-Traffic von PHP-Throughput. Die Cache-Hit-Rate wird zum zentralen Kosten-KPI.

Worker-Layer: Separate EC2-ASG für Cron/Indexer und Queue-Consumer. Die Jobs müssen idempotent sein. Retries dürfen keine Doppelbuchungen erzeugen. Event-Driven Integrationen profitieren von klaren Outbox-Patterns. Sonst kippt die Konsistenz.

Start-Sizing für B: Cache-Layer 2× c7g.large für Varnish. App-Layer 2–6× c7g.xlarge je nach PHP-CPU-Profil. Worker-Layer 1–3× c7g.large mit getrennten Scaling-Policies. Datenbank: Aurora MySQL bei hohen Failover-Anforderungen oder Write-Spikes. Sonst RDS MySQL mit Multi-AZ. Redis: cache.r7g.xlarge bei großen Caches und vielen Sessions. Redis-Memory ist der harte Grenzwert.

Komponente	2‑Tier (A)	3‑Tier (B)	Typischer Engpass
Edge	CloudFront für Assets	CloudFront + optional FPC-Regeln	Cookie-Varianten, niedrige Cache-Hit-Rate
Load Balancing	ALB	ALB	Header-/Timeout-Tuning, Keep-Alive
Cache-Layer	NGINX only	Varnish dediziert	Hit-Rate, Purge-Strategie
App	EC2 ASG, stateless	EC2 ASG, stärker skaliert	PHP-FPM Worker, CPU, OpCache
State	Redis + RDS	Redis + RDS/Aurora	DB CPU/IOPS, Redis Memory
Jobs	separate Worker empfohlen	separate Worker Pflicht	Locking, Retry-Strategie, Idempotenz

# Beispiel: Security-Group-Flows (Prinzip, keine vollständige Policy)
# ALB-SG: Inbound 443 from 0.0.0.0/0, Outbound to App-SG:80/443
# App-SG: Inbound 80/443 from ALB-SG, Outbound to Redis-SG:6379, RDS-SG:3306, S3 via NAT/VPCE
# Redis-SG: Inbound 6379 from App-SG and Worker-SG
# RDS-SG: Inbound 3306 from App-SG and Worker-SG

# Beispiel: Magento env.php (Auszug) - Sessions und Cache in Redis
'session' => [
  'save' => 'redis',
  'redis' => ['host' => 'redis-primary', 'port' => '6379', 'database' => '2']
],
'cache' => [
  'frontend' => [
    'default' => ['backend' => 'Cm_Cache_Backend_Redis', 'backend_options' => ['server' => 'redis-primary', 'port' => '6379', 'database' => '0']]
  ]
]

# Beispiel: Varnish-Health über ALB Target Group
# ALB Health Check Path: /health_check.php
# Erwarteter Status: 200
# Timeout/Interval so wählen, dass Deployments keine False-Negatives erzeugen.

# Beispiel: Worker-Entkopplung per systemd (Cron/Indexer getrennt von Web)
# w


  
In den meisten Projekten ist die Datenbankabfrage der Hauptflaschenhals
  

    
Beispiel: n8n Workflow Automation (500+ Workflows)
    
Execution Time um 60% reduziert
  

eb.service: php-fpm + nginx
# worker.service: bin/magento cron:run && bin/magento indexer:reindex --quiet
# Wichtig: Idempotenz prüfen und Retry-Strategie definieren.

Hands-on: IaC, Magento-Konfiguration und Deployment-Runbook (prod-tauglich)

Reproduzierbarkeit entsteht durch IaC, Remote State und harte Umgebungsgrenzen. Alles andere erzeugt Drift. Drift zerstört Debuggability. Das gilt besonders bei Netzwerk, Cache und Datenhaltung.

Technisch gesehen: Terraform mit klaren Modulen trennt Ownership und Blast Radius. Dev, Stage und Prod laufen in getrennten AWS Accounts oder mindestens getrennten VPCs.

Gemeinsame Ressourcen bleiben selten. KMS-Keys und IAM-Rollen bleiben pro Umgebung isoliert.

• vpc: VPC, Public Subnet, Private Subnet, Routing, NAT Gateway, VPC Endpoints.
• alb: ALB (Application Load Balancer), Listener, Target Groups, TLS, Health Checks.
• asg-app: Auto Scaling Group (ASG) für EC2 App-Nodes, Launch Template, User Data.
• asg-worker: ASG für Worker, getrennte Scaling-Policy und Instance-Typen.
• rds: RDS MySQL oder Aurora MySQL, Subnet Group, Parameter Groups, Multi-AZ.
• redis: ElastiCache Redis, Subnet Group, Parameter Group, Auth Token.
• s3: Media-Bucket, Artefakt-Bucket, Lifecycle, SSE-KMS, Bucket Policy.
• cloudfront: Distribution, Origins (ALB, S3), Cache Policies, Origin Request Policies.
• waf: AWS WAF WebACL, Managed Rules, Rate-Based Rules, Logging.

Remote State gehört in S3 mit Locking über DynamoDB. Ohne Locking entstehen Race Conditions. State-Promotions zwischen Umgebungen passieren nie. Jede Umgebung hat eigenes Backend.

# backend.hcl (pro Umgebung)
bucket         = "tfstate-prod-eu-central-1"
key            = "magento/networking/terraform.tfstate"
region         = "eu-central-1"
dynamodb_table = "tfstate-lock-prod"
encrypt        = true

Das führt zum nächsten Problem: Magento braucht klare Cache-Zuständigkeiten. Redis ist kein HTTP-Cache. Varnish ist kein Session-Store (kein Scherz). CloudFront ist kein dynamischer HTML-Cache ohne harte Cookie-Disziplin.

Wie setze ich Redis/Varnish/CloudFront für Magento korrekt ein? Redis übernimmt Cache-Backend und Sessions. Varnish übernimmt Full Page Cache vor Magento. CloudFront cached statische Assets und optional Varnish-Responses. Optional heißt: nur mit kontrollierten Variations. Cookies und Header bestimmen die Cache-Hit-Rate.

Nginx bleibt als Origin-Webserver hinter dem ALB. FastCGI-Timeouts müssen Magento-Realität abbilden.

Health Checks dürfen keine PHP-Workloads triggern. Static Assets werden direkt ausgeliefert.

# /etc/nginx/conf.d/magento.conf (Auszug)
location / {
  try_files $uri $uri/ /index.php$is_args$args;
}

location ~ \.php$ {
  include fastcgi_params;
  fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
  fastcgi_pass unix:/run/php-fpm/www.sock;
  fastcgi_read_timeout 120s;
  fastcgi_connect_timeout 10s;
  fastcgi_send_timeout 120s;
  fastcgi_buffering on;
  fastcgi_buffers 16 16k;
}

Varnish braucht eine Magento-spezifische VCL-Strategie. Ziel ist deterministische Cacheability. Admin, Checkout und Kundenkontext bleiben uncacheable. Alles andere wird über Cache-Tags invalidiert.

// VCL-Ansatz (konzeptionell, Magento liefert Generatoren)
sub vcl_recv {
  if (req.method != "GET" && req.method != "HEAD") { return (pass); }
  if (req.url ~ "^/checkout" || req.url ~ "^/customer" || req.url ~ "^/admin") { return (pass); }
  if (req.http.Authorization) { return (pass); }
  return (hash);
}

Redis-Policy entscheidet über Latenz-Spikes. Evictions müssen vorhersehbar sein. Für Magento ist allkeys-lru oft der praktikable Startwert. Sessions brauchen ausreichendes Memory-Headroom. Sonst kippt Login-Stabilität.

# ElastiCache Parameter (Startwerte)
maxmemory-policy allkeys-lru
timeout 0
tcp-keepalive 300

PHP-FPM wird auf Throughput und Tail-Latenz getrimmt. Zu viele Worker erhöhen Context Switches. Zu wenige Worker erhöhen Queueing. Startwerte hängen von vCPU und Redis/Varnish Cache-Hit-Rate ab. Details zur TTFB-Optimierung gehören ins Monitoring-Loop; siehe TTFB im Shop optimieren: konkrete Hebel statt Bauchgefühl.

; /etc/php-fpm.d/www.conf (Startwerte für 4 vCPU)
pm = dynamic
pm.max_children = 24
pm.start_servers = 8
pm.min_spare_servers = 8
pm.max_spare_servers = 16
pm.max_requests = 800
request_terminate_timeout = 120s

Magento-spezifisch entscheidet env.php über Cache-Konsistenz. Redis für Cache und Sessions trennt Failure Domains.

Prefixes sind pro Umgebung eindeutig. Das verhindert Key-Kollisionen bei Shared Redis-Clustern.

// app/etc/env.php (Auszug)
'cache' => [
  'frontend' => [
    'default' => [
      'backend' => 'Cm_Cache_Backend_Redis',
      'backend_options' => [
        'server' => 'redis-cache.prod.local',
        'port' => '6379',
        'database' => '0',
        'compress_data' => '1',
        'prefix' => 'prod_cache_'
      ],
    ],
    'page_cache' => [
        'port' => '6379',
        'database' => '1',
        'compress_data' => '0',
        'prefix' => 'prod_fpc_'
      ],
    ],
  ],
],
'session' => [
  'redis' => [
    'host' => 'redis-cache.prod.local',
    'port' => '6379',
    'database' => '2',
    'disable_locking' => '0',
    'max_concurrency' => '10',
    'break_after_frontend' => '5',
    'break_after_adminhtml' => '30',
    'first_lifetime' => '600',
    'bot_lifetime' => '60',
    'prefix' => 'prod_sess_'
  ],
],

Deployment ist artifact-basiert. Build läuft in CI. Runtime-Nodes ziehen nur versionierte Artefakte aus S3. Composer läuft nicht auf EC2. Static Content wird im Build erzeugt. Das reduziert Cold-Start-Latenz beim Scale-Out.

1. Build: composer install, di:compile, static-content:deploy, Tests, Artefakt nach S3.
2. Provision: Immutable ASG mit neuer Launch Template Version und User Data.
3. Deploy: Artefakt pull, symlink release, config import, DB migrations kontrolliert.
4. Warmup: Cache warmup über definierte URLs, dann Traffic-Switch.

DB-Migrations sind der kritische Pfad. Schema-Änderungen müssen vor Traffic-Switch laufen. Destruktive Änderungen brauchen zweiphasige Rollouts. Feature Flags entkoppeln Code von Datenmodell. Maintenance Mode bleibt der letzte Ausweg.

Rollback-Plan folgt Blue/Green Deployment oder Immutable ASG. Blue bleibt intakt. Green wird hochgezogen und geprüft. Health Checks prüfen nicht nur 200 OK. Sie prüfen Magento Readiness, ohne Indexer zu triggern. Bei Fehlern wird Traffic zurückgeschwenkt. DB-Rollback ist selten möglich. Deshalb: vorwärts-kompatible Migrations und Idempotenz.

Schritt	Prüfung	Abbruchkriterium
Green ASG hochfahren	ALB Health + App-Readiness Endpoint	Fehlende Dependencies, hohe 5xx
DB Migration	Locking, Laufzeitbudget, Retry-Strategie	Deadlocks, Timeout, Partial Apply
Traffic-Switch	Canary 1–5%, Error Budget	TTFB-Anstieg, Cache-Hit-Rate fällt
Rollback	ALB Target Group zurück auf Blue	Nur wenn DB vorwärts-kompatibel bleibt

In der Praxis zeigt sich: CloudFront wird nur für Assets aggressiv konfiguriert. HTML bleibt bei Varnish. Wenn CloudFront HTML cached, dann mit strikter Origin Request Policy.

Cookies werden minimiert. Varianten werden explizit modelliert. Sonst sinkt die Cache-Hit-Rate und die Latenz steigt.

Betrieb aus der Praxis: Failure-Modes, Troubleshooting und Monitoring (Runbooks)

Störungen sind selten monokausal. Meist kippt ein gekoppeltes System aus Cache, PHP-FPM und Datenbank. Das zeigt sich zuerst in Latenz-Spikes. Danach folgen 5xx am ALB. Dann erst kommen CPU-Alarme.

Incident-Story (anonymisiert): Ausgangslage: Multi-AZ in einer AWS Region, ALB vor EC2 in einer Auto Scaling Group (ASG), RDS MySQL Multi-AZ, ElastiCache Redis für Sessions und Cache. Symptom: 504 hinter ALB, nur auf Checkout. Timeline: 10:02 erste 504, 10:05 TargetResponseTime p95 von 0,9s auf 8,7s, 10:07 ALB HTTPCode_Target_5XX_Count von 0 auf 120/min. Parallel: Magento TTFB p95 9–12s. RDS DatabaseConnections stiegen von 280 auf 780. CPU blieb bei 55%. Root Cause: Redis Sessions mit Lock-Contention. Ein Release hatte Session-Schreibfrequenz erhöht. Dadurch stauten sich PHP-FPM Worker. Retry-Strategie im Frontend verstärkte den Throughput. Fix: Session-Handler auf Redis mit kürzerer Lock-TTL. Checkout-Calls wurden idempotent gemacht. Zusätzlich wurden aggressive Client-Retries begrenzt. Prävention: Alarm auf Redis “blocked clients” und PHP-FPM Queue. Runbook ergänzt, mit Lasttest vor Green-Traffic.

Signal	Typischer Failure-Mode	Sofortmaßnahme
ALB 5xx + TargetResponseTime p95 > 2s	502/504 durch Timeouts, Health Checks, überlastete Worker	Timeouts prüfen, PHP-FPM Queue entlasten, Traffic drosseln
RDS IOPS am Limit, ReadLatency > 20ms	IOPS/Buffer Pool Bottleneck	Slow Queries isolieren, Parameter prüfen, Storage/Instance anpassen
Redis evictions > 0, memory > 80%	Cache churn, Session-Verluste, Locking	Memory-Policy prüfen, Keyspace analysieren, TTLs korrigieren
Varnish Hit-Rate fällt, Backend Requests steigen	Cache Stampede / Invalidation	Grace/saintmode, Warmup, Purge-Strategie härten
EFS PercentIOLimit > 80%, Latenz > 15ms	EFS Latenz/Throughput-Limit	Hot paths entfernen, lokale Disks nutzen, EFS Mode prüfen

Das führt zum nächsten Problem: Runbooks müssen konkrete Debug-Schritte enthalten. Sonst eskaliert jeder Alarm zur Ratesession.

• Redis Session Locks: Redis INFO clients auf blocked. Key-Pattern für Sessions prüfen. Lock-TTL und Session write frequency reduzieren. Retries begrenzen, Idempotenz im Checkout erzwingen.
• RDS IOPS/Buffer Pool Bottleneck: Slow query log aktivieren. Top-Queries mit hoher Rows_examined isolieren. Buffer Pool Hit-Rate prüfen. Parameter wie innodb_buffer_pool_size und Query-Pläne validieren.
• Cache Stampede/Invalidation: Varnish Backend-Fetches und X-Cache auswerten. Grace aktivieren. Purge-Events entkoppeln, z. B. Event-Driven Queue statt synchroner Purges.
• 502/504 hinter ALB: ALB Idle Timeout gegen PHP-FPM max_execution_time abgleichen. Health Checks auf Readiness, nicht auf “/”. Target deregistration delay prüfen. PHP-FPM pm.max_children gegen CPU und RAM dimensionieren.
• EFS Latenz/Throughput: CloudWatch EFS BurstBalance und PercentIOLimit prüfen. Magento Media besser auf S3, nicht auf EFS. Falls Shared Storage nötig ist, nur für wenige Pfade.

Technisch gesehen: Monitoring muss Metriken, Logs und Traces korrelieren. CloudWatch Dashboards sollten harte Schwellen haben. Beispiele: ALB HTTPCode_Target_5XX_Count > 10/min, TargetResponseTime p95 > 2s, EC2 Load > vCPU*2, PHP-FPM Queue > 20 für 5 Minuten.

RDS: CPU > 75%, IOPS > 85% Provisioned, DatabaseConnections > 80% max, ReplicaLag > 2s. Redis: evictions > 0, memory > 80%, connected_clients Sprünge.

Log-Strategie: ALB access logs nach S3, mit Athena-Abfragen für 5xx und TargetProcessingTime. App-Logs strukturiert, request_id propagiert. RDS slow query log zeitweise aktiv, mit Sampling. Traces müssen Checkout und Search trennen. Sonst verschwimmt Latenz in Mittelwerten.

# Athena: 504-Spikes nach Path und Target
SELECT elb_status_code, target_status_code, request_url, COUNT(*) c
FROM alb_logs
WHERE elb_status_code IN ('502','504')
  AND from_iso8601_timestamp(time) > now() - interval '15' minute
GROUP BY 1,2,3
ORDER BY c DESC;

# PHP-FPM: Engpass sichtbar machen
sudo tail -n 200 /var/log/php-fpm/www-error.log | grep -E "server reached pm.max_children|slow"

# RDS: akute Locks und lange Queries
SHOW FULL PROCESSLIST;
SHOW ENGINE INNODB STATUS\G

# Redis: Locking- und Memory-Signale
redis-cli INFO clients
redis-cli INFO memory
redis-cli --scan --pattern "sess_*" | head

In der Praxis zeigt sich: Backup ist nur dann relevant, wenn Restore geübt wird. RPO/RTO müssen explizit sein, etwa RPO 5 Minuten, RTO 30 Minuten. RDS snapshots plus PITR müssen getestet werden. S3 versioning schützt Artefakte und Media gegen Löschfehler. Restore-Drills sollten mindestens quartalsweise laufen. Bei Peak-Season monatlich. Jede Übung endet mit gemessener Restore-Dauer und dokumentierten Abweichungen.

Welche typischen Performance-Probleme hat Magento 2 auf AWS und wie behebt man sie? Fast immer sind es Cache-Hit-Rate, Session-Locking, DB-IOPS und Timeouts. Die Behebung folgt derselben Kette: Cache stabilisieren, Workload entkoppeln, Datenbank entlasten, Retries kontrollieren. Jede Maßnahme wird gegen TTFB und 5xx validiert.

Kosten, DSGVO und Betriebsmodell: TCO, Kostentreiber, Verantwortlichkeiten (inkl. Migrationspfad)

Das Budget kippt selten durch EC2. Es kippt durch Netzwerk, Datenhaltung und Observability.

Die Frage lautet daher konkret: Was kostet Magento Hosting auf AWS pro Monat?

Für Magento 2 als Multi-AZ-Design in einer AWS Region liegen realistische Bandbreiten meist hier:

Profil	Monatliche Bandbreite	Typische Kostentreiber
Klein	1.200–4.000 EUR	RDS MySQL (Storage/IOPS), NAT Gateway + Data Processing, CloudFront Egress, CloudWatch Logs, Backups
Mittel	4.000–15.000 EUR	RDS Multi-AZ, ElastiCache Redis, CloudFront Egress, WAF, Logs/Retention, höhere IOPS und Snapshots
Enterprise	15.000–80.000+ EUR	RDS/Aurora Multi-AZ, hohe IOPS/Throughput, mehrere NAT Gateways, WAF-Regeln, SIEM-Export, Cross-Region Backups

In der Praxis zeigt sich: NAT Gateway ist ein Dauerläufer mit zwei Preisschrauben. Stunden plus Datenvolumen.

Jeder Request aus Private Subnet ins Internet addiert Latenz und Kosten. Auch Paket-Repos zählen.

CloudFront Egress skaliert mit Traffic. Das ist gewollt, aber muss budgetiert werden.

CloudWatch Logs sind der stille Killer. Vor allem bei Debug-Logs und langen Aufbewahrungsfristen.

WAF kostet pro Web ACL, Rule und Request (kein Scherz). Bot-Traffic wird damit nicht kostenlos.

Backups kosten als Snapshots plus S3. Cross-Region-Replikation verdoppelt oft den Storage-Anteil.

Technisch gesehen: Reserved Instances und Savings Plans sind Pflicht, sobald die Architektur stabil ist.

Sie wirken primär auf EC2 und RDS. Sie wirken nicht auf NAT Gateway und Egress.

# Beispiel: CloudWatch Log Retention hart setzen, sonst wächst TCO unkontrolliert.
aws logs put-retention-policy \
  --log-group-name "/magento/app" \
  --retention-in-days 14

Das führt zum nächsten Problem: DSGVO ist Architekturarbeit, nicht Dokumentenarbeit.

• Region EU: Primär eu-central-1 Frankfurt oder eu-west-1. Keine Datenflüsse über Drittstaaten.
• AVV/DPA: Vertraglich fixieren. Subprozessoren und Support-Zugriffe explizit.
• Datenklassifizierung: PII gehört nicht in Logs. Keine E-Mail, IP, Token im Klartext.
• Aufbewahrungsfristen: CloudWatch Logs und S3 Lifecycle steuern. Auditierbar und minimal.
• Verschlüsselung: KMS für EBS/RDS/S3/Secrets. Key-Policies nach Least Privilege.
• Zugriff: IAM Rollen statt Keys. MFA für Konsole. Breakglass-User streng begrenzen.
• Backups: Backup-Standorte definieren. Cross-Region nur mit Rechtsgrundlage und Dokumentation.

# Beispiel: S3 Lifecycle für Backups, reduziert Kosten und erfüllt Aufbewahrungsfristen.
aws s3api put-bucket-lifecycle-configuration --bucket my-magento-backups --lifecycle-configuration '{
  "Rules": [{
    "ID": "expire-old-backups",
    "Status": "Enabled",
    "Filter": {"Prefix": ""},
    "Expiration": {"Days": 35}
  }]
}'

Beim Betriebsmodell entscheidet sich, ob Incidents in Minuten oder in Tagen enden.

• Self-Managed: Merchant/Agency betreiben VPC, ASG, RDS, Deployments, Patching, On-Call. Maximale Kontrolle, maximale Verantwortung.
• Managed: SLA, On-Call, Patch-Fenster, Change-Management und Runbooks sind Teil des Vertrags. Weniger Risiko bei 24/7-Betrieb.

Rollenmodell muss klar sein. Sonst werden Changes unreviewed und nicht idempotent ausgerollt.

• Merchant: Priorisiert Features, definiert RPO/RTO, genehmigt Wartungsfenster.
• Agency: Applikations-Changes, Magento 2 Module, Performance-Budgets, Release-Notes.
• DevOps: IaC, Security Baselines, Observability, Incident-Response, Retry-Strategie für Jobs.

# Beispiel: DNS Cutover vorbereiten. Niedriger TTL reduziert Risiko beim Switch.
aws route53 change-resource-record-sets --hosted-zone-id Z123 --change-batch '{
  "Changes": [{
    "Action": "UPSERT",
    "ResourceRecordSet": {
      "Name": "shop.example.com",
      "Type": "A",
      "TTL": 60,
      "ResourceRecords": [{"Value": "203.0.113.10"}]
    }
  }]
}'

Der Migrationspfad ist planbar, wenn man ihn als Kette behandelt. Nicht als Ticketsammlung.

1. Discovery: Traffic, Cache-Hit-Rate, Datenvolumen, Cron/Indexer-Last, Compliance-Anforderungen.
2. Landing Zone: VPC, Subnets, IAM, KMS, Logging, Guardrails, Naming, Tagging, Cost Allocation.
3. Datenmigration (RDS): Initial Load, dann CDC. Idempotenz und Checksums für Verifikation.
4. Cutover: Wartungsfenster oder Near-Zero-Downtime. DNS/TTL, Session-Drain, Cache-Invalidation.
5. Validierung: Orders, Payments, Indexer, Async-Queues, 5xx, TTFB, Logs auf PII prüfen.

Downtime ist eine bewusste Option. Sie reduziert Komplexität, erhöht aber Business-Risiko.

Near-Zero-Downtime erhöht Komplexität. CDC, Dual-Write und Race-Conditions sind typische Fehlerquellen.

Für den Cutover helfen Checklisten. Sie gehören in Change-Management und werden versioniert.

Siehe auch: Migration pragmatisch planen (Risiken, Cutover, Checklisten).

# Beispiel: WAF aktivieren und Managed Rules nutzen. Bot-Traffic wird messbar.
aws wafv2 create-web-acl \
  --name "magento-edge" \
  --scope CLOUDFRONT \
  --default-action Allow={} \
  --visibility-config SampledRequestsEnabled=true,CloudWatchMetricsEnabled=true,MetricName=magentoEdge

Wenn Architektur, Betrieb und Kostenkontrolle gemeinsam designed werden, wird AWS kalkulierbar.

Anmerkung: Die hier gezeigte Konfiguration stammt aus einem realen Setup – nicht aus der Doku kopiert.

Wenn Verantwortlichkeiten unklar sind, wird jeder Incident zum Eskalationsspiel.

Für Setup, Betrieb und Change-Management im Team hilft eine klare Übergabe. Oder ein externer Betriebspartner.

Wenn das gesucht ist, passt eine spezialisierte Magento Agentur als Schnittstelle zwischen Code und Plattform.