Cloud-Kosten: Wo Agenturen unnötig Geld verbrennen
Cloud klingt bequem. Schnell gebucht, alles schick. Bis die Kosten anziehen – mehr Traffic, mehr Speicher, kleine Extras wie Failover. Plötzlich wird aus der vermeintlichen Sparlösung ein Kostenfresser. Typisch: Projekte mit ein paar Tausend bis vielleicht zwanzigtausend Nutzern landen trotzdem im Managed-Cloud-Tarif, weil keiner nachts wegen Ausfall aufstehen will. Verstehe ich. Aber: Die Angst vor selbstgebauten Setups ist oft größer als nötig.
Problem dabei: Startet ein Projekt erst mal bei AWS, Azure & Co, gibt es später beim Skalieren oder für Redundanz die Quittung. Lock-in. Features, die nie jemand braucht, stehen brav auf der Rechnung. Preissteigerungen inklusive. Dabei gehen viele Anforderungen auch ohne große Cloud-Ketten – und das mit überschaubarem Aufwand. Flexibler, kontrollierbarer und meistens günstiger.
Edge-Server plus kleine Cloud-Instanzen – was ist das eigentlich?
Edge-Hosting heißt: Server stehen verteilt, möglichst nah an den Nutzern. Kein zentraler Klotz in Frankfurt, sondern zwei, drei Server in verschiedenen Rechenzentren. Für Agenturen meist: Ein, zwei dedizierte Kisten bei Hetzner, Netcup oder OVH, dazu vielleicht noch eine kleine Cloud-VM. Wichtig: Standorte und Routing – nicht das „Cloud“-Label auf dem Angebot.
Typischer Aufbau: Zwei bis vier Server, synchronisiert. DNS-Routing oder ein Load Balancer (z.B. HAProxy) verteilt die Anfragen. Wer ausfällt, fliegt raus, der Rest übernimmt. VPS, Root-Server, kleine Clouds – geht alles, solange die Koordination stimmt.
Welche Technik braucht’s?
- Lastverteilung: Load Balancer (HAProxy, nginx) oder DNS-Round-Robin. Health Checks schalten bei Ausfall automatisch um.
- Datenbank-Replikation: Ohne Abgleich geht’s nicht. MySQL-Master/Slave oder Galera-Cluster funktionieren auch auf kleinen Maschinen, solange sauber konfiguriert.
- Monitoring & Failover: Prometheus, Zabbix oder ein paar Shell-Skripte reichen oft schon. Automatisierte DNS-Updates oder Failover-Skripte bringen die Seite in Minuten wieder hoch.
- Statische Inhalte: CDN oder Edge-Caching für Bilder, JS, CSS. Oder einfach Assets regelmäßig auf alle Server kopieren.
- Automatisierung: Ansible, Terraform oder Bash-Skripte – ohne Automatisierung wird’s schnell chaotisch, gerade bei Updates auf mehreren Standorten.
Praxis: Agentur-Setup ohne Cloud-Ballast
Beispiel, wie’s laufen kann: Agentur mit mehreren Standorten und Kunden in Deutschland. Drei Server in getrennten Rechenzentren. DNS-Routing verteilt die Nutzer auf den jeweils erreichbaren und nächsten Server. Datenbank als Galera-Cluster, Änderungen in Sekunden überall. Kostenersparnis? Ungefähr die Hälfte im Vergleich zum Cloud-Vollpaket. Pflege läuft über ein paar Skripte für Backups, Updates und Failover – kein Hexenwerk, aber solide Handarbeit. Funktioniert.
Meine Einschätzung nach fast 30 Jahren Webentwicklung
In Projekten bis mittlerer Größe funktioniert der Ansatz. Cloud-Dienste sind bequem, keine Frage. Aber oft bezahlt niemand für 24/7-Redundanz, sondern für Komfort und Features, die nie genutzt werden. Wer weiß, wie man ein Monitoring konfiguriert und Failover testet, kann mit eigenen Edge-Servern eine Menge sparen. Und hat Kontrolle – auch über Updates und Datensicherung.
Agenturen mit fünf bis zehn Leuten: Klar, mehr Verantwortung. Aber mit Ansible oder Terraform bleibt der Aufwand überschaubar, solange die Abläufe stimmen. Server kosten meist weniger als Managed-Cloud, gerade bei dedizierten Kisten oder günstigen VPS. Wichtig: Automatisierung für Backups, Updates, Failover – sonst gibt’s Stress, wenn nachts was knallt.
Eigene Edge-Architektur aufsetzen – was tun?
- Vorhandene Infrastruktur analysieren: Was läuft, wie viel Traffic?
- Rechenzentren passend zu Kunden wählen
- Load Balancer oder DNS-Routing einbauen
- Datenbank-Replikation planen, testen, nochmal testen
- Automatisierung für Deployments, Monitoring, Backups
- Failover regelmäßig üben (ernsthaft: regelmäßig)
- Laufende Kosten gegen Cloud-Angebote rechnen
Was nicht verschwiegen werden sollte: Risiken und Grenzen
Wer alles selbst macht, trägt das Risiko. Komplexe Anwendungen, dynamische Lastspitzen, internationaler Traffic – wird schnell anspruchsvoll. Fehler bei der Replikation, vergessene Backups, fehlende Tests: teuer. Sicherheit an mehreren Standorten muss sitzen. Keine Ausreden, keine Schlamperei.
Bei massiver Last oder globalem Publikum kommt der Eigenbau an Grenzen. Manchmal ist die große Cloud dann doch die bessere Wahl. Nicht jedes Kundenprojekt taugt fürs Basteln. Manchmal ist Service billiger als ständiges Gefrickel.
Edge-Hosting 2026: Was sich geändert hat
Immer mehr Tools machen verteilte Setups auch für kleine Teams praktikabel. Wer heute umsteigt, ist für die nächsten Jahre gewappnet. IPv6, neue Netzwerk-Features (siehe IPv6 2026: Ohne den neuen Standard läuft im Hosting nichts mehr) – wird alles wichtiger. Wer da früh Erfahrung sammelt, hat später weniger Stress.
Kurz: Wer sich traut, spart. Wer nicht, zahlt.
Nicht nur Cloud kann hochverfügbar. Mittelgroße Agenturen sparen oft mit eigenen Edge-Servern, wenn Planung und Tools passen. Erfahrung, saubere Automatisierung und Bereitschaft, sich um die eigene Infrastruktur zu kümmern, zahlen sich aus. Wer mehr wissen will (gerade zu PHP-Setups): Warum klassische PHP-Architektur 2026 oft die bessere Wahl ist.
bye
mo