Shopware auf AWS hosten: Was zum verlässlichen Betrieb dazugehört und welche Kosten entstehen
Shopware-AWS-Hosting für Händler: Wann es passt, welche Kosten neben der Cloud-Rechnung entstehen und wer Updates, Backups und laufenden Betrieb übernimmt.
Stell dir vor, dein Werkzeughandel plant eine Aktion für Stammkunden. Der Newsletter geht Dienstag raus, gleichzeitig läuft der Import der neuen Herstellerpreise. Du willst wissen: Trägt der Shop das, wer schaut an dem Tag hin und was kostet die zusätzliche Leistung?
„Der Shop läuft auf AWS“ beantwortet keine dieser Fragen. Amazon Web Services, kurz AWS, stellt unter anderem Server, Datenbanken und Speicher bereit. Jemand muss daraus eine passende Umgebung für deinen Shop bauen, sie betreiben und die Kosten im Blick behalten.
Bei PoloProfi setze ich AWS für einen Shopware-Shop mit einem WordPress-Ratgeber ein. Das ist für mich ein Praxisbeispiel, kein Beweis dafür, dass jeder Shop in die Cloud gehört. Hier geht es darum, wann Shopware-AWS-Hosting sinnvoll ist, was du dabei bezahlst und welche Aufgaben trotzdem bei Menschen bleiben.
Für dich als Unternehmer
AWS ist eine Betriebsentscheidung, kein Gütesiegel. Auch ein großer oder stark genutzter Shop kann bei einem spezialisierten Shopware-Hoster gut aufgehoben sein. Ein eigener AWS-Aufbau ist nicht automatisch schneller, günstiger oder verlässlicher.
Einen eigenen AWS-Aufbau würde ich prüfen, wenn du die Umgebung gezielter steuern musst, als es dein vorhandenes Hosting erlaubt. Zum Beispiel, wenn Importe eigene Rechenleistung bekommen sollen, ohne die Bedienung des Shops auszubremsen. Große Importe oder viele Besucher allein sind noch kein Grund für einen Wechsel. Entscheidend ist, ob die zusätzliche Kontrolle ein konkretes Problem löst. Dafür steigt der Aufwand, die technischen Bausteine aufeinander abzustimmen.
Die Cloud-Rechnung ist nur ein Teil der Kosten. Ich würde ein Hosting-Angebot nie allein an der monatlichen Serverposition vergleichen. Für einen fairen Vergleich gehören mindestens diese Bereiche auf den Tisch:
| Kostenbereich | Was dahintersteckt |
|---|---|
| Laufende Infrastruktur | Rechenleistung, Datenbank, Zwischenspeicher, Medien und Netzwerk |
| Nutzung | Datenübertragung, Anfragen und gespeicherte Protokolle, abhängig vom Aufbau |
| Absicherung und Test | Backups, Überwachung und eine Umgebung zum Prüfen von Änderungen |
| Einrichtung und Umzug | Infrastruktur aufbauen, Daten übertragen und den Wechsel vorbereiten |
| Laufender Betrieb | Updates, Fehlerbearbeitung, Livegänge und Kostenkontrolle |
| Weitere Verträge | Shopware-Lizenzen und Erweiterungen, soweit sie für den Shop benötigt werden |
Ein Teil der Infrastruktur kostet auch dann Geld, wenn nachts niemand bestellt. Andere Kosten wachsen mit der Nutzung. Automatisch mehr Leistung bereitzustellen kann eine Lastspitze abfangen, erhöht aber gegebenenfalls die Rechnung.
Eine belastbare Schätzung braucht deshalb den Katalogumfang, die vorhandenen Schnittstellen, typische Nutzung und geplante Spitzen. Ich würde mir dazu zwei Kostenschätzungen zeigen lassen: für einen normalen Monat und für einen Monat mit einer größeren Aktion. Beides sind Annahmen, die später mit den tatsächlichen Kosten verglichen werden müssen.
Zuständigkeit und Erreichbarkeit müssen konkret sein. Wer spielt Shopware-Updates ein? Wer untersucht einen fehlgeschlagenen Import? Wer entscheidet, ob zusätzliche Kapazität freigegeben wird? Und zu welchen Zeiten reagiert jemand auf eine Störung?
Ein AWS-Account beantwortet das nicht. Auch ein Alarm ist noch keine Rufbereitschaft. Leistungsumfang und Reaktionszeiten gehören ausdrücklich vereinbart. Ebenso muss klar sein, wer übernimmt, wenn die erste Ansprechperson nicht weiterkommt.
Ein eigener AWS-Account erleichtert einen Dienstleisterwechsel. Bei PoloProfi läuft die Infrastruktur in einem eigenen AWS-Account für diesen Shop. Die Trennung hilft dabei, Zugänge, Kosten und technische Ressourcen eindeutig zuzuordnen. Für einen späteren Dienstleisterwechsel braucht es zusätzlich dokumentierte Konfigurationen, Berechtigungen und Betriebsabläufe. Ein eigener Account allein ersetzt keine saubere Übergabe.
Wann ich dir davon abrate. Wenn dein vorhandenes Hosting die Anforderungen erfüllt, Änderungen verlässlich laufen und die Zuständigkeiten geklärt sind, würde ich nicht allein wegen des Namens AWS umziehen. Auch ein kleines Hosting-Budget und der Wunsch nach möglichst wenig Betriebsaufwand sprechen eher für ein passendes Standardangebot.
Ich würde AWS dann prüfen, wenn die zusätzliche Kontrolle ein konkretes Problem löst und jemand den dauerhaften Betrieb übernehmen kann. Erst die Anforderungen, dann die Architektur.
Für dich, wenn du den Shop im Alltag betreust
Aktionen und Importe gemeinsam planen. Wenn der Newsletter zusätzliche Besucher bringt und gleichzeitig neue Preise importiert werden, konkurrieren mehrere Aufgaben um Ressourcen. Dein Team kennt die Termine und Datenmengen. Der technische Betrieb muss daraus ableiten, was vorher getestet oder zeitlich getrennt werden sollte.
Bei einer geplanten Aktion würde ich nicht nur die Startseite aufrufen. Suche, große Warenkörbe und die Ermittlung der Kundenpreise gehören dazu, gerade wenn dafür die Warenwirtschaft angesprochen wird. Zusätzliche Webserver helfen wenig, wenn die Preisabfrage im anderen System der Engpass ist.
Änderungen zuerst prüfen, dann veröffentlichen. Eine Testumgebung gibt deinem Team einen Ort, an dem es neue Funktionen, Updates und geänderte Produktdarstellungen vor dem Livegang prüfen kann. Welche Prüfungen nötig sind, hängt von der Änderung ab: bei einem Zahlungs-Plugin andere als bei einem neuen Menüpunkt.
Vor dem Livegang sollte feststehen, wer aus deinem Team die betroffenen Abläufe prüft und die Änderung freigibt. Danach wird kontrolliert, ob sie auch im laufenden Shop funktionieren. Bei PoloProfi werden Änderungen über einen automatisierten Ablauf veröffentlicht. Das macht die Schritte wiederholbar, ersetzt aber nicht diese Prüfungen durch dein Team.
Vorab klären, wie schnell der Shop wieder laufen muss. „Es gibt ein Backup“ ist erst der Anfang. Für deinen Betrieb zählt, wie viele neue Bestellungen im Fehlerfall fehlen könnten und wie lange der Shop bis zur Wiederherstellung ausfallen darf. Davon hängen Sicherungsrhythmus, Aufbewahrung und Aufwand ab.
Diese Grenzen würde ich gemeinsam mit deinem Team und dem technischen Betrieb festlegen. Ob sie eingehalten werden können, muss durch einen Wiederherstellungstest geprüft werden.
Für deine Entwickler oder IT
Kapazität dort erweitern, wo die Last entsteht. Bei PoloProfi laufen Webanwendung, Hintergrundverarbeitung und geplante Aufgaben als getrennte Dienste auf Amazon Elastic Container Service, kurz ECS. Dieser AWS-Dienst betreibt die Anwendung in Containern, also abgegrenzten Laufzeitumgebungen mit der benötigten Software. Der Webdienst kann innerhalb festgelegter Grenzen automatisch zusätzliche Anwendungsinstanzen starten. Das ist kein unbegrenztes Skalierungsversprechen: Datenbank, Cache, Schnittstellen und Anwendung müssen die zusätzliche Last ebenfalls verarbeiten können.
Infrastruktur nachvollziehbar beschreiben. Die AWS-Ressourcen werden als Code verwaltet: Aufbau und Einstellungen der technischen Umgebung sind in Dateien beschrieben, deren Änderungen nachvollziehbar gespeichert werden. Änderungen an der Umgebung lassen sich dadurch vor der Umsetzung prüfen. Das hilft beim Aufbau von Testumgebungen und bei einer Übergabe. Welche Teile redundant ausgelegt werden und welche Unterbrechungen bei Wartung vertretbar sind, muss trotzdem bewusst entschieden werden. Daraus ergeben sich unterschiedliche Kosten.
Kosten und Leistung zusammen beobachten. Budgets und Kostenwarnungen helfen, Abweichungen zu erkennen. Sie sind keine automatische Ausgabensperre. Für die Bewertung gehören Kosten und technische Signale zusammen: Steigt die Rechnung wegen zusätzlicher Bestellungen, eines großen Imports oder einer fehlerhaften Dauerschleife? Auch Aufbewahrungszeiten für Logs, ungenutzte Testressourcen und Skalierungsgrenzen brauchen regelmäßige Kontrolle.
Eine Änderung zurücknehmen ist nicht dasselbe wie den Shop wiederherstellen. Bei einem Rollback wird eine vorherige Anwendungsversion wieder eingesetzt. Dadurch werden Änderungen an der Datenbank nicht automatisch rückgängig gemacht. Datenbankmigrationen, also Änderungen an der Datenbankstruktur oder bestehenden Daten, brauchen deshalb einen eigenen Plan, gerade wenn währenddessen neue Bestellungen eingehen. Ein automatisierter Veröffentlichungsablauf sollte nicht pauschal versprechen, dass sich jede Änderung mit einem Knopfdruck zurücknehmen lässt.
Für die Wiederherstellung müssen neben der Datenbank auch die benötigten Dateien und Konfigurationen berücksichtigt werden. Bei PoloProfi laufen tägliche Datenbanksicherungen. Der vollständige Wiederherstellungstest steht noch aus. Damit ist noch nicht nachgewiesen, dass sich der gesamte Shop aus den vorhandenen Sicherungen wiederherstellen lässt.
Als technischen Einblick für deine IT beschreibe ich in Shopware-Monitoring auf AWS: Dashboards und Alarme am Praxisbeispiel, welche Signale ich bei PoloProfi erfasse, wie ich Fehler untersuche und welche Prüfungen noch offen sind.
Wie wir das machen
Ich schaue zuerst auf Shop, Schnittstellen, Last und die Arbeit deines Teams. Daraus leite ich ab, welche Umgebung gebraucht wird und wer welche Aufgaben übernimmt. Ein bestehender Shop muss dafür nicht automatisch umziehen.
Welche Leistungen xebro bei Hosting und Betrieb übernimmt, steht auf der Leistungsseite. Den Rahmen findest du in der Paketübersicht. Den grundsätzlichen Unterschied zwischen Hosting und Anwendungsbetrieb erkläre ich in Shopware Hosting für B2B-Händler.
Wenn du deinen eigenen Aufbau einordnen möchtest, ist der Shop-Selbsttest ein erster Einstieg ohne Termin.