Ein vps ist ein virtueller Server, der sich wie eine kleine eigene Maschine verhält, obwohl er auf gemeinsamer Hardware läuft. Sie erhalten Ihr eigenes Betriebssystem, Root- oder Admin-Zugriff, zugewiesene CPU/RAM/Storage und eigene Netzwerkkonfiguration, während der Provider sich um die physischen Hosts kümmert. Für IT-Teams ist das meist das Mittel zwischen günstigen Shared Hosting-Angeboten und der Miete eines kompletten physischen Servers.

Was ist ein vps?

Ein vps wird erstellt, indem ein physischer Server mithilfe eines Hypervisors in mehrere isolierte Gastsysteme aufgeteilt wird. Jeder Gast hat sein eigenes Betriebssystem und eigene Services, sodass z.B. ein Kunde Ubuntu mit Nginx betreiben kann, während ein anderer denselben Host für Windows Server mit IIS nutzt. Diese Isolierung hängt stark vom Hypervisor, dem Storage, den Netzwerkkontrollen und einer ehrlichen Ressourcenvergabe durch den Anbieter ab – Magie ist das nicht.

Nehmen wir eine Steuerkanzlei mit 40 Nutzern an zwei Standorten. Sie benötigen vielleicht einen kleinen extern gehosteten Server für ein Kundenportal, ein SFTP Endpoint oder ein Monitoring-Relay. Dafür extra einen eigenen Server im Rechenzentrum zu kaufen, wäre überdimensioniert. Ein virtual private server gibt genug Kontrolle, um Pakete zu installieren, SSH abzusichern, Backups zu planen oder den Webstack zu optimieren – ohne eigene Hardware und ohne sich den Application Pool mit Fremdanwendungen zu teilen.

Die einfache Faustregel: Es ist nicht „nur Hosting“ und nicht „jemandes fremder Laptop in der Cloud“. Ein vps ist ein Betriebssystem-Instanz mit fest zugewiesenen Ressourcen, über das Netzwerk erreichbar, meist monatlich oder stundenbasiert abgerechnet. Für alles, was im Gast passiert – Nutzer, Patch Management, Firewall-Regeln, Services, Zertifikate, Logs und Backups – sind Sie zuständig, sofern Ihr Anbieter nicht explizit Managed Services bereitstellt.

Wie funktioniert die Architektur auf einem physischen Host?

Meist setzen Provider Hypervisoren wie KVM, VMware ESXi, Hyper-V oder Xen auf großen physischen Servern ein. Ein Host könnte dann z.B. 2 CPUs mit 32 Kernen, 256 GB RAM, mehrere NVMe-Drives und 10 Gbit-Uplinks bieten. Der Hypervisor stellt den Kunden kleinere virtuelle Maschinen bereit, etwa mit 2 vCPU, 4 GB RAM, 80 GB SSD und einer öffentlichen IPv4-Adresse.

Entscheidend ist die Zuteilung. CPU-Ressourcen werden oft geteilt und zeitlich geschaltet, RAM kann je nach Plattform garantiert oder überbucht sein, und die Disk-I/O-Performance hängt von der Architektur des Storage-Backends ab. Ein günstiger Plan mit „8 vCPU zum Mittagessenpreis“ kann trotzdem schnell langsam werden, wenn sich 80 Hosts um dieselben Kerne streiten.

Hypervisoren bieten bei guter Konfiguration solide Isolation, aber das Modell bleibt Multi-Tenant. Sollte das bei Ihrer Risikoanalyse relevant sein, erklärt XEOX Multi-Tenant-Architekturen und ihre Vor- und Nachteile ausführlich. Für die Grundlagen der Virtualisierung bietet der NIST Guide to Security for Full Virtualization Technologies weiterhin einen klaren Überblick zu den Rollen von Host, Gast und Hypervisor.

Volle Virtualisierung vs. Container

Ein virtueller Server (Gast) bringt in der Regel sein eigenes Kernel mit. Ein Container nutzt denselben Host-Kernel und isoliert Prozesse per Namespaces, cgroups und weiteren Controls. Diese Unterscheidung ist relevant, wenn Sie z.B. eigene Kernel-Module, Windows-Workloads, stärkere Tenant-Isolation oder volle Betriebssystemkontrolle benötigen.

