Magento Cloud Hosting: Architecture, Deployment Models, and How to Choose the Right Provider

Was meint „Magento Cloud Hosting“ wirklich – und wo endet Marketing?

„Cloud“ ist erst dann belastbar, wenn Verantwortlichkeiten, Topologie und Betriebsziele klar sind. Sonst ist es nur ein Server, der anders abgerechnet wird.

Das wurde eben als Architektur-Entscheid sichtbar. Der Kontrast: Viele Teams kaufen „Cloud“ und erwarten Stabilität, obwohl Cache-, Search-, Queue- und Deploy-Mechanik unverändert bleibt – und wundern sich dann: „Warum ist unser Shop trotz ‚Cloud‘ nicht schnell/stabil?“

Begriffe zuerst. Hart.

Magento Open Source bedeutet: kostenfreie Magento-Edition, aber self-hosted.

Infrastruktur, Hardening, Deployments, Monitoring, Backups, Incident Response: alles beim Betreiber/Partner. Adobe Commerce ist die Enterprise-Edition mit zusätzlichen Features; sie kann genauso self-hosted laufen – dann gelten dieselben Betriebsaufgaben, nur mit mehr Komplexität und meist höheren SLA/SLO-Erwartungen. Adobe Commerce Cloud (AC Cloud) ist etwas anderes: ein PaaS-Angebot mit vorgegebener Build/Deploy-Pipeline, Umgebungs-Konzept und standardisiertem Stack (z. Redis, Varnish, OpenSearch je nach Version). Das ist nicht „Magento Hosting“, sondern ein Betriebs-Framework mit Leitplanken.

Antwort auf die Kernfrage: Magento Hosting ist der Betrieb von Magento (Open Source oder Adobe Commerce) auf IaaS/PaaS-Ressourcen nach eigener Wahl; Adobe Commerce Cloud ist eine konkrete PaaS-Produktisierung mit standardisierten Deploy- und Runtime-Mechaniken und klarer Shared Responsibility.

Aufgabe	Provider (IaaS/PaaS)	Agentur/Managed Partner	Inhouse
Patchen (OS/Runtime/App)	IaaS: OS nein / PaaS: Plattform ja	optional (SLA-gebunden)	App fast immer ja
Monitoring/Alerting (SLOs)	Basis-Metriken	typisch ja	ja, inkl. TTFB/LCP/Cache-Hit-Rate
Backups/DR (RPO/RTO)	Snapshots/Services	Runbooks + Restore-Tests	Owner der Ziele
Deployments (Blue-Green, Rollback)	PaaS-Mechanik teilweise	Pipeline-Betrieb	Release-Engineering
Security Hardening/WAF	Perimeter optional	Policies + Betrieb	Risikoentscheidung

Typische Cloud-Topologien. Kurz, aber mit Folgen.

• Single-VM: maximaler Durchgriff, minimale Komplexität. Skaliert vertikal. Failure-Domain: eins.
• Multi-VM: Web/PHP-FPM, DB, Redis, Varnish, OpenSearch getrennt. Mehr Throughput, mehr Netzwerk, mehr Betriebsfläche.
• Container/Kubernetes: gute Entkopplung, gute Rollouts. Dafür: Plattform-Engineering, Limits/Requests, Observability-Pflicht.
• PaaS-Umgebungen (AC Cloud): standardisierte Pipeline, Staging/Production-Parität als Default. Kontrolle sinkt, Vorhersagbarkeit steigt.

Anti-Patterns, die „Cloud“ entwerten. „Mehr vCPU“ statt Cache/DB/Search-Design. Punkt. Varnish ohne Cache-Hit-Rate als KPI. OpenSearch/Elasticsearch ohne Indexing-Strategie, dann wird Layered Navigation zum Latenz-Treiber (been there, done that). Cron/Queue ohne Retry-Strategie, dann kippt das System unter Last, obwohl das Frontend „grün“ wirkt.

