Cloud Infrastruktur für Startups und KMU: der praxisnahe Leitfaden

Cloud Infrastruktur ist mehr als „ein Server in der Cloud". Sie besteht aus Rechenleistung (virtuelle Maschinen, Container, serverlose Funktionen), Speicher (Block-, Objekt- und Datenbank-Storage), Netzwerk (Load Balancer, private Netze, DNS, TLS) und den Diensten, die alles zusammenhalten: Deployment-Pipelines, Secrets-Management, Monitoring und Backups. Für ein Startup ist die entscheidende Frage nicht „welche dieser Bausteine gibt es", sondern „welche brauchen wir jetzt und welche in achtzehn Monaten".

Der häufigste Fehler früher Teams ist, Infrastruktur für eine Skalierung zu bauen, die noch Jahre entfernt ist. Ein Zwei-Personen-Team mit einem Produkt und unter 50.000 Nutzern braucht keinen Multi-Region-Cluster mit Service Mesh. Es braucht eine solide, langweilige Basis: eine oder zwei VMs, eine verwaltete Datenbank, automatisierte Backups und ein Deploy-Skript, das jeder im Team versteht. Genauso teuer wird der umgekehrte Fehler, alles manuell in einer Web-Konsole zusammenzuklicken, ohne dass irgendjemand später nachvollziehen kann, wie der Zustand entstanden ist.

Gute Cloud Infrastruktur zeichnet sich durch drei Eigenschaften aus: Sie ist reproduzierbar (Sie können die gesamte Umgebung aus Code neu erstellen), sie ist beobachtbar (Sie sehen, was passiert, bevor Ihre Kunden es tun) und sie ist übergabefähig (ein neuer Engineer versteht sie in Tagen, nicht Monaten). Diese drei Eigenschaften kosten am Anfang etwas mehr Disziplin und zahlen sich ab dem ersten Incident aus. Alles Weitere in diesem Leitfaden dient diesen drei Zielen.

„Multi-Cloud" bedeutet oft zwei verschiedene Dinge, die man sauber trennen sollte. Das eine ist portable Architektur: Sie bauen so, dass Sie den Anbieter theoretisch wechseln könnten, ohne Ihr Produkt neu zu schreiben. Das andere ist echter Parallelbetrieb auf mehreren Clouds gleichzeitig. Das erste ist fast immer klug, das zweite fast nie nötig, bevor Sie eine handfeste Anforderung dafür haben.

Unsere Haltung ist multi-cloud-fähig, ohne einen Anbieter zum Zentrum zu machen. AWS Frankfurt, Azure, Google Cloud in EU-Regionen und Hetzner haben je nach Workload klare Stärken: Hetzner ist bei reiner Rechenleistung um ein Vielfaches günstiger, die Hyperscaler bieten tiefere Managed-Services und globale Regionen. In der Praxis heißt das oft: rechenintensive, planbare Workloads auf Hetzner, spezialisierte Managed-Dienste (etwa eine bestimmte Datenbank oder ein KI-Dienst) beim passenden Hyperscaler in einer EU-Region. Die Kunst ist, diese Grenze bewusst zu ziehen und nicht aus Bequemlichkeit den gesamten Stack an proprietäre Dienste eines Anbieters zu binden.

Der teuerste Fehler ist Vendor-Lock-in aus Versehen: Sie nutzen ein Dutzend anbieterspezifischer Dienste, und drei Jahre später ist ein Wechsel ein Sechs-Monats-Projekt. Vermeiden lässt sich das mit einfachen Prinzipien — Container statt proprietärer Laufzeiten, offene Standards für Datenbanken und Messaging, Infrastructure as Code, die nicht komplett um einen Anbieter herum gebaut ist. Echter Multi-Cloud-Parallelbetrieb wiederum verdoppelt Ihre operative Komplexität; er lohnt sich erst bei konkreten Souveränitäts-, Ausfallsicherheits- oder Verhandlungsanforderungen, nicht als Standard.

Für Unternehmen in Deutschland, Österreich, der Schweiz und der EU ist der Datenstandort keine Fußnote, sondern eine frühe Architekturentscheidung. Die DSGVO verlangt nicht pauschal „Server in Deutschland", aber der Transfer personenbezogener Daten in Drittländer wie die USA ist rechtlich aufwändig und für viele Ihrer Kunden ein Ausschlusskriterium. Der pragmatische Weg ist, Daten von Anfang an in EU-Regionen zu halten: Hetzner (Deutschland und Finnland), Google Cloud und AWS in Frankfurt oder anderen EU-Standorten, Azure in EU-Regionen.

