Wofür wir AWS einsetzen
AWS kommt ins Spiel, wenn die Anforderung es begründet. Ein Shop mit Zielgruppen in mehreren Ländern profitiert von Auslieferung nahe am Nutzer. Eine Kampagne, die Last in Stunden statt Monaten erzeugt, braucht Kapazität, die danach wieder verschwindet. Konzernkunden geben die Plattform teilweise vor — dann bauen wir dort. Und manchmal ist es ein einzelner verwalteter Dienst, der den Ausschlag gibt, etwa eine Datenbank mit automatischem Failover.
Typische Bausteine in unseren Projekten: EC2 oder ECS für die Anwendung, RDS für MariaDB oder PostgreSQL, S3 für Medien und Backups, CloudFront für die Auslieferung, Route 53 für DNS. Dazu ElastiCache, wenn Valkey oder Redis verwaltet laufen sollen, und SES für Transaktionsmails. Alles in europäischen Regionen, meist Frankfurt. Häufig ist AWS auch nur ein Teil: die Anwendung bei uns, einzelne Dienste dort — oder umgekehrt.
Wie wir AWS-Umgebungen aufbauen und betreuen
Infrastruktur beschreiben wir als Code, mit Terraform oder CloudFormation, statt sie in der Konsole zusammenzuklicken. Das ist kein Selbstzweck: Eine geklickte Umgebung kann niemand nachvollziehen und im Ernstfall auch niemand schnell wieder aufbauen. Rechte vergeben wir über IAM nach dem Prinzip der kleinsten nötigen Berechtigung, getrennt nach Konten für Test und Produktion. Netzwerk, Sicherheitsgruppen und Zertifikate gehören zum Aufbau, nicht zur Nacharbeit.
Zur Betreuung gehört die Rechnung. Wir richten Budgets und Alarme ein, prüfen regelmäßig, welche Ressourcen tatsächlich gebraucht werden, und schalten ab, was nur noch aus Gewohnheit läuft. Datenschutz klären wir vorab: europäische Regionen, Auftragsverarbeitungsvertrag, Verschlüsselung im Speicher und auf dem Transportweg. Für den Datenschutzbeauftragten Ihres Hauses liefern wir die technischen Angaben, die er für sein Verzeichnis braucht. Support läuft nach individuell vereinbarten SLA.
Grenzen und Alternativen
Der Standard des Hauses ist die eigene Proxmox-Infrastruktur, Serverstandort Deutschland. Für planbare Lasten ist sie meist wirtschaftlicher und vollständig unter eigener Kontrolle. Elastizität kostet Geld, auch wenn niemand sie abruft — und die meisten Mittelstandsprojekte haben einen Lastverlauf, der sich seit Jahren kaum ändert. Wer eine feste Grundlast in einer Umgebung betreibt, die für ein Vielfaches ausgelegt ist, zahlt Bereitschaft statt Leistung.
Dazu kommt der Bindungseffekt. Je tiefer eine Anwendung in verwaltete Dienste hineinwächst, desto aufwendiger wird ein späterer Umzug. Das kann richtig sein — man sollte es nur entscheiden und nicht hineinrutschen. Wir empfehlen den Weg, der zum Projekt passt, nicht den, der mehr Rechnungsposten erzeugt. Wenn AWS die bessere Antwort ist, bauen wir dort. Wenn nicht, sagen wir das vor dem Angebot und nicht nach der ersten Abrechnung.