Beispiel: Ein MSP, der eine ältere Branchenanwendung hostet, wählt oft einen Windows-Gast, weil der Softwarehersteller eine spezielle .NET-Version und geplante Tasks als Dienst fordert. Container sind ideal für zustandslose APIs, aber ältere Anwendungen, die das Geschäft tragen, verlangen oft eine vollständige Serverumgebung.

Wann macht dieses Hosting-Modell Sinn – und wann nicht?

Ein vps besetzt die pragmatische Mittelposition. Ideal, wenn Sie Administrationsrechte, eine feste IP, kalkulierbare Kosten und genug Isolation brauchen, um typische Shared-Hosting-Probleme zu vermeiden. Weniger sinnvoll, wenn Sie garantierte Bare-Metal-Performance, Managed Application Support oder automatisches Skalieren ohne viel Eigenaufwand benötigen.

Typische Einsatzszenarien sind: die Firmenwebsite eines mittelständischen Herstellers, privates Git Hosting für ein kleines Entwicklerteam, ein Jump Host, ein kleiner Mail-Relay, Monitoring-Probe, Lab-Domaincontroller oder Staging-Umgebung. Häufige Fehlanwendungen: auf dem günstigsten Tarif eine ausgelastete Datenbank mit unklarem I/O-Profil hosten, regulierte Anwendungen ohne Vertragsprüfung einstellen oder sämtliche internen Tools auf einer öffentlichen Maschine bündeln.

Praktische Entscheidungsregel: Benötigt Ihr Dienst Betriebssystem-Level-Kontrolle und sind die Ressourcen überschaubar, ist ein vps die erste Wahl. Sollen Anwendungen horizontal skalieren, mit Managed Database Services integriert werden und auch regionale Ausfälle robust abfedern, dann besser gleich auf Cloud Services bauen. Benötigt das Workload Hardware-Dongles, sehr hohe dauerhafte IOPS oder Single-Tenant-Hardware, nehmen Sie dedizierte oder colocated Server.

Shared Hosting, Cloud-Instanzen und dedizierte Hardware

Shared Hosting ist meist günstiger und bequemer, aber man steuert selten OS, Webserver-Module, Patch-Timing oder Service-Architektur. Mit dedizierter Hardware besitzen Sie alles – aber auch Beschaffung, Kapazitätsplanung, Ausfallrisiken und einen höheren Mindestpreis. Cloud-Instanzen bei AWS, Azure oder Google ähneln vps auf OS-Ebene, werden aber von einem vielschichtigen Ökosystem begleitet: IAM, VPCs, Snapshots, Managed Disks, Load Balancer, private Endpoints und umfangreiche Abrechnung.

Die Falle besteht darin, die Angebote nur am Preis zu unterscheiden. Wer verwaltet Patch Management, Monitoring und Recovery? Ein 10-Euro-Gast bei einem lokalen Provider ist ideal für eine Neben-Website, aber dieselbe Serverkonfiguration wäre fahrlässig für einen Payment-Service mit Auditing, Recovery-Konzept und Netzwerksegmentierung.

Wie dimensioniert man CPU, RAM und Storage ohne Ratespiel?

Orientieren Sie sich am Workload, nicht an der Preisliste des Providers. Eine kleine statische Website mit Nginx läuft auf 1 vCPU, 1 GB RAM problemlos. WordPress mit WooCommerce, Hintergrundjobs und lokaler Datenbank braucht schnell 2 vCPU, 4 GB RAM und flotte Storage, damit die Seite stabil bleibt. Windows Server Guests brauchen in der Regel noch mehr RAM; 2 GB ist Testumgebung, keine Produktionsbasis.

Eine schnelle Abschätzung vor dem Kauf:

• Peaks abschätzen: 20 interne Wiki-Nutzer erzeugen eine andere Last als 2000 Website-Besucher in einer Kampagne.
• Datenbankbedarf separieren: Lokale MySQL/SQL Server-Instanzen machen sich sofort im RAM- und Disk-Profil bemerkbar.
• Schreibvolumen prüfen: Logs, Queues, Uploads und Backups können eine 80 GB Disk überraschend schnell füllen.
• 30 Prozent Reserve einplanen: Wer täglich bei 95 Prozent RAM läuft, hat demnächst Supportfälle vorprogrammiert.