Und „Managed“ ohne Runbooks/SLA ist nur Outsourcing von Unklarheit. Incident Response ohne klare Ownership, ohne RPO/RTO-Tests, ohne definierte SLOs für TTFB und LCP: Das funktioniert bis zum ersten echten Peak.

Architektur ist der Hebel. Nicht der Tarif. Wer die Magento-Architektur (Module, Themes, Schnittstellen) sauber einordnen kann, entscheidet Cloud-Topologie und Betriebsmodell nicht nach Bauchgefühl, sondern nach Bounded Context, Entkopplung und messbaren Betriebszielen.

# Minimaler Realitätscheck: Cache-Hit-Rate und TTFB sichtbar machen
curl -s -D - https://shop.example/ -o /dev/null | egrep -i 'x-cache|age|x-magento-cache-debug|server|x-request-id'

# Queue/Cron: Stau erkennen (Symptom), bevor UX kippt
bin/magento queue:consumers:list
bin/magento cron:run --group=index

# OpenSearch/Elasticsearch: Cluster-Health ist kein Nice-to-have
curl -s http://opensearch:9200/_cluster/health?pretty

# PHP-FPM: Tail-Latency entsteht oft durch zu wenige/zu viele Worker (und Memory)
ps -o pid,cmd,%mem,%cpu -C php-fpm

Referenz-Architekturen: Small/Medium/Enterprise – inkl. Multi-Store, B2B und Headless

Der Cache ist grün, trotzdem kippt Checkout bei Peaks – warum?

Weil Checkout kaum FPC ist. Weil Sessions kleben. Weil DB-Locks und Payment-Roundtrips Tail-Latenz dominieren, während die Cache-Hit-Rate weiter „gut“ aussieht.

Der Engpass wandert in ein anderes Bounded Context. Und der Graph der Abhängigkeiten wird zur Architektur.

Blueprint Small. Für wenige Stores, moderates Throughput-Ziel, klare Release-Zyklen.

• LB/CDN/WAF → Varnish → PHP-FPM → DB → Redis (Cache/Sessions) → OpenSearch → Queue/Workers → Object Storage

Skalierung: PHP-FPM horizontal. Punkt.

DB und OpenSearch vertikal, solange Indexing und Query-Profile stabil sind; sobald Reindex-Jobs in Peak-Zeiten laufen, braucht Cron/Queue eine harte Entkopplung, sonst blockiert Checkout auf denselben Ressourcen wie Katalog und Admin.

# Varnish: Cache-Key für Store/Customer-Group trennen, sonst Cross-Store-Leaks
sub vcl_hash {
  hash_data(req.http.host);
  hash_data(req.url);
  if (req.http.X-Magento-Vary) { hash_data(req.http.X-Magento-Vary); }
}

Blueprint Medium. Multi-Store, erste B2B-Features, mehr API-Last, längere Kataloge.

• LB/CDN/WAF → Varnish → PHP-FPM (stateless) → DB (+ Read-Replica) → Redis (Cache getrennt von Sessions) → OpenSearch (2–3 Nodes) → Queue/Workers (separat) → Object Storage

Skalierung: Web/PHP-FPM horizontal, mit aggressivem Connection-Pooling und klaren Timeouts.

DB: Read-Replica für Katalog-Reads, aber Checkout bleibt write-heavy; Read-Your-Writes ist kein „Feature“, sondern ein Risiko, wenn Replikations-Lag nicht gemessen wird.

OpenSearch: vertikal bis Heap und Segment-Merge kippen, dann Cluster; Indexing-Strategie entscheidet, ob Layered Navigation Latenz frisst.

# Magento env.php: Redis getrennt, sonst Session-Pressure killt Cache
'session' => ['save' => 'redis', 'redis' => ['host' => 'redis-session', 'db' => '2']],
'cache'   => ['frontend' => ['default' => ['backend' => 'Cm_Cache_Backend_Redis',
  'backend_options' => ['server' => 'redis-cache', 'database' => '0']]]]

