Fallstudie: Private Cloud-Anbindung für eine Holding mit drei Rechtseinheiten und hybrider Infrastruktur

Private Cloud-Anbindung – eine dedizierte private Leitung außerhalb des öffentlichen Internets, die die Unternehmensinfrastruktur direkt mit Cloud-Plattformen verbindet – ist nicht länger das exklusive Domänen großer Konzerne. New Telekom s.r.o. realisierte über seinen Dienst CloudConnect eine private Cloud-Anbindung für eine tschechisch-slowakische Holding mit drei Rechtseinheiten, Hauptsitz in Prag, einer Niederlassung in Ostrau und hybrider Cloud-Infrastruktur, verteilt auf ein eigenes Colocation-Rechenzentrum in Prag, Microsoft Azure Westeuropa und AWS eu-central-1 (Frankfurt). Das Ergebnis: eine private MPLS-VPN-Verbindung, die alle drei Einheiten, beide Clouds und beide Standorte bedient – unter einem einzigen Vertrag mit New Telekom, mit 99,9 % SLA und 44 % Einsparung bei den gesamten Egress-Kosten.

Was ist eine private Cloud-Anbindung und warum ist sie wichtig?

Eine private Cloud-Anbindung ist eine physisch dedizierte Datenleitung, die ein Unternehmensnetzwerk oder Rechenzentrum direkt mit Cloud-Plattformen verbindet – Microsoft Azure (ExpressRoute), AWS (Direct Connect) oder Google Cloud (Cloud Interconnect) – ohne auf irgendeinem Segment der Strecke das öffentliche Internet zu durchlaufen. Im Gegensatz zu einem VPN-Tunnel über das Internet ist es kein verschlüsselter Pfad über eine gemeinsam genutzte Infrastruktur, sondern eine physisch dedizierte Übertragungskapazität mit garantierten Parametern. Für Unternehmen, die sensible Geschäftsdaten, Kundeninformationen übertragen oder Produktionsanwendungen in der Cloud betreiben, bringt eine private Anbindung drei spezifische Vorteile: konstante Leistung unabhängig vom Zustand des öffentlichen Internets, Sicherheitsisolierung ohne Datenverkehr über unkontrollierte Transitknoten und deutlich niedrigere Egress-Kosten dank Vorzugstarifen der Cloud-Anbieter für Verkehr über dedizierte Leitungen.

Wer war der Kunde und was erschwerte seine Situation?

Der Kunde – eine Holding, die drei Rechtseinheiten (Muttergesellschaft und zwei Tochtergesellschaften) in den Bereichen Finanzberatung, Immobilienverwaltung und IT-Beratung umfasst – betrieb für jede Einheit separaten Cloud-Zugang: drei verschiedene Azure-Abonnements, zwei AWS-Organisationen, und jede Einheit hatte ihren Cloud-Zugang historisch separat gelöst – über das öffentliche Internet mit kommerziellen VPN-Clients. Der resultierende Zustand war betrieblich nicht nachhaltig:

• Fünf separate Verträge mit verschiedenen Anbietern für Konnektivität und Cloud-Zugang
• Unkontrollierte Egress-Kosten – jede Einheit zahlte separate Standard-Cloud-Egress-Tarife, ohne Möglichkeit der Volumenverhandlung
• Sicherheitsheterogenität – drei verschiedene VPN-Clients von drei verschiedenen Anbietern mit unterschiedlichen Verschlüsselungsstufen und unterschiedlichen Audit-Logs
• Compliance-Problem – zwei der Einheiten unterlagen Pflichten gemäß Gesetz Nr. 264/2025 Slg. (NIS2) und mussten eine überprüfbare Transportarchitektur nachweisen; der Datentransfer über drei verschiedene kommerzielle VPNs über das öffentliche Internet ermöglichte diese Dokumentation nicht

Der Kunde suchte eine Lösung, die den Cloud-Zugang für die gesamte Holding unter einer technischen Architektur und einem Vertrag konsolidiert – unter Wahrung der rechtlichen Trennung der drei Einheiten (keine Datenweitergabe zwischen den Einheiten auf Netzwerkebene).

