Dein Portal läuft auf einem VPS. Was passiert, wenn es wichtig wird?

Es läuft auf einer Maschine bei einem Hoster. Darauf Docker, ein docker-compose.yml, daneben eine .env-Datei mit dem Datenbankpasswort. Ausgerollt wird per SSH mit git pull und docker compose up -d.

Das ist keine Verlegenheitslösung. Es ist einfach, eine Person versteht die ganze Kiste, es kostet wenig und es läuft jahrelang. Für den Anfang ist das eine vernünftige Wahl, und ich würde niemandem davon abraten, so zu starten.

Die Frage kommt später. Was passiert, wenn das Portal wichtig wird? Wenn die Kunden dort ihre Dokumente holen, wenn Ausfallzeit auffällt, wenn jemand fragt, wo die Daten liegen und wer sie sichert.

Dann steht meist ein Angebot auf dem Tisch, und darin steht Kubernetes. Damit tauscht man ein Problem gegen ein anderes.

Der Massstab

Ich vergleiche in diesem Text keine Rechnungen. Bei einem Portal dieser Grösse liegen alle Varianten nahe genug beieinander, dass die Zahl niemanden überzeugt. Ein VPS für fünfzig Franken im Monat und ein vergleichbarer Aufbau bei einem grossen Anbieter kosten ähnlich viel.

Was sich unterscheidet, ist die betriebliche Einfachheit. Drei Fragen dazu:

Wie viele Teile muss jemand verstehen? Jedes Bauteil hat eine eigene Version, einen eigenen Lebenszyklus und eine eigene Art, kaputtzugehen.

Wer tut es? In einem Betrieb mit zwölf bis fünfzig Leuten gibt es selten eine Person, deren Aufgabe das wäre.

Was passiert, wenn ein Jahr lang niemand etwas tut? Das ist die ehrlichste aller Betriebsfragen, weil sie den Normalzustand beschreibt.

Der Testfall

Ein Kundenportal, wie es ein Betrieb mit zwölf bis fünfzig Leuten braucht. Anmeldung, Dokumente hoch- und herunterladen, ein paar Listen, Benachrichtigungen per Mail. Angular im Browser, ein Backend, Postgres als Datenbank. Eine Handvoll gleichzeitiger Nutzer und eine Spitze am Montagmorgen.

Die Anmeldung habe ich in der Aufstellung bewusst getrennt gehalten, sie bekommt weiter unten einen eigenen Abschnitt.

Vier Varianten, ausgewählt entlang einer Achse vom vollständigen Eigenbetrieb bis zum weitgehend verwalteten Betrieb. Das ist eine Auswahl und keine vollständige Liste, denn verwaltete App-Plattformen, Managed Server und Shared Hosting liegen ebenfalls im Feld. Auf die komme ich am Schluss zurück.

0, VPS mit Docker. Eine Maschine bei einem Hoster, alles in Containern, docker compose als Werkzeug.

A, Kubernetes. Ein verwalteter Kubernetes-Cluster, alles in Containern, auch Postgres. Angular aus einem nginx-Container. Eingang über einen Ingress-Controller.

B, ECS. Der Container-Dienst von AWS ohne Kubernetes, das Backend auf Fargate, RDS für Postgres, Angular auf S3 hinter CloudFront.

C, Lambda. Lambda mit verwalteter Laufzeit, RDS für Postgres, Angular auf S3 hinter CloudFront.

Drei Begriffe brauchen vorher eine Abgrenzung.

Kubernetes und EKS. Kubernetes ist die Plattform, ein offenes Projekt. Es läuft im eigenen Rechenzentrum, auf gemieteten Maschinen, und bei praktisch jedem grösseren Anbieter als verwaltetes Angebot. Wer es selbst aufsetzt, hat die Aufgaben aus Variante 0 und die von Kubernetes gleichzeitig, weshalb ich in diesem Text von der verwalteten Form ausgehe. EKS ist die verwaltete Fassung von AWS. Die Fristen und Preise weiter unten stammen von dort. Bei einem anderen Anbieter sind die Bauteile dieselben und die Termine andere.

OpenShift. Eine Kubernetes-Distribution von Red Hat, ebenfalls selbst betreibbar oder verwaltet zu kaufen, auch bei Schweizer Anbietern. Sie bringt für mehrere der Themen weiter unten eine fertige Antwort mit, etwa Eingang, Registry und Beobachtbarkeit. Das nimmt dir Entscheidungen ab und stellt dafür ein Produkt mit eigenem Lebenszyklus und eigenen Lizenzkosten daneben. Für diesen Text zählt sie als Kubernetes.

Fargate. Eine Art, Rechenleistung zu beziehen, und keine Plattform. Es läuft unter ECS und ebenso unter EKS. Die Varianten hier unterscheiden deshalb den Orchestrator und nicht die Maschine darunter.