Blueprint Enterprise. Viele Stores, B2B mit Preisregeln, Headless, Black-Friday-Pattern.

• LB/CDN/WAF → Varnish (+ Edge-Cache Regeln) → PHP-FPM (autoscaled) → DB (Primary + Read-Replicas, ggf. Multi-AZ) → Redis (Cache/Sessions/Locks isoliert) → OpenSearch (Cluster, dedizierte Master/Data) → Queue/Workers (horizontale Consumer-Gruppen) → Object Storage (+ asynchrone Medien-Pipeline)

Skalierung: PHP-FPM strikt horizontal, aber nur mit stateless Nodes und externer Session.

Entkopplung: Queue/Workers skalieren nach Lag, nicht nach CPU; Retry-Strategie mit Backoff ist Pflicht, sonst DDoS durch eigene Retries.

DB: Writes sind der harte Deckel. Wenn Promotions, Inventory und Orders denselben Primary stressen, helfen Read-Replicas nur beim Browsing.

# Queue-Consumer: parallelisieren, aber mit Idempotenz und Backoff
bin/magento queue:consumers:start async.operations.all --max-messages=1000 --batch-size=50

Multi-Store ist kein Skinning-Problem. Es ist Cache-Invalidation.

Cache-Tags explodieren bei vielen Store-Views, wenn Content-Updates breit invalidieren; dann sinkt Cache-Hit-Rate, TTFB steigt, und Varnish wird zum Pass-through (was in der Theorie einfach klingt, aber in der Praxis Kopfschmerzen bereitet). Store-spezifische TTLs und präzise Tagging-Disziplin sind Architektur, nicht Tuning.

B2B verschiebt Last in Preisregeln, Customer Segments und Indexer.

Wenn Preisberechnung zur Request-Zeit passiert, wird PHP-FPM der Bottleneck; wenn Indexing zu aggressiv ist, wird OpenSearch instabil. Preis- und Katalog-Indizes gehören in getrennte Queue-Pfade, sonst blockiert ein Segment-Rebuild den gesamten Throughput.

Headless/PWA verschiebt Last auf APIs. GraphQL wird zum Hot Path.

CDN-Strategie braucht saubere Cache-Keys (Store, Currency, Customer Group, Auth) und ein bewusstes Caching-Modell für GraphQL, sonst ist jede Seite „uncacheable“ und LCP hängt am Backend. Details und Trade-offs stehen bei Headless/PWA-Optionen für Magento und ihre Architektur-Folgen.

# CDN: vary nur auf das Nötige, sonst Cache-Fragmente
Cache-Control: public, s-maxage=300, stale-while-revalidate=60
Vary: X-Magento-Vary

Welche Hosting-Option ist besser: AWS, Google Cloud, Azure oder ein Managed Hoster?

Die bessere Option ist die, die dein Betriebsmodell trägt. Punkt.

AWS/GCP/Azure sind Cloud Hosting. Du bekommst primitives für LB, Object Storage, Managed DB, Observability. Du zahlst mit Operational Overhead, wenn Unmanaged Hosting daraus wird.

Ein Managed Hoster reduziert Overhead, wenn SLA/SLO, Runbooks, RPO/RTO-Tests und Ownership wirklich vertraglich und operativ gelebt werden; sonst kaufst du nur Tickets.

PaaS wie Adobe Commerce Cloud (AC Cloud) passt, wenn du standardisierte Build/Deploy-Pipeline, Umgebungen und Staging/Production-Parität willst, und wenn du den Stack nicht ständig verbiegen musst.

Kubernetes/Helm passt, wenn du Plattform-Kompetenz, Observability-Rei ```typescript // Basis-Konfiguration – anpassen je nach Umgebung export const config = { environment: 'production', apiEndpoint: 'https://api.example.com', timeout: 5000, // 5s reicht für die meisten APIs retries: 3 // Exponential backoff empfohlen }; ``` fe und hohe Release-Frequenz hast; sonst wird Deploy-Mechanik dein Produkt. Klassische VMs passen, wenn Topologie stabil ist und du präzise Kapazitätsplanung akzeptierst.

