Leaving an instance running when it isn’t needed isn’t especially cost effective. But is there a better solution when you need to run short jobs on a recurring schedule? A cloud scheduler allows you “talk” to your cloud and pre-define when instances will start-up and be shut down, from development through to production. Essentially, it enables you to pay only for the time you need.

Having worked with Amazon cloud customers for several years now, one of the initial requests cloud newcomers always make is to ensure that an efficient environment is maintained. In order to maintain an efficient cloud, the principal capacity demand must be upheld. But how can that be applied when migrating legacy applications to the cloud? Supporting horizontal scaling deployment is often not very straightforward when migrating traditional IT services to Amazon cloud. At Emind Systems, we figured out that limiting the online services for specific demand times can have a significant impact on the cost. For example, if your instance is “always on” you will be charged for 720 hours per month (24hrs x 30 days). However If your service needs to work only from 8am to 5pm, five days a week (9hrs x 20 days), about 180 hours a month, you can actually save around 75%! on your cloud underlying compute resources. This statistic is actually the reason we built in-house tools that can be deployed and given these scheduling capabilities. In this article I would like to share some important guidelines to help you build an in-house cloud scheduler for your organization.

To build your cloud scheduler, you will need to understand your current usage. Which instances are connected to a load balancer or elastic IPs? What is happening behind the RDS database? You will need to take a snapshot of your current environment. With this you can initiate the build of your cloud scheduler:

1. Decide which of your instances can be shut down incrementally. The scheduling automation can be instructed to shut down critical resources but this is a fairly intrusive approach. A better practice would be to configure a schedule per instance and grouping by profile that uses Amazon tags (i.e. development, staging, etc.).

2. Move the selected instance to a stop state and take a snapshot of the EC2 instance configuration including its attached EIP and LB connection. Determine the need to drilldown into the Amazon API and find all relevant actions required. Regardless of the DNS route53 that is connected, the EBS will not be affected as it has been stopped.

3. The scheduler needs to trigger an event in your monitoring system to make sure it isn’t alerting your instances at the wrong time. This will serve to prevent false alarms.

4. The scheduler uses an IAM role to gain access to an environment and complete intrusive actions. In order for the user to access the scheduler, it requires the correct permissions from the organization’s active directory.

5. The Amazon cloud scheduler should have a global view point, taking time zones into consideration to coordinate high availability zones and regions.

6. If you have dozens of instances across the Amazon global infrastructure, you will need to deploy Amazon API tasks in parallel, placing them in a queue and running them asynchronously.

7. If you use Amazon AWS RDS, the only way to stop an RDS is to delete it, you should take a data snapshot backup. Store all configuration metadata (i.e. security group, engine type, disk size, Multi AZ, etc.) in the appointed DNS addresses.

8. It is imperative to monitor and record all scheduler activities in order to track and respond to any errors (such as AWS API errors). This log should include the stop and start of the scheduler and if there were any exceptions.

9. It is important not to harm development and on-going activity in your environment. As such, you will want to enable the user to abort the operation or, at the very least, to send a notification that it will happen.

Following these guidelines will enable you to build an effective cloud scheduler. This automation will enable you to define when each instance will be turned on and off, saving your organization both money and time. I hope this helps! You are invited to contact me for more information or help.

[Newvem analytics tracks your AWS cloud utilization:

• Hourly Utilization Pattern Analysis 
• Reserved Instances Decision Tool 
• Resource Resizing Opportunities

Get Started For Free or Learn More]

About the Author

Lahav Savir

Keywords: Amazon web services, Amazon Cloud Services, Cloud Scheduler, RDS Database, Cloud Automation, AWS EC2, EC2 Instances, Amazon Route53, Amazon API, Amazon IAM, Cloud Consumption, Elasticity, Utilization, Management and Control,

Content Disclaimer