MCN Reality Check: Cloud Native Vs. Spoke Gateway Sprawl


Multi-cloud tunneling with spoke gateways in every VPC is NOT cloud-native - It is value destruction. A multi-cloud networking solution should be both app & network-centric, follow a cloud-native approach and deliver the agility enterprises seek.

Disruption is the name of the game. In the hybrid multicloud world that we live in today, cloud practitioners, networking professionals, and executives are confronted with the challenging task of balancing multiple objectives such as agility, cost, and operational efficiency.

Customers, yes enterprise ones, have long been asked to make unnatural tradeoffs [a tradeoff tax, if you will] in achieving these outcomes.

  • You want a networking solution that works across clouds, BUT you’ll get operational redundancy and complexity. Your staff will manage the lifecycle of virtual appliances installed in each VPC in the cloud instead of the data center.
  • You want cost agility, BUT the new spend will mostly exceed with the shift from using cloud-native constructs to virtual appliances.
  • You want cloud agnostic, BUT you’ll NOT get a cloud-native operating model
    You want multicloud, BUT you must deal with costly, complex overlays that do not scale.

Hub and Spoke overlays - Making Trade-Offs

A good idea often bides its time. Hub and Spoke overlays ( where IPSEC tunnels were built from gateways or virtual routers from each VPC to a transit VPC ) were relevant until the CSPs caught up with their cloud-native versions. The “ disruptive idea “ became the norm. As an enterprise customer, you should question these tradeoffs you have been asked to make thus far.

  • I want cloud agility AND operational simplicity. I want to leverage CSP native tools for connectivity as much as possible and not have to reinvent the wheel or manage appliances for this purpose.
  • I want cloud agnostic AND cloud native. An ISV that takes a “good cloud-native” idea and makes it multi-cloud-native is much more “enterprise-ready” and future-proof than the one asking customers to pay this “tradeoff tax.”
  • I want an elastic multicloud infrastructure that provides app-centric and network-centric connectivity models. My organization has the full complement of network- and app-centric endpoints, and my connectivity options should reflect the same.
  • I want cost agility AND operational agility based on deep visibility. Deep visibility allows me to build and enforce robust policies quickly and consistently across multiple regions and cloud environments and understand the traffic patterns/flows flowing to my various cloud accounts.

Understanding True Costs of a Spoke Gateway Approach...

Given the laser focus on cloud cost control, many organizations have begun seeking ISVs that offer cost-effective solutions with innovative services. With their wide range of connectivity, networking, performance, and security requirements, enterprises are familiar with the limitations of the native networking services provided by cloud providers. These are building blocks by design. Any ISV or self-designed and automated solution must not significantly increase its ballooning cloud costs.

For example, an enterprise with resources running in 1000 VPCs and deployed across 2 regions may evaluate architectural proposals from Prosimo and other ISV.  While both claim to provide similar outcomes, there is a stark difference in the upfront solution cost and the total cost of ownership for the solution.

Imagine having to upgrade several thousand appliances, patch them every time there is a bug, and worry about those half-alive tunnels / BGP sessions in an HA pair. Even if there is a management portal for this task, didn’t “enterprises” move to the cloud to avoid these challenges?

Unrealistic claims and scale challenges…

The picture shows a single region architecture for the ISV that leads with a spoke gateway model in every VPC. Multiply this by the number of regions and clouds an enterprise will have. This model substitutes or superimposes the CSP’s inherent connectivity framework with tunneled overlays that span multiple cloud environments. The claim is that the approach enables connectivity and security across multiple clouds and multicloud visibility.

However, it deviates from the cloud-native paradigm, necessitating L3 tunnels to attach to vendor transit and subsequent security measures across clouds. If you are wondering how this will even scale, the ISV answers in their configuration guide:

Any AWS/Azure Spoke gateways that you want to use in gateway scaling cannot have HPE, BGP, NAT, DNAT, SNAT, FQDN gateways, or Site2Cloud enabled

The recent claim of becoming NGFW by adding a network-based IDS engine worsens all of these further – first off, what use does a signature match provide when 99% of cloud traffic is encrypted? We will leave the genuine NGFW vendors or the security experts inside enterprises to debunk these security claims, now returning to the architecture topic. If an enterprise has to decrypt all VPC traffic on these VM appliances, the vendor has already provided the answer on the scale above. Essentially if an enterprise needs to run the features that the ISV layer promised to bring on top of cloud-native, they ask the enterprise not to expect any scale.

Debunking Costs Claims