Messbare Performance: Benchmarks, Lasttests und Tuning (Varnish/Redis/PHP-FPM/OpenSearch)

[error] varnishlog: FetchError backend fetch failed (HTTP/1.1 503 Service Unavailable)

So fängt Performance-Arbeit an. Mit einem Symptom.

Ein Performance-Modell braucht KPIs. Wenige. Hart gemessen. Über alle Umgebungen mit Staging/Production-Parität.

KPI	Zielkorridor (Startwerte)	Messpunkt
TTFB cached	50–150 ms	CDN/Varnish Edge, Real User Monitoring
TTFB uncached	300–800 ms	Origin, APM Traces (PHP-FPM → DB/Redis/OpenSearch)
LCP	1,8–2,5 s (p75)	RUM (Core Web Vitals), segmentiert nach Template
Cache-Hit-Rate (CDN+Varnish)	> 90% (PLP/PDP), > 95% für statische Assets	CDN Logs, Varnish VCL Stats
p95/p99 Response Time	p95 < 800 ms, p99 < 1500 ms (cached getrennt)	Loadtest + APM, getrennt nach Route
Error Rate	< 0,2% 5xx; < 1% 4xx (ohne Bots)	Ingress/ELB, App Logs, WAF
Queue-Lag	< 60 s normal, < 300 s Peak	Cron/Queue Metriken, Consumer Throughput
Search p95	< 250–400 ms	OpenSearch/Elasticsearch Query Latency

Brauche ich Varnish/Redis/CDN für Magento. Ja. Für Throughput und Latenz.

Ohne Varnish landet Full Page Cache in PHP. Das skaliert teuer und bricht bei Peaks zuerst (und das ist noch die einfache Version). Mit Varnish wird p95 stabil, weil der Backend-Pfad seltener läuft und Tail-Latency sinkt.

Ohne Redis-Sessions werden Sessions oft zu Files. Das erzeugt Locking, I/O und sporadische p99-Spikes. Redis reduziert Contention und macht horizontale Skalierung erst sauber.

Ohne CDN sind Assets und oft auch HTML näher am Origin. TTFB cached und LCP verlieren sofort. Punkt. Mehr Details stehen in Hebel für bessere Shop-Ladezeiten (TTFB, Cache, Rendering).

Lasttests müssen echte Bounded Contexts abbilden. Nicht nur “1000 Users auf /”.

1. Warmup: Caches füllen (PLP/PDP/Search), 10–20 Minuten.
2. Ramp-up: linear oder stufig, bis Ziel-RPS erreicht ist.
3. Peak: 15–30 Minuten, mit realer Mix-Ratio.
4. Soak: 2–6 Stunden, Memory-Leaks und Queue-Lag finden.

Szenarien: PLP, PDP, Search, Checkout. Dazu Login und Add-to-Cart als State-Changer. Cache-Busting muss kontrolliert passieren, sonst misst du nur Miss-Pfade.

Abnahmekriterien sind numerisch. Stop Conditions auch. Backpressure ist ein Feature, kein Unfall.

• Stop: 5xx > 1% über 5 Minuten.
• Stop: p99 > 3 s auf Checkout oder Search.
• Stop: Queue-Lag > 15 Minuten oder wächst monoton.
• Stop: OpenSearch Cluster Health != green.
• Stop: DB Connections > 85% des Limits.

Dann Tuning. Immer mit Vorher/Nachher und gleicher Lastkurve.

; PHP-FPM (Platzhalter)
pm = dynamic
pm.max_children = {{MAX_CHILDREN}}
pm.start_servers = {{START}}
pm.min_spare_servers = {{MIN_SPARE}}
pm.max_spare_servers = {{MAX_SPARE}}
pm.max_requests = {{MAX_REQUESTS}}
request_terminate_timeout = {{TIMEOUT}}s

Zu viele Worker erhöhen Throughput kurz. Dann kippt die DB. Tail-Latency explodiert.