Datensouveränität ist mehr als der Standort der Festplatte. Entscheidend sind drei Ebenen: Wo liegen die Daten physisch, wer kann rechtlich darauf zugreifen, und wer betreibt die darunterliegende Plattform. Ein europäischer Anbieter wie Hetzner gibt Ihnen hier die klarste Position; ein Hyperscaler in einer EU-Region ist ein guter Kompromiss, wenn Sie einen bestimmten Managed-Dienst brauchen. Für jeden externen Anbieter, der personenbezogene Daten verarbeitet, brauchen Sie einen Auftragsverarbeitungsvertrag (AVV) — und zwar bevor die ersten echten Kundendaten fließen, nicht danach.

Wenn Sie KI-Funktionen integrieren, verschärft sich das Thema. Ein Prompt an einen US-Anbieter kann personenbezogene Daten enthalten; der EU AI Act stellt zusätzliche Transparenz- und Dokumentationsanforderungen. Hier hilft eine bewusste Trennung: sensible Daten in der EU verarbeiten, gegebenenfalls Open-Source-Modelle selbst hosten (etwa über Ollama auf eigener Infrastruktur), und für jeden externen KI-Dienst prüfen, ob EU-Regionen und ein sauberer Datenverarbeitungsvertrag verfügbar sind. Souveränität kostet manchmal etwas Bequemlichkeit — aber sie ist im Vertrieb ein Verkaufsargument statt ein Risiko.

Infrastructure as Code (IaC) bedeutet, dass Ihre gesamte Umgebung — Netzwerke, Server, Datenbanken, Berechtigungen — als versionierter Code beschrieben ist und nicht als Ergebnis von Klicks in einer Web-Konsole existiert. Die beiden Werkzeuge, die wir in nahezu jedem Projekt einsetzen, sind Terraform für die Provisionierung von Ressourcen und Ansible für die Konfiguration innerhalb der Server. Terraform sagt „diese fünf Server, dieses Netzwerk, diese Datenbank sollen existieren"; Ansible sagt „auf diesen Servern soll genau diese Software in genau dieser Konfiguration laufen".

Der Nutzen zeigt sich spätestens beim ersten Ernstfall. Wenn eine Region ausfällt oder eine Umgebung kompromittiert ist, ist der Unterschied zwischen „wir bauen alles aus Code in einer Stunde neu" und „wir versuchen zu rekonstruieren, was jemand vor einem Jahr geklickt hat" existenziell. IaC macht außerdem Änderungen überprüfbar: Jede Infrastrukturänderung läuft als Pull Request durch, wird reviewt und ist im Git-Verlauf nachvollziehbar. Das ist derselbe Disziplin-Gewinn, den Versionskontrolle für Anwendungscode gebracht hat — nur für Ihre Infrastruktur.

Es gibt einen echten Trade-off: IaC erfordert Vorabinvestition. Für ein Wochenendprojekt ist ein Terraform-Setup übertrieben. Sobald aber mehr als eine Person die Infrastruktur anfasst oder Sie eine Produktionsumgebung betreiben, die Ihr Geschäft trägt, ist manuelles Klicken die teurere Option — nur verzögert sich die Rechnung, bis niemand mehr weiß, warum eine Firewall-Regel existiert. Ein sinnvoller Startpunkt ist bescheiden: Terraform-State in einem Remote-Backend, eine getrennte Staging- und Produktionsumgebung, und alle Secrets außerhalb des Codes.

Container sind fast immer die richtige Wahl. Docker verpackt Ihre Anwendung mit allen Abhängigkeiten in ein reproduzierbares Artefakt, das auf jedem Rechner und in jeder Cloud gleich läuft. Das löst die Klasse von Problemen, die mit „bei mir lief es" beginnt, und ist gleichzeitig Ihre beste Versicherung gegen Vendor-Lock-in, weil ein Container-Image nicht an einen Anbieter gebunden ist. Fangen Sie mit Containern an — die Frage ist nie ob, sondern womit Sie sie orchestrieren.

Kubernetes ist hervorragende Technologie und gleichzeitig das häufigste Stück verfrühter Infrastruktur, das wir aus Startup-Stacks entfernen. Der ehrliche Test hat vier Fragen: Deployen mehrere Teams unabhängig und behindern sich ohne Isolation? Ist Ihre Last wirklich spitzenlastig, mit dem Zehnfachen zwischen ruhig und Peak? Verlangen Compliance oder Enterprise-Kunden echte Workload-Isolation? Betreiben Sie bereits zehn oder mehr Services, die orchestrierte Rollouts und Self-Healing brauchen? Beantworten Sie zwei oder mehr mit Ja, lohnt sich Kubernetes. Bei null oder einem Ja nicht.