Claiming to help eliminate high-cost services such as NAT gateway and eliminating data processing fees is not offset by the requirement to deploy a pair of spoke gateways in every VPC which contains application resources. This is a cost-prohibitive approach in almost all cases. Additionally, spoke gateways encrypt traffic from each VPC to their hub, which is a redundant service, mainly as most applications communicate using TLS. Instead, a cloud-native private link or AWS transit gateway(Transit Gateway (TGW)) can be leveraged for ingress networking to the hub.

Why should I pay an ISV for connectivity overlay when I already paid the CSP?

This architecture touts visibility and security to that particular overlay while other aspects are treated as add-ons. It represents a minimalistic approach that forces customers into a realm of compromises.

Common sinkhole...

If you want to spin up a new workload and connect There’s a VPC and spoke appliance for that.
Want to scale throughput up? There’s a spoke appliance for that.
Overlapping CIDRs? There’s a spoke appliance for that.
Want L3 security? Yes, there is a spoke appliance for that (now branded as a pseudo firewall)
Want to reach PaaS services? Wait
Want application-level segmentation and performance? Wait
Want full-stack visibility(Not just layer 3) and insights? Wait
Want to use a new cloud connectivity model from the CSP ? Wait
Want to reduce (not shift) cost or reduce complexity? Wait

Cloud Native Approach

Doing it the right way

For the reasons above, most customers have realized that building on top of cloud primitives is the right bet when considering future-proofing their architectures.

A cloud-native architecture does not just connect “cloud-natively” ( there are no appliances or spoke tunnels needed in each VPC ); it is architected with cloud-native principles ( think elastic and fault-tolerant), connects all types of “cloud-native” endpoints ( applications, networks, PaaS services, serverless) and secures them at the appropriate layers (L3-L7). An ISV that delivers “all of the above” without penalizing the customer with a performance or an operational tax can be considered cloud-native.

Enterprises with the internal wherewithal might undertake a “do-it-yourself” approach to cloud adoption, but they soon cross multiple “chasms” in their cloud journey. Automation is presented as a panacea to navigating this multicloud complexity. While deployment speed is great initially, as the code base grows, the ability to introspect about your infrastructure and, therefore, to make changes and understand their impact reduces over time.

Full Stack from Prosimo

This is where Prosimo comes in. You can operate your infrastructure as IaC, with full-stack visibility, AI/ML-based insights into your infrastructure, and the ability to orchestrate your multicloud infrastructure using cloud-native constructs. All without the tradeoff tax or the additional overhead of maintaining spoke appliances. Prosimo reduces NAT gateway usage (over 50%), lowers egress costs, and eliminates spending on cloud-native services – Without paying this tax because it uses and intelligently orchestrates cloud-native alternatives from a regional point-of-view and extends them to the multicloud. You get operational agility, deployment agility, and cost agility.

What true cloud-native MCN delivers

If you want to spin up a new workload, application, VPC, subnet, or Paas Endpoint- Prosimo's got you covered
Want to scale throughput up? Cloud-native scaling (up and down) with Prosimo.
Overlapping CIDRs? Yes
Want full stack security and access policy (L3-L7) Yes (Natively and with adaptive service insertion. Keep using your current firewall)
Want to reach PaaS services? Yes, with Prosimo!
Want application-level segmentation and performance? Yes, with Prosimo!
Want segmentation inside a VPC? Yes, with Prosimo!
Want full-stack visibility(Not just layer 3) and insights? Yes, with Prosimo!
Want to use a new cloud connectivity model such as CloudWAN? Yes, and we’ll make it multicloud - that’s the Prosimo value-add
Want to reduce (not shift) cost or reduce complexity? Actual cost reduction with Prosimo
No operational overhead- SaaS managed and delivered. No spokes, reduced NAT GW usage, reduced egress costs Built-in, not bolt-on, L4-L7 security, and visibility allow you to eliminate appliances or PaaS services
No operational overhead- SaaS managed and delivered. No spokes, reduced NAT GW usage, reduced egress costs Built-in, not bolt-on, L4-L7 security, and visibility allow you to eliminate appliances or PaaS services
No operational overhead- SaaS managed and delivered. No spokes, reduced NAT GW usage, reduced egress costs Built-in, not bolt-on, L4-L7 security, and visibility allow you to eliminate appliances or PaaS services

The Redefined MCN

No Trade-offs

Full Stack

Being cloud-native allows customers to free themselves from the world of unnecessary trade-offs. If your ISV claims to be cloud-native, you should be able to demand that all your business and architectural objectives are met. Deployment, operational, and cost agility are outcomes when Prosimo is the foundational bedrock of your cloud-native infrastructure.