Ein präzises dreistöckiges Architekturmodell auf Beton — unten ein Walnussblock, mittig eine gebürstete Messingplatte mit feinen Rillen, oben eine kleine wachsversiegelte Kraftpapierbox; ein oxblutfarbener Faden zieht senkrecht durch alle Schichten. Daneben ein kleines Messing-Architektenlineal und ein geschlossenes ledernes Notizbuch im kühlen Nordlicht.
28. April 2023 · Kai Ole Hartwig

Warum wir auf AWS setzen

Amazon Web Services als Hosting-Partner für Enterprise-Anforderungen.

Hosting ist die langweiligste Entscheidung in einem Web-Projekt — bis sie schiefgeht. Dann wird sie die teuerste. Wir haben in den letzten zwei Jahren bewusst die Bequemlichkeits-Entscheidungen reduziert und auf Amazon Web Services konsolidiert, und in diesem Beitrag beschreibe ich, warum.

Warum nicht Hetzner oder Bare Metal?

Die ehrliche Antwort zuerst: Hetzner und vergleichbare Provider sind pro CPU-Stunde fast immer günstiger als AWS. Wer ausschließlich Strompreis und Bandbreite rechnet, kommt nicht auf AWS. Wir rechnen aber den vollen Lebenszyklus eines Setups: Auto-Healing nach einem Node-Ausfall, Backups mit definierter Restore-Zeit, Verschlüsselung auf Storage- und Netzwerk-Ebene, automatisches Patching der Datenbank, Audit-Logs, die einem späteren Penetration-Test standhalten.

All das ist auf Hetzner machbar — kostet aber Engineering-Zeit, die wir lieber in die Anwendung unserer Kunden stecken. Auf AWS ist es eingebaut, getestet und dokumentiert. Bei einem mittelständischen TYPO3-Setup ist diese Differenz oft die Hälfte der Total-Cost-of-Ownership, und sie wird erst sichtbar, wenn etwas kaputtgeht.

Skalierbarkeit als Eigenschaft, nicht als Versprechen

Skalierbarkeit liest sich auf jedem Anbieter-Slide ähnlich. Praktisch ist sie eine Eigenschaft der konkreten Services. Wir setzen für TYPO3- und Symfony-Anwendungen typischerweise auf eine von zwei Compute-Topologien — EC2-Instanzen in einer Auto-Scaling-Group für Kunden mit klassischem Hosting-Mindset, oder Amazon EKS für Kunden mit eigener Kubernetes-Kompetenz im Haus. In beiden Fällen liegt Amazon RDS for MySQL als verwaltete Datenbank dahinter, CloudFront vor den statischen Assets und dem HTTP-Caching. Beide Topologien skalieren in beide Richtungen ohne nächtliche Eingriffe: Wenn eine Marketing-Kampagne anläuft, fährt die Auto-Scaling-Group neue Instanzen hoch oder der Horizontal Pod Autoscaler zusätzliche Pods; wenn der Lastpeak vorbei ist, gehen sie wieder weg.

Wichtiger als die maximale Skalierung ist für uns die untere Grenze. Wir konfigurieren die Auto-Scaling-Group bzw. den Horizontal Pod Autoscaler so, dass sie über Nacht und am Wochenende auf eine Minimal-Konfiguration herunterfahren, die den Morgens-Burst noch auffängt. Auf der Datenbankseite reservieren wir die RDS-Instanzgröße für die regelmäßige Tages-Spitze, nicht für den Worst Case — die seltenen Ausreißer fängt die Anwendung über CloudFront-Caching ab.

Sicherheit als geliefertes Fundament

Beim Thema Sicherheit unterschätzen viele Teams, wie viel ein Cloud-Anbieter heute mitbringt — und wie viel sie bei einem klassischen Root-Server selbst hochziehen müssten. AWS liefert Verschlüsselung at-rest über KMS, Verschlüsselung in-transit über ACM-verwaltete Zertifikate, granulare Berechtigungen über IAM und eine kontinuierliche Konformitätsprüfung über AWS Config. Wer eine ISO-27001-konforme Plattform betreiben will, hat einen Großteil der technischen Maßnahmen ab Tag eins erfüllt.

Konkret betreiben wir alle Workloads in der Region Frankfurt (eu-central-1), schließen den Auftragsverarbeitungsvertrag direkt mit AWS Europe SARL ab und protokollieren Zugriffe lückenlos über CloudTrail. Für unsere Kunden bedeutet das, dass eine DSGVO-Prüfung nicht in einem Audit-Marathon endet, sondern in einer ablesbaren Dokumentation.