Die meisten Betriebe sitzen auf 0. Angeboten bekommen sie A. Dazwischen liegen zwei Varianten, über die selten gesprochen wird.

Frontend

Angular baut zu statischen Dateien. HTML, JavaScript, CSS, Bilder, und die ändern sich zwischen zwei Deploys nicht.

In den Varianten 0 und A liegen diese Dateien in einem nginx-Container. Damit hast du einen Webserver im Betrieb: ein Basis-Image mit einem Betriebssystem darin, nginx selbst, und bei jeder Sicherheitsmeldung einen Neubau plus Neuausrollung.

In den Varianten B und C liegen dieselben Dateien in S3, ausgeliefert von CloudFront. Kein Betriebssystem, kein Paket, kein Patch.

Das ist der einfachste Vergleich im ganzen Text: derselbe Inhalt, einmal mit einem Server davor und einmal ohne.

Backend

Hier ist die naheliegende Antwort falsch. Fargate nimmt dir das Patchen des Backends nicht ab.

Ebene	VPS	Kubernetes	ECS auf Fargate	Lambda
Host-Betriebssystem	du	du	AWS	AWS
Container-Laufzeit	du	du	AWS	entfällt
Basis-Image im Container	du	du	du	AWS
Sprachlaufzeit	du	du	du	AWS, mit Termin
Abhängigkeiten	du	du	du	du
Dein Code	du	du	du	du

Die entscheidende Zeile ist das Basis-Image. Fargate führt dein Image aus, also dein Debian oder Alpine, deine Node- oder Java-Version, deine Systempakete. Wenn dort eine OpenSSL-Lücke aufschlägt, baust du neu und rollst neu aus, genauso wie auf Kubernetes oder auf dem VPS. Was Fargate wegnimmt, ist die Maschine darunter.

Ein Basis-Image sammelt Schwachstellen im Regal. Ein Image, das vor sechs Monaten gebaut wurde, hat heute bekannte Lücken, ohne dass sich an ihm etwas geändert hätte. Und was ich im Feld sehe: das Image wird bei der Projektübergabe einmal gebaut und danach nie wieder. Es gibt keine Pipeline, die nachts neu baut, und niemanden, der die Scanberichte liest. Nach zwei Jahren läuft ein Container mit dem Paketstand vom Übergabetag.

Wer es besser machen will, landet in einer Zwickmühle. Baust du nicht neu, altert das Abbild. Baust du regelmässig neu, bekommst du bei jedem Lauf ein anderes Artefakt als das getestete, weil die Paketversionen mitwandern, und brauchst dafür Tests und ein Ausrollfenster. Pinnst du die Versionen fest, damit der Bau reproduzierbar bleibt, sitzt du wieder auf einem eingefrorenen Stand.

Der Ertrag ist dabei klein. Eine Untersuchung von Container-Abbildern fand einen starken Zusammenhang zwischen der Anzahl installierter Pakete und der Anzahl bekannter Lücken, im Schnitt rund 1.7 zusätzliche pro Paket. Wer nur aktualisiert, bewegt die Zahl kaum, weil dieselben Pakete auch in der neuesten Fassung der Distribution Lücken tragen.

Der Ausweg liegt deshalb bei der Menge. Weniger Pakete im Abbild, oder gar kein eigenes Abbild. Beides ist eine Entscheidung beim Bauen, und danach muss sie niemand jede Woche wiederholen.

Bei Lambda mit verwalteter Laufzeit passiert das strukturell nicht. AWS erneuert Betriebssystem und Laufzeit unter deiner Funktion, ohne dass du etwas tust.

Dafür verlangt Lambda einen Termin. Bei Node 20 haben die Sicherheitsupdates am 30. April 2026 aufgehört, und ab dem 30. September 2026 lassen sich bestehende Funktionen nicht mehr aktualisieren. Die Ausführung wird nie blockiert, Funktionen laufen weiter. Ändern kannst du sie danach nicht mehr, ohne vorher die Laufzeit zu wechseln. Alle zwei bis drei Jahre steht damit eine Migration an, die sich nicht verschieben lässt. Das ist der ehrliche Preis der verwalteten Laufzeit.

Zwei Fallen dazu. Wer seine Funktion in ein eigenes Container-Image packt, weil es bequem ist, hat beim Patchen wieder die Fargate-Situation, ohne es zu merken. Und ein Dienst auf einem distroless-Image hat kaum Systempakete, womit der Vorsprung von Lambda deutlich schrumpft. Beides setzt jemanden voraus, der so etwas einrichtet und pflegt.

Datenbank

Hier ist der Risikounterschied am grössten.

Postgres im Container heisst, dass du selbst führst: kleinere Versionsupdates, Hauptversionswechsel, Backups, Wiederherstellungstests, Failover, Speicherplatz, Überwachung. Nichts davon macht Docker für dich, und Kubernetes auch nicht. Ein StatefulSet ist eine Ablaufhülle und kein Datenbankbetrieb.

