Cloud Exit & AWS-Migration für Magento — raus aus der Public Cloud

Drei Hauptgründe in Reihenfolge der Häufigkeit, die wir bei Kunden sehen: (1) Kosten — AWS hat sich für Magento-typische Workloads (relativ vorhersehbarer Traffic, große S3/Object-Storage-Mengen) als 2–3× teurer erwiesen als dedizierte Server. (2) Egress-Gebühren — jeder Asset-Download kostet Geld, was bei Bildern und PDFs schnell zur Kostenfalle wird. (3) Datenhoheit & DSGVO — viele Kunden wollen das Rechenzentrum in der EU, idealerweise Österreich. Dazu kommt: bei Magento-Performance-Tuning ist die Hardware-Nähe zur DB wichtig. Public Cloud trennt das oft.

In den von uns durchgeführten Migrationen lag das neue Hosting bei rund 10 % der AWS-Kosten — also ca. 90 % Ersparnis bei vergleichbarer oder besserer Performance. Bei einem 2026-Projekt (B2B-Magento-Shop, vorher AWS ECS + Aurora + S3, ~25k Produkte) sind die Hosting-Gebühren von einer vierstelligen monatlichen AWS-Rechnung auf einen niedrigen dreistelligen Betrag pro Monat gesunken. Plus: keine Engineering-Stunden mehr für AWS-Wartung. Gesamt-TCO inkl. Personal-Aufwand deutlich darunter.

Magento nutzt S3 typischerweise für Produktbilder, Medien-Assets, Backups und manchmal als Queue-Storage. Wir migrieren das wahlweise auf: (a) lokales Filesystem mit Backup-Strategie, (b) selbst-gehosteten S3-kompatiblen Object Storage wie SeaweedFS oder Garage in einem AT/DE-Rechenzentrum, (c) klassisches NFS für High-Performance-Cases. Die Migration läuft mit aws s3 sync parallel zum Live-Betrieb, der Cutover ist Sekunden.

Für einen mittleren Magento-Shop (B2B, ~25k Produkte, eine Sprache): 3–6 Wochen von Auftrag bis Go-Live. Setup-Phase 1–2 Wochen (Server, DB, Webserver, PHP, Magento, Imports). Test-Phase 1–2 Wochen (Daten-Sync, Schnittstellen, Cookie-Consent). Cutover 1 Tag (DNS-Wechsel + finale DB-Sync). Komplexe B2B-Shops mit ERP-Schnittstellen sind länger — typisch 6–10 Wochen wegen ERP-Re-Integration.

Das ist meist der härteste Teil der Migration, weil ERP-Systeme (BMD, SAP, Pimcore, Odoo) typischerweise über AWS-SQS oder S3-basierte Queues mit Magento kommunizieren. Wir ersetzen das durch: (a) RabbitMQ oder Redis-basierte Queues auf eigenen Servern, (b) direkte Datenbank-Kommunikation für synchrone Use-Cases, (c) n8n-basierte Datenpipelines für komplexere Workflows. Die ERP-Anbindung muss in der Regel auf Provider-Seite parallel angepasst werden — das ist außerhalb unserer Kontrolle und braucht Zeit.

Standardmäßig auf unseren Servern in österreichischen oder deutschen Rechenzentren (internex AT, eigene gemietete Server in Wien und Deutschland). Hardware: dedizierte Bare-Metal- oder Cloud-VPS-Server mit dezidierten Magento-/PHP-FPM-/MySQL-/Redis-Konfigurationen. Wenn du eigene Hosting-Präferenzen hast (z.B. ein bestimmter AT-Hoster), arbeiten wir auch dort. Backup-Strategie: 3-2-1 mit Off-Site-Replikation.

Theoretisch ja, praktisch fast nie relevant für Magento-B2B. Magento-Shops haben planbaren Traffic (B2B-Geschäftszeiten, klare Saisonalität) — Auto-Scaling rechnet sich selten. Multi-AZ-Replication ist bei dedizierten Servern durch Backup + DB-Replica gleichwertig abgedeckt. Was du gewinnst: direkter Server-Zugriff für Performance-Tuning (was in AWS oft nur über teure Plan-Upgrades geht), planbare Kosten, kürzere Latenzen zur DB.

Geht jederzeit. Unsere Migrationen sind so aufgebaut, dass der Stack (Magento + DB + Object Storage + Queue) zwischen Provider wandern kann — das ist Standard-LAMP-/LEMP-Architektur, keine Cloud-Lock-Ins. Wir dokumentieren jeden Migrationsschritt, sodass du auch ohne uns wieder migrieren könntest. Aber: ein Großteil unserer Kunden, die einmal raus sind, bleiben es.