When Cloud Advice Doesn't Match Enterprise Reality

Recently I attended a talk given by a Google Cloud architect about connecting corporate networks to Google Cloud. The talk was interesting, but within minutes something felt off. The architect described High Availability VPN (HA VPN) as the recommended way to connect an organisation to Google Cloud. Two tunnels, two gateways, BGP between them, and you have a resilient connection to the cloud.

Technically, nothing they said was wrong.

But from the perspective of someone who spent years working on large enterprise networks, it felt immediately incomplete. The architecture being described simply didn’t match the type of network environments I had worked in. That disconnect made me consider something important: cloud architecture advice is often aimed at a very different audience than traditional enterprise network engineers.

A Quick Refresher on Enterprise WAN Connectivity

Before looking at cloud connectivity, it’s worth stepping back and reviewing the types of links commonly used in enterprise networks.

MPLS

For many years, Multiprotocol Label Switching (MPLS) has been the backbone of enterprise WAN connectivity. Organisations with multiple large offices around the world often connect their major sites using MPLS circuits provided by carriers.

Key characteristics:

• Private carrier network
• Predictable latency and performance
• No exposure to the public internet
• Usually integrates with BGP routing

From a network design perspective, MPLS allows the corporate WAN to behave like a single routed network across the globe.

Site-to-Site VPN

A site-to-site VPN uses IPsec tunnels across the public internet to connect two networks.

Advantages:

• Relatively cheap
• Fast to deploy
• Secure encryption

Disadvantages:

• Dependent on internet performance
• Less predictable latency
• Usually used as backup connectivity or for smaller locations

Many organisations use VPN tunnels as secondary paths in case MPLS links fail.

DMVPN

Dynamic Multipoint VPN (DMVPN) became popular for connecting many smaller sites to central hubs.

DMVPN allows:

• Hub-and-spoke connectivity
• Dynamic tunnel creation
• Reduced configuration complexity compared to static VPNs

In practice, many enterprises used DMVPN to:

• Connect branch offices
• Provide backup paths between large sites
• Extend connectivity where MPLS was not available

Raw Internet Access

Enterprise internet access often looks very different from consumer internet access.

In many large organisations:

• Internet access is routed through central proxy servers
• DNS and web filtering are centrally controlled
• Access policies are enforced using Active Directory group policy

A typical design might include:

• Two large data centres per region
• Multiple proxy servers per site
• Users automatically discovering the nearest proxy using PAC files

This design provides both resilience and consistent security policies.

The Google Cloud Approach

In the talk I attended, the Google architect focused on HA VPN as the recommended connectivity option.

The design looked something like this:

• Two VPN gateways in Google Cloud
• Two tunnels to the on-premises network
• BGP used to exchange routes
• Automatic failover between tunnels

For organisations without complex WAN infrastructure, this is actually a very reasonable solution.

It provides:

• Redundancy
• Encrypted communication
• Dynamic routing
• Quick deployment

But for someone who had worked on large enterprise networks, something still didn’t feel quite right.

Why It Felt Wrong

In one of my previous roles, the network looked very different. We operated a global WAN with:

• Three major geographic regions
• Two primary sites per region
• MPLS connectivity between large sites
• DMVPN connecting smaller locations
• Multiple internet providers at key sites
• BGP controlling routing across the entire network

Every part of the network was designed with redundancy in mind. If one link failed, traffic could take another path. If one site failed, another site in the same region could take over. If an MPLS link failed, DMVPN could provide a fallback path. BGP policies ensured that there was always at least one viable route available. In that kind of environment, the idea of connecting the entire organisation to the cloud with two VPN tunnels over the internet felt like a major step backwards.

The Aha Moment

Eventually the realisation clicked. The talk wasn’t aimed at organisations with large, globally distributed enterprise WANs. It was aimed at organisations that have something much simpler:

• A few offices
• Internet connectivity
• No private WAN infrastructure

For those organisations, HA VPN is absolutely a sensible recommendation. It solves a real problem in a simple way. But for organisations that already operate large-scale WAN architectures, the solution needs to integrate with existing routing and connectivity models.

What Would Work Better for a Large Enterprise?

For a network like the one I previously worked on, the best approach to connecting to Google Cloud would likely be Dedicated Interconnect or Partner Interconnect. These services allow an organisation to connect Google Cloud directly into their WAN. In practice this means:

• Establishing private connectivity between the organisation’s network and Google Cloud
• Integrating the cloud environment into the existing BGP routing domain
• Treating Google Cloud as another region of the corporate network

A typical design might look like this:

Primary connectivity:

• Dedicated Interconnect links into two major data centres
• BGP exchanging routes between the enterprise WAN and Google Cloud
• Traffic flowing through MPLS as the primary path

Backup connectivity:

• HA VPN used as a fallback if private connectivity fails
• DMVPN or internet paths providing additional resilience

Smaller sites would continue to operate exactly as before:

• Branch sites connect via DMVPN
• Large regional sites provide access to cloud resources
• BGP policies determine the preferred paths

From a routing perspective, Google Cloud simply becomes another destination reachable through the WAN.

Cloud Doesn’t Replace Networking Fundamentals

One of the biggest lessons from that talk was this: Cloud platforms introduce new tools, but they don’t replace the fundamentals of network design. Architectures still need to consider:

• Redundancy
• Routing policy
• latency
• regional resilience
• failure scenarios

For smaller organisations, HA VPN may be perfectly adequate. For large enterprises with global WANs, integrating cloud environments into the existing network architecture will usually require private interconnects and careful routing design. Understanding the difference between those two worlds is essential when evaluating cloud architecture advice.

Sometimes the guidance isn’t wrong. It’s simply aimed at a completely different scale of network.