Bei RDS laufen die kleineren Updates im Wartungsfenster, Backups und Zeitpunkt-Wiederherstellung sind eingebaut, Failover ist eine Einstellung. Was dabei anders wird, ist der Zugriff: eine RDS liegt im privaten Netz, und wie man von aussen hineinkommt, habe ich in Privater RDS-Zugriff 2026 durchgerechnet.

Der Satz, um den es hier geht: ein Backup, das nie zurückgespielt wurde, ist kein Backup. Ein Dump-Job, der jede Nacht schreibt, sieht überall grün aus. Ob sich daraus eine lauffähige Datenbank bauen lässt, weiss niemand, weil es niemand versucht hat. Das fällt an dem einen Tag auf, an dem es zählt.

Auf dem VPS kommt eine Verschärfung dazu, die ich oft sehe: das Backup liegt auf derselben Maschine. Dann schützt es gegen einen versehentlich gelöschten Datensatz und gegen sonst nichts.

Auf Kubernetes gibt es eine andere Überraschung. Ein Volume lebt in genau einer Verfügbarkeitszone. Der Postgres-Pod, der sich angeblich selbst heilt, kann bei einem Zonenausfall nirgendwohin, weil seine Platte dort festhängt. Das lernen die meisten während des Vorfalls.

Viele Teams nehmen deshalb den Cluster für die Anwendung und eine verwaltete Datenbank daneben. Das ist vernünftig, und es nimmt genau die gefährlichsten Themen weg. Alles andere in diesem Text bleibt.

Die zwölf Betriebsthemen

Das ist der Kern. Zwölf Themen, die in jeder Variante gelöst sein müssen. Der Unterschied liegt darin, wer sie löst und wie viel davon eine bewusste Entscheidung war. Lambda hat keine eigene Spalte, weil es sich von ECS nur in zwei Zeilen unterscheidet, die stehen unter der Tabelle.

Thema	VPS mit Docker	Kubernetes	ECS auf Fargate, mit RDS und S3
Speicher	Bind Mounts auf der Systemplatte	StorageClass, CSI-Treiber, PVCs, Vergrösserung	RDS verwaltet ihn
Backup	cron mit pg_dump, oft lokal	Dump, WAL-Archiv, Ablage, Wiederherstellungstest, dazu die Clusterobjekte	eingebaut, Zeitpunkt-Wiederherstellung
Eingang	nginx oder Traefik von Hand	Ingress-Controller, Umstieg auf Gateway API, Load-Balancer-Controller	ALB, eine Zeile
Zertifikate	certbot, läuft meist	cert-manager, ACME, DNS-Challenge	ACM, erneuert selbst
DNS	beim Registrar von Hand	external-dns oder von Hand	Route 53
Geheimnisse	.env neben dem compose-File	Secrets plus Operator für den Tresor, Rotation	Secrets Manager mit IAM
Netzwerk	Docker-Bridge, Host-Firewall, offene Ports	CNI, IP-Verbrauch, NetworkPolicies, CoreDNS	Security Groups
Zugriff	SSH-Schlüssel, und wer sie hat	RBAC, Pod Identity, kubeconfig	IAM-Rollen
Beobachtbarkeit	docker logs	Prometheus samt Ablage, Logausleitung, Alarme	CloudWatch
Ausrollen	SSH, git pull, compose up	Helm oder Kustomize, GitOps, Registry	CDK-Deploy
Skalierung	keine, vertikal mit Ausfallzeit	HPA, metrics-server, Karpenter, Verdrängungsregeln	eine Zielgrösse
Plattform	Betriebssystem plus Docker-Engine	Nebenversionen, Verträglichkeitsmatrix, Node-Rotation	entfällt

Lambda unterscheidet sich von der ECS-Spalte in zwei Zeilen. Die Skalierung entfällt ganz, und der Eingang läuft über API Gateway oder eine Funktions-URL statt über einen Load Balancer. Die übrigen zehn Zeilen sind dieselben.

Der dreizehnte Posten: die Anmeldung

Ein Kundenportal ohne Anmeldung gibt es nicht, und in der Zwölfertabelle steht sie trotzdem nicht. Das hat einen Grund. Die Anmeldung ist ein Betriebsposten für sich, und in Offerten steht sie als Feature, das einmal gebaut wird.

Drei Wege, mit sehr unterschiedlichen Folgen.

Selbst bauen. Passwort-Hashing, Zurücksetzen per Mail, Sitzungsverwaltung, Sperren nach Fehlversuchen, zweiter Faktor, Rechteprüfung an jedem Endpunkt. Jeder dieser Teile ist ein bekanntes Angriffsziel, und jeder Fehler darin ist ein Datenabfluss. Warum ich davon abrate und wie die Alternative in drei Schichten aussieht, steht in Baue nie dein eigenes Login-System.

