Private cloud connectivity means linking your offices or data centre to Azure or AWS over a dedicated circuit — Microsoft ExpressRoute or AWS Direct Connect — instead of an encrypted tunnel across the public internet. Most UK businesses running hybrid workloads connect over a site-to-site VPN, often without realising that a private option exists, what it actually costs, or which problems it solves. Others hear about dedicated circuits from a supplier and assume they must need one because it sounds more enterprise-grade.
Both reactions miss the point. A site-to-site VPN over a good internet connection is the right answer for a large share of businesses: inexpensive, quick to set up and secure. A private circuit solves a specific set of problems — inconsistent latency, throughput ceilings, heavy data transfer and requirements to keep traffic off the public internet — and costs more in money, lead time and design effort. The question is not which sounds more serious, but which problems your workloads actually have.
This guide starts with what ExpressRoute and Direct Connect genuinely deliver that a VPN cannot, then covers how they work, realistic cost and lead times, common myths, resilience, when the workload justifies a private circuit, and a decision framework based on data volume, latency sensitivity and compliance requirements. It is written for IT managers, infrastructure leads and technical decision makers at UK businesses with workloads in Azure, AWS or both.
What private connectivity to the cloud is
There are two broad ways to connect your own network to a cloud provider’s network.
Site-to-site VPN over the internet
A VPN device at your office or data centre — often your firewall or SD-WAN appliance — establishes encrypted IPsec tunnels across the public internet to a VPN gateway in Azure or AWS. Traffic between your network and your cloud resources travels inside those tunnels. Setup takes hours or days, costs are low, and the connection is only as consistent as the internet paths in between.
Dedicated private circuit
ExpressRoute and Direct Connect provide a private, layer-two or layer-three connection between your network and the cloud provider’s network at a peering or Direct Connect location, typically a major colocation facility. You reach that location either because your equipment is already there, or through a connectivity provider that extends a circuit from the facility to your premises or connects you through its own network. Traffic never crosses the public internet, and the path is engineered for consistent performance.
The hybrid cloud network path
In practice, many organisations use both: a private circuit for production traffic and a VPN as backup, or VPNs for smaller sites and a private circuit for the data centre. The design question is which path each type of traffic should take, and what happens when one fails.
Before considering a private circuit, measure what your current VPN actually delivers: latency and its variation over a week, peak throughput, tunnel drops and monthly data transferred to and from the cloud. Many businesses find their VPN is perfectly adequate; others find clear evidence of a problem worth solving. Either way, the numbers make the decision far easier.
What a dedicated circuit delivers that a VPN cannot
A private circuit is not simply a faster VPN. Its advantages come from not depending on the public internet for the path between you and the cloud.
Consistent latency
Internet routing changes, congestion at peering points and contention on your own broadband or leased line all cause latency to vary. For most applications the variation is unnoticeable. For latency-sensitive workloads — chatty database connections between on-premises applications and cloud databases, real-time systems, virtual desktop traffic, synchronous replication — the variation, not the average, causes problems. A private circuit offers a predictable path with consistent latency.
Higher, reliable throughput
VPN throughput is limited by the encryption capacity of the devices at each end, the gateway size in the cloud, per-tunnel limits and the internet connection itself. Private circuits are provisioned at a stated bandwidth, from tens of megabits to many gigabits per second, and deliver it consistently. For large data transfers, backups, migrations and analytics pipelines, that predictability matters.
Traffic that never touches the public internet
With a private circuit, traffic between your network and your cloud resources stays on private infrastructure. For some organisations, contractual, regulatory or internal policy requirements make that a firm requirement, and for others it is a meaningful reduction in exposure.
Potentially lower data transfer charges
Cloud providers typically charge for data leaving their network. Data transferred out over a private circuit is often charged at lower rates than data leaving over the internet, and some circuit options include outbound data within the price. For businesses moving large volumes out of the cloud, this can offset part of the circuit cost. Our guide to cloud network egress costs explains how these charges work.
Service level commitments
Private circuits come with availability commitments from the cloud provider and the connectivity provider, subject to resilient design. VPNs depend on the internet, which nobody guarantees end to end.
Internet VPN versus a dedicated private circuit
The comparison sets out the practical differences between the two approaches.
Site-to-site VPN over the internet
Encrypted tunnels across public internet paths
Dedicated private circuit
ExpressRoute or Direct Connect via a peering location
The private circuit is highlighted because it is the option most businesses do not know they could use, not because it is the right default. For many workloads, the VPN column is entirely sufficient, and the extra cost and lead time of a private circuit buy nothing the business needs.
Scoring three hybrid connectivity designs
The score grid compares three common designs. A high badge means strong performance on that dimension, except for the last row, where high means high cost and effort.
A single VPN is quick and cheap but fragile. Dual VPNs over diverse internet connections, often managed through SD-WAN, add resilience at modest cost and suit many businesses well. A private circuit with VPN backup is the strongest design on performance and path control, at the highest cost and effort. Note that the private circuit only keeps traffic off the internet when it is working; during failover to the VPN, traffic crosses the internet again, which matters if the requirement is absolute.
Hybrid cloud connectivity in UK businesses — the numbers
The figures below are indicative, drawn from hybrid network reviews we carry out for UK businesses. They are not a formal survey.
Two messages sit side by side here. Most businesses rightly use VPNs, and only a minority have workloads that justify a private circuit. But a third rely on a single tunnel with no backup, which is a resilience gap worth fixing regardless of whether a private circuit is ever needed.
Problems reported on VPN-only hybrid connections
The chart shows the problems most often reported by UK businesses using internet VPNs for hybrid workloads, across the environments we review. Many report more than one, so figures add up to more than 100%.
The most common problem, tunnel drops, is usually solved by better VPN design rather than a private circuit: redundant tunnels, diverse internet links and properly configured failover. Slow transfers and throughput ceilings can sometimes be solved with a larger gateway or better devices. It is the latency-sensitive applications, heavy recurring data transfer and path requirements lower down the chart where a private circuit becomes the natural answer.
How ExpressRoute and Direct Connect actually work
The two services are similar in concept and differ in detail. Understanding the moving parts helps when comparing quotes and designs.
Peering and Direct Connect locations
Both providers connect to customers at specific facilities, usually major colocation data centres. The UK has several such locations, predominantly in and around London, with options elsewhere depending on the provider. Your traffic enters the cloud provider’s network at that facility, and from there travels over the provider’s backbone to your cloud regions.
Getting to the location
If your servers are already in a facility where the cloud provider is present, connecting can be relatively quick: a cross-connect within the building. Most SMEs are not, so they use a connectivity provider. Some providers extend a dedicated circuit from your office to the facility; others connect your office or data centre to their own network, which in turn connects to the cloud providers. Network-as-a-service and cloud exchange providers have made this much easier, often provisioning cloud connections in days once you are connected to their network.
Circuit types and bandwidths
ExpressRoute circuits are commonly provisioned through partners at bandwidths from tens of megabits up to several gigabits per second, with ExpressRoute Direct offering very high-capacity ports directly from Microsoft. AWS Direct Connect offers dedicated connections at high port speeds directly at Direct Connect locations, and hosted connections at a range of lower speeds through partners. Check current options, as available speeds change over time.
Peering and routing
On ExpressRoute, private peering connects to your Azure virtual networks; a separate Microsoft peering can reach some Microsoft public services, subject to restrictions. On Direct Connect, private virtual interfaces connect to your VPCs, public virtual interfaces reach AWS public services, and transit virtual interfaces connect to transit gateways for larger designs. Routing is exchanged using BGP, so your network team or provider needs to manage BGP sessions and route advertisements carefully.
Gateways and SKUs
Inside the cloud, traffic reaches your virtual networks through a gateway: an ExpressRoute gateway in Azure, or a virtual private gateway, Direct Connect gateway or transit gateway in AWS. Gateway size affects throughput and cost. ExpressRoute also offers different circuit SKUs with different reach, such as local options that connect only to nearby regions with outbound data included, and premium options with global reach.
Our earlier guide to Azure ExpressRoute covers the Azure service in more depth; this guide compares the private options across both clouds against VPNs.
Sizing bandwidth sensibly
Whether you use a VPN or a private circuit, sizing bandwidth from real traffic avoids both bottlenecks and paying for capacity you never use.
Start with measured traffic between your premises and the cloud: average and peak throughput in each direction, and when peaks occur. Nightly backups and data loads often dominate peaks; daytime application traffic may be modest by comparison. Separate the two, because they have different needs. A circuit sized for overnight transfers may be far larger than daytime traffic requires, and it may be cheaper to schedule large transfers more evenly, or use offline transfer for one-off bulk loads, than to provision for the peak.
Allow headroom for growth over the contract term, and for the backup path to carry essential traffic if the primary fails. Remember that the cloud gateway also has throughput limits; a large circuit behind a small gateway will not deliver its rated speed. Private circuits can usually be upgraded in bandwidth during their term with modest effort, so starting at a realistic size and increasing later is often better than over-provisioning from day one.
Data plans matter too. Metered plans charge for outbound data on top of the circuit; unlimited plans include it at a higher fixed price. The right choice depends on how much data leaves the cloud each month.
Practices in place among businesses with private circuits
The progress bars show how often each practice is in place among UK businesses that already use ExpressRoute or Direct Connect, across the environments we review. Figures are indicative, and the gaps show where private circuits often fall short of their potential.
Private circuit practices in place
Many businesses that have invested in a private circuit have not tested failover, do not have physically diverse paths, and have never checked whether the expected savings or performance gains materialised. A private circuit with an untested backup and a single physical route can be less resilient in practice than a well-designed pair of VPNs.
From decision to live: a typical private circuit project
The timeline shows a typical sequence for a UK business adding a private circuit to Azure or AWS from its office or data centre, using a connectivity provider.
The access circuit dominates the timeline. If you already have a leased line or a connection to a network provider that offers cloud on-ramps, the private connection itself can sometimes be added in days. If new fibre is needed to your premises, lead times of several months are possible. Planning private connectivity alongside an office move or leased line renewal can avoid paying for and waiting on two separate circuits.
Choosing a connectivity provider
For most SMEs, the connectivity provider determines much of the cost, lead time and resilience of a private circuit. Comparing providers on more than price pays off.
- Reach to your premises. Can they serve your office or data centre over existing fibre, or is new construction needed? This largely sets the lead time.
- Cloud on-ramps. Which cloud providers and locations can they connect you to, and how quickly can new cloud connections be provisioned once you are on their network?
- Diversity options. Can they provide physically diverse paths, or connections to two different peering locations, for resilience?
- Flexibility. Can bandwidth be changed during the term, and can additional cloud connections be added without new access circuits?
- Service levels and support. Availability commitments, fault response times and who you call when something breaks.
- Commercial terms. Contract length, set-up charges, excess construction charges and exit terms.
If you already have a leased line from a provider that offers cloud connectivity, adding a private cloud connection over the same access circuit may be the quickest and cheapest route, though it means the internet and cloud connections share the same physical path, which affects resilience.
Common myths about private connectivity
Several assumptions about private circuits are widespread and can lead to poor decisions.
“Private means encrypted”
Traffic on ExpressRoute and Direct Connect is not encrypted by default. It travels over private infrastructure, which reduces exposure, but if your requirements call for encryption in transit, you need to add it: application-level encryption such as TLS, IPsec tunnels running over the private circuit, or link-level encryption where the service and port type support it. Many organisations already encrypt sensitive application traffic regardless of the path, which is good practice.
“Private means more secure in every way”
A private circuit protects the path, not the endpoints. Poorly configured routing can expose more of your network to the cloud, or vice versa, than intended. Network security rules, segmentation and identity controls matter just as much as with a VPN.
“It will make everything faster”
A private circuit improves consistency and throughput between your network and the cloud. It does nothing for users reaching cloud applications over the internet from home or from other sites, and if application slowness is caused by the application itself, the database or user devices, the circuit will not help.
“We need it for Microsoft 365”
Microsoft generally recommends reaching Microsoft 365 over the internet with good local breakout, rather than over ExpressRoute, except in specific approved scenarios. A private circuit to Azure is not a solution to Microsoft 365 performance issues.
“One circuit is resilient”
Cloud providers build redundancy into their side of a circuit, but a single access circuit from your premises, a single provider or a single location remains a single point of failure. Resilient designs need diversity, or at least a tested backup path.
Hybrid cloud network maturity — where most UK businesses sit
Combining path resilience, performance visibility, encryption, routing control and cost awareness gives an indication of hybrid network maturity. The gauge reflects a typical UK business running production workloads across its own premises and one cloud provider.
A score in the high thirties typically reflects a working connection with little around it: a single VPN tunnel, no measurement of latency or throughput over time, no tested backup, routing configured once and not reviewed, and no view of data transfer costs. It works until it does not, and when performance problems arise there is no data to diagnose them.
Most of the improvement does not require a private circuit. Adding a second tunnel over a diverse internet link, monitoring performance, testing failover and tracking data transfer typically moves a business into the sixties. A private circuit becomes the next step only when measured requirements justify it.
Realistic cost of each option
The table compares indicative monthly costs for connecting a UK office or data centre to a cloud provider. Figures are broad ranges in pounds and vary widely with bandwidth, provider, location, contract term and data volumes; they are a guide to proportion rather than a quotation. Cloud provider charges change, so check current pricing.
| Cost element | Site-to-site VPN | Private circuit via provider | Notes |
|---|---|---|---|
| Cloud gateway | £25 to £300 depending on size | £100 to £800 depending on size and type | Larger gateways for higher throughput |
| Cloud port or circuit charge | None | £50 to £1,500 depending on bandwidth and plan | Metered and unlimited data plans differ |
| Connectivity provider | Existing internet connection | £300 to £2,000 for access and cloud connection | Depends on whether new fibre is needed |
| Data transfer out of the cloud | Standard internet egress rates | Often lower rates, or included on some plans | Significant at high volumes |
| Set-up and design | Hours to a few days | £1,000 to £10,000 including design and installation | Excess construction charges can add more |
For a typical SME, a resilient VPN design might cost tens to a few hundred pounds a month on top of existing internet connections. A private circuit with a VPN backup commonly costs from several hundred to a few thousand pounds a month, plus set-up. The difference is justified when the business problems in the earlier chart are real and costly, or when data transfer savings offset part of the cost. It is not justified simply because a private circuit sounds more robust.
How often private circuit failover has been tested
A private circuit is usually paired with a backup path, but backups that have never been tested often do not work as expected. Across the private circuits we review in UK businesses, the share where failover to the backup path has not been tested in the last year is high.
The figure is indicative rather than a formal survey. Common problems found when failover is finally tested include VPN tunnels that were configured but never brought up, routing preferences that keep traffic trying the failed circuit, backup gateways too small for production traffic and firewall rules that only allow the private path. Each is easy to fix once found. A planned failover test, at least annually and after significant changes, turns a theoretical backup into a real one.
When the workload actually justifies a private circuit
A private circuit earns its cost in a recognisable set of situations. If none applies, a well-designed VPN is usually the better choice.
Heavy, recurring data transfer
Businesses moving large volumes between on-premises systems and the cloud — nightly backups, data warehouse loads, media files, replication — benefit from consistent throughput, and may save on data transfer charges. As a rough guide, recurring transfers measured in many terabytes a month are where the economics start to favour a private circuit.
Latency-sensitive hybrid applications
Applications split between on-premises and cloud that make many small round trips, such as an on-premises application talking to a cloud database, are sensitive to latency variation. If users experience intermittent slowness that tracks internet conditions, a private circuit can stabilise it.
Strict path requirements
Some contracts, regulators or internal policies require that certain traffic does not cross the public internet. Where that requirement is genuine and absolute, a private circuit is the straightforward way to meet it, with care taken over what happens during failover.
Large migrations
Moving large data sets or many servers to the cloud can be faster and more predictable over a private circuit. For one-off migrations, offline transfer services or temporary bandwidth may be cheaper; for long migration programmes, a circuit can pay off.
High-volume, business-critical integration
Where on-premises and cloud systems exchange data continuously as part of core operations — manufacturing, logistics, trading, healthcare — the reliability and predictability of a private path can justify the cost.
A decision framework: data volume, latency and compliance
Work through three questions, using measured data rather than assumptions.
1. How much data moves between you and the cloud?
Measure monthly data in each direction and its peaks. Low to moderate volumes favour VPN. High, recurring volumes, particularly outbound from the cloud, start to favour a private circuit on both performance and cost grounds.
2. How sensitive are the workloads to latency and its variation?
Identify which applications depend on the hybrid path and how they behave when latency varies. If users of hybrid applications experience intermittent slowness, measure latency and jitter over time to see whether it correlates. Workloads that tolerate variation suit VPN; those that do not suit a private circuit.
3. Are there genuine requirements about the network path?
Check contracts, regulatory obligations and internal policies for explicit requirements. Distinguish genuine requirements from general preferences. Where a requirement exists, confirm whether encryption over the internet satisfies it, since many do, or whether traffic must avoid the internet entirely.
Applying the answers
- Low volume, latency tolerant, no path requirement: site-to-site VPN, ideally with two tunnels over diverse internet links.
- Moderate volume or some latency sensitivity: improve the VPN design first — diverse links, larger gateway, SD-WAN — and measure again.
- High volume, significant latency sensitivity or a genuine path requirement: private circuit with a tested VPN backup.
- Critical workloads with all three: two private circuits on diverse paths, ideally at different locations, plus VPN backup.
For a broader view of wide area network options, including SD-WAN and MPLS, see our comparison of SD-WAN, MPLS and internet VPN.
Designing for resilience
Whichever option you choose, resilience comes from removing single points of failure on your side of the connection.
For VPNs, use two tunnels, ideally from two devices over two internet connections from different providers, terminating on a gateway configured for redundancy. Cloud VPN gateways typically support active-active or redundant configurations; use them.
For private circuits, the cloud side is built with redundancy, but your access circuit, your provider and the peering location are not automatically diverse. Options in rising order of resilience include a private circuit with a VPN backup, two private circuits from the same provider on diverse paths, and two circuits at different peering locations, possibly from different providers. Cloud providers publish recommended resilient designs; for critical workloads, follow them.
For both, make sure routing prefers the right path and fails over cleanly, that the backup path has enough capacity for essential traffic, and that failover is tested regularly. Monitor latency, throughput and path status, and alert on changes.
Monitoring the hybrid path
Without monitoring, connectivity problems surface as vague complaints that “the system is slow”, and nobody can tell whether the network, the application or the cloud service is responsible. A small amount of monitoring changes that.
Track latency and packet loss between your premises and your cloud resources continuously, using the providers’ network monitoring tools or your own. Watch throughput on tunnels and circuits against their capacity, so you see saturation coming. Monitor tunnel and BGP session status, with alerts when a path goes down or fails over. Record data transfer volumes and costs monthly. And keep the measurements: a history of performance is invaluable both for diagnosing problems and for deciding, with evidence, whether a VPN is sufficient or a private circuit is justified.
For businesses that already have a private circuit, monitoring also shows whether it is delivering what was expected. If latency, throughput and data transfer costs look much the same as they would over a well-designed VPN, the circuit may be worth reconsidering at renewal.
The 12-point hybrid connectivity checklist
The checklist covers the essentials for connecting your network to Azure or AWS.
- Measure current performance. Latency, jitter, throughput and tunnel stability over at least a week.
- Measure data transfer. Monthly volumes in each direction, and current egress charges.
- List latency-sensitive workloads. And how they behave when latency varies.
- Check for genuine path requirements. Contracts, regulation and policy, not preference.
- Fix VPN resilience first. Two tunnels, diverse internet links, redundant gateways.
- Choose a private circuit only for a measured need. Volume, latency or path requirements.
- Plan the access route early. Existing leased lines and network providers with cloud on-ramps shorten lead times.
- Size gateways for real traffic. On both primary and backup paths.
- Encrypt sensitive traffic. Private circuits are not encrypted by default.
- Design routing deliberately. Document advertisements, preferences and failover behaviour.
- Test failover. At least annually and after significant changes.
- Review the business case. Three months after go-live and annually: performance, reliability and costs.
Many hybrid connectivity problems are solved without a private circuit: a second internet connection from a different provider, a correctly sized cloud gateway, redundant VPN tunnels and basic monitoring. Fixing those first costs little, improves resilience immediately and provides the measurements needed to decide whether a private circuit is worth the investment.
Case study: two businesses, two answers
Two UK businesses approached the same question in the same quarter: should they move from VPN to a private circuit?
The first, a professional services firm with around 90 staff, ran its practice management system in Azure, with users in two offices connecting over a single site-to-site VPN from each office. Staff reported occasional slowness and two outages in a year when a tunnel dropped. A supplier had suggested ExpressRoute. Measurements over two weeks showed modest data volumes, latency that was stable except during the outages, and an application that worked well over the internet when the tunnel was up. The firm added a second internet connection from a different provider at each office, configured redundant tunnels to an appropriately sized gateway and added monitoring. Outages stopped, at a fraction of the cost of a private circuit.
The second, a manufacturing business with around 250 staff, ran production planning and machine data collection on-premises, with analytics, reporting and backups in Azure. Every night it transferred several terabytes to the cloud and pulled processed data back, and a planning tool on-premises queried a cloud database throughout the day. Its VPN was regularly saturated overnight, backups overran into the working day, and planners experienced intermittent delays that tracked internet congestion. Outbound data charges were also rising. The business installed an ExpressRoute circuit through a connectivity provider, with a VPN backup over its existing internet connection. Backups completed within their window, planning tool delays disappeared, and reduced data transfer charges offset a meaningful part of the circuit cost. Failover was tested before go-live and again six months later.
“We were told we needed a dedicated circuit, but the numbers said otherwise. Two internet lines and proper VPN design fixed our problems for a few hundred pounds a month. For us, measuring first saved a lot of money.” — Operations Director, UK professional services firm
The lesson is not that one technology is better. It is that the right answer followed from measured data volume, latency sensitivity and business impact, and the two businesses reached different answers for good reasons.
Common hybrid connectivity mistakes
The mistakes below account for most of the problems we see in hybrid cloud networking.
- Buying a private circuit because it sounds enterprise-grade. Without a measured need, it adds cost and lead time.
- Relying on a single VPN tunnel. A single point of failure that is cheap to fix.
- Undersized cloud gateways. A common cause of throughput ceilings blamed on the internet.
- Assuming private means encrypted. Add encryption where requirements call for it.
- A single access circuit to the private connection. Cloud-side redundancy does not cover your side.
- Untested failover. Backups that have never been exercised often fail when needed.
- Routing that does not fail over cleanly. Traffic keeps trying the failed path.
- Routing Microsoft 365 over a private circuit. Generally not recommended without specific approval.
- Ignoring data transfer charges. They can make a private circuit more economical, or a VPN more expensive than expected.
- Never reviewing the business case. Circuits outlive the projects that justified them.
If a private circuit was chosen because traffic must not cross the public internet, a VPN backup over the internet may breach that requirement when it activates. Decide in advance whether encrypted internet failover is acceptable for each type of traffic, and if not, use a second private circuit for resilience and restrict which traffic may use the VPN path.
Connecting to both Azure and AWS
Businesses using both clouds face a choice: separate connections to each, or a shared approach. Separate VPNs to each cloud are simple and inexpensive. For private connectivity, network-as-a-service and cloud exchange providers can connect your premises once to their network and then provision private connections to Azure, AWS and other providers from there, often in days and with flexible bandwidth. This avoids separate access circuits for each cloud and can also provide private paths between the clouds themselves.
If workloads in the two clouds need to talk to each other heavily, consider where that traffic should flow. Routing it back through your own premises adds latency and consumes your circuit bandwidth; routing it between clouds through a provider’s network or a dedicated cross-cloud connection is often better. Data transfer charges apply when traffic leaves either cloud, so design with costs in mind. Our comparison of Azure and AWS covers the wider platform differences.
Private access to cloud services, not just virtual networks
Private circuits and VPNs connect your network to your virtual networks in the cloud. Many cloud services, however, are reached through public endpoints by default: storage accounts, databases, key vaults and similar platform services. Even with a private circuit in place, traffic to these services may still use public endpoints unless you configure otherwise.
Both providers offer private endpoint features — Azure Private Link and AWS PrivateLink and VPC endpoints — that give platform services private addresses inside your virtual network. Combined with a VPN or private circuit and correct DNS configuration, this lets on-premises systems reach those services privately, and lets you disable public access to them entirely. For businesses with path requirements, this is often as important as the circuit itself, and it is frequently overlooked.
DNS is the part most often got wrong. On-premises systems need to resolve service names to the private addresses rather than the public ones, which usually means forwarding specific DNS zones to resolvers in the cloud. Test name resolution from on-premises carefully when introducing private endpoints.
Where private connectivity fits in a wider hybrid design
The connection between your premises and the cloud is one part of a hybrid network. It sits alongside internet breakout for users reaching software-as-a-service applications, remote access for home workers, connectivity between offices and the network design inside the cloud itself. Decisions about private circuits should be made with that whole picture in view.
For example, a business moving most workloads to the cloud over the next two years may find that its offices increasingly need good internet connections rather than a private path to a data centre, and that remote workers need secure access to cloud resources directly. A private circuit may still make sense for a remaining on-premises system with heavy integration, but the long-term direction affects how much to invest and on what contract term. Our guide to building a hybrid cloud environment in Azure covers the broader architecture.
At a glance: private connectivity versus internet VPN
| Factor | Site-to-site VPN | ExpressRoute or Direct Connect |
|---|---|---|
| Path | Public internet, encrypted | Private infrastructure, not encrypted by default |
| Latency | Generally fine; varies with internet conditions | Consistent and predictable |
| Throughput | Limited by devices, gateway, tunnels and internet link | Provisioned bandwidth delivered reliably |
| Lead time | Hours to days | Days to months, mostly the access circuit |
| Monthly cost | Low | Several hundred to thousands of pounds |
| Data transfer charges | Standard internet egress | Often lower; included on some plans |
| Resilience | Redundant tunnels over diverse links | Diverse circuits or VPN backup needed on your side |
| Encryption | Built in | Add TLS, IPsec over the circuit or link encryption |
| Routing | Static or BGP | BGP; careful route management required |
| Microsoft 365 | Use internet breakout | Generally not recommended without approval |
| Best for | Most SMEs and moderate hybrid workloads | Heavy data, latency-sensitive hybrid apps, strict path requirements |
How Cloudswitched approaches cloud connectivity
We start with measurement rather than a product. For businesses connecting to Azure, AWS or both, we measure current latency, throughput, stability and data transfer, identify the workloads that depend on the hybrid path, and check for genuine requirements about how traffic travels.
Where a VPN is the right answer, we design it properly: redundant tunnels over diverse internet connections, appropriately sized cloud gateways, private endpoints and DNS for platform services, and monitoring that shows what the connection is doing. Where the data justifies a private circuit, we design ExpressRoute or Direct Connect with the right bandwidth, location and provider, encryption where requirements call for it, routing that fails over cleanly and a backup path that has been tested before go-live. We help plan the access route, often alongside leased line or office projects, to avoid unnecessary lead times.
After go-live, we review whether the connection is delivering the expected performance, reliability and cost outcomes, and adjust as workloads change. No connection is free of risk, but choosing on evidence ensures you pay for the problems you actually have.
Not sure whether you need a private circuit?
Talk to us about measuring your hybrid connectivity, improving VPN resilience or designing ExpressRoute and Direct Connect where the data justifies it.
Talk to a Cloud Networking SpecialistFrequently Asked Questions
What is the difference between ExpressRoute and a VPN?
A VPN creates encrypted tunnels across the public internet to your cloud network. ExpressRoute provides a private connection to Microsoft’s network through a peering location, offering more consistent latency and throughput and keeping traffic off the public internet, at higher cost and lead time.
What is AWS Direct Connect?
The AWS equivalent of ExpressRoute: a dedicated private connection between your network and AWS at a Direct Connect location, available as dedicated connections or hosted connections through partners.
Is ExpressRoute encrypted?
Not by default. Traffic travels over private infrastructure. Where encryption is required, use TLS at the application level, run IPsec over the circuit, or use link-level encryption where the service and port type support it.
Do I need a private circuit to use the cloud securely?
No. A well-configured site-to-site VPN provides encrypted, secure connectivity suitable for most businesses. Private circuits address performance consistency, throughput, data volume and path requirements rather than basic security.
How much does ExpressRoute or Direct Connect cost?
Costs combine cloud port or circuit charges, connectivity provider charges, gateways and data transfer. For a typical SME, a private circuit with backup commonly costs several hundred to a few thousand pounds a month, plus set-up.
How long does a private circuit take to install?
From days, where you already connect to a provider with cloud on-ramps, to several months where a new access circuit and fibre construction are needed.
Will a private circuit reduce my data transfer costs?
Often. Data leaving the cloud over a private circuit is typically charged at lower rates than internet egress, and some plans include outbound data. Whether savings offset the circuit cost depends on your volumes.
Should Microsoft 365 traffic use ExpressRoute?
Generally not. Microsoft recommends reaching Microsoft 365 over the internet with good local breakout, except in specific approved scenarios.
Is one ExpressRoute circuit resilient?
The Microsoft side includes redundancy, but a single access circuit, provider or location is still a single point of failure. Use a VPN backup or diverse circuits for resilience, and test failover.
Can I connect to Azure and AWS with one circuit?
Through a network-as-a-service or cloud exchange provider, a single connection to their network can be used to provision private connections to several clouds.
What are private endpoints and do I need them?
Private endpoints give cloud platform services private addresses in your virtual network. They let on-premises systems reach those services over your VPN or circuit and allow public access to be disabled, which matters where traffic must stay private.
How do I know whether my business needs a private circuit?
Measure data volumes, latency sensitivity of hybrid workloads and any genuine path requirements. If none is significant, improve VPN resilience instead. If one or more is, a private circuit is worth evaluating.
Related reading
More guidance for UK businesses from the Cloudswitched blog:
- Azure Kubernetes Service vs App Service: choosing the right compute platform
- Fixed wireless access: 5G and microwave as an alternative to fibre
- Why Microsoft 365 native retention is not a backup
- AI integration architecture: connecting LLMs without a maintenance nightmare
- Cyber Essentials scope: deciding what is in and out of your certification
Connect to the cloud the way your workloads need
Cloudswitched designs hybrid cloud networks for UK businesses, from resilient VPNs to ExpressRoute and Direct Connect, chosen on measured need rather than assumption.
Talk to a Cloud Networking Specialist
Cloudswitched
London-based managed IT services provider offering support, cloud solutions and cybersecurity for SMEs.