# Redis Sessions vs. Files (Platzhalter)
bin/magento setup:config:set \
  --session-save=redis \
  --session-save-redis-host={{REDIS_HOST}} \
  --session-save-redis-db={{SESSION_DB}} \
  --session-save-redis-disable-locking=0 \
  --session-save-redis-max-concurrency={{MAX_CONCURRENCY}}

Session-Locking ist der stille Killer bei Checkout-Peaks. Ein Kollege hat letztens genau diesen Fehler gemacht.

# Varnish TTL/Grace/Purge-Strategie (Platzhalter, VCL-Snippet)
sub vcl_backend_response {
  set beresp.ttl = {{TTL}}s;
  set beresp.grace = {{GRACE}}s;
}
# Purge: tag-basiert, nicht URL-basiert
# x-magento-tags: ...  => gezielte Invalidierung

Grace kaschiert Origin-Jitter. Zu viel Grace versteckt echte Fehler. Miss die Error Rate getrennt nach cached/uncached.

# OpenSearch Shards/Replicas/Refresh (Platzhalter)
PUT /{{INDEX}}/_settings
{
  "index": {
    "number_of_shards": {{SHARDS}},
    "number_of_replicas": {{REPLICAS}},
    "refresh_interval": "{{REFRESH}}"
  }
}

Zu viele Shards senken Query-Performance. Zu wenige bremsen Reindexing. Refresh zu aggressiv erhöht I/O und Latenz.

Indexer und Cron/Queue brauchen Entkopplung. Async Indexer senkt Frontend-Latenz, erhöht aber Queue-Lag-Risiko. Miss Consumer Throughput und setze Backpressure statt “mehr Cron”.

Observability ist minimal, aber hart. Drei Dashboards reichen oft: Edge/Cache, App/APM, Search/Queue.

• Alert: Cache-Hit-Rate < 85% (PLP/PDP) über 10 Minuten.
• Alert: OpenSearch cluster health != green oder Search p95 > 400 ms.
• Alert: Cron/Queue backlog > {{N}} Jobs oder Lag > 300 s.
• Alert: DB connections saturation > 85% oder Lock-Waits > {{X}}/min.

Wenn diese Metriken stabil sind, wird Skalierung planbar. Wenn nicht, kaufst du nur größere Maschinen.

Migration & Go-Live ohne Drama: Cutover-Plan, DNS, Rollback, Staging/Prod-Parität

30 Sekunden DNS-TTL vor dem Cutover ist kein Detail, sondern der Unterschied zwischen steuerbarem Switch und stundenlangem Schwebezustand.

Sieht man das im Monitoring?

Wir hatten das bei einem Kunden, der von Monolith auf Services migriert hat. Der Shop war Magento Open Source, Ziel war Cloud Hosting auf IaaS mit Managed Hosting drumherum.

Das eigentliche Risiko lag nicht in PHP-FPM oder Redis. Es lag im Cutover: Datenbewegung, DNS, und der Moment, in dem du merkst, dass „Rollback“ nur dann existiert, wenn du ihn geprobt hast.

Aber funktioniert das wirklich?

Drei Migrationspfade. Drei Risiko-/Aufwandsprofile.

• Lift-and-Shift: gleicher Stack, neue Infrastruktur. Schnell. Drift-Risiko hoch, weil „wir kopieren nur“ meist Konfigurationsschulden konserviert.
• Replatform: Stack-Wechsel (z. B. OpenSearch/Elasticsearch-Cluster neu, Redis-Topologie anders, Varnish/CDN neu). Aufwand hoch, dafür Architektur-Entkopplung möglich und Throughput planbarer.
• PaaS-Move auf Adobe Commerce Cloud (AC Cloud): standardisierter Stack, Pipeline vorgegeben. Risiko verschiebt sich: weniger OS-Themen, mehr Build/Deploy-Mechanik, Limits, und Paritätsdisziplin.