Einen offenen Identitätsdienst selbst betreiben. Auf einem VPS oder im Cluster ist das der naheliegende Weg: Keycloak als weiterer Container, fertig. Was dabei mitkommt, ist ein zweites vollständiges System mit eigener Datenbank, eigenem Versionsstrang, eigener Verträglichkeitsmatrix und eigenen Sicherheitsmeldungen. Hauptversionswechsel bei Identitätsdiensten sind selten eine Kleinigkeit, weil Datenmodell und Konfigurationsformat mitwandern.

Damit hat die Anmeldung in den Varianten 0 und A alle zwölf Themen noch einmal im Kleinen: Speicher, Backup, Wiederherstellungstest, Zertifikate, Upgrades, Überwachung. Und dieses eine System hält deine gesamte Benutzerdatenbank.

Einen verwalteten Dienst nehmen. Auf AWS heisst er Cognito. Benutzerdatenbank, Zurücksetzen-Ablauf, Sitzungen, zweiter Faktor und Sperren liegen beim Anbieter.

Ehrlich dazu gehört: umsonst ist auch das nicht. Beim Aufbau kostet es Tage, und die Fallen stehen selten in der Referenzdokumentation. Zwei davon habe ich aufgeschrieben, die vier Fallen bei der Custom Domain im CDK und die drei Fallen beim eigenen Mailversand.

Der Unterschied bleibt trotzdem deutlich. Die Fallen eines verwalteten Dienstes kosten dich einmal, beim Aufbau. Ein selbst betriebener Identitätsdienst kostet dich jedes Jahr wieder.

Dazu kommt etwas, das man beim Selbstbetrieb nachbauen müsste: ein verwalteter Dienst bringt neue Verfahren mit, ohne dass du etwas tust. Cognito liefert Passkeys mit, auch in eu-central-2, also die Anmeldung ohne Passwort über ein Schlüsselpaar auf dem Gerät. Wer seinen Identitätsdienst selbst betreibt, hätte WebAuthn dort selbst nachziehen müssen.

Eine Sache bleibt in jeder Variante bei dir: die Prüfung. Eine Sitzung muss geprüft sein, bevor eine Anfrage die Anwendung erreicht, sonst hängt der Schutz an jedem einzelnen Endpunkt und an der Disziplin desjenigen, der den nächsten schreibt. Auf AWS lässt sich diese Prüfung vor die Auslieferung ziehen. Wie das geht und wo die harten Grenzen liegen, 128 MB Arbeitsspeicher, fünf Sekunden, kein privates Netz, steht in Lambda@Edge: Code am Rand der Welt. Der Code darin ist deiner, also bleibt auch seine Pflege bei dir.

Und zur Leitfrage dieses Textes: ein ungepflegter Identitätsdienst ist der schlechteste Ort für eine bekannte Lücke. Dort liegen die Benutzerkonten, und er muss aus dem Internet erreichbar sein, sonst kann sich niemand anmelden.

Eingerichtet gegen einfach da

Der interessanteste Unterschied steht nicht in der Tabelle.

Auf Kubernetes ist jede der zwölf Zeilen ein bewusster Einrichtungsschritt. Jemand hat entschieden, gelesen, ausgewählt und konfiguriert. Das ist viel Arbeit, und danach weiss diese Person, was dort läuft.

Auf dem VPS sind die zwölf Zeilen ebenfalls belegt, nur hat niemand entschieden. Sie stehen in der Standardeinstellung da, aus der Anleitung übernommen, aus einem Blogbeitrag kopiert. Das ist der Grund, warum der VPS so einfach wirkt: die Entscheidungen sind unsichtbar und nicht abwesend.

Ein Beispiel aus einer eigenen Messung. Ich habe 30 Tage Firewall-Logs einer Seite ausgewertet, die ich betreibe. Dieselben Pfade sind mir schon bei der Auswertung der Zugriffslogs aufgefallen, siehe KI-Crawler in Server-Logs erkennen. Was Scanner gezielt abrufen, sieht so aus:

/.env                 /backend/.env
/.env.local           /config/.env
/.aws/credentials     /.ssh/id_rsa

Auf einer statisch ausgelieferten Seite läuft das ins Leere, dort gibt es keine solche Datei. Auf einem VPS mit docker compose gibt es sie, und darin steht das Datenbankpasswort. Ob sie über den Webserver erreichbar ist, hängt an der nginx-Konfiguration, die aus derselben Anleitung stammt wie der Rest.

Der Punkt ist nicht, dass der VPS unsicher wäre. Der Punkt ist, dass die Antwort auf diese Frage niemand kennt, weil sie nie gestellt wurde.

Was “managed” tatsächlich heisst

Hier sitzt der teuerste Irrtum.

Ein verwalteter Kubernetes-Dienst übernimmt die Steuerungsebene: API-Server, etcd, Scheduler, Controller Manager. Deren Verfügbarkeit und deren Patches.