Die meisten Teams vor der Series A beantworten alle vier mit Nein — und sind mit einer VM plus Docker Compose oder einer Managed-Container-Plattform (Google Cloud Run, AWS App Runner) besser bedient, für einen Bruchteil des Betriebsaufwands. Kubernetes kostet ein kleines Team realistisch vier bis acht Stunden pro Woche an Upgrades, YAML-Pflege und Ingress-Debugging — ein Fünftel eines Engineers für Komplexität, die das Produkt noch nicht braucht. Der beruhigende Teil: Wenn der Bedarf kommt, ist die Migration von sauberem Compose zu Kubernetes eine Sache von Wochen. Die Entscheidung aufzuschieben kostet Sie fast nichts.

Eine CI/CD-Pipeline automatisiert den Weg von einem Git-Commit zu laufendem Code in Produktion — mit Tests, Build und Deployment dazwischen. Mit GitLab CI oder GitHub Actions richten Sie das an einem Tag ein, und es zahlt sich täglich aus. Ohne Pipeline ist jedes Deployment ein manueller, fehleranfälliger Ritus, den nur eine Person beherrscht; mit Pipeline ist es ein reproduzierbarer, getesteter Prozess, den jeder auslösen kann. Ein Deployment, das man sich nicht traut zu machen, wird selten gemacht — und seltene Deployments sind riskante Deployments, weil sich zu viele Änderungen aufstauen.

Observability beantwortet die Frage „was passiert gerade in meinem System?" — idealerweise, bevor ein Kunde anruft. Die drei Säulen sind Metriken (Prometheus und Grafana zeigen Auslastung, Latenz und Fehlerraten über die Zeit), Logs (strukturiert und zentral durchsuchbar) und Alerts (die Sie nachts wecken, wenn etwas kaputt ist — und nur dann). Der Fehler kleiner Teams ist selten „zu wenig Monitoring", sondern „zu viele Alerts, die niemand mehr ernst nimmt". Fangen Sie mit wenigen aussagekräftigen Signalen an: Ist der Dienst erreichbar, wie hoch ist die Fehlerrate, wie steht es um Latenz und freien Speicher.

Der verbindende Gedanke ist, dass CI/CD und Observability zusammen Ihre Deploy-Angst reduzieren. Wenn Sie schnell deployen können und sofort sehen, ob etwas schiefläuft, wird jedes einzelne Deployment kleiner und sicherer. Genau diese Schleife — kleine Änderungen, automatisiert ausgeliefert, sofort beobachtet — ist der Unterschied zwischen einem Team, das wöchentlich liefert, und einem, das vor jedem Release die Luft anhält.

Cloud-Kosten laufen leise aus dem Ruder, weil jede einzelne Entscheidung günstig aussieht und die Summe erst am Monatsende erscheint. Die drei größten Posten sind meist überdimensionierte Rechenressourcen (VMs, die für ihren schlimmsten Tag dimensioniert wurden und 90 Prozent der Zeit langweilen), vergessene Ressourcen (Testumgebungen, verwaiste Volumes, alte Snapshots) und Datenverkehr (besonders teuer bei Hyperscalern, wenn Daten die Cloud verlassen). Ein einfacher Kostenoptimierungs-Durchgang alle paar Monate — Rightsizing, Aufräumen, Reserved-Kapazität für planbare Last — bringt oft die deutlichsten Einsparungen ohne jedes Risiko.

Der strategisch größte Hebel ist die Anbieterwahl pro Workload. Reine Rechenleistung ist bei Hetzner um ein Vielfaches günstiger als bei den Hyperscalern; ein planbarer, rechenintensiver Dienst dort statt bei AWS kann die Rechnung dramatisch senken, ohne dass Sie irgendetwas Wichtiges aufgeben. Umgekehrt lohnt sich ein Managed-Dienst eines Hyperscalers, wenn er Ihnen wochenlange Betriebsarbeit erspart — der teurere Listenpreis ist dann eine gute Investition, keine Verschwendung.

Die wichtigste Warnung: Optimieren Sie nicht Ihre Ingenieurskosten weg, um Cloud-Rechnungen zu senken. Wenn ein Engineer eine Woche damit verbringt, 200 Euro pro Monat einzusparen, war das ein schlechtes Geschäft. Bei einem Startup ist die teuerste Ressource fast immer die Zeit Ihres Teams, nicht die Cloud-Rechnung. Kostenoptimierung ist ein regelmäßiger, gezielter Durchgang mit klaren, großen Hebeln — kein Dauerzustand der Angst, in dem niemand mehr eine Testumgebung startet, weil sie ja Geld kostet. Zur Einordnung der Gesamtinvestition: Ein einfaches MVP liegt bei 25.000–40.000 €, ein vollwertiges SaaS-MVP mit KI bei 50.000–120.000 €; die laufende Infrastruktur ist demgegenüber meist der kleinere Posten.