In theory, one of the benefits of cloud computing is that it allows businesses to pay only for the resources they consume. In reality, organizations only unlock that benefit if they excel at cloud parking – which means turning resources off when they're not needed.
Unfortunately, cloud parking is much easier said than done. Identifying which resources to park, let alone parking and unparking them in a way that doesn't jeopardize workload reliability or performance, can be quite challenging.
That's why it's critical to develop a sophisticated strategy for cloud parking – which this article helps you do.
Below, I explain what cloud parking means, why it can be challenging and how to get the most out of cloud parking by going above and beyond basic practices for turning off unused cloud resources.
What is cloud parking?
Cloud parking, a component of FinOps, is the practice of shutting down cloud resources when your business is not using them.
For example, if you have a cloud server instance running on a service like EC2, turning the server off when it's not hosting an active workload is an example of cloud parking.
Later, if you want to use the server again, you'd "unpark" it by starting the instance back up.
Cloud parking is important because almost all cloud services charge, at least in part, based on total running time.
By parking cloud resources that you're not actively using, you stop the pricing meter and avoid paying for resources you don't actually need.
Alongside practices like choosing the right resource configurations and taking advantage of committed-use discounts, cloud parking is a core step toward cloud cost optimization.
The challenges of cloud parking
Shutting off unused cloud resources may sound simple enough. However, it can become challenging in practice, for several reasons:
● Identifying unused resources: Determining which cloud resources to park can be difficult, especially in large organizations with multiple teams and sprawling cloud estates. Even if engineers carefully tag cloud resources to help identify their purpose, it's not always obvious from tags alone whether a resource actually needs to be active.
● Unpredictable needs: It's not always clear, either, when a cloud resource will need to restart – which can become an issue if you need to unpark a resource quickly but you've parked it in a way that makes a quick restart impossible. For this reason, cloud parking strategies require insight not just into when resources are not needed, but when they might be needed again.
● Lack of automation: The tools and procedures for shutting down or restarting cloud resources vary widely from one type of cloud service to another. As a result, it can be challenging to automate the process, and cloud vendors themselves offer few platforms or integrations to help.
● Complex dependencies: It's often the case that one type of cloud resource (like a server instance) depends on another (like a storage volume). If you park or unpark interdependent resources in the wrong order, you may destabilize them or make it harder to unpark them at a later time.
In short, while the concept of cloud parking is easy enough to understand, the challenges arise when it comes time to design and execute a cloud parking strategy.
Best practices for cloud parking
The complexity of cloud parking doesn't mean, however, that the only way to park resources effectively is to take a manual or ad hoc approach.
Given the right tools and strategies, you can streamline your parking initiatives in ways that optimize value while minimizing risks.
To get the most from cloud parking, consider these strategies.
Continuously track resource usage
Again, strategies like tagging aren't enough for identifying which cloud resources to park or predicting when to unpark them.
Instead, businesses should continuously and comprehensively track the cloud resources they run, and then analyze usage data to detect patterns that can guide cloud parking.
For instance, you might notice through comprehensive resource tracking that a particular cloud server instance only runs one day a week, and that it should therefore be parked the rest of the week.
Labels like "development server" or "weekly backup server" wouldn't necessarily clue you into when and for how often the server should run, but usage data would.
Establish parking and unparking priorities
As I mentioned, it's often the case that some cloud resources need to start or stop before others.
For instance, if you have an application that depends on a database, you'll typically need to bring up the database instance before the app can operate. And you'll want to take down the app before shutting down the database, lest you leave the app in a state where it can't read or write data.
To accommodate needs like these, set priority levels for different cloud resources as you formulate parking plans.
When you park or unpark, do so such that high-priority resources are started first and stopped last, avoiding the risk of causing disruptions to interdependent resources.
Park data resources
An opportunity that organizations commonly miss when parking cloud resources is reducing data costs.
Most types of cloud data resources, such as databases or storage volumes, can't be shut off in the same way that compute resources can, so businesses end up paying for their data even after applications that interact with the data are no longer running.
With a sophisticated toolset that allows you to convert between data storage types quickly, it's possible to minimize this cost. For instance, imagine you shut down an EC2 instance and want to stop paying for the EBS volume that the instance uses.
You could do this by snapshotting the EBS volume, moving that data to S3 (where storage prices are generally lower than in EBS) and then restoring the data to an EBS volume when you want to start your EC2 instance back up.
As long as you keep metadata intact to ensure that the operating system recognizes the restored EBS volume, this strategy can drastically reduce your cost of storing data during periods when you don't need it.
Align parking with business units
Different business units or groups are likely to have different cloud parking and unparking needs.
Developers may be able to accept some delay in the unparking of a server instance that they use to test code, for example, but a database that hosts mission-critical financial data may need to be unparked as quickly as possible when your accounting department needs to access it.
For this reason, design cloud parking policies that are granular enough to reflect the varying priorities of different business groups. There should be no such thing as a one-size-fits-all approach to cloud parking.
It's a simple fact: If you want to save money in the cloud, you need to park your cloud resources effectively, and while the typical organization already invests some effort in identifying and shutting down unused cloud resources, an advanced cloud parking strategy must go much further than this.
You need to know exactly what to park, as well as how and when to park and unpark, and you need to extend your parking strategy to all types of supported cloud resources, not just server instances and other obvious candidates.
More in Cloud & Hyperscale
Episode Why Sweden, why now?