buchachon - Fotolia
Control resource sprawl in multi-cloud architectures
Resource sprawl can occur quickly and easily in a multi-cloud deployment. Learn how to dodge this costly, yet common, issue with these five best practices.
Cloud sprawl, the uncontrolled proliferation of cloud instances, is a common problem for many organizations. And it's an even bigger concern for those with multi-cloud architectures.
Cloud sprawl occurs when users fail to decommission unused cloud computing instances or services. In addition to increasing cloud costs, sprawl complicates resource management and security, as it makes it more difficult to keep track of all the services that run in your organization. Sprawl can also create resource visibility issues during personnel turnover: An IT admin who knows where sprawling resources are located takes all that information with her when she leaves the company.
Causes of multi-cloud sprawl
Sprawl can happen in many IT environments, but it's more prevalent in multi-cloud architectures for two reasons.
First, with a single cloud, organizations use monitoring tools from their cloud vendor to identify available resources. These vendor-supplied tools provide a centralized point of reference for cloud resources. In a multi-cloud model, however, monitoring tools from one cloud vendor likely won't work with another vendor's cloud. For example Amazon CloudWatch won't track down resources that run on Azure. This eliminates that centralized point of reference.
Second, when you use multiple clouds, it's likely that workloads will move between clouds frequently. One the primary benefits of multi-cloud architectures is the enterprise's ability to shift a workload from one cloud to another at any time for any reason, such as when a vendor offers a better price or new features. But, when you move workloads around, it's easy to leave one running when it shifts to a different cloud.
Best practices to mitigate sprawl
There are a few best practices to avoid sprawl within multi-cloud architectures.
1. Establish cloud policies.
Set clear and firm policies for how teams should deploy and decommission cloud resources throughout your organization. Don't let individual departments or personnel decide when to move a resource from one cloud to another, or how to handle inactive cloud services. Integrate an organizationwide governance plan.
2. Use third-party monitoring tools.
Third-party monitoring tools can provide visibility into your multi-cloud infrastructure. These tools can peer into multiple clouds at once and give you a single reference point to track all your resources.
Provider-native monitoring tools are also helpful to collect specific information from certain cloud services. But, at some point, you should have a tool in your stack that provides holistic visibility into all the clouds you use.
3. Automate resource decommissioning.
Whenever possible, use automated provisioning and deployment tools to shut down a resource or service automatically when you move workloads among clouds. With automation, you minimize the risk that your engineers will leave a service running accidentally.
4. Scrutinize your cloud bill.
Your cloud bill is more than just a bill; it gives you visibility into cloud spending trends and cloud app performance. Spending more without significantly expanding your workload footprint could be a signal that additional -- and unwanted -- resources are still running. Your bills won't provide definitive visibility into cloud sprawl, but they're useful to detect it.
5. If you can't turn it off, scale it down.
There might be times when you deliberately keep resources running in one cloud, even if you're not actively using them, so you can easily access them later. If you do this, scale down the service or lower its cost. For example, if you leave data in storage on one cloud after you copy it to another cloud, switch your storage plan on the first cloud to a less expensive cold storage option. Data will remain in the first cloud, but you won't pay as much to keep it there.
