TCO für Unternehmens-VPN: Cloud vs. On-Premises für 100, 500 und 1000 Nutzer
Umfassender Leitfaden zur Berechnung des TCO für Unternehmens-VPNs. Wir vergleichen Cloud- und On-Premises-Lösungen für 100, 500 und 1000 Nutzer, bieten Formeln, Checklisten, Optimierungsstrategien, Fallstudien und Antworten auf komplexe Fragen. Berücksichtigt werden CAPEX, OPEX, Risiken, SLA und Trends für 2026.
Inhalt des Artikels
- Einleitung: warum das thema relevant ist und was sie erfahren
- Grundlagen: grundlegende konzepte zu tco und vpn-architektur
- Vertiefung: kostentreiber, leistung und risiken
- Methode 1. tco-framework: formeln, struktur und ablauf
- Methode 2. tco-berechnung: 100, 500 und 1000 nutzer (cloud vs. on-prem)
- Methode 3. techno-ökonomische dimensionierung: infrastruktur richtig dimensionieren
- Methode 4. tco-rechner erstellen: artefakte und templates
- Methode 5. umsetzung in der cloud: schritt für schritt
- Methode 6. umsetzung on-premises: schritt für schritt
- Methode 7. tco-optimierung: 12 hebel für kostenersparnis
- Typische fehler: was bei tco und architektur zu vermeiden ist
- Tools und ressourcen: praktische empfehlungen
- Fallstudien und ergebnisse: wie zahlen die wahl beeinflussen
- Faq: häufig gestellte fragen
- Fazit: zusammenfassung und nächste schritte
Einleitung: Warum das Thema relevant ist und was Sie erfahren
Das Unternehmens-VPN bleibt auch im Zeitalter von Zero Trust und SASE die Grundlage für Remote-Zugriff und Interoffice-Konnektivität. In der Praxis entscheidet jedoch nicht die Technologie an sich, sondern die Gesamtbetriebskosten (TCO) über Architektur und Plattformwahl. Wie sieht der TCO für Cloud- und On-Premises-VPN-Lösungen im Jahr 2026 bei 100, 500 und 1000 Nutzern aus, unter Einbeziehung von Leistung, Verschlüsselung, Redundanz, Support, Compliance-Anforderungen und versteckten Betriebskosten? In diesem Leitfaden berechnen wir systematisch die Gesamtbetriebskosten für typische Szenarien, liefern verifizierbare Formeln und Frameworks, geben Schritt-für-Schritt-Anleitungen zur Bewertung und Optimierung, zeigen Fallbeispiele und typische Stolperfallen. Am Ende steht Ihr eigenes vertrauenswürdiges TCO-Modell für Budgetplanung und technische Architektur.
Grundlagen: Grundlegende Konzepte zu TCO und VPN-Architektur
Was ist TCO für VPN
TCO (Total Cost of Ownership) umfasst die Gesamtkosten über einen definierten Zeitraum (typisch 36–60 Monate) inklusive CAPEX (Hardware, zeitlich unbefristete Lizenzen, Implementierung), OPEX (Wartung, Support, Abonnements, Strom, Rackspace, Traffic) sowie Risiko- und Ausfallkosten (SLA-Strafen, entgangene Umsätze, Reputations- und Compliance-Verluste). Bei VPN-Projekten entfallen oft bis zu 60 Prozent des TCO auf Betrieb und Personal, während die Technologiekosten vom gewählten Protokoll, Tunnel-Architektur und Traffic-Profil abhängen.
Kernarchitekturen und Begriffe
- Remote Access VPN: Nutzer verbinden sich mit Clients (WireGuard, OpenVPN, IKEv2, SSTP, L2TP) mit einem Zugangsknoten.
- Site-to-Site VPN: Vernetzung zwischen Standorten, Rechenzentren und Clouds.
- Full Tunnel vs. Split Tunnel: Im Full Tunnel läuft der gesamte Nutzerverkehr über das VPN, beim Split Tunnel nur Unternehmenssubnetze und -anwendungen.
- Cloud VPN: Deployment in IaaS oder als Managed VPN Service beim Provider. Zahlung erfolgt für Rechenressourcen, Traffic, öffentliche IPs und Support.
- On-Premises: Eigene Infrastruktur im Rechenzentrum oder Büro mit Servern oder Hardware-Gateways, Kommunikationsleitungen, Stromversorgung und Betrieb vor Ort.
- Protokolle: WireGuard (modern, leistungsstark), OpenVPN (bewährt), IKEv2/IPsec (Standard für S2S und Unternehmenskunden), SSTP und L2TP für Kompatibilität.
Nutzungsdauer und Abschreibung
Für On-Premises-Hardware sind 3–5 Jahre Abschreibung typisch. Bei Cloud hängt die Nutzungsdauer von Reservierungsmodellen, Lastoptimierung und möglicher Migration zwischen Instanzen ab. Planen Sie für die TCO-Berechnung mit einem Zeithorizont von 36 Monaten und ergänzend 60 Monaten, um Sensitivitäten zu erkennen. So sehen Sie, wie Equipment-Austausch und Lastentwicklung die Wahl beeinflussen.
Vertiefung: Kostentreiber, Leistung und Risiken
TCO-Treiber
- Leistung und Skalierung: Anzahl gleichzeitiger Verbindungen, kryptografische Last, Bandbreite pro Nutzer, Lastspitzen (Videokonferenzen, Updates).
- Zuverlässigkeit und Verfügbarkeit: HA-Cluster, aktiv-aktiv oder aktiv-passiv, Geo-Redundanz, RTO und RPO. Höhere SLA-Levels erhöhen Kosten für zusätzliche Knoten und Leitungen.
- Sicherheit und Compliance: MFA, PKI, HSM, Audits, Protokolle in SIEM, DLP, Branchenanforderungen. Jeder Kontrollmechanismus steigert Komponenten- und Betriebskosten.
- Betriebliche Reife: Automatisierung (IaC), Monitoring, Updates, Ausfalltests, Dokumentation und Schulung. Reduziert Vorfälle, benötigt jedoch Expertenzeit.
- Traffic und Routing: Split- vs. Full-Tunnel verändern massiv Egress-Kosten in der Cloud und Kapazitätsanforderungen On-Premises.
- Lizenzen und Support: Kommerzielle Stacks, Vendor-Support, Premium-Cloud-Pläne vs. Open Source und eigene Expertise.
2026 Lastmodellierung: Änderungen im Überblick
- Mehr Videokommunikation und interaktive Apps mit höheren Spitzenanforderungen an Bandbreite und Jitter-Empfindlichkeit.
- Breite Akzeptanz von WireGuard dank besserer Kern-Leistung und vereinfachter Kryptografie.
- Strengere Audit-Anforderungen: Verbindunglogs 180–365 Tage speichern, Korrelierung mit EDR und IdP, MFA als Standard.
- Zunahme hybrider Topologien: Teil der Nutzer geht über SASE, andere über VPN (z. B. für sekundäre Systemzugänge).
Risiko-basierter Ansatz
Im TCO berücksichtigen Sie Kosten von Ereignissen: Ein Ausfall des VPN-Zugangs für 2 Stunden im Arbeitstag kann zehntausende Dollar entgangener Produktivität kosten. Bei Online-Verkauf erhöhen verlorene Transaktionen die Summe. Rechnen Sie mit erwarteten Kosten: Eintrittswahrscheinlichkeit multipliziert mit Schaden. Architekturelemente (HA, aktiv-aktiv) senken Wahrscheinlichkeit und/oder Schaden, erhöhen aber den Basis-TCO. Der optimale Punkt ist ein ausgewogener Kompromiss.
Methode 1. TCO-Framework: Formeln, Struktur und Ablauf
Kostenstruktur
- CAPEX: Hardware (Server, NIC, HSM), unbefristete Lizenzen, Implementierung und Migration.
- OPEX: Cloud-Instanzen, Egress-Traffic, IP-Adressen, Rackspace und Strom, DIA-Leitungen, Vendor-Support, Abos (MFA), Redundanz, Monitoring und SIEM.
- Personalkosten (PeopleEx): FTE für Betrieb (NOC, NetSec), Rufbereitschaft, Schulung und Dokumentation.
- Risikokosten (RiskEx): Erwartete Verluste durch Ausfälle und Security-Incidents, Compliance-Strafen.
Formeln
TCO = (CAPEX / Lebensdauer) + OPEX + PeopleEx + RiskEx. Zur Vereinheitlichung wird CAPEX als monatliche Abschreibung dargestellt. Unit Economics: CPUU Kosten pro Nutzer und Monat = TCO / Nutzerzahl. CPGb Kosten pro Gbps Kapazität = (monatliche Ressourcenkosten) / bereitgestellte Bandbreite. CPConn Kosten pro gleichzeitige Verbindung = (Kosten) / max. gleichzeitige Verbindungen.
Lastparameter
- Gleichzeitigkeit: 20–40 % der Nutzer sind gleichzeitig aktiv (30 % als Durchschnitt bei Büroangestellten). Spitzen sollten mit Faktor 1,5–2,0 über dem Mittelwert simuliert werden.
- Traffic-Profil: Split Tunnel 10–20 GB pro Nutzer und Monat; Full Tunnel 40–80 GB. Basisannahmen: 15 GB bzw. 60 GB.
- Spitzengeschwindigkeit pro aktivem Nutzer: 2–5 Mbit/s im Bürogebrauch, 5–8 Mbit/s bei HD-Video. Für Berechnung: 5 Mbit/s Spitze, 2,5 Mbit/s als 50 % Headroom.
Checkliste für Eingangsdaten
- Nutzerzahl, geforderte SLA (z. B. 99,9 %), regulatorische Anforderungen.
- Split- vs. Full-Tunnel, Anteil Mac/Windows/Linux, mobile Clients.
- Protokolle: standardmäßig WireGuard, OpenVPN/IKEv2 für Kompatibilität.
- Geographie und Latenzen: Standort von Nutzern und Anwendungen.
- Vorhandene Kommunikationsleitungen und Rechenzentren.
- Automatisierungsgrad und Kompetenzen des Teams.
Methode 2. TCO-Berechnung: 100, 500 und 1000 Nutzer (Cloud vs. On-Prem)
Allgemeine Vergleichsannahmen
- Zeithorizont: 36 Monate. Währung: USD als neutrale Basis (Kursanpassung je Region bei Implementierung).
- MFA: 1 USD pro Nutzer und Monat (oft bereits Teil der Unternehmenslizenz, hier als VPN-Projekterweiterung berücksichtigt).
- SIEM und Auditing: 150–300 USD pro Monat je nach Umfang (wenig Logs, aber Retention und Korrelation erforderlich).
- Personalkosten: 100.000 USD pro Jahr voll belastet pro FTE für Netzwerksicherheit (8.333 USD/Monat). In der Cloud geringer FTE-Anteil wegen weniger Hardwarebetrieb.
- WireGuard als Hauptprotokoll für Kapazität, OpenVPN und IKEv2 für Kompatibilität.
- Gleichzeitigkeit: 30 % aktiv; Spitzenlastfaktor 2x für Kapazität.
Kapazitätsmodellierung
- 100 Nutzer: 30 aktiv. Spitze 30 × 5 Mbit/s × 2 = 300 Mbit/s (Full). Bei Split ca. 40 % Last, ca. 120 Mbit/s.
- 500 Nutzer: 150 aktiv. Spitze 150 × 5 × 2 = 1500 Mbit/s (1,5 Gbit/s Full). Split ca. 600 Mbit/s.
- 1000 Nutzer: 300 aktiv. Spitze 300 × 5 × 2 = 3000 Mbit/s (3 Gbit/s Full). Split ca. 1200 Mbit/s.
Cloud: monatliche Kosten
Komponenten: Compute-Instanzen (HA 2–6 Knoten), Egress-Traffic (0,06 USD/GB mit Rabatten), IPs & Storage (20–80 USD), Provider-Support (300–800 USD), Betrieb (0,2–0,6 FTE), MFA (1 USD pro Nutzer), SIEM (50–300 USD). Optimierung bzgl. Instanzenanzahl und regionale Nähe zu Nutzern angenommen.
100 Nutzer
- Instanzen: 2 × C-Class Medium je 68 USD = 136 USD.
- Traffic: Split 1,5 TB ≈ 92 USD; Full 6 TB ≈ 369 USD.
- IP & Storage: 20 USD.
- Support: 300 USD.
- Betrieb: 0,2 FTE ≈ 1667 USD.
- MFA: 100 USD.
- SIEM & Audit: 50 USD.
Gesamt Cloud 100: Split ≈ 2398 USD/Monat (≈ 24 USD/Nutzer), Full ≈ 2675 USD (≈ 26,8 USD/Nutzer).
500 Nutzer
- Instanzen: Split 400 USD, Full 600 USD (mehr Knoten und/oder höherer Klasse).
- Traffic: Split 7,5 TB ≈ 461 USD; Full 30 TB ≈ 1843 USD.
- IP & Storage: 50 USD.
- Support: 500 USD.
- Betrieb: 0,4 FTE ≈ 3333 USD.
- MFA: 500 USD.
- SIEM: 150 USD.
Gesamt Cloud 500: Split ≈ 5361 USD (≈ 10,7 USD/Nutzer), Full ≈ 6943 USD (≈ 13,9 USD/Nutzer).
1000 Nutzer
- Instanzen: Split 700 USD, Full 900 USD.
- Traffic: Split 15 TB ≈ 922 USD; Full 60 TB ≈ 3686 USD.
- IP & Storage: 80 USD.
- Support: 800 USD.
- Betrieb: 0,6 FTE ≈ 5000 USD.
- MFA: 1000 USD.
- SIEM: 300 USD.
Gesamt Cloud 1000: Split ≈ 7802 USD (≈ 7,8 USD/Nutzer), Full ≈ 11766 USD (≈ 11,8 USD/Nutzer).
On-Premises: monatliche Kosten
Komponenten: Server/Appliances (36 Monate Abschreibung), DIA-Leitungen (2 Leitungen für Ausfallsicherheit), Rackspace & Strom, Vendor-Support, Betrieb (0,4–1,0 FTE), MFA, SIEM, Ersatzteile. Open Source Stack auf Commodity-Servern angenommen; Kommerzielle Client-Lizenzen separat zuzurechnen.
100 Nutzer
- Server: 2 × 2500 USD = 5000 USD; Abschreibung ca. 139 USD/Monat (inkl. 2000 USD für NIC & Kleinteile).
- DIA-Leitungen: 2 × 500 Mbit/s ≈ 1200 USD.
- Rackspace & Strom: 480 USD.
- Support: 100 USD.
- Betrieb: 0,4 FTE ≈ 3333 USD.
- MFA: 100 USD.
- SIEM & Audit: 150 USD.
- Ersatz & Kleinteile: 100 USD.
Gesamt On-Prem 100: ≈ 5479 USD/Monat (≈ 54,8 USD/Nutzer).
500 Nutzer
- Server: 2 × 4000 USD = 8000 USD plus Kleinteile; Abschreibung ca. 166 USD.
- DIA-Leitungen: 2 × 1 Gbit/s ≈ 2400 USD.
- Rackspace & Strom: 500 USD.
- Support: 200 USD.
- Betrieb: 0,6 FTE ≈ 5000 USD.
- MFA: 500 USD.
- SIEM: 250 USD.
- Ersatz: 150 USD.
Gesamt On-Prem 500: ≈ 9166 USD (≈ 18,3 USD/Nutzer).
1000 Nutzer
- Server: 3 × 5000 USD = 15000 USD plus Kleinteile; Abschreibung ca. 300 USD.
- DIA-Leitungen: 2 × 2 Gbit/s ≈ 4000 USD.
- Rackspace & Strom: 600 USD.
- Support: 300 USD.
- Betrieb: 1,0 FTE ≈ 8333 USD.
- MFA: 1000 USD.
- SIEM: 400 USD.
- Ersatz: 200 USD.
Gesamt On-Prem 1000: ≈ 15133 USD (≈ 15,1 USD/Nutzer).
Fazit Grundvergleich
- Bei allen drei Größenordnungen ist die Cloud mit Split Tunnel günstiger als On-Prem, besonders bei 100 und 500 Nutzern.
- Full Tunnel in der Cloud bleibt bis 1000 Nutzer konkurrenzfähig dank FTE-Einsparung und fehlenden DIA-Leitungen im Rechenzentrum, wird aber durch höheren Egress-Traffic deutlich teurer.
- On-Prem punktet nur, wenn bereits bezahlte DIA-Leitungen und Rechenzentrumsfläche vorhanden sind, hohe interne Expertise verfügbar ist und die administrative Zusatzlast maximal 0,2–0,3 FTE beträgt. Dann sinkt der TCO für 1000 Nutzer auf 9–11 USD pro Nutzer und Monat.
Alternative Sensitivitätsszenarien
- Wenn DIA-Leitungen bereits vorhanden sind (keine Kosten): On-Prem 1000 Nutzer fällt auf ≈ 11133 USD (≈ 11,1 USD/Nutzer).
- Bei höheren FTE-Kosten (z. B. 140.000 USD/Jahr): steigen Cloud-Kosten weniger als On-Prem, da FTE-Anteil in der Cloud geringer ist.
- Bei Einschluss kommerzieller VPN-Lizenzen (20–40 USD pro Nutzer/Jahr): steigen Cloud und On-Prem, aber bei 500–1000 Nutzern trifft es On-Prem wegen DIA stärker.
- Wenn Egress in der Cloud teurer ist (0,09 USD/GB): Full Tunnel bei 1000 Nutzern erhöht Traffickosten um ≈ 1843 USD, nähert sich On-Prem an.
Methode 3. Techno-ökonomische Dimensionierung: Infrastruktur richtig dimensionieren
Protokollleistung
- WireGuard: Lineare Skalierbarkeit mit CPU-Kernen, 1–2 Gbit/s pro vCPU auf modernen Hosts mit Krypto-Beschleunigung. Ideal für hohe Nutzerdichte.
- OpenVPN: 200–400 Mbit/s pro Kern mit AES-NI & Optimierungen. Kompatibel, aber weniger effizient.
- IKEv2/IPsec: Stabil für S2S, Leistung nahe WireGuard auf Hardware mit Beschleunigung.
Schrittweise Dimensionierung
- Bestimmen Sie Gleichzeitigkeit und Spitzen-Mbit/s pro aktivem Nutzer.
- Berechnen Sie Spitzenkapazität (aktive × Spitze × Headroom).
- Wählen Sie Protokoll: Für Massenclients WireGuard bevorzugt, für S2S IKEv2/IPsec, für ältere Clients OpenVPN.
- Vergleichen Sie mit Instanzprofilen: Start mit 2 vCPU, skalieren in Schritten zu 4–8 vCPU, prüfen Sie Kryptoleistung und Kontextwechsel.
- Planen Sie HA: Mindestens 2 aktiv-aktive Knoten; für 500+ Nutzer sinnvoll 3–4 Knoten pro Region.
- Prüfen Sie MTU und MSS besonders bei doppelter Einkapselung und S2S; häufig Ursache für Performance-Einbußen.
- Legen Sie Limits für Handshakes und Rate-Limits als DoS-Schutz gegen UDP-Fluten fest.
Monitoring und Nutzererlebnis
- Sammeln Sie Metriken: aktive Sessions, erneute Handshakes, Latenz zu Anwendungen, Paketverlustrate, Bandbreite pro Nutzer. Visualisieren Sie in Grafana.
- Erkennen Sie Anomalien: Traffic-Spitzen, ungewöhnliche Länder, mehrfach fehlgeschlagene Logins – automatisieren Sie SOC-Playbooks.
- Testen Sie Ausfälle: Knoten- und Regionsausfälle, plötzliche Lastspitzen von 30–50 %.
Methode 4. TCO-Rechner erstellen: Artefakte und Templates
Input Template
- Nutzerzahl, Anteil aktiv, Split vs. Full, GB pro Nutzer.
- Protokollanteile nach Clienttypen.
- Regionenliste, Latenzen, Anforderungen an HA und DR.
- Preise für Instanzen, Leitungen, Rackspace, Strom, FTE-Kosten.
Berechnete Felder
- Spitzenkapazität, Knotenanzahl pro Region, Gesamtkosten Instanzen.
- Egress-Traffic und Kosten.
- CAPEX-Abschreibung und OPEX.
- Personalanteile: FTE und Rufbereitschaft.
- RiskEx: Wahrscheinlichkeit × Schaden für 2–3 zentrale Szenarien.
Schritt-für-Schritt-Anleitung
- Sammeln Sie Baseline für 1 Monat im Pilot: Nutzeraktivität, GB, Spitzen-Mbit/s.
- Wenden Sie Wachstumsfaktoren an (Saisonalität, Neueinstellungen, neue Apps).
- Simulieren Sie 2 Szenarien: 100 % Split und 100 % Full – obere und untere Grenze.
- Fügen Sie HA und DR atopisch auf Knotenzahlen ein.
- Detailieren Sie FTE: Administration, Automatisierung, Erstlinient-Support.
- Führen Sie Stresstest durch und passen Sizing an.
- Erstellen Sie Gesamt-TCO-Modell für 36 Monate und Unit-Economics pro Nutzer.
Methode 5. Umsetzung in der Cloud: Schritt für Schritt
Ziele und Kriterien
- SLA 99,9 %, RTO 15 Minuten.
- Standard Split Tunnel, Full Tunnel für privilegierte Rollen und Richtlinien.
- MFA und Anbindung an IdP (SAML/OIDC).
Schritte
- Wählen Sie Regionen der Instanzen nahe bei Nutzern.
- Deploy 2–4 Knoten WireGuard/OpenVPN aktiv-aktiv, balancieren Sie mit L4/UDP-fähigen Loadbalancern.
- Automatisieren Sie Konfiguration über IaC und Client-Config-Templates.
- Setzen Sie Split-Routen und Gruppenrichtlinien (HR, Dev, Finance).
- Integrieren Sie MFA und Schlüssel-/Zertifikats-Rotation.
- Aktivieren Sie zentrales Logging im SIEM, Alerts bei Anomalien.
- Führen Sie Lasttests durch und rollen Sie Canary-Deployments aus.
Checkliste
- Tests bei Knoten- und Region-Ausfällen.
- Verfahren für Schlüsselrotation und Widerruf.
- Dokumentation für L1/L2-Support.
- Regelmäßige Prüfung von Egress und Reserved/Committed Discounts.
Methode 6. Umsetzung On-Premises: Schritt für Schritt
Ziele und Kriterien
- Niedrige Latenz zu internen Systemen, Kontrolle über Leitungen.
- Flexibler Einsatz von HSM/PKI und Einhaltung branchenüblicher Standards.
Schritte
- Wählen Sie Rechenzentrumsstandort und richten Sie 2 unabhängige DIA-Verbindungen ein.
- Kaufen Sie 2–3 Server mit AES-NI, 10G NIC und redundanter Stromversorgung.
- Deploy WireGuard/IKEv2 auf Hypervisoren oder Bare Metal, konfigurieren aktiv-aktiv.
- Implementieren Sie Split-Routing, bei Bedarf route-basiertes IPsec zu externen Clouds.
- Integrieren Sie MFA, IdP, zentrales Logging und HSM/TPM für Schlüsselmanagement.
- Errichten Sie Monitoring und Konfigurations-Backup.
- Testen Sie Ausfälle: DIA-Ausfall, Knoten-Down, Routing-Degradation.
Checkliste
- Kommerzielle und Open Source Lizenzen, Supportbedingungen und Lieferzeiten.
- SLA mit Leitungsanbietern, Vereinbarungen zur Reparaturzeit.
- Spare-Verfahren: Ersatz-NIC, Backup-Server, Firmware-Kompatibilitätsprüfungen.
Methode 7. TCO-Optimierung: 12 Hebel für Kostenersparnis
- Standard Split Tunnel mit Full Tunnel nur für definierte Rollen. Spart Egress- und Leitungsressourcen.
- WireGuard als Basisprotokoll: Höhere Leistung pro Kern, weniger CPU und Knoten.
- Geo-Lokalisierung der Knoten: Niedrigere RTT erhöht Verbindungseffizienz und reduziert Spitzenbandbreite.
- Reserved/Committed Discounts für Cloud-Instanzen und Egress.
- Automatische Skalierung während Spitzenzeiten.
- SaaS-Traffic-Routing direkt (lokales Breakout) statt Umweg über Rechenzentrum.
- Unified Clients mit usergruppenbasierten Konfigurationen und Richtlinien.
- Kontinuierliches Performance-Testing und MSS/MTU-Optimierung.
- Reduktion von FTE durch IaC, GitOps und fertige Deployment-Module.
- Log-Aggregation und smarte Retention (länger Metadaten, kürzer detaillierte Logs mit Archivierung).
- Leitungseinkauf mit Burst-Fähigkeit und SLA für Jitter/Latenz.
- Richtiges Keepalive-Setting, um unnötig aktive Verbindungen zu vermeiden.
Typische Fehler: Was bei TCO und Architektur zu vermeiden ist
- Ignorieren von Gleichzeitigkeit und Spitzen: Berechnung mit Mittelwerten ohne Headroom führt zu Überlastungen und Ausfällen.
- Falsche Protokollwahl: OpenVPN dort, wo WireGuard oder IKEv2 nötig sind, erhöht Knotenanzahl und Kosten.
- Unbegründeter Full Tunnel: Verdreifacht Egress-Kosten und Leitungskosten.
- Keine HA oder Leitungsredundanz: Einsparungen von wenigen zehn Dollar verursachen Ausfälle im vierstelligen Bereich.
- Unberücksichtigter Betrieb: FTE und Rufbereitschaft sind oft teurer als erwartet. Dokumentation und Automatisierung zahlen sich aus.
- Kommerzielle Lizenz ohne TCO-Rational: Pro-Nutzer-Kosten verdoppeln TCO dort, wo Open Source plus Expertise reichen.
- Suboptimale Geographie: Knoten fern vom Nutzer erhöhen Latenz und unproduktive Kapazitätskosten.
Tools und Ressourcen: Praktische Empfehlungen
Protokoll- und Server-Stack
- WireGuard für performanten User Access und S2S.
- OpenVPN für Kompatibilität zu Legacy-Clients und speziellen Proxy-Szenarien.
- strongSwan/Libreswan für IKEv2/IPsec, insbesondere S2S und BGP-over-IPsec.
- SoftEther als Multi-Protokoll-Variante mit fortschrittlicher NAT-Traversal.
Management und Automatisierung
- Infrastructure as Code: Terraform/Ansible für Deployment von Knoten und Richtlinien.
- CI/CD für Konfigurationen: GitOps, Review von Routing-Regeln und ACLs.
- Monitoring: Prometheus, Grafana, Exporter für WireGuard/OpenVPN.
- Sicherheit: Zertifizierungszentrum (PKI), IdP-Integration (AD/Entra, Okta, Keycloak), MFA als Standardpolicy.
- Logs: Zentralisierung im SIEM, Normalisierung der Formate, Überwachung von fehlgeschlagenen Logins und Geoanomalien.
Praktische Lösung für Pilotprojekte und schnelle PoCs
Wenn Sie Hypothesen validieren, Split vs. Full abwägen, reale Last messen und Baselines ohne lange Einkaufszyklen sammeln möchten, bietet sich der Service vpn.how an. Ein persönlicher VPN-Server (kein Shared, eigene IP), mit Unterstützung für WireGuard, OpenVPN, IKEv2, L2TP, SSTP, Auswahl passend zur Aufgabe, Serverstandorte in Moskau, St. Petersburg, Amsterdam, Frankfurt, London, New York, San Jose, Chicago, Singapur, Sydney, Madrid, Helsinki, Stockholm, Warschau, Kopenhagen, Stavanger; Zahlungsoptionen mit russischen Karten (inkl. Tinkoff und Ozon), SBP, USDT/BTC; Tarife ab 490 RUB pro Tag und 2490 RUB pro Monat mit Rabatten für längere Laufzeiten; automatische Bereitstellung binnen 5 Minuten nach Zahlung und kein Logging. Ideal für Piloten und PoCs: schnelle Knotenbereitstellung, Traffic-Metriken, Client-Kompatibilität und Routing-Policy testen. Für den langfristigen Betrieb empfiehlt sich der Wechsel zu eigener Infrastruktur (Cloud oder On-Prem) oder zertifizierten Lösungen wie GOST-VPN, je nach Sicherheits- und Compliance-Anforderungen.
Fallstudien und Ergebnisse: Wie Zahlen die Wahl beeinflussen
Fall 1: 100 Nutzer, verteiltes Entwicklungsteam
Aufgabe: Sicherer Zugang zu Git, CI, Staging. Anforderungen: Split Tunnel, 99,9 % SLA, WireGuard. Ergebnis: Cloud 2398 USD/Monat (24 USD/Nutzer), On-Prem 5479 USD (54,8 USD). Entscheidung: Cloud mit 2 Knoten und IaC. Von Pilot bis Produktionsreife: 2 Wochen. 55 % Kosteneinsparung gegenüber On-Prem. Automatisierungs-ROI (Ansible + CI/CD) nach 3 Monaten durch FTE-Reduzierung von 0,3 auf 0,2.
Fall 2: 500 Nutzer, Fintech, kompletter Traffic-Filter
Aufgabe: Full Tunnel über Corporate Backbones mit Inspektion und Logging. Ergebnis: Cloud 6943 USD/Monat, On-Prem 9166 USD. Überraschung: Egress stark gestiegen, aber FTE-Kosten weiterhin Cloud-vorteilhaft. Entscheidung: Hybridmodell. 60 % Nutzer split (SaaS direkt), 40 % Full Tunnel mit Inspektion in der Cloud. Gesamtmonatliche Kosten gesenkt auf ≈ 5600 USD.
Fall 3: 1000 Nutzer, Fertigungsunternehmen, niedrige Latenz zu MES
Aufgabe: Zugang zu internen Anwendungen im Rechenzentrum mit minimaler Verzögerung. Pilot: Cloud-Knoten nahe Fabriken boten akzeptable Leistung, aber Full Tunnel Egress für einige Nutzer verursachte erhebliche Kosten. Ergebnis: On-Prem mit bezahlten DIA-Leitungen und Rackspace reduzierte TCO auf 11 USD pro Nutzer. Entscheidung: On-Prem mit WireGuard und IKEv2 für S2S, hybrid für reisende Mitarbeiter.
FAQ: Häufig gestellte Fragen
1. Kann man TCO ohne Ausfallzeiten und Sicherheitsrisiken berechnen?
Technisch ja, aber das ist ein falscher Maßstab: Ausfälle in Spitzenzeiten können die ersparte Jahreskosten durch billigere Varianten schnell auffressen. Mindestens zwei Risikoszenarien mit Wahrscheinlichkeits- und Schadensabschätzung einbeziehen.
2. Wie kritisch ist die Protokollwahl für den TCO?
Sehr. WireGuard schafft gleiche Last mit weniger CPU-Kernen, senkt damit Knoten- und Energiebedarf. Ab 500+ Nutzern kann das bis zu 20–30 % Computerkosten sparen.
3. Ist Split Tunnel für Unternehmen sicher?
Ja, bei korrekter Routenpolitik, verpflichtendem MFA, Gerätekontrolle (MDM/EDR) und Inspektion nur des Firmenverkehrs. Full Tunnel ist für privilegierte Rollen, Admins und strenge Compliance-Szenarien sinnvoll.
4. Was beeinflusst den Cloud-TCO mehr: Compute oder Egress?
Bis 500 Nutzer dominieren Compute und FTE. Ab 500 bei Full Tunnel wird Egress vergleichbar oder höher, besonders ohne Rabatte und SaaS-Direktrouting.
5. Wann gewinnt On-Prem eindeutig?
Wenn bezahlte DIA-Leitungen und Rackspace vorliegen und erfahrenes Team die Laststeigerung mit 0,2–0,3 FTE trägt. Oder wenn Compliance Hardware-Module und strikte Isolation erfordert.
6. Wie kalkuliert man benötigte Knotenzahl?
Ausgehend von Spitzenbandbreite und Zielknotenauslastung (max. 60–70 %), multipliziert mit HA-Faktor. Tests im Piloten und 20 % Puffer für Lastspitzen einbauen.
7. Wie steht es um IPv6?
IPv6 verbessert Stabilität und Leistung in Mobilnetzen, erhöht aber Komplexität bei Routing und Policies. Stellen Sie sicher, dass Clients und Server IPv6 unterstützen, sowie ACLs und SIEM dual-stack-fähig sind.
8. Wie behandelt man kommerzielle VPN-Client-Lizenzen?
Mit monatlichem Aufpreis pro Nutzer kalkulieren und mit Open Source plus Supportkosten vergleichen. Oft durch Kompatibilität und bessere Telemetrie gerechtfertigt.
9. Kann man Protokolle mischen?
Ja, üblich und sinnvoll. WireGuard als Standard, OpenVPN für Kompatibilität, IKEv2 für S2S und manche mobile Clients. Verteile Anteile im TCO-Rechner.
10. Wie erkennt man Überzahlung für Egress?
Beobachten Sie GB pro Nutzer und Monat. Bei Full Tunnel über 80–100 GB ohne erklärbaren Grund sollten SaaS-Routen und Content-Caching geprüft und bei nicht-kritischen Apps Split angewendet werden.
Fazit: Zusammenfassung und nächste Schritte
Die Betriebskosten von Unternehmens-VPNs werden durch Architektur, Protokoll und Betriebsexzellenz bestimmt, nicht den Anbieternamen. Über 36 Monate ist Cloud bei Split Tunnel bis 1000 Nutzer meist günstiger als On-Prem, dank geringerem FTE-Anteil und Verzicht auf CAPEX. Full Tunnel in der Cloud verlangt Disziplin bei Egress und SaaS-Routing, sonst wächst der TCO rasant. On-Prem punktet mit bezahlten Leitungen, eigenem Team und strikten Isolationsvorgaben. Der beste Weg: Hypothesen im Piloten testen, Metriken sammeln und TCO für Produktionsarchitektur mit klaren SLA und Prozessen fixieren. Ihre nächsten Schritte: 1) Pilot innerhalb 1–2 Wochen aufbauen, Last und Egress messen; 2) TCO-Rechner nach Leitfaden aufsetzen; 3) Split als Default-Strategie, WireGuard als Basisprotokoll, HA als Muss wählen; 4) Optimierung mit Automatisierung, Monitoring und gezielter Standortwahl managen. So erreichen Sie Planungssicherheit, beherrschbare Risiken und stabile User-Experience – VPN wird vom Blackbox-Risiko zur kalkulierbaren Investition.
Herausgeber: vpn.how