Case Study: Private Cloud Link for a Holding Company with Three Legal Entities and Hybrid Infrastructure

Private cloud link — a dedicated private circuit outside the public internet connecting corporate infrastructure directly to cloud platforms — is no longer the exclusive domain of large corporations. New Telekom s.r.o. implemented, through its CloudConnect service, a private cloud connection for a Czech-Slovak holding company with three legal entities, headquarters in Prague, a branch in Ostrava, and hybrid cloud infrastructure distributed across its own colocation data center in Prague, Microsoft Azure West Europe, and AWS eu-central-1 (Frankfurt). The result: one private MPLS VPN circuit serving all three entities, both clouds, and both locations — under a single contract with New Telekom, with 99.9% SLA and 44% savings on total egress costs.

What is a private cloud link and why does it matter?

A private cloud link is a physically dedicated data circuit connecting a corporate network or data center to cloud platforms — Microsoft Azure (ExpressRoute), AWS (Direct Connect), or Google Cloud (Cloud Interconnect) — without traversing the public internet on any segment of the path. Unlike a VPN tunnel over the internet, it is not an encrypted path over shared infrastructure, but a physically dedicated transmission capacity with guaranteed parameters. For companies transferring sensitive business data, customer information, or running production applications in the cloud, a private link brings three specific advantages: consistent performance independent of the state of the public internet, security isolation without data passing through uncontrolled transit nodes, and significantly lower egress costs thanks to preferential rates from cloud providers for traffic over dedicated circuits.

Who was the customer and what complicated their situation?

The customer — a holding company comprising three legal entities (parent company and two subsidiaries) in the sectors of financial advisory, property management, and IT consulting — operated separate cloud access for each entity: three different Azure subscriptions, two AWS organizations, and each entity had historically resolved its own cloud connection separately — over the public internet with commercial VPN clients. The resulting state was operationally unsustainable:

• Five separate contracts with different connectivity and cloud access providers
• Uncontrolled egress costs — each entity paid standard cloud egress rates separately, without the possibility of volume negotiation
• Security heterogeneity — three different VPN clients from three different vendors with different encryption levels and different audit logs
• Compliance problem — two of the entities were subject to obligations under Act No. 264/2025 Coll. (NIS2) and needed to demonstrate an auditable transport architecture; data transfer over three different commercial VPNs over the public internet did not allow this documentation

The customer sought a solution that consolidates cloud connectivity for the entire holding under one technical architecture and one contract — while respecting the legal separation of the three entities (no data sharing between entities at the network level).

How did New Telekom design the private cloud link for the holding?

Architecture: one port, three VRFs, two clouds

The key design decision was to use MPLS VPN technology with separate VRF (Virtual Routing and Forwarding) instances — the same physical CloudConnect circuit carries three logically completely isolated private links, one for each holding entity. At the network layer, there is no path between VRF instances — entity A's traffic is neither visible nor accessible to entities B and C, even though they share the same physical connection. Prague — holding headquarters: Primary physical node. CloudConnect circuit with 2 Gbit/s capacity terminated in the holding's colocation data center in Prague. From this node, three logically separate VRF instances run:

• VRF-A (parent entity) — private circuit to Microsoft Azure ExpressRoute, region West Europe; capacity 1 Gbit/s
• VRF-B (financial advisory) — private circuit to AWS Direct Connect, region eu-central-1 (Frankfurt); capacity 500 Mbit/s
• VRF-C (property management) — private circuit to Microsoft Azure ExpressRoute, same West Europe region as VRF-A but completely separate BGP session and separate virtual networks (VNets) in Azure; capacity 500 Mbit/s

Ostrava — holding branch: The branch in Ostrava is connected to the Prague node via a New Telekom MPLS VPN circuit and accesses Azure and AWS via the CloudConnect terminated in Prague — without needing a second physical CloudConnect termination point. All cloud traffic from Ostrava first travels over the private MPLS WAN link to Prague and from there via CloudConnect to the cloud — the entire path remains private, without traversing the public internet.

Why one port and not three separate CloudConnect circuits?

The straightforward solution — three separate CloudConnect circuits for three entities — would work, but would be unnecessarily expensive and complex. The VRF architecture on a single physical circuit brings:

