Im Januar 2026 haben wir bei CopeX einen Auftrag bekommen, der uns seitdem oft beschäftigt: Ein österreichischer B2B-Messebauer wollte seinen Magento-Shop raus aus der AWS-Cloud. Vorgänger-Agentur: ein AWS-Cloud-Spezialist. Stack: ECS für die Magento-Container, Aurora als Datenbank, S3 für Medien, SQS als Queue zur ERP-Anbindung. Klingt nach Lehrbuch — und war es auch. Trotzdem war es zu teuer, zu opak und für die DSGVO-Anforderungen des Kunden unzureichend.
Sieben Wochen später lief der Shop auf einem dedizierten Server in Österreich. Am 27. Februar 2026 zogen wir den DNS-Stecker bei AWS, am 1. April 2026 wurde der gesamte AWS-Stack vollständig deprovisioniert. Die Hosting-Kosten liegen jetzt bei rund 10 % des vorherigen AWS-Niveaus — eine Ersparnis von ungefähr 90 %. In diesem Artikel zeigen wir, wie wir das gemacht haben — und warum dieser Weg für viele Magento-B2B-Shops aus Österreich sinnvoll ist.
Warum überhaupt aus der Public Cloud raus?
Wenn wir mit Magento-Shopbetreibern über ihre AWS-Rechnungen sprechen, kommen immer dieselben drei Gründe für einen Cloud-Exit:
1) Die Kosten laufen unkontrolliert. Eine typische AWS-Magento-Installation mit ECS Fargate, RDS Aurora, S3, CloudFront, NAT Gateway und ELB kostet schnell 800 – 1.500 EUR pro Monat für mittelgroße B2B-Shops. Davon ist ein erheblicher Teil “Cloud-Overhead” — also Services, die nicht direkt zum Shop-Betrieb beitragen, sondern AWS-spezifische Architektur-Konstrukte sind.
2) Egress-Gebühren fressen die Marge. Jeder Bild-Download aus S3, jeder Asset-Aufruf via CloudFront kostet Geld. Bei B2B-Shops mit großen PDF-Katalogen oder produktbild-intensiven Listings (typische Industrie-Kataloge mit hochauflösenden Fotos) summiert sich das schnell auf einen dreistelligen Eurobetrag pro Monat — für gar nichts, was den Shop besser macht.
3) Datenhoheit und DSGVO. Viele österreichische Mittelständler wollen ihre Kundendaten nachweislich in der EU — idealerweise in einem österreichischen Rechenzentrum. AWS-EU-Regionen (Frankfurt, Stockholm) sind formal EU-konform, aber wegen US-CLOUD-Act-Themen rechtlich nicht eindeutig. Ein österreichischer Hoster löst das Problem strukturell.
Dazu kommt etwas, was wir bei Hosting-übergreifenden Performance-Audits regelmäßig sehen: Public Cloud trennt App und DB oft so stark, dass Magento-typische Queries langsamer werden als auf einem klassischen dedizierten Server mit App und DB im selben Rack. Das hat nichts mit AWS-Qualität zu tun — sondern mit Magento’s Architektur, die für DB-Latenz unter 1 ms optimiert ist.
Die Migration im Detail
Ausgangslage
Der Kunde hatte einen Magento-2-Shop mit:
- ~25.000 Produkten in 4 Sprachen
- Bidirektionale ERP-Schnittstelle (drittanbieter-ERP) via AWS SQS
- Medien-Assets (Bilder, PDFs) in einem S3-Bucket
- ECS-Fargate-Setup mit Aurora MySQL als RDS
- CloudFront als CDN, ELB als Load Balancer
Pain Points: 4-stellige monatliche AWS-Rechnung, keine direkten Server-Zugriffe für Performance-Tuning (alles ging nur über AWS-Konsole), Cookie-Consent-Setup war fragmentiert, ERP-Schnittstelle hatte chronische Queue-Delays.
Zielarchitektur
Wir haben uns für eine klassische, robuste LEMP-Architektur entschieden:
- Dedizierter Linux-Server in einem österreichischen Rechenzentrum
- nginx + PHP-FPM 8.3 mit OPcache und Redis als Cache-Backend
- MariaDB 11 statt Aurora — Magento-Connection-Performance um Faktor 1.5–2 besser als bei Aurora-Reader-Endpoint
- S3-kompatibler Object Storage für Medien (selbst-gehosteter SeaweedFS, transparente Migration aus AWS S3)
- RabbitMQ statt SQS — robuste AMQP-Queue mit Magento-Standard-Connector
- Cloudflare als CDN davor (kostet einen Bruchteil von CloudFront)
- Backup: 3-2-1 mit Off-Site-Replikation
Ablauf
| Woche | Phase | Aktivität |
|---|---|---|
| 1 | Audit | Bestandsaufnahme AWS-Services, Kosten-Inventur, Zielarchitektur-Skizze |
| 2 | Setup | Server-Provisionierung, nginx/PHP/DB/Redis konfiguriert, erste Test-Imports |
| 3 | Migration | Initialer DB-Dump aus Aurora, S3-Sync, Magento-Bootup auf neuer Infrastruktur |
| 4 | Schnittstellen | ERP-Re-Connect, RabbitMQ-Queue-Setup, Funktionstests, Cookie-Consent |
| 5 | Performance | Tuning, OPcache-Konfiguration, Bilder-Optimization, LCP-Reduktion |
| 6 | Test | Vollständiger Funktionstest auf Staging, ERP-Anbieter-Abstimmung, Payment-Tests |
| 7 | Cutover | DNS-TTL-Reduzierung, finale DB-Sync, DNS-Switch, Live-Validation |
| 8–10 | Cleanup | Schrittweise AWS-Service-Abschaltung, Queue-Migration, Storage-Cleanup |
Cutover-Tag
Der DNS-Switch am 27. Februar 2026 lief in vier Schritten:
- Shop auf AWS in Maintenance Mode
- Finaler DB-Dump aus Aurora gezogen und auf den neuen Server importiert (Delta gegen Initialdump: wenige hundert Bestellungen)
- S3-Bucket nochmal gesynct (mit
aws s3 sync— kontinuierliche Syncs in den Wochen davor hielten das Delta unter 100 MB) - DNS auf neue Server-IP umgestellt, TTL vorher auf 60 Sekunden reduziert
Downtime: unter 30 Minuten. Der Großteil davon: Maintenance-Mode plus finale DB-Sync. Nutzer in den ersten Minuten sahen entweder noch AWS oder schon den neuen Server — beide hatten denselben Code, dieselbe DB.
Was schwierig war
Die ERP-Schnittstelle. Das vorgelagerte ERP-System hatte über Jahre mit AWS SQS gearbeitet, und der Schnittstellen-Code lag beim ERP-Anbieter, nicht bei uns. Die Queue-Migration verzögerte sich um Wochen, weil parallel zur DNS-Umstellung der ERP-Anbieter erst Anpassungen auf seiner Seite vornehmen musste. Bis dahin liefen AWS-Komponenten parallel weiter — und kosteten weiterhin. Diese Phase ist die teuerste in einer Cloud-Exit-Migration, weil zwei Stacks parallel laufen.
Lesson Learned: Vor dem Cutover muss die ERP-Schnittstellen-Roadmap mit dem Drittanbieter fixiert sein. Wir bauen das heute in den Audit der ersten Woche fest ein.
Ein Moment, der hängengeblieben ist
Kurz nach dem Go-Live öffnete der Kunde den frisch migrierten Shop im Browser. Eine Produktseite, die unter AWS gerne mal drei, vier Sekunden brauchte bis das Bild stand, war auf einmal in unter einer Sekunde komplett da. Login, Warenkorb, Kategorie-Filter — alles spürbar direkter.
Der Kunde, sichtlich überrascht: „Wahnsinn, ist das schnell auf einmal. Früher hat das viel länger gedauert.”
Und das ist genau das Paradox an AWS, das viele unterschätzen. AWS ist hoch skalierbar nach oben — wenn Traffic plötzlich explodiert, kommen weitere Container automatisch dazu. Klingt großartig. Aber: Skaliert man wieder runter, um Kosten zu sparen — und das passiert eben immer, weil B2B-Shops außerhalb der Geschäftszeiten leer sind — wird das System träge. Erst kommt der Request, dann muss der Container hochgefahren werden, die DB-Connection aufgebaut, der OPcache gewärmt. Der erste Request nach einer Cold-Phase ist quälend langsam. Und genau diese ersten Requests sind es, die ein Kunde am Vormittag erlebt, wenn er nach dem Kaffee in den Shop schaut.
Auf einem dezidierten Server gibt es das Problem schlicht nicht. Der Server läuft. Immer. Mit derselben Antwortzeit, ob nachts um drei oder am Black-Friday-Mittag. Deployments dauern bei uns übrigens auch ihre fünf bis zehn Minuten — Build, Tests, Cache-Warmup. Was schneller geworden ist, ist das, was den Kunden tatsächlich interessiert: das Backend unter dem Shop und das Frontend, das im Browser ankommt. Mehr dazu, wie wir das dezidierte Magento-Hosting und die laufende Performance-Betreuung konkret aufsetzen.
Was hat es gespart?
Konkrete Zahlen, anonymisiert:
| Posten | Vorher (AWS) | Nachher (CopeX-Server) |
|---|---|---|
| Hosting (App + DB + Storage) | vierstellig pro Monat | niedrig dreistellig pro Monat |
| Egress / CDN | erheblich (S3 + CloudFront) | minimal (Cloudflare) |
| Monitoring / Logs | extra (CloudWatch) | inkludiert |
| Hosting-Niveau gesamt | 100 % | ~10 % |
| Ersparnis | ~90 % |
Nicht in der Tabelle: Engineering-Zeit. Vorher mussten Anpassungen an der Infrastruktur über AWS-IAM, Terraform und ECS-Task-Definitions laufen — pro Anpassung mehrere Stunden. Auf einem dedizierten Server: ssh, vim, fertig. Über ein Jahr sparen sich Kunden damit zusätzlich mehrere Tausend Euro an Engineering-Aufwand.
Wann lohnt sich ein Cloud-Exit für deinen Magento-Shop?
Klare Indikatoren aus unserer Erfahrung mit Magento-Hosting-Migrationen:
- AWS-Rechnung über 500 EUR/Monat, Traffic aber relativ planbar (B2B-Geschäftszeiten, klare Saisonalität)
- Magento-Performance-Probleme, die in der Cloud nicht oder nur teuer zu lösen sind
- DSGVO-Anforderungen, die ein österreichisches/europäisches Rechenzentrum verlangen
- ERP-Schnittstellen, die in AWS unnötig komplex aufgesetzt sind (SQS-Queue mit IAM-Roles für ein simples One-Way-Sync)
- Sehnsucht nach planbaren Monatskosten ohne Egress-Überraschungen
Klare Gegenindikatoren:
- Echte globale Traffic-Verteilung mit Auto-Scaling-Bedarf
- B2C-Shops mit massiv unvorhersehbarem Traffic (Influencer-Marketing, Viralität)
- Tiefe Integration mit anderen AWS-Services (Lambda, SageMaker, etc.), die nicht ersetzbar sind
Was du als nächstes tun kannst
Wenn du den Eindruck hast, dass deine AWS-Rechnung höher ist als sie sein müsste, gibt es zwei pragmatische erste Schritte:
- AWS-Kostenanalyse via Cost Explorer: Filter auf den Magento-Tag oder die Magento-relevanten Services. Was kostet was?
- Cloud-Exit-Audit anfordern: Wir machen das in 1–2 Wochen — Bestandsaufnahme, Zielarchitektur, Kostenkalkulation, Migrationsplan. Konkrete Zahl: was du im Monat sparen würdest. Kontakt: office@copex.io oder Audit anfragen.
Verwandte Themen aus unserem Blog: Performance-Optimierung mit Hyvä, Largest Contentful Paint optimieren, ERP-Schnittstellen-Effizienz. Und natürlich unsere Service-Seiten zu Magento-Entwicklung, Magento-Schnittstellen und Cloud-Exit.