Wie entwickelte New Telekom die private Cloud-Anbindung für die Holding?

Architektur: ein Port, drei VRFs, zwei Clouds

Die entscheidende Designentscheidung war die Verwendung von MPLS-VPN-Technologie mit separaten VRF (Virtual Routing and Forwarding)-Instanzen – dieselbe physische CloudConnect-Leitung trägt drei logisch völlig isolierte private Anbindungen, eine für jede Holding-Einheit. Auf der Netzwerkebene gibt es keinen Pfad zwischen VRF-Instanzen – der Verkehr von Einheit A ist für Einheiten B und C weder sichtbar noch zugänglich, selbst wenn sie dieselbe physische Verbindung teilen. Prag – Holding-Hauptsitz: Primärer physischer Knoten. CloudConnect-Leitung mit 2 Gbit/s Kapazität terminiert im Colocation-Rechenzentrum der Holding in Prag. Von diesem Knoten laufen drei logisch getrennte VRF-Instanzen:

• VRF-A (Muttergesellschaft) – private Anbindung an Microsoft Azure ExpressRoute, Region Westeuropa; Kapazität 1 Gbit/s
• VRF-B (Finanzberatung) – private Anbindung an AWS Direct Connect, Region eu-central-1 (Frankfurt); Kapazität 500 Mbit/s
• VRF-C (Immobilienverwaltung) – private Anbindung an Microsoft Azure ExpressRoute, dieselbe Region Westeuropa wie VRF-A, aber vollständig separate BGP-Session und separate virtuelle Netzwerke (VNets) in Azure; Kapazität 500 Mbit/s

Ostrau – Holding-Niederlassung: Die Niederlassung in Ostrau ist über eine MPLS-VPN-Leitung von New Telekom an den Prager Knoten angebunden und greift über die in Prag terminierte CloudConnect-Leitung auf Azure und AWS zu – ohne einen zweiten physischen CloudConnect-Endpunkt. Der gesamte Cloud-Verkehr von Ostrau geht zunächst über die private MPLS-WAN-Verbindung nach Prag und von dort über CloudConnect in die Cloud – der gesamte Pfad bleibt privat, ohne das öffentliche Internet zu durchlaufen.

Warum ein Port und nicht drei separate CloudConnect-Leitungen?

Die naheliegende Lösung – drei separate CloudConnect-Leitungen für drei Einheiten – würde funktionieren, wäre aber unnötig teuer und komplex. Die VRF-Architektur auf einer einzigen physischen Leitung bringt:

• Niedrigere Gesamtkosten – eine physische Verbindung, ein Port, ein Vertrag
• Einfachere Verwaltung – ein Monitoring, eine Eskalationsmatrix, ein Ansprechpartner
• Dieselbe Sicherheitsisolierung wie drei separate Leitungen – VRF auf MPLS-Ebene bietet strikte logische Isolation; netzwerkseitiges Eindringen zwischen Einheiten ist architektonisch ausgeschlossen
• Flexible Neuzuteilung der Kapazität – bei geringer Auslastung von Einheit B kann die verfügbare Kapazität für Einheit A vorübergehend erhöht werden, ohne physischen Eingriff

Was wurde physisch implementiert?

Prag – Colocation-Rechenzentrum

• Dediziertes OS2-Einmoden-Glasfaserpaar vom Verteilungsknoten New Telekom Prag zum Rack-Bereich der Holding, Länge 520 Meter, Dämpfung 1,6 dB, Terminierung LC/APC
• Juniper MX480 – Backbone-Router mit 960 Gbit/s Kapazität, drei separate VRF-Instanzen, BGP-Sessions zu Cloud-Zugangsknoten separat für jede Einheit, QoS DiffServ pro VRF, IPv4/IPv6-Dual-Stack; physisch im Rack-Bereich der Holding platziert
• Juniper EX4650 – Core-Switch mit 10GbE-Ports für die Verbindung der Serverinfrastruktur jeder Einheit mit der jeweiligen VRF
• Fortinet FortiGate 600F – NGFW-Firewall; separate Sicherheitszone und Richtlinie für jede VRF der Einheit; IPS, Anwendungskontrolle, Audit-Logs mit 90 Tagen Aufbewahrung, exportiert in SIEM Microsoft Sentinel
• Eaton 9PX 3000VA USV – unterbrechungsfreie Stromversorgung für aktive Komponenten für 40 Minuten