• Lower total costs — one physical connection, one port, one contract
• Simpler management — one monitoring system, one escalation matrix, one point of contact
• Same security isolation as three separate circuits — VRF at the MPLS level provides strict logical isolation; cross-entity network layer intrusion is architecturally impossible
• Flexible capacity reallocation — during low load of entity B, available capacity for entity A can be temporarily increased without physical intervention

What was physically implemented?

Prague — colocation data center

• Dedicated OS2 Single-Mode fiber pair from New Telekom Prague distribution node to the holding's rack space, length 520 meters, attenuation 1.6 dB, termination LC/APC
• Juniper MX480 — backbone router with 960 Gbit/s capacity, three separate VRF instances, BGP sessions to cloud access nodes separately for each entity, QoS DiffServ per-VRF, IPv4/IPv6 dual-stack; physically located in the holding's rack space
• Juniper EX4650 — core switch with 10GbE ports for connecting each entity's server infrastructure to the respective VRF
• Fortinet FortiGate 600F — NGFW firewall; separate security zone and policy for each entity's VRF; IPS, application control, audit logs with 90-day retention exported to SIEM Microsoft Sentinel
• Eaton 9PX 3000VA UPS — backup power for active equipment for 40 minutes

Ostrava — branch

• MPLS VPN circuit Ostrava—Prague: capacity 500 Mbit/s symmetrical, latency < 8 ms, operated via New Telekom partner network in Ostrava
• Juniper NFX250 — SD-WAN CPE in Ostrava with BGP session to Prague node, QoS prioritization of application traffic, backup LTE-A Pro connection via New Telekom eSIM with automatic failover within 10 seconds
• Cisco Catalyst 9200 — access switch for the Ostrava office

Cloud access configuration

Microsoft Azure ExpressRoute (VRF-A and VRF-C): two separate ExpressRoute Circuits at the Prague (CE Colo Prague) peering location — one for each entity — with Private Peering to the respective Azure Virtual Networks and Microsoft Peering for access to Azure PaaS services (Azure Blob Storage, Azure SQL Database, Microsoft 365). BGP communities configured so that each entity's traffic always prefers the ExpressRoute path over the backup internet path. AWS Direct Connect (VRF-B): Virtual Private Gateway connected via Direct Connect to the AWS region eu-central-1 with Transit Gateway activated for access to multiple VPCs within entity B's AWS organization. Hosted Connection capacity: 500 Mbit/s.

What parameters does the link achieve in operation?

How did egress costs change after migrating to the private link?

Before implementation, the three holding entities paid cloud egress rates separately, each for their own traffic over the public internet — the total monthly egress bill across all entities and clouds reached approximately €9,500 per month. After migrating to the CloudConnect private link, egress costs decreased to approximately €5,300 per month — a 44% savings. The reasons are twofold: preferential ExpressRoute and Direct Connect egress rates compared to standard internet rates, and volume consolidation over a single circuit, which enabled better negotiated terms. With growing data volume — the holding plans to expand its cloud environment in the next two years — the absolute savings will continue to increase at the same percentage rates.

What does the private cloud link mean for the holding's NIS2 compliance?

Two of the three holding entities are obligated entities under Act No. 264/2025 Coll. — financial advisory (regulated entity under CNB supervision) and IT consulting (provider of ICT services to critical infrastructure entities). Both entities must demonstrate technical measures for data transport security according to Decree No. 410/2025 Coll. The CloudConnect private link meets this requirement at the architectural level: data transfer between corporate infrastructure and the cloud does not traverse the public internet — this fact can be technically demonstrated with a BGP routing table printout, a topology diagram, and New Telekom's confirmation of the circuit architecture. For records of personal data processing according to Art. 30 GDPR (EU Regulation 2016/679), this is a specific and auditable technical measure for transport security. Separate VRF instances for each entity further ensure that sensitive data of the financial entity (VRF-B) cannot be accessed from the network infrastructure of the other entities — even with a shared physical connection. This isolation is documentable and verifiable during a security audit.

Frequently asked questions about private cloud links

What is the difference between a private cloud link and a VPN over the internet?

