One of the most important -- and most complex -- concepts in multicloud is network integration between public cloud...
providers. This model facilitates cross-cloud load balancing and failover but, without careful planning, can also lead to hefty network integration costs.
Nearly all enterprises have a virtual private network (VPN) that connects their sites, users, applications and data center resources. When they adopt cloud computing, they often expect to use that VPN to connect their public cloud resources as well. Many cloud providers have features to facilitate this, and even when they don't, it's usually possible to build VPN support into application images hosted in the cloud.
When enterprises put their public cloud applications on their VPN, it's easier to integrate applications and workflows because the application IP addresses are all internal and under their control. From a networking perspective, cloud bursting and failover look similar to scaling or replacing resources in your own data center. This kind of integration is even more valuable in multicloud because it makes all cloud providers look almost like extensions of your own data center or like a single, elastic pool of resources.
Problems arise, however, when multicloud users add more providers -- especially around traffic charges. Seemingly insignificant changes to applications and workflows can increase overall network integration costs.
Understand traffic charges in multicloud
Most public cloud providers price some or all of their services based, in part, on traffic in and out of their cloud. This is particularly true of database services. It's routine for providers to offer free data traffic between cloud applications in the same region and between applications and cloud data services, but not across a cloud border into a VPN. As a result, if you access two cloud providers via your VPN, you need to pay each for transfers between the cloud and your data center.
Most users expect these charges, but the billing surprises occur when a workflow moves between application components hosted in different public clouds. In this case, you transfer data from one cloud to another via your VPN. This means you pay once for the traffic exiting one cloud and again when it enters the other.
If all your cloud providers share your VPN address space, it makes it easier to deploy and redeploy components to accommodate changes in load or to respond to failures because you control all the addressing. This flexibility enables you to easily -- and sometimes accidentally -- create workflows that generate those expensive provider-to-provider charges. If you move a single application component from one provider to another, you could double traffic charges.
Here are some steps to optimize that flexibility, without creating additional costs.
Reduce multicloud network integration costs
First, understand when your cloud providers apply traffic charges. Not all services incur these costs, and cost assessments could vary between providers. Even if you don't currently use any services that incur these traffic charges, one application modification could change that and create significant cost variability as your hosting patterns shift. Always keep track of pricing and traffic policies.
Second, think in terms of workflows, not application components. Cloud computing performance and efficiency depend on how effectively you manage the intercomponent connections that support application workflows. In multicloud, this workflow is the largest cost variable you can control. When you shift where you host application components -- either among cloud providers or between providers and your own data center -- remap the workflows to assess costs.
Third, remember that workflows are the result of where you host your application components in the cloud. Manage multicloud workflows by controlling where you put application components -- meaning which clouds you can use and when -- and not by applying network traffic filters to prevent cloud border crossings. Establish cloud bursting and failover policies to ensure you don't introduce workflows that cross provider boundaries, adding to overall network integration costs.
Finally, assign each cloud provider its own address range within your VPN. Most enterprises use an RFC 1918 (IPv4) or RFC 4193 (IPv6) address for their VPNs. In IPv4, the Class A space 10.x.x.x is available, and it offers ample room to create cloud provider subnetworks. If you use this approach, it's possible to control -- or at least identify -- where application component placement creates a workflow that crosses between two or more cloud providers and therefore runs the risk of multiple traffic charges.
Prepare your IT team for a multicloud model
Navigate the challenges of APIs in multicloud
Build a successful multicloud strategy with automation