Hybrid Cloud Connectivity
Last updated 15 Oct 2026
At a glance
Most operators that move BSS to a hyperscaler end up with the same shape. OSS and sensitive systems stay in the operator’s data centre; BSS, dev/test and non-sensitive applications run in two cloud regions; and two private connections through a carrier join them. AWS, Azure and Google Cloud name the parts differently, but the design and its failure points are the same.
The picture
Operator data centre
OSS
Inventory, NMS, fault, activation
10.10.0.0/16
Sensitive systems
HSS/UDM, policy, mediation, lawful intercept
10.11.0.0/16
Core router → firewall → carrier edge
AWS Direct Connect
Two connections, diverse paths, via a carrier’s private circuits
BGP to Direct Connect gateway / Transit Gateway
Private, not encrypted by default
AWS · one VPC per zone
eu-central-1 (Frankfurt)
PrimaryBSS applications
10.100.0.0/16
Dev / test
10.101.0.0/16
Non-sensitive apps
10.102.0.0/16
⇄
replication
(configured)
eu-west-1 (Ireland)
Secondary · DRBSS applications
10.110.0.0/16
Dev / test
10.111.0.0/16
Non-sensitive apps
10.112.0.0/16
Address ranges are illustrative. The rule is that none overlaps another: the data centre, every VPC and both regions are one routed network once the private link is up.
How it works
What stays, what moves
- Stays on-premises. The OSS that reaches the network’s management plane (inventory, NMS, fault, activation), and systems holding regulated subscriber or network data: HSS/UDM, policy, mediation (usage records are personal data), lawful intercept. Policy, latency and national rules keep them there, as Where BSS/OSS Workloads Run explains.
- Moves first. Dev/test environments: they give teams cloud tooling with the least risk, and they are where the private link and the address plan get proven.
- Moves next. BSS applications (CRM, CPQ, catalog, COM, often billing) and non-sensitive internal applications, in their own isolated networks (one VPC or VNet per zone).
The private connection
Each provider sells a private, dedicated connection from an operator site into its network, usually delivered over a carrier’s circuit to a colocation facility where the provider has a presence. Routes are exchanged with BGP. Traffic does not cross the internet, but it is not encrypted by default: sensitive flows need MACsec on the link or IPsec over it.
| Concept | AWS | Azure | Google Cloud |
|---|---|---|---|
| Private connection | Direct Connect (dedicated, or hosted through a partner) | ExpressRoute (through a provider, or ExpressRoute Direct) | Cloud Interconnect (Dedicated or Partner) |
| Private network in the cloud | VPC | VNet | VPC |
| Where routes are exchanged | Direct Connect gateway, Transit Gateway | ExpressRoute gateway, Virtual WAN hub | Cloud Router |
| Built-in redundancy | None per connection; resilient designs use two or more connections at separate locations | A circuit has two connections to the same peering location; site resilience needs a second circuit elsewhere | Two connections in separate edge availability domains; four across two metros for the highest SLA |
| Encryption | MACsec on dedicated links, or IPsec VPN over it | MACsec on ExpressRoute Direct, or IPsec over it | MACsec, or HA VPN over Interconnect |
Two regions
- Primary and secondary. The secondary region is the recovery site. It only helps if data replication, DNS failover and the private connection to it are all set up and tested: none of them is automatic.
- Address plan. Once the private link is up, the data centre and every cloud network form one routed network, so no two may use the same address range. Overlaps found late are expensive: re-addressing a live estate, or NAT that hides which system is calling.
- Two connections, two paths. Redundant connections that share a building, a duct or a carrier fail together. Diversity has to be checked on the physical path, not the order form.
Who owns what
| Entity | System of Record | System of Engagement | System of Reference | Notes |
|---|---|---|---|---|
| Private connections (circuits, cross-connects, BGP sessions) | Network team’s inventory and the carrier contract | Cloud provider console / API | Infrastructure-as-code repository | The carrier owns the circuit, the provider owns its port; the operator owns knowing both |
| Address plan (on-premises and every VPC/VNet) | IP address management (IPAM) | — | Infrastructure-as-code repository, cloud control plane | One plan for both sides, or overlaps appear |
| Landing zones (accounts, subscriptions, projects; networks per zone) | Infrastructure-as-code repository (Git) | Platform team pipeline | Cloud provider control plane | — |
| Business records (orders, customers, bills) | The owning BSS application, wherever it runs | — | Data platform | Moving to cloud changes where the record lives, not which system owns it |
| Subscriber and usage data (HSS/UDM, mediation) | The on-premises systems | — | — | Kept on-premises by policy or regulation; copies sent to cloud analytics need a lawful basis |
In practice
Operators commonly start with dev/test in the cloud over a private connection, then move BSS environments, and keep OSS and core-network data in their own data centres. Many run more than one provider: one for BSS, another for analytics or AI, each with its own private connection. That doubles the connectivity, the address plan and the operating model, not just the bill.
The trade-off
What it solves
It lets BSS and development teams use cloud services and elasticity while regulated and network-facing systems stay where policy and latency require, joined by a connection that is private, predictable and does not cross the internet.
What it does not solve
- It does not make the secondary region a working recovery site: replication, DNS failover and testing are separate work.
- It does not encrypt traffic or decide which data may leave the data centre.
What it adds
- Circuits, BGP, two regions and a shared address plan to design and operate, often with a carrier in between.
- Two operating models, code in the cloud and tickets on-premises, that must be kept consistent.
Architecture decision
How should the private connection to the cloud be built?
Partner or hosted connection
Choose when bandwidth needs are moderate, speed of delivery matters, and an existing carrier already reaches the provider’s locations.
Dedicated connection
Choose when bandwidth is high and steady, MACsec on the link is required, or the operator already has presence in the provider’s colocation facility.
VPN over the internet, as backup only
Choose when a cheap fallback is needed for the private connection; never as the only path for BSS-to-OSS traffic.
Breaks if both connections share a building, a duct or a carrier, or the secondary region has no tested route and replication: the design then has one point of failure that the diagram hides.
Takeaways
Key Takeaways
- OSS and regulated systems usually stay on-premises; BSS and dev/test move to the cloud first
- Private connections are private, not encrypted: add MACsec or IPsec for sensitive flows
- Two connections only help if their physical paths are diverse
- A secondary region is a recovery site only once replication and failover are configured and tested
- One address plan for the data centre and every cloud network, decided before the first link
Check yourself
An operator has two private connections to its cloud provider, both of which failed in one outage. What should the design review have checked?Show answerHide
Physical diversity: whether the two connections share a building, a duct, a carrier or a provider location. Two connections on one path are one connection.
BSS runs in a primary and a secondary region. The primary fails and the secondary does not take over. Name two likely causes.Show answerHide
Replication to the secondary was not configured or not current, DNS failover was not set up, or the on-premises side has no route to the secondary region’s address ranges. None of these is automatic.