A VPN tunnel encrypts the data content but transmits it over the public internet — over third-party infrastructure without guarantees of latency, capacity, or transport path. A private cloud link (CloudConnect) is a physically dedicated path over the New Telekom network and the cloud provider's backbone infrastructure — data does not use the public internet at all. The result is guaranteed throughput, consistent latency, and an auditable security architecture. In addition, significantly lower egress rates compared to standard internet egress.

Can I operate access to both AWS and Azure simultaneously on a single private link?

Yes — and that is exactly what CloudConnect from New Telekom enables. From a single physical port, you can simultaneously operate private circuits to Microsoft Azure ExpressRoute, AWS Direct Connect, and Google Cloud Interconnect — as logically separate circuits on one physical link. The customer pays for one port and has access to all the cloud environments they need. More at cloudconnect.cz.

How does CloudConnect handle the legal separation of multiple entities sharing a physical connection?

Via VRF (Virtual Routing and Forwarding) instances at the MPLS level — each entity has its own logically isolated virtual network within the physical circuit. One entity's traffic is neither visible nor routable to another entity's VRF; isolation is enforced at the network architecture level, not just by firewall configuration. This architecture is standard for shared MPLS infrastructure and is auditable.

Is a private cloud link available outside Prague — for example, in Ostrava or Brno?

Yes. The physical access point of the CloudConnect circuit is most efficiently placed in a location with the nearest New Telekom backbone node — typically Prague. Branches in Ostrava, Brno, or other locations access the cloud via an MPLS VPN circuit to the central node and from there via CloudConnect — the entire path remains private. For regional branches, one central CloudConnect circuit for the entire company is sufficient.

How long does it take to deploy a private cloud link?

The CloudConnect circuit itself can be deployed within 3–5 weeks from contract signing for locations within reach of the New Telekom backbone network in Prague. Configuration of Azure ExpressRoute or AWS Direct Connect on the cloud provider side runs in parallel and typically takes 1–2 weeks. The project described in this case study — including three VRF instances, two cloud access paths, and the MPLS VPN circuit to Ostrava — was completed in 8 weeks.

Conclusion

The private cloud link via CloudConnect is no longer a solution exclusively for large corporations. For a holding with three entities, two cloud environments, and a branch in Ostrava, consolidation under one private MPLS VPN architecture brought three measurable results: 44% savings on egress costs, an auditable security architecture for NIS2 compliance, and unified management under a single contract instead of five separate relationships. The key insight from the project is that a private cloud link does not have to mean one circuit per cloud per company — VRF architecture on MPLS allows serving multiple entities and multiple clouds from one physical point more efficiently and securely than any combination of separate solutions. If your company or holding is looking for a private cloud link, is interested in New Telekom data services, or wants to assess potential savings on egress costs compared to existing internet access to Azure or AWS, contact our team via the contact page or directly at cloudconnect.cz (Czech language).

---

This case study was prepared by the expert team of New Telekom s.r.o. Technical parameters correspond to the state on the project handover date. The customer's industry and holding structure are presented in anonymized form with customer consent; exact business names and addresses are not disclosed for commercial reasons. Information corresponds to the technological state as of May 2026.

Technologies and standards used

• CloudConnect / cloudconnect.cz — private MPLS VPN cloud link
• Microsoft Azure ExpressRoute — private circuit to Azure West Europe (VRF-A, VRF-C)
• AWS Direct Connect / Hosted Connection — private circuit to AWS eu-central-1 (VRF-B)
• MPLS VPN, VRF — logical isolation of three entities on shared physical circuit
• Juniper MX480, EX4650, NFX250 — backbone router, core switch, SD-WAN CPE
• Cisco Catalyst 9200 — access switch Ostrava
• Fortinet FortiGate 600F — NGFW firewall, per-VRF security zones
• Microsoft Sentinel — SIEM, audit logs with 90-day retention
• BGP, MP-BGP, IPv4/IPv6 dual-stack, QoS DiffServ — network protocols
• NIX.CZ — Neutral Internet eXchange Prague, New Telekom direct peering
• Act No. 264/2025 Coll. (NIS2) — technical measures for transport security
• Decree No. 410/2025 Coll. — security requirements for obligated entities
• EU Regulation 2016/679 (GDPR) — Art. 30, records of personal data processing
• EU Regulation 2022/2554 (DORA) — digital operational resilience