Cloud Hosting

One of the most important -- and most complex -- concepts in multicloud is network integration between public cloud...

Enjoy this article as well as all of our content, including E-Guides, news, tips and more.

By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.

You also agree that your personal information may be transferred and processed in the United States, and that you have read and agree to the Terms of Use and the Privacy Policy.

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.

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 you move a single application component from one provider to another, you could double traffic charges.

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.

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.

Cloud computing performance and efficiency depend on how effectively you manage the intercomponent connections that support application workflows.

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

Original post:
Avoid steep network integration costs in multicloud - TechTarget