Für Linux-Webworkloads empfiehlt es sich, leicht unterdimensioniert zu starten, aber mit sauberem Monitoring und klarem Upgradepfad. Bei Windows lieber großzügiger planen. CPU können Sie häufig später anpassen – Storage und Softwareannahmen sind aufwendig, sobald der Server 1,5 Jahre läuft.

Beobachten Sie auch die Differenz zwischen „vCPU-Zahl“ und echter Leistung. Der 2-vCPU-Tarif eines Anbieters mit aktueller AMD EPYC-Hardware kann besser laufen als ein 4-vCPU-Angebot eines überbuchten Providers. Lassen Sie für wichtige Workloads einen Benchmark laufen, aber verwechseln Sie diese Werte nicht mit Betriebsstabilität. Wichtiger als Zahlen sind Netzwerk-Latenz, Storage-Konsistenz, Supportzeit und zuverlässige Snapshots.

Was sollten IT-Admins in den ersten 30 Minuten absichern?

Der erste Login ist oft der Moment, in dem Schwachstellen entstehen. vps-Provider liefern Systeme meist mit öffentlicher IP, Passwort-SSH oder RDP und minimaler Firewall. Wer die Kiste eine Woche zum „Ausprobieren“ offen lässt, wird von Scannern meist schneller entdeckt als vom eigenen UAT-Team.

Deshalb direkt umsetzen:

• Passwortzugänge deaktivieren: SSH-Keys für Linux, RDP via VPN, Bastion oder Quell-IP-Filter für Windows nutzen.
• Betriebssystem patchen: Sicherheitsupdates installieren, bevor Anwendungen live gehen.
• Host-Firewall einschalten: Nur notwendige Ports erlauben – meistens 22/3389 für Admins, 80/443 ins Internet.
• Non-Root-Admin einrichten: Direkten root-Look deaktivieren, Privilege Escalation loggen.
• Backups vor Datenstart einrichten: Ein „Backup später“ ist Wunschdenken, nicht Schutz.

Bei öffentlichen Systemen gilt: MFA für Management, API oder Verwaltungszugänge muss Standard sein. API-Tokens nicht in Shell-Historien oder Deploymentskripten liegen lassen. Speichert der vps Kundendaten? Definieren Sie Verschlüsselung, Aufbewahrung und Zugriffsprüfung vor dem ersten Upload.

Ein guter Security-Baseline ist kein 90-seitiges PDF, das niemand liest, sondern ein reproduzierbarer Zustand: gepatchtes OS, limitierter Inbound-Zugriff, benannte Admin-Accounts, Logging, Backups, Endpoint-Schutz (wo möglich) und dokumentiertes Ownership. Einen praxiserprobten Ansatz skizziert dieser Artikel von XEOX zu Security Baselines.

Wie ändern sich Backups, Patching und Monitoring?

Bei Shared Hosting sehen Sie als Kunde nie das eigentliche Betriebssystem. Mit vps sind plötzlich Sie dafür zuständig: Backup-Prozesse, Patch-Termine, Disk-Alerts, Zertifikatslaufzeiten, Login-Fails und Service-Health – alles liegt in Ihrer Verantwortung, es sei denn, Sie buchen ein Full Managed-Paket.

Ein häufiger Fehler: Sich ausschließlich auf Provider-Snapshots als Backup verlassen. Snapshots sind praktisch für ein schnelles Rollback vor einem Update, aber nicht das Gleiche wie applikationsbewusste Backups mit Retention, Restore-Tests und externem Backup-Ziel. Auch bei Providerausfall oder gehacktem Kundenzugang helfen Snapshots auf derselben Plattform nicht wirklich weiter.

Patch Management ist jetzt eigene Aufgabe. Sie brauchen Wartungsfenster, Rückfallebene und die Kontrolle, ob Updates tatsächlich installiert wurden. Agentloses Monitoring reicht für Patch-Compliance nicht; die VM könnte zwar pingen, aber 23 kritische Pakete fehlen trotzdem. Bei mehreren Servern ist Patch Orchestration wesentlich sinnvoller als einzelne manuelle SSH-Updates.

