Hosting-Modelle im Vergleich - Shared Hosting, VPS, PaaS, Kubernetes, Serverless

Fünf grundlegend unterschiedliche Wege, eine Website oder Anwendung zu betreiben - was jedes Modell an Kontrolle, Kosten und Betriebsaufwand mit sich bringt, mit konkreten Entscheidungsszenarien statt einer reinen Merkmalsliste.

“Wo soll das gehostet werden?” klingt nach einer einzigen Entscheidung, ist aber eigentlich eine Wahl zwischen mehreren grundverschiedenen Betriebsmodellen, die unterschiedlich viel Kontrolle, Betriebsaufwand und Kosten mit sich bringen. Ein Leitgedanke zieht sich dabei durch den gesamten Vergleich: Das einfachste Modell, das die tatsächlichen Anforderungen erfüllt, ist in der Regel das richtige - nicht das modernste oder das mit den meisten Skalierungsversprechen.

1. Shared Hosting

Bei Shared Hosting teilen sich viele Kunden einen physischen Server, verwaltet über eine grafische Oberfläche des Anbieters, ohne eigenen Root-Zugriff. Die eigentliche Einschränkung ist dabei weniger die schiere Traffic-Menge als vielmehr die vom Anbieter vorgegebene Laufzeitumgebung: eingeschränkte oder fehlende Hintergrundprozesse, vorgegebene Softwareversionen, kaum Möglichkeit für eigene zusätzliche Dienste (etwa eine separate Datenbank oder einen eigenen Warteschlangen-Prozess). Gut optimiertes, spezialisiertes Shared Hosting (etwa für WordPress) kann auch deutlich stärker frequentierte Websites zuverlässig bedienen, solange die Anwendung selbst in dieses Modell passt - hoher Traffic allein ist noch kein zwingender Grund zum Wechsel.

2. VPS

Ein VPS stellt eine eigene virtuelle Maschine mit fest zugewiesenem Arbeitsspeicher und definierten CPU-Ressourcen bereit, inklusive eigenem Root-Zugriff. “Fest zugewiesen” bedeutet dabei nicht zwingend physisch exklusiv: Je nach Anbieter und Tarif teilen sich mehrere VPS weiterhin dieselbe physische CPU-Kapazität, nur mit garantierten oder priorisierten Anteilen - erst dedizierte vCPU-Tarife reservieren tatsächlich exklusive Rechenkerne. Ein VPS eignet sich für Projekte, die individuelle Serverkonfiguration, eigene Hintergrundprozesse oder zusätzliche Dienste neben der eigentlichen Anwendung benötigen. Die Kehrseite: Betriebssystem-Updates, Sicherheitskonfiguration und Wartung liegen in der eigenen Verantwortung.

3. Managed-Platform / PaaS

Zwischen VPS und vollständigem Serverless liegt eine Schicht, die in Vergleichen dieser Art häufig übersehen wird: Platform as a Service (PaaS). Statt einen Server selbst einzurichten, liefert man Code direkt an eine Plattform aus - oft per Git-Push oder als Container-Image - die Betriebssystem, TLS-Zertifikate, Skalierung, Logging und häufig auch verwaltete Datenbanken automatisiert bereitstellt. Für viele moderne Webanwendungen ist die eigentliche Entscheidung heute nicht “VPS oder Kubernetes”, sondern “VPS oder eine solche Managed-Platform” - PaaS deckt einen großen Teil dessen ab, was ein kleines Team an Betriebskomfort will, ohne in die Komplexität einer eigenen Container-Orchestrierung einzusteigen.

Wichtig dabei: Ein einzelner Docker-Container auf einem einzelnen VPS ist operativ weiterhin im Wesentlichen VPS-Betrieb - Containerisierung allein macht aus einem Server noch keine “Cloud”-Betriebsart. Erst eine Plattform, die Deployment, Skalierung und Betrieb tatsächlich automatisiert übernimmt, verschiebt das Modell in Richtung PaaS.

4. Container-Orchestrierung mit Kubernetes

Kubernetes orchestriert potenziell Hunderte oder Tausende Container über viele Server hinweg - startet ausgefallene Container automatisch neu, skaliert bei steigender Last und verteilt Anfragen über einen Load Balancer auf mehrere Instanzen. Das ist eine eigene, deutlich komplexere Ebene gegenüber PaaS, nicht einfach “Cloud-Hosting im Allgemeinen”. Ein häufiger Fehlschluss ist, dass mehrere zusammenspielende Dienste automatisch Kubernetes erfordern - das stimmt nicht: Ein kleines Team kann mehrere Dienste über Docker Compose, mehrere separate Managed-Services oder eine Managed-Platform durchaus zuverlässig betreiben. Kubernetes lohnt sich in der Praxis meist erst, wenn die organisatorische und technische Komplexität (viele Dienste, dediziertes Ops-Team, echter Bedarf an mehrere Server übergreifender Skalierung) bereits vorhanden ist - nicht, um sie vorsorglich einzuführen. Details dazu, wie sich Docker und Kubernetes konkret zueinander verhalten, stehen im Artikel Docker vs. Kubernetes.

5. Serverless

Serverless abstrahiert Server vollständig weg und ist eher ein Betriebs- und Abrechnungsmodell als eine einzelne Technologie: Klassische, einzelne Funktionen (Function as a Service) gehören ebenso dazu wie serverlose Container, Edge-Functions oder ereignisgesteuerte, serverlose Datenbanken. Gemeinsam ist ihnen die Abrechnung nach tatsächlicher Ausführung statt nach fest gebuchter Serverzeit. Besonders geeignet für unregelmäßige, ereignisgesteuerte Lastspitzen - etwa einzelne Hintergrundaufgaben. Bei dauerhaft hoher, gleichmäßiger Auslastung kann die nutzungsbasierte Abrechnung dagegen teurer ausfallen als ein fest gebuchter Server, und kurze Verzögerungen beim erneuten Start einer länger inaktiven Funktion (Kaltstart) können latenzkritische Anwendungen beeinträchtigen.

