Cloud Parking

What is Cloud Parking?

The cloud’s model of operations lets you use resources on-demand, but ironically you’re paying for them even when you aren’t using them. This system of cloud services is a double-edged sword to the unprepared. Cloud Parking is a concept that enables you to leverage the ‘pay for what you consume’ philosophy for every cloud resource that you use. Turn on the resource when you’re using it, and park it when you’re not - but applicable across your entire cloud. 

What can be parked? 

The very paradigm of Cloud Parking rests on a resource’s ability to be turned on & off. Some resources have an inherent ability to be started at a certain time and be parked at a certain time - the best known would be EC2 & RDS instances. These can be parked out of the box in multiple ways that have been explored before. 

But your cloud has a multitude of other resources that are charged 24/7, but not used the same. Almost 80% of your cloud can be parked when not in use, barring a few functions like serverless. Why not extend the parking feature even to the ‘non-schedulable’ services - like RedShift Clusters, ECS, and EKS? ‘Start and Stop’ in their case involves a few additional actions like taking a backup/snapshot, deleting the resource & restoring it when needed from the backup. 

What are the current ways to park?

The current most widely practiced method of parking resources is to manually create lambda functions that start and stop them at a specified time. AWS has equipped users with the Instance Scheduler that provides a CloudFormation script, that they can use in conjunction with DynamoDB tables to set up schedules. There are a couple of third-party tools that solely provide the function of scheduling instances - in an automated fashion, and an easy-to-use UI. 

Pitfalls of the existing parking methods

Like Michael Wittig points out, EC2s have been around for 13 years. Despite this the existing parking methods haven’t prevented multiple businesses from incurring losses up to ‘000s of dollars from unnecessary uptime.

They only park EC2 & RDS instances 

The existing parking methods focus on just two out of the hundreds of resources that exist in your cloud. That hardly fulfils the paradigm of ‘Cloud Parking’. 

The most widely used method is hardly automated

The biggest parking method, the Instance Scheduler, is a manual of instructions to follow to achieve a schedule, it doesn’t put your cloud on auto-pilot. Consider a set of windscreen wipers. In the case of a slight drizzle, you might manually wipe it whenever needed. But as soon as the rain gets heavier, you trigger them to run automatically. Suppose the makers of the cars hadn’t inserted the automatic option - a heavy downpour would have you scrambling in chaos, your visibility is affected & you’re driving slower. As your cloud scales & becomes more intricate, human error & redundant repetition become your enemies.  


They only park based on time

The standard approach to parking is to set a start and stop time - based on usual business hours for your non-prod instances. But in a lot of scenarios, for larger companies, time doesn’t justify the scheduling needs. If you’re dealing with a complex or cross-continental infra, you need a smarter parking method that’s dynamic and based on actual usage. As soon as an idle resource is identified, it should power off, without the hassle of calculating the ideal time or worrying about timezones.  

I’m talking real-time power off & on-demand turn on (as easy as the flick of a switch, sticking with the metaphor). The duration where employees take breaks or their priority shifts between projects are all valid reasons to reduce uptime. 

They do not allow collaboration

DevOps teams that operate in a multi-geo setup require collaboration-friendly tools & platforms. You wouldn’t want team meetings being called on Slack just to park or unpark a resource. In a lot of cases, the creator and users of the resources are different, the intention is to give the actual user the required control to operate smoothly. 

Your engineers should be able to spin up a resource whenever they need without any hassle, through simple external URL triggers and integrations. This ability, synced with automated parking based on idleness, will be a well-oiled machine in a collaborative landscape.

 In conclusion

We’re always looking for ways to create a better version of our architecture, applications, and offering - the same applies to every cloud management function. In the case of Cloud Parking, although lambdas have been around for a while, it’s time we have something more scalable and dynamic - so that you don’t have to recreate it across resources, regions & accounts.

Cloud Parking

Smart Scheduling at your fingertips

Go from simple to smart, real-time AWS resource scheduling to save cost and increase team productivity.

Learn More
More Posts

You Might Also Like

DevOps World
Effective Transition to Remote Working for DevOps
The COVID-19 pandemic has changed the work culture among DevOps, take advantage of these proven strategies to maintain productivity. Everything from cloud migration to automation tools and work culture is addressed to keep you going strong.
April 6, 2020
AWS Tips & Tricks
The Proven Practices for Successful AWS Cost Optimization
Running your AWS cloud architecture can be expensive, you need to adopt strategies that tried and tested to bring down your expenses. Here are the best AWS cost optimization strategies available currently.
March 4, 2020
AWS Tips & Tricks
AWS Cost Optimization Checklist
Want to cut down on the costs of maintaining your cloud services? Here's a list of things you need to make sure when running your AWS architecture.
March 2, 2020
AWS Tips & Tricks
How to Schedule RDS Instances with an AWS Lambda function?
Save your costs with scheduled operation of your database. Start and stop the RDS instances manually with python Lambda functions.
February 25, 2020
Introducing the TotalCloud Smart Scheduler
Announcing the launch of the TotalCloud Resource Scheduler! Take complete advantage of AWS's 'pay for what you consume' model by putting a power control for every AWS resource that you use.
January 14, 2020
AWS Use Case Files
Increase EBS Volume Size In Aws
Learn how a simple workflow can auto-remediate and increase the EBS volume size when disk utilization goes beyond 90%
December 2, 2019