Monitoring sollte mindestens vier Ebenen abdecken: Dienstverfügbarkeit, Systemressourcen, Security Events, Backup-Erfolg. Praktisch ist: HTTP-Status-Checks, Alert bei 80% Disk-Usage, CPU-Steal-/Readytimes wo verfügbar, Login-Fails, Zertifikatswarnung 14 Tage vor Ende, täglicher Backup-Check. Das ist kein Overkill, sondern die Grenze zwischen „wir betreiben einen Server“ und „wir hoffen, dass er noch funktioniert“.

Was dokumentieren, bevor die nächsten 20 vps gestartet werden?

Ein einzelner vps ist einfach. Zwanzig undokumentierte Guests werden schnell zum Inventar-, Abrechnungs- und Sicherheitsproblem. Klassisch: Der Entwickler testet was, ein Dienstleister bekommt mal kurz ein SFTP Endpoint, Marketing braucht eine Microsite, und nach einem halben Jahr fragt keiner mehr, wofür die öffentlichen IPs eigentlich sind.

Dokumentieren Sie: Owner, Zweck, Betriebssystem, Provider Account, Region, öffentliche IPs, offene Ports, Datenklassifikation, Backup-Richtlinien, Wartungsfenster und geplantes Ablaufdatum – und zwar bei Inbetriebnahme, nicht erst bei einem Vorfall. Gibt es keine verantwortliche Person und keinen Geschäftszweck, sollte der Server nicht existieren.

Hier beginnt Cloud Sprawl – auch außerhalb der ganz großen Anbieter. Kleine Monatsbeträge tarnen verwaiste Systeme gut. Einzelne 12-Euro-VMs sind kein Drama, aber 60 vergessene Instanzen bei drei Providern tragen nicht gepatchte Pakete, alte SSH-Keys, abgelaufene Zertifikate und potentiell Kundendaten. Das Muster ist das gleiche wie im Cloud Sprawl-Artikel beschrieben: schnelle Erstellbarkeit ohne Lebenszykluskontrolle.

Configuration Management hilft. Nutzen Sie z.B. Ansible, PowerShell DSC, cloud-init, Terraform oder ein anderes Automatisierungs-Tool, um Systeme jederzeit definierbar zu halten. Ein Golden Image oder ein sauberer Bootstrap-Script ist besser als „Sarah fragen, wie der Server damals installiert wurde“. Wenn Sie Server-Guests gemeinsam mit Notebooks und anderen Endpoints verwalten, kann XEOX Patch Management, Sichtbarkeit und Compliance aus einer Oberfläche ermöglichen.

FAQ

Ist ein vps das gleiche wie eine Cloud Instance?

Aus Sicht des Betriebssystems fast immer: Sie loggen sich ein, patchen, installieren Services und monitoren. Der Unterschied steckt in der umgebenden Plattform. Hyperscaler bieten meist mehr Optionen für Networking, Identität, Logging und Automatisierung, während einfache vps-Anbieter es bei rudimentären Panels und geringem Managed-Angebot belassen.

Können auf einer Instanz mehrere Anwendungen sicher laufen?

Es ist möglich, aber immer ein Kompromiss. Eine Website, ein Wiki und eine Monitoring Probe auf einer VM sind für kleinere Unternehmen OK – aber geteilte Abhängigkeiten bedeuten bei Störungen oder Kompromittierung höhere Risiken für alle Anwendungen auf dem selben System.

Wie viel RAM ist für kleine Produktions-Workloads genug?

Für kleine Linux-Webdienste genügen 2 GB RAM, wenn die Datenbank ausgelagert und der Traffic vorhersehbar ist. Für WordPress mit lokaler Datenbank sollten Sie 4 GB einplanen. Bei Windows Server sind 4 GB als Mindestwert zu sehen – besser großzügig nach oben anpassen, je nach Rolle und Monitoringdaten.

Wer ist zuständig für Updates?

Sofern nicht ein managed Service mit Patch Management gebucht wurde, ist Ihr Team für Updates von Gast-OS und Anwendungen verantwortlich. Der Provider übernimmt üblicherweise Host, Hypervisor, Strom, Netzwerk und Hardwaretausch. Prüfen Sie die Supportvereinbarung genau; „Managed Infrastruktur“ heißt nicht automatisch „wir patchen Ihren Server“.