Does Your Backbone Have Your Back?

Listen to post: Getting your Trinity Audio player ready...

Private backbone services are all the rage these days. Google’s recent announcement of the GCP Network Connectivity Center (NCC) joins other similar services such as Amazon’s AWS Transit Gateway and Microsoft’s Azure Virtual WAN.

Private backbones enable high quality connections that don’t rely on the public Internet. There are no performance guarantees in the public internet which means connections often suffer from high latency, jitter and packet loss. The greater the connection’s distance, the greater the performance degradation we will typically experience. A private backbone overcomes this and ensures traffic runs fast and smooth between any two locations within the provider’s network.

So, should you use a private backbone? Absolutely. Why travel single-lane, congested and traffic-light ridden roads when you can take a multi-lane, obstacle free highway? This is a no-brainer. And with all major public cloud providers now offering private backbones, there’s got to be one that’s right for you, right? Let’s take a deeper look at an enterprise’s connectivity needs and what private backbones have to offer.

SASE vs SD-WAN – What’s Beyond Security | Download eBook

What are we trying to solve?

Enterprises have been relying on MPLS circuits to ensure connection quality between their offices and datacenters. Looking beyond the obvious drawbacks of MPLS, namely high cost and operational rigidity for applications which have been migrated to the cloud, MPLS lines provide little to no value. Enterprises must therefore find an alternative way to optimize traffic to cloud datacenters.

This is where private backbones prove their value and enable highway-like connectivity to cloud deployments. But just like any other highway, the benefit they provide depends on how close they run to where you are travelling from and where you need to get to. Since public cloud providers deploy private lines between their datacenter locations, they will benefit enterprise endpoints which are themselves located near them. Let’s break this down into a couple of questions which can help us better understand what it means.

Where are you coming from?

The point of origin for enterprise connectivity is anywhere employees connect from. This used to be the office for the most part but has increasingly shifted to employees’ homes. This means the dispersion of connecting endpoints has significantly grown and requires a highway system which has much greater and more granular coverage in order to be effective. In the world of private backbones this translates into PoP coverage. The more locations the network has PoPs at, the closer it will likely reach your origin points. AWS Transit Gateway has 16 PoPs1, Azure virtual WAN has 392 and GCP NCC has 103. Are all your users connecting from locations close to these PoPs? There’s a good chance you need a private backbone with better coverage.

Where are you headed?

One of the main reasons to use a private backbone is to enable high quality connectivity to public cloud datacenters. As mentioned above, public cloud offerings provide connectivity to these locations exactly, which makes them seem like an obvious choice. An important point to keep in mind, though, is that since private backbone services don’t interconnect, you can only use one. Most enterprises, however, don’t use just one public cloud. In fact, out of all enterprises using public services, 92 percent have a multi-cloud strategy4 with an average of 2.64 public cloud services each. Choosing a public cloud’s private backbone offerings will be a good fit for that specific cloud’s datacenter locations, but what about the other 1.6 public clouds the typical enterprise needs to reach? Who is going to guarantee connectivity performance to their datacenters? It is certainly not in the interest of AWS to guarantee your network’s performance when accessing Azure, GCP or any other cloud provider. If anything, their interest is exactly the opposite. They want to lock you into their own service. Only a cloud-agnostic private backbone service will have an interest and the ability to guarantee connectivity performance to all public cloud datacenters. It will also reduce your dependency and risk of lock-in to any single public cloud vendor.

They may serve, but do they protect?

Network performance plays an important part in ensuring enterprise applications are delivered smoothly, but we must also ensure the enterprise network is protected. This is where security services such a Next Generation Firewalls (NGFW), Intrusion Prevention Systems (IPS), Next Generation Anti-Malware (NGAM), Secure Web Gateway (SWG), Software Defined Perimeter (SDP)/Zero Trust Network Access (ZTNA) for remote user connectivity, and others come into play. The question is where do they fit in the traffic flow?

One option is to deploy them at the enterprise endpoint locations, which means traffic will first pass through them before entering, or after exiting, the private backbone. However, deploying all the above security solutions at each and every endpoint location can become quite expensive, not to mention complex to manage. Deploying them at a subset of locations (for example only at datacenters) means branch office and remote user traffic bound for a cloud-based service will need to backhaul through these locations (Fig.1). This adds latency and misses the point of having a private backbone connection for direct access to the cloud.

A second option is to use a cloud-based security service (Fig. 2). This means adding a hop along the way in order to pass through where the service is delivered from. So instead of using the private backbone for a single, direct end-to-end connection, we need to break the journey into two separate legs, user to cloud security service and cloud security service to enterprise service. This, again, defeats the purpose of having a private backbone.

 A third option is to use a private backbone which has all the security services deployed at each of its PoPs. This means that wherever you connect from, your traffic will be protected by a full security stack at the PoP nearest to you. From there, the private backbone will carry your traffic directly to its destination, wherever it may be. This will enable full security for all endpoints with no backhauling or additional stops along the way. The question is where do you find a solution that converges a private backbone with a full security stack in a single service? Gartner have defined such an architecture and named it the Secure Service Access Edge (SASE).

SASE: Private backbone done right

Cato is the world’s first SASE platform which converges networking, security, remote access, and a global private backbone into a unified cloud-native service. All PoPs run Cato’s full security stack and provide complete protection to all endpoint traffic (Fig. 3).

 

This architecture, in which the security services are embedded within each network node, enables enterprises to harness the full performance potential of their global private backbone. There is no need to backhaul or add hops on the way to the service destination. Additionally, Cato’s SASE Cloud is comprised of more than 65 PoPs, providing superior global coverage from anywhere your users connect from.

Why Choose Cato’s SASE Cloud?

Cato’s SASE Cloud has superior global distribution for optimal backbone performance. It has a full security stack embedded into every PoP, which eliminates the need for backhauling or adding hops to your traffic flows.

Cato’s SASE Cloud is a truly converged solution which simplifies your network topology and offers single-pane-of-glass management for backbone, security, networking, and remote access in a unified console. It is also IaaS vendor agnostic, ensuring your applications’ performance when delivered from any public cloud platform, and helps you avoid vendor lock-in.

Cato SASE Cloud. The backbone that serves and protects.

 

Figure 1 
Figure 2 
Figure 3
Figure 4