Ostrau – Niederlassung

• MPLS-VPN-Leitung Ostrau—Prag: Kapazität 500 Mbit/s symmetrisch, Latenz < 8 ms, betrieben über das New Telekom-Partnernetzwerk in Ostrau
• Juniper NFX250 – SD-WAN-CPE in Ostrau mit BGP-Session zum Prager Knoten, QoS-Priorisierung des Anwendungsverkehrs, LTE-A Pro-Backup-Verbindung über New Telekom eSIM mit automatischem Failover innerhalb von 10 Sekunden
• Cisco Catalyst 9200 – Access-Switch für das Ostrauer Büro

Konfiguration der Cloud-Zugänge

Microsoft Azure ExpressRoute (VRF-A und VRF-C): zwei separate ExpressRoute Circuits am Peering-Standort Prag (CE Colo Prag) – einer für jede Einheit – mit Private Peering zu den jeweiligen Azure Virtual Networks und Microsoft Peering für den Zugriff auf Azure PaaS-Dienste (Azure Blob Storage, Azure SQL Database, Microsoft 365). BGP-Communities so konfiguriert, dass der Verkehr jeder Einheit immer den ExpressRoute-Pfad dem reservierten Internetpfad vorzieht. AWS Direct Connect (VRF-B): Virtual Private Gateway verbunden über Direct Connect mit der AWS-Region eu-central-1 mit aktiviertem Transit Gateway für den Zugriff auf mehrere VPCs innerhalb der AWS-Organisation von Einheit B. Hosted Connection-Kapazität: 500 Mbit/s.

Welche Parameter erreicht die Anbindung im Betrieb?

Wie veränderten sich die Egress-Kosten nach der Migration auf die private Anbindung?

Vor der Implementierung zahlten die drei Holding-Einheiten Cloud-Egress-Tarife separat, jede für ihren eigenen Verkehr über das öffentliche Internet – die gesamte monatliche Egress-Rechnung über alle Einheiten und Clouds hinweg erreichte etwa 9.500 € pro Monat. Nach der Migration auf die private CloudConnect-Anbindung sanken die Egress-Kosten auf etwa 5.300 € pro Monat – eine Einsparung von 44 %. Die Gründe sind zweifach: Vorzugstarife für ExpressRoute und Direct Connect im Vergleich zu den Standard-Internet-Tarifen und die Volumenkonsolidierung über eine einzige Leitung, die bessere Verhandlungskonditionen ermöglichte. Mit wachsendem Datenvolumen – die Holding plant in den nächsten zwei Jahren eine Erweiterung ihrer Cloud-Umgebung – werden die absoluten Einsparungen bei gleichen prozentualen Sätzen weiter steigen.

Was bedeutet die private Cloud-Anbindung für die NIS2-Compliance der Holding?