Wie migrierst du ohne Downtime? Du versprichst es nicht pauschal. Du baust es: Read-only-Fenster, Delta-Sync, und ein Timeboxed Cutover mit Go/No-Go-Kriterien. Wenn du Writes nicht einfrierst, brauchst du entweder Dual-Write (selten sauber) oder akzeptierst Inkonsistenz. Punkt.

Der Ablauf, der in der Praxis funktioniert, ist langweilig. Genau deshalb funktioniert er.

1. DNS TTL-Plan (Owner: NetOps): 48h vorher TTL schrittweise runter (z. B. 3600 → 300 → 30). Kein spontanes „gleich umstellen“.
2. Datenfreeze (Owner: Product/Business): klare Timebox. Bestellungen laufen weiter? Dann brauchst du Delta-Sync bis zum Switch und danach eine Nachzieh-Strategie.
3. Delta-Sync DB/Media (Owner: Platform): initialer Bulk, dann inkrementell. Idempotenz erzwingen, sonst multiplizierst du Fehler.
4. Cache-Warmup (Owner: App): Varnish/CDN füllen, Critical Paths primen, Cache-Hit-Rate vor Traffic.
5. Smoke Tests (Owner: QA): Checkout, Login, Suche, Admin-Cron/Queue, plus Payment/Shipping Provider Checks.

RACI ist kein Prozess-Overhead. Es ist Backpressure gegen „alle machen alles“.

Arbeitspaket	R	A	C/I
DNS Switch & TTL	NetOps	Platform Lead	C: Security, I: Support
DB/Media Delta-Sync	Platform	Platform Lead	C: DBA, I: QA
Payment/Shipping Live-Checks	QA	Release Manager	C: Provider, I: Support

Rollback-Runbook: schriftlich. Mit Entscheidungspunkten. Mit Uhrzeiten.

Und genau da liegt das Problem.

• T+10 min: Smoke Tests fail? Sofort zurück. Kein Diskutieren.
• T+30 min: Latenz/TTFB außerhalb SLO? Circuit Breaker: Checkout-Traffic drosseln, Bots blocken, Rollback vorbereiten.
• T+60 min: Queue-Stau (Cron/Queue) steigt weiter? Go/No-Go anhand definierter Thresholds, nicht Bauchgefühl.

Monitoring-Kriterien sind „Go“ oder „No-Go“. Beispiele: TTFB p95 < 800ms auf Cache-Hits, Cache-Hit-Rate > 85% nach Warmup, OpenSearch/Elasticsearch Cluster-Health grün, Error-Rate im Checkout < 0,5%.

Parität ist der stille Killer. Staging/Production-Parität bedeutet: gleiche PHP-Version, gleiche Extensions, gleiche OpenSearch-Version, gleiche Redis-Config. Und Drift-Kontrolle über IaC/Config-as-Code plus sauberes Secrets-Handling, nicht über „wir klicken das im Portal“.

# DNS TTL vor Cutover (BIND Beispiel)
; 48h vorher
shop.example.com. 3600 IN A 203.0.113.10
; 6h vorher
shop.example.com. 300  IN A 203.0.113.10
; 30min vorher
shop.example.com. 30   IN A 203.0.113.10

# DB Delta-Sync (Beispiel, logisch - Tooling variiert)
# 1) initialer Dump/Restore
mysqldump --single-transaction --routines --triggers magento | gzip > base.sql.gz
# 2) inkrementell via binlog position (idempotent anwenden!)
mysqlbinlog --start-position=POS --read-from-remote-server | mysql magento

# Cache-Warmup (gezielt, nicht "crawl the web")
curl -sS -H 'Host: shop.example.com' https://NEW_EDGE/ | head
curl -sS -H 'Host: shop.example.com' https://NEW_EDGE/category/top-seller | head

# Drift-Check: Versionsgleichheit (Beispiel)
php -v
php -m | sort | sha256sum
curl -s http://opensearch:9200 | jq '.version.number'
redis-cli INFO server | grep redis_version

