Back in 2021, a colleague at PacketFabric published some work around the cost of connecting to the public cloud. In the two years since, cloud providers have decreased their costs for connectivity, making a review of the findings useful for our sales teams and our customers.
The main challenge now, as it was back in 2021, is the complexity of cloud access pricing across the major public cloud providers and communicating the impact of the differences in variable cost components of the two transport options – private direct connection and public network connection.
Two things are verifiably true for a private direct connection as transport that makes it superior to the multiple different ways of packaging connection via public network transport:
The latter point is particularly true for industrial-work-month use cases like cloud-to-cloud connectivity (hybrid and multi-cloud) and cloud-to-SaaS connectivity. These use cases form the “cloud core” of both the in-process digitizing enterprise and cloud-native startup operations.
Hybrid work and site-to-cloud use cases that leverage public network transport to access public cloud and have utilization patterns that fit office-work-month characteristics may also realize benefits by switching to private network connections, including spend reduction. But, any use case that has “industrial” use characteristics has the potential for large variable egress data costs that can be addressed by private direct connection.
The Cost of Egress Data
Comparing direct private connection to public network connection to public cloud requires an understanding of multiple public cloud providers’ connectivity cost structures. Their differences require any analysis to include a caveat that generalizations about public cloud access costs are just the starting point of a conversation. You may have a specific use case with a specific provider that is outside the norm for the generalization. So my observations here are meant to pique your curiosity about your specific costs and doing further analysis on your own.
Let’s start with a clarification – public network connection INCLUDES cases where your provider has a private peer with a public cloud provider as an alternative to leveraging a shared local public peer. It also includes vendor products that build “fabrics” or “multi-cloud” overlays of public networks with customized gateways for the public cloud and DCO.
While these solutions may replace or consolidate products on the cloud provider side to normalize networking across providers, the architecture of these on the cloud provider side (and the variable billing rates) are the same with few exceptions.
Without exception or caveat, the variable egress data cost of public network cloud connection is higher than dedicated private connections. The variable rate differential can be 4-5 times more expensive (particularly if you need “premium” routing) and another 2x higher for public connectivity if you need NAT (Network Address Translation). Note that the use of NAT is particularly prevalent in the cloud-to-cloud (multi-cloud) and cloud-to-SaaS use cases.
To show the dizzying array of possible outcomes, above is an anonymized chart of public network transport options for a simple case (a single default provider public network gateway) across three major cloud providers. There are 14 variations available across them today. The choice of functionality like NAT or what providers call “premium” or “accelerated” access will put you on the steeper cost trajectories. Another useful note here – for many providers, “premium” access rates are the default.
There are two things at work in that chart. The first is the selection of 1Gbps as a connection speed and the second is the highlight of the 10% utilization rate for the industrial and office-work use case categories.
Why the 1Gbps focus? It limits the number of comparable permutations.
As a general rule, the fixed costs associated with network termination are higher for direct connection than using public network access. Direct connection fixed costs include some additional one time and monthly costs for cross-connects, provider and cloud service provider ports.
But, there is an important caveat to that general rule. For public network connection, as bandwidth needs accelerate and a solution has to implement load balancers and/or specialized virtual appliances for functionality beyond that of the cloud vendor gateway or to increase throughput beyond standard IPsec throughput ranges (1-2Gbps), fixed costs for public network transport begin to rise significantly.
It’s all about the slope of two lines. The intersection (break-even) point will move to the left in more complex (higher bandwidth) public transport scenarios as fixed costs increase and create a greater number of permutations of the graph.
The 10% utilization focus is more a matter of psychology. For things that are paid for by volume, it’s natural to underestimate how much you will use/need. 10% is arbitrarily “little.” Now, 20-40 TB/month sounds like a lot of use, but it’s not. At 1Gbps, a link utilized ~20-40% for that period for an office-work-month will carry that much traffic. That same link used in an industrial-work-month (around the cloud, every day) would only require 6-12% utilization to hit that number (saturation would deliver 320+TB/mo) – well below the arbitrarily low 10% rate.
In fact, if you’re using even a modest amount of a 1Gbps connection to your public cloud(s) for hybrid cloud, multi-cloud or cloud-to-SaaS, we should be talking about private direct connectivity.
The Egress Data Problem Applied to Hybrid and Multi-Cloud
Hybrid or multi-cloud networking solutions that propose to use the Internet (public transport) to build “multi-cloud fabrics” are simply moving customers into a potentially disastrous variable cloud egress data rate of the “industrial work month” utilization category at the higher public egress data rates.
The anonymized example above illustrates the breakeven points for dedicated connectivity (in this case via a hosted 1Gbps cloud connection) are at fairly light utilization, even for office work scenarios. Since I show charts that show the lighter range of use in this blog, it may also be instructive to also look at the potential costs of that 1Gbps at its “full potential” to get a real idea of the potential savings of private connectivity, particularly for “industrial” use.
The separation in total cost for private transport versus public transport for “industrial” use cases can be quite stark. At 150TB/mo (50% continuous utilization) the difference between private and the lowest cost public transport egress rates across providers is ~$3500/mo)!
Transport for cloud connectivity can get a bit more convoluted when you start to consider multi-cloud routing, particularly if you’re considering public transport solutions. Solutions in this space often add appliances to the public cloud footprint, increasing cost.
TruNaaSTM delivers dedicated private multi-cloud solutions as well.
Not only does our multi-cloud solution (Cloud Router) not require any hardware or other presence on our fabric other than your dedicated or hosted cloud ports, can easily deliver 100Gbps throughput and delivers the same cost benefits for interconnecting clouds as it does for connecting to a single cloud.
Cloud Router is designed (and priced) for high bandwidth multi-cloud routing, yet the break even points for its deployment compared to public transport are incredibly low for this industrial use case. When adjusted for the potential increased fixed cost of public transport solutions, it becomes even more compelling.
Cloud to SaaS
We’re busily expanding the capabilities of our Cloud Router to attack yet another industrial-work-month use case – cloud-to-SaaS connectivity.
PacketFabric QuickConnect will support the ability to easily connect public and private transport in Cloud Router for SaaS applications that use a lot of public-cloud-generated data but don’t support direct private connectivity. The solution compared with public-only transport would map (from a cost perspective) like the chart below.
As in the multi-cloud use case, this use case doesn’t require any specialized hardware or appliances in either the public cloud or the SaaS provider instance. The breakeven points are well within the extremely low end of utilization, particularly for an industrial use case.
Beyond Price
The value of dedicated private connectivity for both your WAN and Cloud Access needs goes beyond price. Dedicated connectivity for cloud access has a proven advantage in application performance that comes with tight SLAs delivered over a private network.
In a 2021 test between PacketFabric Cloud Router (private direct connection between cloud providers) and cloud provider VPN services, we showed “PacketFabric’s Cloud Router, with a 1G connection, outperformed the Site-to-Site VPN by 225%” for an Apache Kafka pipeline between Azure and AWS using standard tools and libraries.
Direct private connection offers low latency and jitter resulting in a consistent network experience. While shared networks, whether shared in transit or at a peering site, are more unpredictable as a transport underlay.
Direct private cloud access via PacketFabric TruNaaSTM is created on high performance, high bandwidth hardware forwarding engines and has none of the potential hidden performance impacts that lurk in the use of software-based access gateways. Software-based solutions often run on shared infrastructure in public cloud deployments and may have real throughput limitations.
The key to the potential variance in public network performance, where usage of public networks is necessary, is mitigation. Some analysts call these mitigation strategies “enhanced Internet,” but these enhancements can’t substitute for the consistent performance of our diverse, private fiber optic network fabric.
Dedicated cloud access via PacketFabric TruNaaS™ also provides solutions that are better aligned with emerging cloud core workflows. Our real-time, on-demand consumption mirrors applications (and other infrastructure usage) and the superior automation of our Cloud Router with provider side automation and Terraform support set us apart from our competitors.
Conquering Complexity
On the surface, obtaining private direct cloud connection may seem more complex than using public network transport, but the only really easy thing about public network access is the ubiquity of the Internet. Beyond that, what happens inside your VPC/VNET to plumb your connection to your compute, storage and provider-specific SaaS has almost as many caveats and complexities (if not more) for public connectivity as private connectivity.
PacketFabric TruNaaSTM automates the acquisition and maintenance of direct private cloud connections across cloud providers. Depending upon whether your desired connection is dedicated or “hosted”, there can be slight variations in the process, but we make it as easy as possible to consume private connections.
Our PacketFabric Cloud Router product extends that automation to connectivity BETWEEN public cloud providers. And, our evolving capabilities from our recent merger with Unitas Global will allow us to extend our private connectivity fabric presence both physically via our Edge to Everywhere initiative and virtually via the integration of public network access with our private network services.
NaaS Nearby
That’s a lot to process and we’d be happy to sit down and talk through the costs and options for private dedicated cloud connectivity via PacketFabric TruNaaSTM with you.
Luckily, we may already be neighbors.
Whether for office-work-month use cases like site to cloud access or industrial-work-month uses like hybrid, multi-cloud or cloud-to-SaaS, if you’re one of the tens of thousands of enterprises already using third party data center operator space for your digitization projects, our network is already adjacent to yours. If not, our Edge to Everywhere capability will make it even easier to extend our fabric to your new edge, whether that’s major office parks, hospitals, manufacturing sites, stages, venues or wherever your edge may be.
Click here to set up a call with our network experts.
Footnotes
1. An industrial-work-month (there are no weekends, holidays or dark time) is 730 hours a month – this would be typical for machine-to-machine interaction
2. A standard office-work-month is 22 days at 10 hours a day or 220 hours a month.
3. In general, the premium rate has to do with how far they carry traffic on their own network (versus dumping it to the public network as soon as possible for transit across service provider networks). In at least one case, it’s a more technically complex service, essentially treating your assigned IP address like an anycast address. Premium routing has obvious implications on your application/user experience.
4. The slope of services that include NAT depends (gets steeper) on the percentage of egress traffic that is being subject to NAT – in this model, 50% was chosen.
5. Private dedicated (vs hosted) connectivity has a higher starting point than hosted ports (an additional cross-connect and more expensive cloud-side port cost – ~$550-$800) but provides more flexibility.
6. Connections are modeled as “Long Haul” (PacketFabric definition) between A and Z endpoints. “Metro” connections would lower the fixed/starting cost of the line in the chart.
7. Adjustments based on publicly available pricing for IaaS infrastructure (recommended instance type) and license from cloud provider Marketplace(s).
8. PacketFabric Proof of Concept: Optimize Multi-Cloud Streaming Performance with PacketFabric Cloud Router | ONUG A subsequent blog provided the instructions for users to repeat the test for themselves.
9. See this prior blog for a discussion of hosted vs dedicated direct connection https://packetfabric.com/blog/understanding-aws-direct-connect-vs-internet-vpn