Cloud Connect: how to link your business to AWS, Azure and Google

Cloud Connect is the set of private interconnection services that link a company's infrastructure to a public cloud without going through the internet. The decision to adopt it almost always appears at the same point in the journey: the critical workloads are already in the cloud, traffic between the company's own data centre and the provider has grown, and latency variability or the data egress bill have started to hurt.

The discussion matters because the real-world scenario for companies is not pure cloud. Flexera's 2026 annual report found that 73% of organisations run hybrid cloud and that barely 14% operate exclusively in multicloud with no private cloud. In large enterprises, 54% of workloads sit in public cloud, which means almost half remain outside and need connecting. This guide compares the available connection models, reviews what each hyperscaler offers and pins down where the cloud provider's responsibility ends and the network operator's begins.

What is Cloud Connect and what problem does it solve?

The three major cloud providers place their edge routers in specific colocation facilities, which they call peering or interconnection locations. To establish a private link, the company's network has to reach one of those facilities physically. Because most organisations have no presence there, a telecommunications operator carries the circuit from the customer's site or data centre to that point and performs the cross connect. That stretch is the last mile, and it is exactly what a Cloud Connect service resolves.

The result is a dedicated link, with deterministic bandwidth, that does not cross the internet. Microsoft puts it plainly in its documentation: ExpressRoute connections do not go over the public internet and offer greater security, reliability and speed, with lower and more consistent latencies than a typical internet connection. AWS describes the benefit in the same terms, noting that traffic stays on its global network and never touches the internet, which reduces the likelihood of encountering bottlenecks or unexpected latency increases.

Private interconnection or VPN over the internet

Before comparing providers it is worth settling the underlying decision, because a VPN over the internet remains a legitimate option for many use cases.

VPN over the public internet

It is quick to provision, requires no physical presence at any facility and comes with encryption built in by design. One fact that tends to surprise: Google's high-availability VPN publishes a service level agreement of 99.99% or 99.9% depending on configuration, so the differential of private interconnection does not lie in the availability figure. Its real limit is elsewhere: the path the traffic takes is the internet, with all the latency and performance variability that implies, and bandwidth is bounded by the capacity of the tunnel and of the equipment terminating it.

Dedicated private interconnection

This delivers guaranteed capacity, consistent latency and isolation of the network path. In exchange it requires presence at an interconnection location (your own or via a partner), a longer provisioning lead time and a port commitment. There is a technical nuance worth treating honestly: private interconnection does not come encrypted by default. Its security argument is path isolation, not automatic encryption. Anyone who needs encryption has to add it explicitly, with MACsec in the case of AWS or by deploying a high-availability VPN over Cloud Interconnect in the case of Google.

The factor that usually decides: data egress cost

Here the difference is quantifiable and Google states it explicitly in its pricing documentation: data transfer from a virtual network through Cloud Interconnect connections is discounted against the general network price. The egress rate over interconnect starts at US$0.020 per gibibyte, whereas internet egress at its premium tier towards South America runs from US$0.15 to US$0.19 per gibibyte depending on volume. In Azure, metered ExpressRoute egress starts at US$0.025 per gigabyte and there is an unlimited data plan with a fixed monthly port charge that includes all inbound and outbound transfer, against US$0.181 per gigabyte of internet egress from South America in the next 10 terabytes per month band. In AWS, outbound data transfer over Direct Connect starts at US$0.02 per gigabyte depending on geography.

For a workload moving tens of terabytes a month, that per-unit gap transforms the analysis: the cost of the dedicated port is recovered through the saving on data egress, and consistent latency becomes an additional benefit rather than the main argument.

How it works in each cloud

AWS Direct Connect

This offers two modalities. A dedicated connection is a physical Ethernet link associated with a single customer, requested directly from the console or the programming interface, at speeds of 1, 10, 100 and 400 gigabits per second. A hosted connection is provisioned by a programme partner on the customer's behalf and covers the range from 50 megabits to 25 gigabits per second, which makes it the natural route when a full port is not needed.

Virtual interfaces of three types are configured over the physical connection: private for reaching a virtual private cloud with private IP addresses, public for reaching AWS public services globally, and transit for connecting to transit gateways. The service level agreement deserves particular attention, because it is not a single number: 99.99% for a redundant deployment across multiple sites, 99.9% for a non-redundant one across multiple sites and 95% for a single connection. AWS explicitly recommends against using any scheme other than the first two for production workloads.

Azure ExpressRoute

This works with circuits from 50 megabits to 10 gigabits per second and has a valuable particularity: each circuit includes built-in redundancy with primary and secondary connections to two Microsoft edge routers, each at the contracted bandwidth. Bandwidth can be increased dynamically without tearing down the connections. It is layer 3 connectivity with BGP and supports two routing domains on new circuits: private peering for virtual networks and Microsoft peering for productivity and platform services.

One architectural point that avoids design errors: the circuit location does not need to coincide with the Azure region where the resources live. For anyone requiring physical isolation or massive data ingestion there is ExpressRoute Direct, which connects directly to Microsoft's global network via port pairs of 10, 100 or 400 gigabits per second, with no intermediary provider. The published service level agreement guarantees a minimum of 99.95% availability of the dedicated circuit.

Google Cloud Interconnect