Staging-Loadtests sind das Gate. Nicht „nice to have“. Du willst nicht maximale RPS. Du willst Tail-Latenz, Queue-Backpressure und Such-Throughput unter realistischen Mix-Patterns sehen, bevor du DNS anfasst.

Für zusätzliche Vergleichslogik lohnt sich der Blick auf Migration-Checklisten und typische Umzugsrisiken (als Vergleichslogik) — anderes System, gleiche Physik: Daten, DNS, Drift, Rollback.

Security, Compliance & Betrieb: Patch-Strategie, WAF, Backups, Incident Response (DSGVO-ready)

< 0,1% 5xx unter Peak ist kein Luxus. Das ist ein Security- und Betriebs-Signal.

Wenn deine WAF-Regeln zu aggressiv sind, killst du Checkout. Wenn sie zu lasch sind, frisst Bot-Traffic deine PHP-FPM-Worker und deine Latenz explodiert. Beides fühlt sich für den User gleich an: langsam. Und ja, das schlägt direkt auf LCP und Conversion durch — Warum Core Web Vitals auch für SEO und Conversion zählen.

Security-Baseline. Nicht verhandelbar.

• TLS 1.2+ mit HSTS (inkl. Preload-Strategie, wenn du’s durchziehen willst).
• WAF + Bot-Protection (Rate Limits, Credential Stuffing Rules, Challenge-Mechaniken für verdächtige ASNs).
• Secret-Management (keine Secrets in Git, keine Secrets in Build-Logs, Rotation als Prozess).
• Least Privilege (IAM, DB-User, S3/Bucket-Policies, Queue-Creds pro Bounded Context).
• Admin-Absicherung: 2FA, IP allowlist/VPN, getrennte Admin-URL, Logging.

DSGVO ist keine Folie. Es sind Artefakte. AVV mit deinem Cloud Hosting/Managed Hosting-Partner.

TOMs als lebendes Dokument (Verschlüsselung at-rest/in-transit, Zugriffskontrolle, Protokollierung). Löschkonzept: welche Daten, welche Fristen, welche Jobs, welche Nachweise. Und ein Incident-Runbook, das nicht aus „wir informieren jemanden“ besteht, sondern aus konkreten Schritten und Zuständigkeiten.

Supply-Chain: Composer ist dein Einfallstor.

Policy first. Lockfile immer. Private Repos nur signiert. Und: keine „dev-master“-Abhängigkeiten in Production. Punkt.

# Composer Supply-Chain Baseline (CI)
composer validate --no-check-all --strict
composer install --no-dev --prefer-dist --no-interaction --no-progress
composer audit --no-interaction

# Optional: Fail, wenn unapproved Repos auftauchen
composer config --global --list | grep -E "repo|repositories"

Patch- & Release-Prozess: Magento Security Patches sind kein Quartalsritual. Sie sind ein Stream. Plane Wartungsfenster, aber deploye so, dass du sie selten brauchst: Canary oder Blue-Green Deployment. Regression-Suite als Gate. Nicht manuell klicken. Automatisiert. Und messbar (TTFB, Cache-Hit-Rate, Error Budget).

Klingt einfach. Ist es nicht.

Updates außerhalb Magento: PHP, OpenSearch/Elasticsearch, Redis. Die Reihenfolge zählt. Erst Kompatibilität prüfen, dann Staging, dann Canary.

Ergebnis?

Ein Kollege hat letztens genau diesen Fehler gemacht: OpenSearch minor bump, Mapping-Change übersehen, Indexing hängt, Cluster wird yellow, Suche degradiert, Checkout-Suche timeouts. Das war kein „Bug“. Das war fehlendes Runbook plus fehlende Canary-Metriken.

# Minimaler Deploy-Check (AC Cloud oder eigenes CI/CD)
php -v
bin/magento setup:di:compile
bin/magento setup:static-content:deploy -f
bin/magento cache:flush

# Smoke: Admin + Checkout Pfade (synthetisch)
curl -I https://shop.example/ | head
curl -I https://shop.example/checkout/ | head

