Wer war der Kunde und warum reichte der Zugang über das öffentliche Internet nicht aus?
Der Kunde – ein Betreiber einer E-Commerce-Plattform für B2B-Kunden im Bereich Baustoffe und Industriekomponenten – betreibt eine hybride Cloud-Architektur: Ein Teil der Infrastruktur (Datenbankserver, Lagersystem, internes ERP) läuft im eigenen Colocation-Rechenzentrum in Prag, während die Anwendungsschicht, der CDN-Ursprung und die Analyseumgebung in Microsoft Azure Westeuropa liegen. Beide Umgebungen tauschen täglich Dutzende GB an Daten aus – Lagerbestandssynchronisation, Kundendaten, Transaktionslogs und Medieninhalte für Produktkataloge. Die bestehende Architektur – der Zugriff auf Azure über eine standardmäßige B2B-Internet-Verbindung – funktionierte ohne größere Probleme, bis die Plattform auf etwa 120.000 aktive B2B-Kunden anwuchs und das übertragene Datenvolumen 180 TB pro Monat überschritt. Zu diesem Zeitpunkt traten drei Probleme gleichzeitig auf. Kostenproblem: Die standardmäßigen Azure-Egress-Tarife für die Region Westeuropa (aus Azure ins Internet abgehende Daten) erzeugten monatliche Kosten in Höhe von 6.000–8.000 € – der größte Einzelposten in der Cloud-Rechnung, wobei das Datenvolumen jedes Quartal wuchs. Leistungsproblem: Der Datentransfer zwischen dem Prager Rechenzentrum und Azure über das öffentliche Internet zeigte während der Nachmittagsstunden und in Kampagnenzeiträumen (Saisonverkäufe) eine spürbare Verschlechterung – die Latenz stieg auf 40–80 ms und der Durchsatz fiel unter Werte, die Verzögerungen bei der Lagerdatensynchronisation verursachten. Plattformkunden sahen veraltete Lagerbestände. Sicherheitsproblem: Der Transfer von Kundendaten – einschließlich Geschäftsbedingungen, Preisen und Kaufhistorie von B2B-Kunden – über das öffentliche Internet ohne dedizierten Übertragungspfad war gegenüber Unternehmenskunden, die im Rahmen ihrer eigenen ISO/IEC 27001-Audits eine Dokumentation der Sicherheitsarchitektur forderten, zunehmend schwer zu rechtfertigen.Wie entwickelte New Telekom die Lösung?
CloudConnect als dedizierte private Cloud-Anbindung an Azure
New Telekom schlug vor, den Zugriff auf Azure über das öffentliche Internet durch eine dedizierte private CloudConnect-Leitung zu ersetzen – einen direkten MPLS-VPN-Ring vom Prager Rechenzentrum des Kunden zum Microsoft Azure ExpressRoute-Peering-Standort in Prag, von wo aus er über das private Backbone von Microsoft zur Region Azure Westeuropa weiterführt. Das Schlüsselprinzip: Daten zwischen dem Prager Rechenzentrum des Kunden und Azure durchqueren das öffentliche Internet überhaupt nicht mehr. Der gesamte Pfad – vom Server im Prager Colocation-Rechenzentrum bis zur Anwendungsumgebung in Azure Westeuropa – ist eine dedizierte physische Route, die vom New Telekom-Netzwerk und der Backbone-Infrastruktur von Microsoft betrieben wird. Keine Transitknoten Dritter, keine gemeinsame Nutzung der Kapazität mit anderen Benutzern des öffentlichen Internets.Kapazität und Redundanz
Für das Datenvolumen des Kunden (180 TB monatlich, Spitzen während Kampagnen bis zum 3-fachen Durchschnitt) wurde eine primäre Kapazität von 2 Gbit/s symmetrisch ausgelegt – mit der Möglichkeit der sofortigen Skalierung auf 5 Gbit/s über die CloudConnect SDN-Plattform ohne physischen Eingriff in die Infrastruktur. Für saisonale Kampagnen wie den Black Friday oder Frühlingsverkäufe kann die Kapazität vorübergehend erhöht und nach Ende der Aktion wieder reduziert werden. Die Redundanz der letzten Meile zwischen dem Prager Rechenzentrum des Kunden und dem New Telekom-Verteilungsknoten wird durch zwei physikalisch getrennte Glasfaserstrecken entlang verschiedener Straßen gewährleistet – ein Grabenbruch oder eine Störung auf einer Strecke beeinträchtigt die andere nicht. Die Umschaltung auf die Reserve-Strecke erfolgt automatisch innerhalb von 8 Sekunden.Was wurde physikalisch implementiert?
Glasfaseranschluss zum Prager Rechenzentrum
Der Kunde betreibt Colocation in einem Rechenzentrum im Bereich Prag – Vinohrady. New Telekom führte ein dediziertes OS2-Einmoden-Glasfaserpaar vom New Telekom-Verteilungsknoten in Prag 2 zum Kundenserverrack – eine Strecke von 680 Metern durch die bestehende Gebäudekabelinfrastruktur, terminiert mit LC/APC-Steckverbindern auf dem Patchfeld im Kundenserverrack. Gemessene Streckendämpfung: 2,1 dB.Aktive Komponenten
- Juniper MX204 – Backbone-Router des Kunden mit dedizierter VRF-Instanz für den CloudConnect-Ring, BGP-Session zum New Telekom-Netzwerk, Hardwareunterstützung für MPLS, IPv4/IPv6-Dual-Stack und QoS DiffServ mit drei Verkehrsklassen: Priorität (Lagerbestandssynchronisation), Standard (Transaktionsdaten) und Best-Effort (Medieninhalte, Logs)
- Juniper EX4300 – Access-Switch für die Verbindung der Serverinfrastruktur des Kunden mit dem Router, 10GbE-Uplinks, LACP-Bonding zur Kapazitätsaggregation
- Fortinet FortiGate 400F – NGFW-Firewall an der Grenze zwischen der privaten CloudConnect-Leitung und dem internen Servernetzwerk des Kunden; auf der CloudConnect-Ebene ohne SSL-Inspektion (unnötige Latenz auf einer privaten Leitung), mit aktiven IPS- und Anomalieerkennungsfunktionen
- APC Smart-UPS 2200VA – unterbrechungsfreie Stromversorgung für aktive Komponenten für 50 Minuten
Azure ExpressRoute Konfiguration
Auf der Microsoft Azure-Seite wurde im Rahmen des Projekts ein ExpressRoute Circuit am Peering-Standort Prag (CE Colo Prague) mit 2 Gbit/s Durchsatz konfiguriert, mit aktiviertem Microsoft Peering für den Zugriff auf Azure PaaS-Dienste (Azure Blob Storage, Azure SQL, Azure CDN Origin) und Private Peering für den Zugriff auf die virtuellen Netzwerke des Kunden in Azure Westeuropa. Die BGP-Konfiguration auf der Azure-Seite stellt sicher, dass der Kundentransport immer den ExpressRoute-Pfad dem reservierten Internetpfad vorzieht.Welche Parameter erreicht die Anbindung im Betrieb?
| Parameter | Nach der Implementierung (CloudConnect) | Vorheriger Zustand (Internet) |
|---|---|---|
| Latenz Prag DC ↔ Azure Westeuropa | < 9 ms konsistent | 18–80 ms, stark variabel |
| Durchsatz bei Spitze | 2 Gbit/s garantiert | Tatsächlich 300–800 Mbit/s (geteilte Kapazität) |
| Packet Loss | < 0,01 % | 0,1–2 % bei Spitzen |
| SLA-Verfügbarkeit | 99,9 % vertraglich | Keine Garantie |
| Redundanz letzte Meile | Doppelglasfaser, Auto-Failover < 8 s | Einzelstrecke |
| Azure-Egress-Kosten | Reduzierung um 47 % | Volle Standardtarife |
| Daten über öffentliches Internet | Null für Cloud-Datenverkehr | 100 % |
| Kapazitätsskalierung | Sofort über SDN, ohne physischen Eingriff | Begrenzt durch ISP, Wochen |
Wie verändert eine dedizierte private Cloud-Anbindung die Ökonomie von Azure Egress?
Dies ist der Aspekt, der Kunden bei der ersten Analyse am meisten überrascht. Azure-Egress-Traffic – Daten, die Azure ins Internet verlassen – wird zu den Standardtarifen von Microsoft abgerechnet (derzeit in der Region Westeuropa etwa 0,05–0,08 €/GB, abhängig vom Volumen). Für einen Kunden, der 180 TB monatlich überträgt, bedeutete dies eine monatliche Egress-Rechnung in Höhe von 6.000–8.000 €. Über CloudConnect und Azure ExpressRoute sind die Egress-Tarife erheblich niedriger – Microsoft gewährt Vorzugstarife für Datenverkehr über ExpressRoute im Vergleich zum standardmäßigen Internet-Egress. Die resultierende Ersparnis für den Kunden: 47 % der monatlichen Gesamt-Egress-Kosten – bei steigendem Datenvolumen wächst die absolute Ersparnis mit jedem Monat. Ein wichtiges Detail: Ingress-Traffic (in Azure eingehende Daten) ist immer kostenlos – CloudConnect und ExpressRoute ändern diese Tatsache nicht, sind aber Teil der gesamtwirtschaftlichen Berechnung. Eine detaillierte Berechnung der Einsparungen für ein bestimmtes Datenvolumen und eine bestimmte Azure-Region finden Sie unter cloudconnect.cz (tschechische Sprache).Was bedeutet eine dedizierte private Cloud-Anbindung für DSGVO und Sicherheitsaudits?
Für eine E-Commerce-Plattform, die B2B-Kundendaten verarbeitet – Geschäftsbedingungen, Preisniveaus, Kaufhistorie – ist der Datenübertragungspfad Teil der Sicherheitsarchitektur, die bei DSGVO-Audits oder bei Sicherheitsüberprüfungen durch Unternehmenskunden nachgewiesen werden muss. Die CloudConnect-Privatleitung erlaubt eine klare Aussage: Kundendaten zwischen unserem Prager Rechenzentrum und Azure durchqueren nicht das öffentliche Internet. Diese Tatsache kann technisch belegt werden – mit einem Netzwerktopologiediagramm, einem BGP-Routing-Tabellenauszug und der Bestätigung von New Telekom über die Architektur der Leitung. Für Verzeichnisse von Verarbeitungstätigkeiten personenbezogener Daten gemäß Art. 30 DSGVO (EU-Verordnung 2016/679) handelt es sich um eine konkrete technische Maßnahme der Transportsicherheit, nicht um eine abstrakte Behauptung. Für Kunden, die NIS2 (Gesetz Nr. 264/2025 Slg.) oder DORA (EU-Verordnung 2022/2554) unterliegen, ist ein privater Übertragungspfad für kritischen Cloud-Betrieb direkt Teil der geforderten technischen Maßnahmen. Umfassende IT-Sicherheitslösungen – einschließlich NIS2-Compliance-Beratung und technischer Implementierung – werden von New Telekom als ergänzender Dienst angeboten.Häufig gestellte Fragen zu dedizierten privaten Cloud-Anbindungen
Was ist der Unterschied zwischen CloudConnect und standardmäßigem Internetzugang zu Azure?
Über Standard-Internet durchlaufen Daten Dutzende von Transitknoten von Drittanbieter-Betreibern – die Kapazität wird geteilt, die Latenz ist variabel und der Übertragungspfad ist nicht kontrollierbar. CloudConnect ist eine dedizierte private Leitung: Daten verbleiben ausschließlich im New Telekom-Netzwerk und der Backbone-Infrastruktur von Microsoft, ohne das öffentliche Internet zu durchqueren. Das Ergebnis sind garantierter Durchsatz, konsistente Latenz und eine überprüfbare Übertragungsarchitektur. Zudem niedrigere Azure-Egress-Tarife im Vergleich zum standardmäßigen Internet-Egress.Ist CloudConnect auch für AWS und Google Cloud verfügbar oder nur für Azure?
CloudConnect von New Telekom verbindet Unternehmensnetzwerke mit Microsoft Azure (ExpressRoute), Amazon Web Services (AWS Direct Connect) und Google Cloud Platform (Cloud Interconnect) – alles unter einem Vertrag und über einen einzigen Anschluss. Der Kunde muss keine separaten privaten Leitungen für jeden Cloud-Anbieter einrichten. Weitere Informationen unter cloudconnect.cz (tschechische Sprache).Wie schnell kann eine private CloudConnect-Leitung bereitgestellt werden?
Für Kunden an Standorten mit verfügbaren New Telekom-Backbone-Strecken (Prag und Umgebung, größere tschechische Städte) beträgt die Standardzeit von der Vertragsunterzeichnung bis zur Aktivierung 3–5 Wochen für den CloudConnect-Ring allein. Das in dieser Fallstudie beschriebene Projekt wurde in 6 Wochen abgeschlossen – einschließlich des Glasfaseranschlusses an das Rechenzentrum, der Konfiguration von Azure ExpressRoute auf der Microsoft-Seite und des Testens von BGP-Failover-Szenarien.Kann die Kapazität einer CloudConnect-Leitung ohne Technikereinsatz geändert werden?
Ja. CloudConnect basiert auf der eigenen SDN-Plattform von New Telekom – Kapazitätsänderungen (Erhöhung und Verringerung) werden softwaregesteuert in Echtzeit ohne physischen Eingriff in die Infrastruktur durchgeführt. Für Kunden mit saisonalen Spitzen (Verkäufe, Kampagnen) bedeutet dies die Möglichkeit, die Kapazität vorübergehend für die Dauer einer Aktion zu erhöhen und nach deren Ende wieder auf das Standardniveau zurückzusetzen – ohne monatliche Verpflichtung auf eine höhere Kapazität.Ist CloudConnect auch für Unternehmen außerhalb Prags geeignet?
Ja. New Telekom liefert CloudConnect-Private-Cloud-Anbindungen für Unternehmenskunden in der gesamten Tschechischen Republik – über das eigene Backbone-Netzwerk und ein Partnernetzwerk von 120+ Betreibern für die Abdeckung außerhalb der Hauptstadt. Die Verfügbarkeit für einen bestimmten Standort und die Konditionen hängen von der Entfernung zum nächstgelegenen New Telekom-Verteilungsknoten ab. Kontaktieren Sie uns zur Überprüfung der Verfügbarkeit an Ihrer Adresse.Fazit
Die dedizierte private Cloud-Anbindung über CloudConnect brachte dem Betreiber der E-Commerce-Plattform drei messbare Ergebnisse: konsistente Latenz unter 9 ms, die Leistungsschwankungen bei der Synchronisation eliminierte, 47 % Einsparung bei den Azure-Egress-Kosten und eine überprüfbare Sicherheitsarchitektur für den Datentransport, die gegenüber Kunden und Aufsichtsbehörden nachgewiesen werden kann. Für Unternehmen, die monatlich Dutzende oder Hunderte von TB Daten zwischen ihrer eigenen Infrastruktur und der Cloud übertragen, ist die Frage nicht, ob eine dedizierte private Anbindung sinnvoll ist – die Frage ist, wann der richtige Zeitpunkt für deren Einführung ist. Für den in dieser Fallstudie beschriebenen Kunden war der richtige Zeitpunkt das Überschreiten von 100 TB monatlichem Volumen, als die Egress-Kosten zum dominierenden Posten auf der Cloud-Rechnung wurden. Wenn Ihr Unternehmen nach einer dedizierten privaten Cloud-Anbindung sucht, sich für Datendienste von New Telekom interessiert oder die Kosten des bestehenden Internetzugangs zu Azure oder AWS mit einer CloudConnect-Lösung vergleichen möchte, kontaktieren Sie unser Team über die Kontaktseite oder direkt unter cloudconnect.cz (tschechische Sprache).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 wird mit Zustimmung des Kunden offengelegt; der genaue Firmenname und die Adresse 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 – privater MPLS-VPN-Ring zu Microsoft Azure ExpressRoute
- Microsoft Azure ExpressRoute – private Leitung zu Azure Westeuropa, Microsoft Peering + Private Peering
- Juniper MX204 – Backbone-Router, BGP, MPLS, VRF, QoS DiffServ
- Juniper EX4300 – Access-Switch, 10GbE, LACP
- Fortinet FortiGate 400F – NGFW-Firewall mit IPS und Anomalieerkennung
- OS2-Einmoden-LC/APC – Glasfaseranschluss zum Prager Rechenzentrum
- New Telekom SDN-Plattform – sofortige Skalierung der CloudConnect-Ringkapazität
- BGP, MPLS, IPv4/IPv6-Dual-Stack – Netzwerkprotokolle
- NIX.CZ – Neutral Internet eXchange Prag, New Telekom Direct Peering
- EU-Verordnung 2016/679 (DSGVO) – Schutz personenbezogener Daten bei der Übertragung, Art. 30
- Gesetz Nr. 264/2025 Slg. (NIS2) – technische Maßnahmen für Transportsicherheit
- EU-Verordnung 2022/2554 (DORA) – digitale operative Resilienz