This distinguishes between Dedicated Interconnect, a direct physical connection to Google's network, and Partner Interconnect, which arrives through a supported service provider. The dedicated modality scales from one to eight connections, allowing aggregates of up to 800 gigabits per second with 100-gigabit links and up to 3,200 with 400-gigabit links. The partner modality offers virtual network attachments from 50 megabits to 50 gigabits per second.

Its partner model incorporates a distinction worth knowing when comparing proposals. At layer 2, the customer configures and establishes the BGP sessions between its cloud routers and its on-premises equipment. At layer 3, it is the provider that establishes that session, with automated configuration, which reduces the network team's workload and allows connections to be pre-activated. The service level agreement is tiered and demanding on topology: 99.99% requires at least four connections distributed across two distinct metropolitan areas, 99.9% allows two connections in the same metropolitan area but in separate availability domains, and a single connection has no service level agreement.

Source: official documentation and the pricing and service level agreement pages of AWS, Microsoft and Google Cloud, consulted in July 2026. 

Where the hyperscaler's agreement ends

This is the point most often overlooked in an evaluation and the one with the greatest impact on real operations. Google says it literally in its service level agreement documentation for Partner Interconnect: the guarantee applies only to connectivity between the customer's virtual network and the service provider's network, and does not include connectivity between the customer's network and the provider's network.

Translated into practice: the hyperscaler answers for its stretch, not for the journey from the customer's site or data centre to the interconnection location. That stretch, its redundancy, its monitoring and its service level agreement belong to the operator. That is why the relevant question when evaluating a Cloud Connect service is not what availability the cloud provider publishes, but what end-to-end availability is contractually committed once both stretches are added together.

The three providers structure this through connectivity partner programmes with formal requirements. In the case of AWS, delivery-enabled partners must pass an additional validation, have interconnect monitoring in place and be authorised to provision capacities above 500 megabits per second. At Liberty Networks we operate as a Direct Connect delivery-certified partner and offer managed AWS services that integrate our data centres with that direct connection, as well as managed Azure services for Microsoft environments.

What to assess before contracting

Five criteria structure the decision and allow proposals that look equivalent at first sight to be compared properly.

• Topology, not just capacity. High service level agreements depend on redundancy, not on port size. A single 10-gigabit-per-second connection carries less assurance than two well-distributed 1-gigabit connections.
• Outbound traffic profile. Estimating the monthly volume of data egress turns the comparison of rates into a concrete figure and is usually the argument that funds the project.
• Last-mile coverage. Verify that the operator reaches the relevant sites and the interconnection location with its own fibre, and with what route diversity.
• BGP management model. Define whether the internal team will administer routing or whether it prefers the provider to establish and automate it, as the layer 3 model allows.
• Multicloud strategy. If more than one cloud is on the horizon, it is worth having an architecture that aggregates the connections at a common point rather than replicating isolated links per provider.

Cloud connectivity as an architectural decision

The market is pushing hard in this direction. Enterprise spending on cloud infrastructure services reached US$129 billion in the first quarter of 2026, a 35% year-on-year rise and the highest growth rate since the end of 2021, with Amazon, Microsoft and Google accounting for 63% of the market. In other words: almost two out of every three enterprise cloud dollars go to the three providers this article covers.

At the same time, 93% of organisations run hybrid multicloud strategies according to F5's annual report, and more than nine out of ten work with at least two of these three environments: public cloud, private cloud and colocation. The architectural conclusion is that the cloud connection has stopped being just another link and become a structural component of network design, with the same redundancy and service level agreement requirements applied to an MPLS link or a data centre. Our ICT solutions portfolio addresses that set in an integrated way, with our own infrastructure and regional connectivity as the foundation. For anyone designing an environment with more than one cloud provider, the next conversation is multicloud architecture, which deserves its own treatment.

Sources

• Amazon Web Services, AWS Direct Connect Service Level Agreement: https://aws.amazon.com/directconnect/sla/
• Amazon Web Services, AWS Direct Connect User Guide: https://docs.aws.amazon.com/directconnect/latest/UserGuide/Welcome.html
• Amazon Web Services, AWS Direct Connect Delivery Partners: https://aws.amazon.com/directconnect/partners/
• Microsoft, ExpressRoute overview: https://learn.microsoft.com/en-us/azure/expressroute/expressroute-introduction
• Microsoft, ExpressRoute FAQ: https://learn.microsoft.com/en-us/azure/expressroute/expressroute-faqs
• Microsoft, Azure ExpressRoute pricing: https://azure.microsoft.com/en-us/pricing/details/expressroute/
• Google Cloud, Cloud Interconnect Service Level Agreement: https://cloud.google.com/network-connectivity/docs/interconnect/sla
• Google Cloud, VPC network pricing: https://cloud.google.com/vpc/network-pricing
• Google Cloud, Dedicated Interconnect overview: https://docs.cloud.google.com/network-connectivity/docs/interconnect/concepts/dedicated-overview
• Flexera, 2026 State of the Cloud Report: https://resources.flexera.com/web/pdf/Flexera-State-of-the-Cloud-Report-2026.pdf
• Synergy Research Group, Cloud Market Annual Revenue Run Rate, first quarter of 2026: https://www.srgresearch.com/articles/cloud-market-annual-revenue-run-rate-topped-half-a-trillion-dollars-in-q1-as-growth-surge-continues
• F5, 2026 State of Application Strategy Report: https://www.f5.com/resources/reports/state-of-application-strategy-report