Backups/DR: Definiere RPO/RTO, bevor du Tools kaufst. RPO 15 Minuten? Dann brauchst du binlog/WAL-Strategie oder sehr häufige Snapshots.

RTO 60 Minuten? Dann brauchst du automatisierte Restore-Pfade, nicht „wir laden ein Dump hoch“.

• Backup-Umfang: DB, Media, relevante Config (env.php), Such-Indizes nach Strategie (oft rebuildbar).
• Immutable Backups (Write-Once / Object Lock), getrennte Accounts/Keys.
• Restore-Tests als Kalendertermin. Mit Protokoll. Mit Zeiten.
• Verantwortlichkeiten: wer entscheidet Failover, wer kommuniziert, wer macht forensische Sicherung.

# Beispiel: DB + Media Snapshot (schematisch)
# DB Dump (verschlüsselt ablegen)
mysqldump --single-transaction --routines --triggers magento \
 | gzip \
 | gpg --encrypt --recipient ops@example.com \
 > magento-db.sql.gz.gpg

# Media Sync (inkrementell)
aws s3 sync pub/media s3://backup-bucket/media --delete

Troubleshooting-Runbooks. Kurz. Brutal konkret.

1. Redis Session Locking/Timeouts: Symptome: Login-Spikes, „Add to Cart“ hängt, PHP-FPM busy. Check: Redis latency, maxmemory, evictions. Fix: Session-Lock-Config, timeouts, separate Redis für Sessions vs Cache, Circuit Breaker im App-Layer für nicht-kritische Writes.
2. Varnish Purge/Cache Invalidation: Symptome: falsche Preise, stale CMS, Cache-Hit-Rate fällt. Check: BAN/PURGE ACL, tags, VCL. Fix: Purge-Queue begrenzen, Tagging prüfen, Purge nur über erlaubte IP/Token.
3. Cron/Queue Stau: Symptome: Indexer lag, Mails verspätet, „new products“ erscheinen nicht. Check: queue:consumers, cron_schedule, Dead Letter. Fix: Worker-Skalierung, poison messages isolieren, Event-Driven Entkopplung statt monolithischer Cron-Welle.
4. OpenSearch Cluster Health (yellow/red): Symptome: Suche langsam/leer. Check: /_cluster/health, unassigned shards, disk watermark. Fix: Shard-Count reduzieren, Replica-Policy, Disk erweitern, Reindex-Plan.
5. Deployment-Fails (Composer/Permissions/Env Vars): Symptome: Build bricht, 500 nach Deploy. Check: composer.lock drift, writable dirs, fehlende env vars. Fix: immutable artifacts, klare Ownership, Env-Var-Validation im Pipeline-Step.

# OpenSearch Health + schnelle Diagnose
curl -s http://opensearch:9200/_cat/indices?v | head -n 20

# Redis: Latenz/Hotkeys grob prüfen
redis-cli -h redis ping
redis-cli -h redis info | egrep "used_memory_human|evicted_keys|connected_clients"

Wie sichere ich Magento in der Cloud (WAF, Backups, Patch-Management, DSGVO)? Indem du Controls als Default setzt (TLS/HSTS, WAF/Bot-Protection, Secrets, Least Privilege, Admin-Hardening), Supply-Chain und Patches durch CI/CD erzwingst (Canary/Blue-Green + Regression-Suite), RPO/RTO als Engineering-Ziele definierst (immutable Backups + Restore-Tests) und DSGVO als nachweisbare Prozesse führst (AVV, TOMs, Löschkonzept, Incident Response).

Kurzer Hinweis: Die genauen Zahlen hängen natürlich vom konkreten Setup ab.

Wenn dir dafür intern die Zeit fehlt: hol dir ein Team, das Betrieb als Architektur behandelt — nicht als Ticketqueue. Eine Magento Agentur mit echter On-Call- und Runbook-Disziplin spart dir mehr Downtime, als jedes „größere Serverpaket“ je könnte.