6. Sonderfall: statische Websites

Für einen erheblichen Teil der Websites im Jahr 2026 lautet die eigentlich passende Antwort: gar keinen Anwendungsserver betreiben. Inhaltsseiten, Dokumentationen, Portfolios oder Marketingseiten, deren Inhalt sich nicht bei jeder Anfrage individuell aus einer Datenbank zusammensetzen muss, lassen sich als vorgefertigtes, statisches HTML über ein CDN oder einen reinen Objektspeicher ausliefern - ohne laufenden Server im klassischen Sinne. Das ist typischerweise das günstigste, am wenigsten wartungsintensive und am einfachsten horizontal skalierbare aller hier verglichenen Modelle, aber naturgemäß nur dort anwendbar, wo Inhalte nicht bei jedem Aufruf individuell serverseitig berechnet werden müssen.

7. Vergleich

Bei den reinen Infrastrukturkosten schneidet ein günstiger VPS auf den ersten Blick oft am besten ab - dabei bleibt der eigene Betriebsaufwand (Patches, Backups, Monitoring, Sicherheitshärtung, Incident-Reaktion) in dieser Zahl unberücksichtigt. Über die Gesamtkosten entscheidet oft weniger die Serverrechnung als die Frage, wer diesen Aufwand trägt - ob intern eingeplante Arbeitszeit oder ein höherer Betrag, der beim Anbieter genau dafür bezahlt wird.

8. Typische Entscheidungen

• WordPress-Firmenseite ohne besondere technische Anforderungen → gut optimiertes Shared Hosting oder Managed-WordPress-Hosting reicht meist aus.
• WooCommerce-Shop mit eigenen Importern oder Hintergrundjobs → VPS oder spezialisiertes Managed-WooCommerce-Hosting, da Shared Hosting solche Zusatzprozesse meist nicht zulässt.
• Einzelne Webanwendung eines einzelnen Entwicklers → VPS oder PaaS, abhängig davon, ob individuelle Serverkonfiguration oder minimaler Betriebsaufwand wichtiger ist.
• SaaS-Anwendung aus Web-Frontend, Hintergrundverarbeitung, Warteschlange und Datenbank, kleines Team → PaaS oder mehrere Managed-Services, bevor Kubernetes überhaupt in Betracht gezogen wird.
• Bildverarbeitung, die einige Male täglich anfällt → Serverless passt gut zum ereignisgesteuerten, unregelmäßigen Charakter der Aufgabe.
• Großes System aus vielen Diensten mit dediziertem Ops-Team → Kubernetes kann hier tatsächlich sinnvoll werden.
• Reine Inhaltsseite, Dokumentation oder Portfolio ohne serverseitige Individualisierung → statisches Hosting über ein CDN, siehe Abschnitt 6.

9. Häufige Fehler

• Ein Modell wählen, weil es “modern” klingt (etwa Kubernetes), ohne dass der tatsächliche Bedarf an Skalierung oder Ausfallsicherheit dafür besteht.
• Mehrere zusammenspielende Dienste automatisch mit “wir brauchen Kubernetes” gleichsetzen, statt erst einfachere Alternativen zu prüfen.
• Einen containerisierten Dienst auf einem einzelnen VPS fälschlich schon als “Cloud-Infrastruktur” mit entsprechenden Skalierungserwartungen behandeln.
• Serverless für dauerhaft gleichmäßig hohe Last einsetzen, ohne die Kosten gegen einen festen Server oder PaaS gegenzurechnen.
• Beim Kostenvergleich nur die Serverrechnung betrachten und den eigenen Betriebsaufwand ausblenden.
• Bei wachsendem Shared-Hosting-Projekt allein die Traffic-Zahl als Wechselsignal nehmen, statt zu prüfen, ob tatsächlich Funktionen fehlen, die das Modell nicht zulässt.

10. Entscheidungsrahmen

1. Reine Inhaltsseite ohne serverseitige Individualisierung? → Statisches Hosting über ein CDN prüfen, bevor überhaupt ein Anwendungsserver in Betracht gezogen wird.
2. Kleine Website, kein Bedarf an eigenen Hintergrundprozessen, kein technisches Team? → Shared Hosting reicht meist aus.
3. Individuelle Serverkonfiguration oder eigene Zusatzdienste nötig, aber überschaubare Komplexität? → VPS oder PaaS - je nachdem, ob Kontrolle oder minimaler Betriebsaufwand wichtiger ist.
4. Mehrere zusammenspielende Dienste, kein dediziertes Ops-Team? → Erst PaaS oder einzelne Managed-Services prüfen, nicht direkt Kubernetes.
5. Große, organisatorisch bereits komplexe Systemlandschaft mit vorhandenem Ops-Team? → Kubernetes kann jetzt eine sinnvolle Option sein.
6. Nur einzelne, unregelmäßig laufende Aufgaben mit stark schwankender Last? → Serverless.
7. Bedarf unklar oder noch im Wachstum? → Mit dem einfachsten passenden Modell starten und erst bei tatsächlich gemessenem Bedarf wechseln - der Umstieg ist später möglich, vorzeitige Komplexität lässt sich nicht rückgängig machen.

Weiterführend

• Docker vs. Kubernetes
• CDN
• Reverse Proxy
• Platform as a Service