Bei dir bleibt alles, was Arbeit macht. Das Node-Betriebssystem mit Kernel und OpenSSL, wobei der Anbieter neue Abbilder bereitstellt und du das Ausrollen auslöst. Die Container-Laufzeit auf jedem Node. Das Rollen selbst, also Nodes ersetzen, Pods verdrängen, Disruption Budgets, Wartungsfenster. Die Add-ons wie CoreDNS, kube-proxy und das Netzwerk-Plugin, deren Version an die Clusterversion gebunden ist. Alles selbst Installierte. Und das Nebenversions-Upgrade des Clusters, in der richtigen Reihenfolge.

Dazu ein Zwang, den kaum jemand einplant. Kubernetes erlaubt dem kubelet nur einen begrenzten Rückstand auf den API-Server. Du kannst die Nodes also nicht stehen lassen, wenn die Steuerungsebene weiterzieht.

Und weiterziehen musst du. Bei EKS gilt: 14 Monate Standard-Support zu 0.10 US-Dollar pro Cluster und Stunde, danach 12 Monate erweiterter Support zu 0.60, also rund 438 statt 73 im Monat. Danach hebt AWS die Steuerungsebene selbst an, und der Rückstandszwang zieht die Node-Arbeit hinterher, ob es gerade passt oder nicht.

Am 29. Juli 2026 hat EKS 1.33 den Standard-Support verlassen. Wer nicht aktualisiert hat, zahlt seither das Sechsfache, ohne dass sich am Portal etwas geändert hätte.

Wie weit so ein Upgrade reicht, zeigt der jüngste Sprung: Kubernetes 1.35 hat cgroup v1 abgekündigt, und das kubelet startet auf einem cgroup-v1-Node standardmässig nicht mehr. Mit dem Ende des Supports für 1.33 endete ausserdem die Pflege bestimmter AWS-verwalteter Speichertreiber-Komponenten. Ein Upgrade der Steuerungsebene zieht Nodes, Speicher und Add-ons hinter sich her.

Kubernetes-Betrieb ist kein Patchen bei Bedarf. Es ist ein Kalender, den jemand anders führt.

Der berechtigte Einwand: es gibt inzwischen Betriebsarten, bei denen der Anbieter die Nodes tatsächlich verwaltet, regelmässig austauscht und patcht. Wer damit arbeitet, hat die Node-Ebene weitgehend erledigt. Die Container-Images, die selbst installierten Bauteile und die Upgrade-Termine bleiben trotzdem.

Und der zweite Einwand: EKS lässt sich ebenfalls auf Fargate betreiben. Dann gibt es überhaupt keine Nodes, also kein Node-Betriebssystem, keine Node-Rotation und keinen Rückstandszwang. Drei der dreizehn Posten fallen damit weg. Stehen bleiben die Steuerungsebene samt Supportfenster und der sechsfachen Rechnung nach vierzehn Monaten, die Add-ons, der Eingang, die Zertifikatsautomatik, RBAC, das Netzwerk, die Beobachtbarkeit und das Nebenversions-Upgrade. Dazu kommen eigene Einschränkungen, etwa keine DaemonSets und feste Kombinationen aus CPU und Speicher, weshalb Logs und Metriken anders eingesammelt werden müssen.

Das schärft den Vergleich eher, als dass es ihn entkräftet. Mit derselben Rechenleistung darunter kostet dich ECS vier der dreizehn Posten und EKS zehn. Der Unterschied ist der Orchestrator und nicht die Maschine.

Der Eingang, der stehenblieb

Im März 2026 hat die Kubernetes-Community ingress-nginx stillgelegt. Keine Releases, keine Fehlerbehebungen, keine Sicherheitsupdates. Die zuständigen Komitees haben dazu geschrieben, das Bauteil habe rund die Hälfte aller Cloud-Native-Umgebungen bedient, wer dabei bleibe, setze sich und seine Nutzer Angriffen aus, und keine der Alternativen sei ein direkter Ersatz.

Das ist fünf Monate her. Irgendwo läuft gerade ein Kundenportal, dessen Eingang seit März keine Sicherheitsupdates mehr bekommt, und niemand dort weiss es.

Genau darum geht es bei betrieblicher Einfachheit. Es geht nicht um die halbe Stunde Patchen im Monat. Es geht um die Bauteile, die dir jemand unter den Füssen wegzieht, und um die Frage, wer die Meldung liest.

Skalierung

Auf Kubernetes braucht Skalierung drei Schichten: eine für die Anzahl Pods samt Metrikquelle, eine für die Anzahl Nodes, dazu Verdrängungsregeln, damit die Verkleinerung keine Sitzungen abwirft. Der Node-Skalierer ist ein eigenständiges Projekt mit eigenem Versionsstrang und einer Verträglichkeitsmatrix zur Clusterversion, also ein weiteres Bauteil.