Zwei der drei Holding-Einheiten sind verpflichtete Unternehmen gemäß Gesetz Nr. 264/2025 Slg. – Finanzberatung (regulierte Einheit unter Aufsicht der CNB) und IT-Beratung (Anbieter von IKT-Diensten für Einrichtungen der kritischen Infrastruktur). Beide Einheiten müssen technische Maßnahmen für die Datentransportsicherheit gemäß Verordnung Nr. 410/2025 Slg. nachweisen. Die private CloudConnect-Anbindung erfüllt diese Anforderung auf architektonischer Ebene: Der Datentransfer zwischen der Unternehmensinfrastruktur und der Cloud durchläuft nicht das öffentliche Internet – diese Tatsache kann technisch nachgewiesen werden mit einem BGP-Routing-Tabellenauszug, einem Topologiediagramm und der Bestätigung von New Telekom über die Leitungsarchitektur. Für Verzeichnisse von Verarbeitungstätigkeiten personenbezogener Daten gemäß Art. 30 DSGVO (EU-Verordnung 2016/679) handelt es sich um eine konkrete und überprüfbare technische Maßnahme der Transportsicherheit. Separate VRF-Instanzen für jede Einheit stellen zudem sicher, dass sensible Daten der Finanzeinheit (VRF-B) nicht von der Netzwerkinfrastruktur der anderen Einheiten aus zugänglich sind – selbst bei einer gemeinsam genutzten physischen Verbindung. Diese Isolierung ist dokumentierbar und bei einem Sicherheitsaudit überprüfbar.

Häufig gestellte Fragen zu privaten Cloud-Anbindungen

Was ist der Unterschied zwischen einer privaten Cloud-Anbindung und einem VPN über das Internet?

Ein VPN-Tunnel verschlüsselt den Dateninhalt, überträgt ihn aber über das öffentliche Internet – über Infrastruktur Dritter ohne Garantien für Latenz, Kapazität oder Übertragungspfad. Eine private Cloud-Anbindung (CloudConnect) ist ein physisch dedizierter Pfad über das New Telekom-Netzwerk und die Backbone-Infrastruktur des Cloud-Anbieters – Daten nutzen das öffentliche Internet überhaupt nicht. Das Ergebnis sind garantierter Durchsatz, konstante Latenz und eine überprüfbare Sicherheitsarchitektur. Zudem deutlich niedrigere Egress-Tarife im Vergleich zum standardmäßigen Internet-Egress.

Kann ich auf einer einzigen privaten Anbindung gleichzeitig auf AWS und Azure zugreifen?

Ja – und genau das ermöglicht CloudConnect von New Telekom. Von einem einzigen physischen Port aus können Sie gleichzeitig private Leitungen zu Microsoft Azure ExpressRoute, AWS Direct Connect und Google Cloud Interconnect betreiben – als logisch getrennte Leitungen auf einer physischen Verbindung. Der Kunde zahlt für einen Port und hat Zugang zu allen benötigten Cloud-Umgebungen. Mehr unter cloudconnect.cz.

Wie löst CloudConnect die rechtliche Trennung mehrerer Einheiten bei gemeinsam genutzter physischer Verbindung?

Über VRF (Virtual Routing and Forwarding)-Instanzen auf MPLS-Ebene – jede Einheit hat ihr eigenes logisch isoliertes virtuelles Netzwerk innerhalb der physischen Leitung. Der Verkehr einer Einheit ist für die VRF einer anderen Einheit weder sichtbar noch routbar; die Isolierung wird auf der Ebene der Netzwerkarchitektur erzwungen, nicht nur durch Firewall-Konfiguration. Diese Architektur ist Standard für gemeinsam genutzte MPLS-Infrastruktur und überprüfbar.

Ist eine private Cloud-Anbindung außerhalb Prags verfügbar – zum Beispiel in Ostrau oder Brünn?

Ja. Der physische Zugangspunkt der CloudConnect-Leitung wird am effizientesten an einem Standort mit dem nächsten New Telekom-Backbone-Knoten platziert – typischerweise Prag. Niederlassungen in Ostrau, Brünn oder anderen Standorten greifen über eine MPLS-VPN-Leitung zum zentralen Knoten und von dort über CloudConnect auf die Cloud zu – der gesamte Pfad bleibt privat. Für regionale Niederlassungen reicht eine zentrale CloudConnect-Leitung für das gesamte Unternehmen aus.

Wie lange dauert die Bereitstellung einer privaten Cloud-Anbindung?

