Anfang 2026 kam ein österreichischer B2B-Händler mit einer AWS-Rechnung zu uns, die er nicht mehr erklären konnte. Magento 2 lief dort nach Lehrbuch: ECS für die Container, Aurora als Datenbank, S3 für Medien, CloudFront davor. Technisch sauber, wirtschaftlich ein Problem. Sieben Wochen später lief derselbe Shop auf einem dedizierten Server in Österreich — bei rund 10 % der bisherigen Hosting-Kosten. Dieser Artikel zeigt, wo die Kosten bei Magento 2 Cloud-Hosting tatsächlich entstehen, wie sich AWS, Managed Hosting und ein eigener gemanagter Server im TCO unterscheiden, und woran du erkennst, welches Modell zu deinem Shop passt.
Wo die Kosten bei Magento auf AWS wirklich entstehen
Der häufigste Denkfehler: Man vergleicht die AWS-Rechnung mit dem Monatspreis eines Hosters. Beides sind nicht dieselben Zahlen. Und der größte Posten ist nicht der, den die meisten vermuten.
Eine typische AWS-Magento-Installation für einen mittelgroßen B2B-Shop — ECS Fargate, RDS Aurora, S3, CloudFront, NAT Gateway, ELB — liegt nach unserer Erfahrung bei 800 bis 1.500 EUR im Monat. Der dominierende Anteil daran ist weder Egress noch Cloud-Overhead. Es ist schlicht die Tatsache, dass Magento in der Cloud in ein halbes Dutzend Einzeldienste zerfällt — und jeder einzelne davon eine Mindestgröße hat und rund um die Uhr läuft.
Magento braucht nicht einen Dienst, sondern diese: Application-Container für PHP-FPM, eine Datenbank, Valkey für Sessions und Cache, OpenSearch für die Katalogsuche, Object Storage für Medien, dazu Queue und Load Balancer. Auf einem Server ist das eine Maschine, auf der sich diese Prozesse die vorhandenen Reserven teilen. In der Cloud ist jeder davon ein eigener Managed Service mit eigenem Grundpreis.
Und dieser Grundpreis ist der Punkt: Du zahlst nicht für Verbrauch, sondern für Vorhaltung. Eine ElastiCache-Node kostet den vollen Node-Preis, ob Valkey nun 200 MB oder 2 GB belegt. OpenSearch will mindestens einen Knoten, für Ausfallsicherheit eher drei — auch für einen Katalog, den ein einzelner Prozess nebenbei bedienen würde. Aurora läuft durch. Nachts um drei, wenn kein einziger Request hereinkommt, tickt jede dieser Positionen weiter und berechnet das Minimum ihrer kleinsten Ausbaustufe.
| Magento-Komponente | In der Cloud | Auf einem dedizierten Server |
|---|---|---|
| PHP-FPM / Webserver | eigener Container-Dienst, Mindestgröße | Prozess auf der Maschine |
| Datenbank | eigene Instanz, läuft 24/7 | Prozess auf der Maschine |
| Valkey (Session, Cache) | eigene Node, voller Node-Preis | ein paar hundert MB RAM |
| OpenSearch | eigener Cluster, min. 1 Knoten | Prozess auf der Maschine |
| Medien-Storage | Storage plus Egress pro GB | Platte im Server |
| Queue, Load Balancer | je eine eigene Position | Prozess bzw. entfällt |
| Summe im Leerlauf | jede Zeile kostet einzeln | eine Rechnung |
Genau hier entsteht die Lücke, aus der die rund 90 Prozent Ersparnis kommen. Nicht, weil dedizierte Hardware pro CPU-Kern so viel billiger wäre — sondern weil ein Server die Leerlauf-Reserven aller Dienste gemeinsam vorhält, statt sie einzeln zu berechnen.
An dieser Grundlast lässt sich immerhin schrauben, ohne die Architektur anzufassen: Valkey-Nodes sind bei ElastiCache spürbar günstiger als die entsprechenden Redis-Nodes — AWS nennt bis zu 20 Prozent. Das ändert nichts am Prinzip, dass du Vorhaltung bezahlst. Es senkt nur den Preis pro vorgehaltener Position.
Egress kommt obendrauf, ist aber selten der Haupttreiber: Produktbilder aus S3 und Asset-Aufrufe über CloudFront werden pro GB abgerechnet, was bei bildlastigen B2B-Katalogen einen dreistelligen Betrag pro Monat ausmachen kann. Dasselbe gilt für die Cloud-spezifischen Konstrukte — NAT Gateway, Load Balancer, CloudWatch-Logs, Cross-AZ-Traffic. Ärgerlich, weil es den Shop nicht schneller macht. Aber es erklärt nicht die Größenordnung.
Und dann ist da noch der Posten, den kaum jemand in die Rechnung aufnimmt: DevOps-Zeit. Eine Änderung an der Infrastruktur läuft über IAM-Policies, Terraform-State und ECS-Task-Definitions. Was auf einem klassischen Server zehn Minuten dauert, kostet in einem sauber gebauten AWS-Setup regelmäßig mehrere Stunden. Über ein Jahr gerechnet ist das oft der größte Einzelposten.
Das Skalierungs-Paradox
AWS skaliert nach oben hervorragend. Traffic-Spitze, neue Container, fertig. Klingt großartig.
Aber: Wer nach unten skaliert, um Kosten zu sparen — und das passiert bei B2B-Shops zwangsläufig, weil nachts und am Wochenende niemand bestellt —, kauft sich Kaltstarts ein. Der erste Request nach einer ruhigen Phase muss auf den Container warten, auf die DB-Connection, auf einen warmen OPcache. Genau dieser Request ist der, den ein Einkäufer um 8:15 Uhr erlebt. Auf einem dedizierten Server gibt es das Problem nicht, weil der Server einfach läuft. Immer, mit derselben Antwortzeit.
Ein zweiter Punkt betrifft Magentos Architektur direkt: Magento ist auf DB-Latenz unter 1 ms optimiert. Public-Cloud-Setups trennen App und Datenbank häufig so weit, dass Magento-typische Query-Kaskaden spürbar langsamer werden. Das ist kein Qualitätsproblem von Aurora — es ist ein Architektur-Mismatch.
Managed Hosting: was der Fixpreis tatsächlich abdeckt
Managed-Hosting-Anbieter verkaufen keine nackte Infrastruktur, sondern einen vorkonfigurierten Stack. Bei einem Magento-tauglichen Angebot bedeutet das konkret: Nginx, PHP-FPM mit OPcache, Varnish als Full-Page-Cache, Valkey für Sessions und Cache, eine auf Magento getunte MariaDB, OpenSearch für die Katalogsuche. Dazu Monitoring, Backups auf separatem Storage und eine Staging-Umgebung.
Ein Wort zu Valkey, weil in vielen Setups noch Redis steht: Nachdem Redis im März 2024 auf eine restriktivere Lizenz wechselte, entstand Valkey als Fork von Redis 7.2.4 unter dem Dach der Linux Foundation, BSD-lizenziert. Der Umstieg ist unspektakulär — Valkey spricht dasselbe Protokoll, Magento kommuniziert also unverändert weiter, und bei AWS bleibt bei einem In-Place-Upgrade sogar der Endpunkt gleich. Ein praktischer Stolperstein: Wer den Remote-Synchronized-Cache (L2) nutzt, sollte auf Magento 2.4.7-p5 oder neuer sein — ältere Patch-Stände quittieren die Valkey-Konfiguration mit einem Deployment-Fehler.
Der wirtschaftliche Hebel liegt weniger im Hardwarepreis als in dem, was nicht anfällt. Kein Terraform-Modul für den Full-Page-Cache, keine eigene Alerting-Pipeline, keine Diskussion darüber, wer die Security-Patches einspielt. Genau so setzen wir unser Magento-Hosting auf: eigene dedizierte Server in Rechenzentren in Wien und Deutschland, Stack auf den jeweiligen Shop getunt, Pflege inklusive.
Ehrlich bleiben gehört dazu: Managed Hosting hat Grenzen. Wer echte globale Traffic-Verteilung mit automatischer Kapazitätsanpassung braucht, wer tief in Lambda, SageMaker oder andere AWS-Dienste integriert ist, oder wer B2C-Spitzen fährt, die um den Faktor 20 auseinanderliegen, ist in der Public Cloud richtig aufgehoben. Nur: Das trifft auf die wenigsten Magento-Shops im Mittelstand zu.
Bot-Traffic — der Kostentreiber, den kaum jemand einplant
Crawler, Preisvergleichs-Bots und zunehmend auch KI-Agenten fragen Produktdaten, Preise und Verfügbarkeiten permanent ab. Für die Infrastruktur ist das echte Last — nur eben Last ohne Bestellung dahinter.
Der Unterschied zwischen den Hosting-Modellen ist dabei bemerkenswert: Bei verbrauchsbasierter Abrechnung wird Bot-Traffic direkt zu Geld. Auto-Scaling reagiert auf Last, nicht auf Kaufabsicht — es fährt Container hoch, weil jemand deinen Katalog scannt. Bei Fixpreis-Hosting wird derselbe Traffic zu einem Performance-Problem statt zu einem Rechnungsproblem. Beides will man nicht, aber nur eines davon kostet unmittelbar Marge.
Was in der Praxis hilft:
- Full-Page-Cache konsequent nutzen. Ein Bot, der aus Varnish bedient wird, kostet fast nichts. Ein Bot, der PHP und die Datenbank erreicht, kostet spürbar.
- Bot-Regeln am Edge. Rate-Limits und Bot-Erkennung gehören vor den Shop, nicht in Magento. Cloudflare oder eine WAF davor ist der billigste Filter, den es gibt.
- Unterscheiden statt blocken. Nicht jeder Bot ist schädlich — manche bringen Sichtbarkeit und Umsatz. Warum das relevanter wird, haben wir in Agentic Commerce für Magento beschrieben.
robots.txtist keine Schutzmaßnahme. Sie ist eine Bitte. Wer die Last technisch begrenzen will, braucht technische Mittel.
AWS vs. Managed Hosting vs. eigener Server: der TCO-Vergleich
Die relevante Größe ist nicht die Hosting-Gebühr, sondern die Total Cost of Ownership — Infrastruktur plus die Arbeitszeit, die nötig ist, um sie am Laufen zu halten.
| Kriterium | AWS (self-managed) | Managed Hosting (Standard-Paket) | Gemanagter dedizierter Server |
|---|---|---|---|
| Dienste-Grundlast | jeder Dienst eine eigene Mindestgröße, 24/7 | im Paket gebündelt | alle Dienste teilen eine Maschine |
| Abrechnung | verbrauchsbasiert, schwankend | Fixpreis pro Stufe | Fixpreis, planbar |
| Egress / Traffic | separat pro GB | meist im Paket | im Kontingent |
| Personalaufwand | hoch, DevOps-Rolle nötig | gering | gering, Pflege inkludiert |
| Magento-Tuning | selbst zu bauen | Stack-Standard, wenig shopspezifisch | auf den Shop getunt |
| Skalierung | automatisch, nach oben unbegrenzt | stufenweise | Sizing plus Reserve |
| Datenhoheit | Region wählbar, US-Konzern | anbieterabhängig | RZ in AT/DE, klar zuordenbar |
| Passt zu | globalem Traffic, tiefer AWS-Integration | Standard-Shops ohne Sonderlocken | Shops mit planbarer Last und Wartungsbedarf |
Konkret aus dem eingangs erwähnten Projekt: Hosting inklusive Datenbank und Storage ging von vierstellig pro Monat auf niedrig dreistellig, Egress von erheblich auf minimal, Monitoring von Zusatzposten auf inkludiert. Unterm Strich rund 90 % Ersparnis — bei gleicher, in den Antwortzeiten sogar besserer Performance. Den vollständigen Ablauf mit Zielarchitektur, Cutover und Stolpersteinen haben wir in Raus aus der Cloud dokumentiert.
Fünf Hebel, die die Rechnung tatsächlich senken
1. Zähl die Dienste, nicht die CPU-Kerne. Der wirksamste Hebel ist, die Zahl der einzeln berechneten Positionen zu senken. Braucht die Suche wirklich einen eigenen Cluster, oder reicht ein Prozess neben der Anwendung? Muss Valkey eine separate Node sein? Jeder Dienst, der eine eigene Mindestgröße reserviert und nachts durchläuft, kostet unabhängig von seiner Auslastung. Bei planbarer B2B-Last ist eine konsolidierte Maschine fast immer günstiger als eine elastische Umgebung, die dauernd atmet — Auto-Scaling gleicht Unterdimensionierung aus, aber es macht die Grundlast nicht billiger.
2. Cache-Hit-Rate vor Hardware. Bevor du mehr CPU kaufst: schau dir die Varnish-Hit-Rate an. Ein Shop, dessen Kategorieseiten wegen falsch gesetzter Cache-Tags ständig invalidiert werden, verbrennt Rechenleistung an Seiten, die sich nicht geändert haben. Das ist die billigste Optimierung überhaupt, weil sie nichts kostet außer Analyse.
3. Egress und CDN trennt man vom Origin. Assets aus dem teuren Objektspeicher direkt auszuliefern ist der klassische Fehler. Ein CDN davor, ordentliche Cache-Header, Bilder als WebP/AVIF in passenden Größen — damit fällt das ausgelieferte Volumen typischerweise deutlich. Erwarte davon aber keine Halbierung der Rechnung: Egress ist ein Ärgernis, die Grundlast der Einzeldienste ist das eigentliche Geld.
4. Indexer und Cronjobs entzerren. Wenn Vollreindex, ERP-Import und Backup gleichzeitig um 2:00 Uhr starten, dimensionierst du deinen Server für einen Zustand, der 30 Minuten am Tag existiert. Zeitversetzt geplant reicht oft die nächstkleinere Stufe.
5. TCO rechnen, nicht Hosting-Gebühr. Addiere zur Infrastruktur die Stunden, die intern oder extern in Serverpflege, Patches, Monitoring und Störungen fließen. Erstaunlich häufig ist das nominell teurere Angebot in Summe das günstigere — und der Unterschied wird größer, je knapper die Personaldecke ist.
Wann welches Modell passt
Klare Indikatoren für einen Wechsel weg von AWS:
- Monatsrechnung über 500 EUR bei planbarer Last (B2B-Geschäftszeiten, bekannte Saisonalität)
- Performance-Probleme, die sich in der Cloud nur durch größere Instanzen lösen lassen
- DSGVO-Anforderungen, die ein Rechenzentrum in Österreich oder Deutschland verlangen
- Niemand im Team, der die Cloud-Konfiguration wirklich verantwortet
- Egress-Posten, die von Monat zu Monat überraschen
Klare Indikatoren für den Verbleib in der Public Cloud:
- Echte globale Traffic-Verteilung über mehrere Kontinente
- B2C-Lastspitzen, die kaum vorhersehbar sind (Influencer-Kampagnen, Viralität)
- Tiefe Integration mit AWS-Diensten, die sich nicht sinnvoll ersetzen lassen
- Ein vorhandenes DevOps-Team, das die Umgebung ohnehin betreut
Zwischen diesen Polen liegt die Mehrheit der Magento-Shops im deutschsprachigen Mittelstand — und für die ist ein gemanagter, Magento-optimierter Server meistens die wirtschaftlichere Antwort.
Was du als nächstes tun kannst
Wenn du den Verdacht hast, dass dein Hosting mehr kostet als es müsste, gibt es zwei pragmatische erste Schritte:
- Rechne einen Monat sauber durch. Bei AWS über den Cost Explorer, gefiltert auf die Magento-relevanten Services — Compute, Datenbank, Storage, Data Transfer und NAT Gateway getrennt ausweisen. Bei jedem anderen Hoster: Grundgebühr plus alle Zusatzposten plus die intern aufgewendeten Stunden. Erst diese Zahl ist vergleichbar.
- Lass dir die Hosting-Kosten durchrechnen. Wir nehmen den Ist-Zustand auf, dimensionieren die Zielarchitektur und rechnen dir vor, was ein Wechsel konkret spart und was die Migration kostet — in ein bis zwei Wochen, mit Zahlen statt Bauchgefühl. Kontakt: office@copex.io oder kostenloses Erstgespräch.
Verwandte Themen aus unserem Blog: Raus aus der Cloud — AWS-Migration in der Praxis, Magento vs. Shopify: die echte Kostenrechnung, Agentic Commerce für Magento. Und unsere Service-Seiten zu Magento-Hosting, Cloud Exit & AWS-Migration und laufender Betreuung.
Quellen / Weiterlesen
- Amazon ElastiCache for Valkey — Engine-Optionen, Preisunterschied und In-Place-Upgrade-Pfad
- Valkey-Projekt — Fork-Historie, Lizenz und Release-Stände
Die schwierigste Zahl in dieser Rechnung ist übrigens nie die Serverrechnung. Es ist die Zeit, die jemand im Team für Infrastruktur aufwendet, ohne dass sie je auf einem Beleg auftaucht.