Auf ECS ist es eine Zielgrösse je Dienst. Bei Lambda ist gar nichts einzurichten, du setzt höchstens Obergrenzen, damit eine Lastspitze nicht die Datenbank überrennt. Auf dem VPS gibt es keine Skalierung, dort wächst man vertikal, mit Ausfallzeit. Was das bei einer Lastspitze praktisch bedeutet, steht in Wenn die Webseite genau dann langsam wird, wenn es zählt.

Punkt für die Gegenseite: ein moderner Node-Skalierer kann Nodes nach Ablaufzeit ersetzen und neuere Abbilder erkennen. Wer das einschaltet, patcht sein Node-Betriebssystem durch Austausch. Auf einem gut geführten Cluster ist die Node-Ebene damit tatsächlich abgedeckt. Falsch eingestellt wirft dieselbe Automatik Nutzer aus dem Portal, mitten in einem Upload.

Für unser Portal ist Skalierung ohnehin kaum relevant. Der Unterschied liegt darin, wie viel Maschinerie du aufbauen und pflegen musst, um sie überhaupt zur Verfügung zu haben.

Kubernetes ist für eine andere Grösse gebaut

Das ist mir wichtig, weil es sonst wie eine Abrechnung klingt.

Kubernetes ist gut gebaut. Es ist dort entstanden, wo tausende Dienste von Plattformteams betrieben werden, und die zwölf Stellschrauben sind dort kein Ballast. Sie sind der Zweck. Wer vierzig Dienste hat, richtet jede Stellschraube einmal ein und wendet sie überall an. Dann ist die Einheitlichkeit über alle Dienste hinweg mehr wert als der Aufwand pro Dienst, und die Rechnung geht auf.

Bei einem Dienst und einer Datenbank richtest du zwölfmal ein und wendest zwölfmal auf einen einzigen Verbraucher an. Dasselbe Werkzeug, andere Grösse, umgekehrtes Ergebnis.

Als Faustregel: ab einem eigenen Betriebsteam, ab einer zweistelligen Zahl von Diensten, oder wenn du zwischen Anbietern und Rechenzentren beweglich bleiben musst. Ein Kundenportal für einen Betrieb mit zwölf Leuten ist keiner dieser Fälle.

Know-how und Personal

Bis hierher ging es um Technik. Der eigentliche Kostenblock ist ein anderer.

Was jemand können muss, um diesen Cluster über drei Jahre zu führen: Kubernetes-Objektmodell, Nebenversions-Upgrades in der richtigen Reihenfolge samt Rückstandsregel, Add-on-Verträglichkeit, Ingress und die laufende Migration zur Gateway API, Zertifikatsautomatik, RBAC und Netzwerkrichtlinien, Node-Skalierung mit Verdrängung, Container-Images bauen und härten, Schwachstellenberichte lesen, Postgres mit Backups und Wiederherstellungstests, Beobachtbarkeit, und die Fehlersuche nachts, wenn ein Pod nicht startet.

Fünfzehn Themen. Für ECS auf Fargate mit RDS und S3 bleiben davon etwa vier: Container-Images bauen und regelmässig erneuern, IAM, Infrastrukturcode, und die Frage, wer im Ernstfall die Wiederherstellung macht.

Beides erfordert Können. Der Unterschied ist der Umfang.

Für einen Betrieb dieser Grösse heisst die lange Liste eine Anstellung. Der Median für DevOps-Ingenieure liegt in der Schweiz bei rund CHF 112’000, Senior bei etwa CHF 135’000, und Kubernetes-Kenntnisse bringen einen Aufschlag von 10 bis 20 Prozent. Mit Arbeitgeberkosten landest du bei rund CHF 170’000 im Jahr.

Zwei Dinge, die dabei untergehen:

Teilzeit löst es nicht. Es gibt keine Zehn-Prozent-Kubernetes-Person. Wer das viermal im Jahr macht, hat beim fünften Mal vergessen, wie es geht, und die Umgebung ist zwei Nebenversionen weiter.

Eine Person reicht auch nicht. Upgrades haben Termine, und Termine kennen keine Ferien und keine Kündigungsfrist. Wer Kubernetes betreibt, braucht zwei Leute, die es können, oder einen Vertrag mit jemandem, der es kann.

Der VPS hat dasselbe Problem in kleiner Form. Dort ist es meistens die eine Person, die das damals aufgesetzt hat, und wenn sie geht, geht das Wissen mit.

Ein Jahr, in dem niemand hinschaut

Die falsche Frage lautet, wie viele Stunden Betrieb im Monat anfallen. Die richtige lautet: was passiert, wenn ein Jahr lang niemand etwas tut?

	nach zwölf Monaten Nichtstun