Die CloudConnect-Leitung selbst kann innerhalb von 3–5 Wochen ab Vertragsunterzeichnung für Standorte in Reichweite des New Telekom-Backbone-Netzwerks in Prag bereitgestellt werden. Die Konfiguration von Azure ExpressRoute oder AWS Direct Connect auf Seiten des Cloud-Anbieters läuft parallel und dauert typischerweise 1–2 Wochen. Das in dieser Fallstudie beschriebene Projekt – einschließlich drei VRF-Instanzen, zwei Cloud-Zugängen und der MPLS-VPN-Leitung nach Ostrau – wurde in 8 Wochen abgeschlossen.

Fazit

Die private Cloud-Anbindung über CloudConnect ist keine Lösung mehr, die ausschließlich großen Konzernen vorbehalten ist. Für eine Holding mit drei Einheiten, zwei Cloud-Umgebungen und einer Niederlassung in Ostrau brachte die Konsolidierung unter einer privaten MPLS-VPN-Architektur drei messbare Ergebnisse: 44 % Einsparung bei den Egress-Kosten, eine überprüfbare Sicherheitsarchitektur für die NIS2-Compliance und einheitliche Verwaltung unter einem einzigen Vertrag anstelle von fünf separaten Beziehungen. Die wichtigste Erkenntnis aus dem Projekt ist, dass eine private Cloud-Anbindung nicht eine Leitung pro Cloud und pro Unternehmen bedeuten muss – die VRF-Architektur auf MPLS ermöglicht es, mehrere Einheiten und mehrere Clouds von einem physischen Punkt aus effizienter und sicherer zu bedienen als jede Kombination separater Lösungen. Wenn Ihr Unternehmen oder Ihre Holding nach einer privaten Cloud-Anbindung sucht, sich für Datendienste von New Telekom interessiert oder die potenziellen Einsparungen bei den Egress-Kosten im Vergleich zum bestehenden Internetzugang zu Azure oder AWS prüfen möchte, kontaktieren Sie unser Team über die Kontaktseite oder direkt unter cloudconnect.cz.

---

Diese Fallstudie wurde vom Expertenteam der New Telekom s.r.o. erstellt. Die technischen Parameter entsprechen dem Stand zum Zeitpunkt der Projektübergabe. Die Branche des Kunden und die Holdingstruktur werden in anonymisierter Form mit Zustimmung des Kunden dargestellt; genaue Firmennamen und Adressen werden aus geschäftlichen Gründen nicht veröffentlicht. Die Informationen entsprechen dem technologischen Stand von Mai 2026.

Verwendete Technologien und Standards

• CloudConnect / cloudconnect.cz – private MPLS-VPN-Cloud-Anbindung
• Microsoft Azure ExpressRoute – private Anbindung an Azure Westeuropa (VRF-A, VRF-C)
• AWS Direct Connect / Hosted Connection – private Anbindung an AWS eu-central-1 (VRF-B)
• MPLS VPN, VRF – logische Isolierung von drei Einheiten auf einer gemeinsam genutzten physischen Leitung
• Juniper MX480, EX4650, NFX250 – Backbone-Router, Core-Switch, SD-WAN-CPE
• Cisco Catalyst 9200 – Access-Switch Ostrau
• Fortinet FortiGate 600F – NGFW-Firewall, pro-VRF Sicherheitszonen
• Microsoft Sentinel – SIEM, Audit-Logs mit 90-tägiger Aufbewahrung
• BGP, MP-BGP, IPv4/IPv6-Dual-Stack, QoS DiffServ – Netzwerkprotokolle
• NIX.CZ – Neutral Internet eXchange Prag, New Telekom Direct Peering
• Gesetz Nr. 264/2025 Slg. (NIS2) – technische Maßnahmen für Transportsicherheit
• Verordnung Nr. 410/2025 Slg. – Sicherheitsanforderungen für verpflichtete Unternehmen
• EU-Verordnung 2016/679 (DSGVO) – Art. 30, Verzeichnis von Verarbeitungstätigkeiten
• EU-Verordnung 2022/2554 (DORA) – digitale operative Resilienz