Eine Nebenbemerkung zum Schluss: Sicherheit auf AWS ist kein Selbstläufer. Falsche IAM-Policies sind eine reale Risiko-Klasse. Wir reviewen Berechtigungen mindestens halbjährlich, deaktivieren ungenutzte Accounts und arbeiten konsequent mit Rollen statt mit Long-Lived-Keys. Das ist Disziplin, kein Feature.

Kosteneffizienz, wenn man rechnet

AWS hat einen Ruf, teuer zu sein. Das stimmt für den Listenpreis, und es stimmt nicht für den Effektivpreis, wenn man die verfügbaren Hebel nutzt. Drei Hebel ziehen den größten Effekt.

Graviton-Instanzen. Graviton ist eine ARM64-Prozessorfamilie aus AWS-eigener Entwicklung. In unseren Lasttests liefert sie rund 20 Prozent mehr Performance bei etwa 20 Prozent niedrigerem Preis als die vergleichbaren Intel- und AMD-Instanzen auf x86_64-Basis. Für PHP-Workloads ist die Umstellung in der Regel ein neuer AMI- oder Container-Image-Build, in den allermeisten Fällen ohne Code-Änderungen. Wir nutzen Graviton standardmäßig, außer ein Drittanbieter-Tool zwingt uns auf x86.

Reserved Instances und Savings Plans. Wer absehbar produktive Workloads ein Jahr oder drei Jahre betreibt, bekommt darauf 30 bis 50 Prozent Rabatt. Wir entkoppeln die Reservierung von der konkreten Instanzform über Compute Savings Plans — damit bleibt die Architektur veränderbar, ohne dass Rabatte verloren gehen.

EC2 Spot Instances für Hintergrundjobs. Cron-Jobs, Bildkonvertierungen, Reports — alles, was unterbrochen und neu gestartet werden darf, läuft auf EC2 Spot Instances zu rund 30 Prozent des regulären On-Demand-Preises. Voraussetzung ist eine saubere Job-Idempotenz, was ohnehin guter Engineering-Hygiene entspricht.

Wir bauen für jeden Kunden ein dediziertes Cost-Dashboard und ein Cost-Anomaly-Alert. Eine versehentlich offen gelassene EC2-Instanz in einer Test-Region oder ein durchdrehender Loop fällt damit innerhalb von Stunden auf, nicht erst auf der nächsten Monatsrechnung.

Wie ein typischer TYPO3-Stack bei uns aussieht

Damit das nicht abstrakt bleibt, hier die Architektur, die wir derzeit für mittelständische TYPO3-11-LTS-Plattformen (und die ersten Pilot-Setups auf der kommenden v12) ausrollen:

Die Infrastruktur dieses Stacks lebt als Terraform-Modul im Kundenrepository und wird über GitLab CI ausgerollt. Eine neue Umgebung — Staging, Demo, Integration — ist damit eine Frage von Minuten, nicht von Wochen.

Was wir aus dem Betrieb gelernt haben

Drei Beobachtungen aus dem Tagesgeschäft, die auf keinem Anbieter-Slide stehen.

Multi-AZ zahlt sich nicht im Notfall aus, sondern beim Patch. RDS Multi-AZ ist nicht primär ein Schutz gegen ein ausgefallenes Rechenzentrum — das passiert in Frankfurt selten — sondern erlaubt uns, Minor- und Major-Upgrades der Datenbank über ein Failover-Fenster von wenigen Sekunden zu fahren. Diese Property haben wir auf einem klassischen Root-Server schlicht nicht.

IAM-Disziplin ist eine Investition mit verzögerter Auszahlung. Die ersten drei Monate, in denen man konsequent mit Rollen, eng gefassten Policies und Permission-Boundaries arbeitet, fühlen sich nach Mehraufwand an. Ab dem dritten Vorfall, in dem ein Kollege keine Long-Lived-Keys in den falschen Slack-Channel kopiert hat, ist die Auszahlung sichtbar.

Cost-Surprises kommen aus Datenausgang, nicht aus Rechenleistung. Die größten unerwarteten Posten auf einer AWS-Rechnung sind in der Regel kein Compute, sondern Data-Transfer aus AWS heraus. Wer CloudFront korrekt vor das Frontend setzt, hält den teuren Egress klein. Wir prüfen das auf jedem neuen Projekt aktiv.

Fazit

AWS ist nicht die richtige Wahl, wenn der einzige Hebel der Stundenpreis einer kleinen virtuellen Maschine ist. Wer eine TYPO3-Plattform mit produktiver Last, ernsthaften Backup-Anforderungen und einer planbaren DSGVO-Position betreiben will, kommt heute mit AWS strukturell weiter als mit klassischem Webhosting. Genau diese Kunden begleiten wir — von der Architekturentscheidung bis zum laufenden Betrieb.