VPS mit Docker	Läuft. Betriebssystem und Images tragen bekannte Lücken, SSH steht offen, die .env liegt auf der Platte. Von aussen sieht alles normal aus.
Kubernetes	Cluster ausserhalb des Standard-Supports, Steuerungsebene sechsmal so teuer, Add-ons auseinandergedriftet, Node-Abbilder veraltet, Eingang ohne Patches. Das Upgrade ist jetzt ein Projekt.
ECS auf Fargate, RDS, S3	Läuft. Plattform und kleinere Datenbank-Updates sind eingespielt. Veraltet sind das Basis-Image und die Abhängigkeiten.
Lambda, RDS, S3	Läuft. Bis eine Laufzeit abgekündigt wird, dann ein Termin mit Vorwarnzeit.

Kubernetes bestraft Nichtstun sichtbar. Der VPS bestraft es unsichtbar, was gefährlicher ist. ECS auf Fargate verzeiht es weitgehend.

Und Nichtstun ist der Normalzustand in einem Betrieb mit zwölf Leuten. Das ist keine Nachlässigkeit. Dort sitzt schlicht niemand, dessen Aufgabe das wäre.

Wenn die Schweiz Bedingung ist

Ein Einwand, der bei jeder solchen Diskussion kommt: die grossen Anbieter sind amerikanisch, und über den Cloud Act könnte eine fremde Behörde an die Daten kommen.

Das Label swiss hosting formuliert die Anforderung präzise. Es beruht auf zwei Zusagen: die Daten bleiben in der Schweiz, und Dritte kommen nur über Schweizer Behörden an sie heran. Die erste Zusage kann ein grosser internationaler Anbieter mit Schweizer Rechenzentrum einhalten. Die zweite nicht.

Dass eine Schweizer Region festlegt, wo gespeicherte Daten liegen, und noch nicht, dass nichts das Land verlässt, habe ich in Daten in der Schweiz: was das technisch wirklich heisst auseinandergenommen.

Ob dich das betrifft, entscheiden drei Fragen:

Unterliegst du einem Berufsgeheimnis oder einer Aufsicht mit geschriebenen Regeln? Hier zählt keine Wahrscheinlichkeit. Wer eine gesetzliche Schweigepflicht trägt, für den ist die theoretische Möglichkeit bereits das Problem. Wen Art. 321 StGB tatsächlich trifft, ist enger gefasst als viele annehmen: Anwälte und Revisoren ja, nicht jeder Treuhänder. Die Abgrenzung samt Hilfspersonen-Regel steht in Berufsgeheimnis und Cloud.

Verlangt es ein Kunde oder eine Ausschreibung? Dann ist die Diskussion beendet, unabhängig davon, wer technisch recht hat.

Was liegt tatsächlich im Portal? Rechnungen und Termine sind etwas anderes als Mandatsakten oder Gesundheitsdaten.

Dreimal nein heisst: das Restrisiko ist überschaubar, und die betriebliche Einfachheit gewinnt. Einmal ja heisst: die Abwägung kippt.

Wir führen das Label bewusst nicht. Wir können die zweite Zusage nicht halten, und ein Logo, dessen Bedingungen man nicht erfüllt, ist schlimmer als keines.

Wer es braucht, findet in der Schweiz für die meisten Bausteine ein Gegenstück:

Baustein	AWS	Schweizer Gegenstück
Angular ausliefern	S3 und CloudFront	S3-kompatibler Objektspeicher, mehrere Anbieter
Backend ohne Cluster	ECS auf Fargate	verwaltete App-Plattform, im Wesentlichen ein Anbieter
Datenbank	RDS	verwaltetes Postgres, im Wesentlichen ein Anbieter
Funktionen ohne Prozess	Lambda	kein Gegenstück

Das Fehlende ist folgenlos, weil ich für ein Portal dieser Art ohnehin zu ECS auf Fargate rate. Lange Sitzungen, Uploads und gelegentliche Berichte passen besser zu einem laufenden Container als zu einer Funktion mit Ausführungsgrenze und Kaltstart, und wie gross der Kaltstart je nach Laufzeit ausfällt, habe ich in Lambda Cold Start gemessen belegt. Ein Aufbau ohne Cluster ist auch mit Schweizer Anbietern möglich.

Warum die naheliegende Wahl selten passt

Und trotzdem sitzen fast alle auf einem VPS oder bekommen Kubernetes angeboten. Das liegt an der Sichtbarkeit, und das lässt sich nachprüfen.

Ich habe im August 2026 drei Suchen gemacht, mit Begriffen, die ein Betrieb dieser Grösse eingeben würde. Suchergebnisse sind persönlich und ändern sich, das hier ist eine Momentaufnahme.

“Kundenportal KMU Schweiz” liefert auf der ersten Seite ausschliesslich Behördenangebote: das KMU-Portal des SECO, EasyGov, kantonale E-Services, ein Verband. Kein einziges kommerzielles Angebot. Der Begriff ist besetzt.

“Webapplikation hosten Schweiz” und “Hosting Kundenportal KMU” liefern Webhosting. Einstiegstarife ab rund zehn Franken im Monat, beschrieben über Speicherplatz, Anzahl Domains, Anzahl Postfächer, PHP-Version und Ein-Klick-Installation für WordPress. Die Vergleichsartikel dazu nennen als Auswahlkriterien Uptime, Ladezeit, Serverstandort und SSD-Leistung.

Keines dieser Kriterien hilft weiter. Wer eine Angular-Anwendung mit einem Backend und einer Postgres-Datenbank betreiben will, erfährt hier, wie viele E-Mail-Postfächer im Paket enthalten sind.

Am anderen Ende steht das Anbieterverzeichnis des Labels swiss hosting mit 29 Cloud-Angeboten als Alternativen zu AWS. Elf davon sind virtuelle Maschinen oder Server, acht sind Kubernetes oder OpenShift. Wie unzuverlässig auch dort die Orientierung ist, zeigt eine Probe: filtert man nach Function as a Service, kommen drei Treffer, und dahinter stehen eine virtuelle Maschine, ein Objektspeicher und ein Kubernetes-Dienst. Die Zuordnung stammt von den Anbietern selbst. Zur Einordnung gehört, dass dieses Verzeichnis Labelmitglieder führt und keine Marktübersicht ist.

Beide Enden sind für einen Betrieb mit zwölf Leuten falsch. Das Webhosting-Paket ist für Websites gebaut. Der Cluster verlangt jemanden, der Kubernetes kann.

Was dazwischen liegt und kaum gefunden wird

Das Passende existiert. Es hat nur keinen Namen, nach dem jemand sucht.

Verwaltete App-Plattformen. Ab acht Franken im Monat, sie machen aus einem Git-Repository eine laufende Anwendung und kümmern sich um Build, Zertifikate, Logs, Datenbank und Backups. Sie bewerben sich mit Begriffen wie Buildpacks und richten sich an Leute, die eine bestimmte amerikanische Plattform kennen. Ein Treuhandbüro kennt diese Begriffe nicht.

Betreuter Container-Betrieb. Unter den acht Suchtreffern war genau einer, der beschreibt, worum es hier geht: Docker und Docker Compose für die meisten Arbeitslasten, Kubernetes erst dort, wo echte horizontale Skalierung nötig wird, dazu Postgres mit Zeitpunkt-Wiederherstellung, Web Application Firewall, Überwachung, Backup und ein Ansprechpartner.

Das ist eine fünfte Variante, und sie führt die Achse dieses Textes zu Ende. Aufbau wie Variante 0, nur liegen die zwölf Themen beim Anbieter und nicht bei dir. Für ein Portal dieser Grösse ist das oft die vernünftigste Antwort, und sie taucht in keiner Architekturdiskussion auf.

Gefunden wird sie kaum, weil sie sich mit demselben Wort bewirbt wie die Shared-Hosting-Pakete daneben. Beide sagen Hosting und meinen etwas völlig anderes.

Das ist der eigentliche Befund. Das Angebot existiert an beiden Enden und in der Mitte. Was fehlt, ist eine gemeinsame Sprache, und deshalb landet der Suchende zuverlässig bei einem der beiden Enden.

Was serverless nicht löst

Damit kein falscher Eindruck entsteht. Serverless verschiebt das Risiko, es beseitigt es nicht.

Eine offene Ablage, eine zu weit geschnittene Rolle oder ein Fehler in deiner eigenen Anwendung wirken dort genauso wie im Cluster. Injection und kaputte Authentifizierung funktionieren überall gleich. Dein Code bleibt dein Code, und niemand pflegt ihn für dich.

Was verschwindet, ist die Wartungsschuld am Unterbau. Das ist viel, und es ist nicht alles.

Vier Fragen an deinen Anbieter

Wenn eine Portal-Offerte auf deinem Tisch liegt, zeigen diese Fragen den Unterschied:

Welche Varianten habt ihr geprüft, bevor ihr mir diese vorgeschlagen habt? Wenn die Antwort nur eine Variante kennt, war es keine Wahl.

Wer führt das Upgrade der Plattform durch, und wie oft steht es an? Bei Kubernetes lautet die Antwort mindestens einmal im Jahr, mit Termin. Wer das nicht beziffern kann, hat nicht damit gerechnet.

Wann wurde zuletzt ein Backup zurückgespielt, und wie lange hat es gedauert? Darauf gibt es zwei Antworten: eine Zahl oder ein Ausweichen.

Was passiert, wenn die Person, die das eingerichtet hat, sechs Wochen ausfällt? Das ist die Frage, die die Architekturentscheidung wirklich trifft, und sie hat mit Technik nichts zu tun.

Ich baue Kundenportale so, dass die Antwort auf die letzte Frage kurz ausfällt. Das ist kein Argument gegen Kubernetes und keines gegen den VPS. Es ist ein Argument dafür, die Betriebsfrage vor der Technikfrage zu stellen.