EC2 Scheduling Best Practices

EC2 Scheduling Best Practices

The ‘pay for what you consume’ model has been favored by AWS users for as long as one can remember. Even with EC2 instances, there are certain servers that need to be kept running 24/7, usually in the production environment; but other servers in the staging and dev environments are only used at certain calculable intervals. So running all your instances at all times prohibits you from leveraging the best part of AWS. This is where basic instance scheduling comes in, where you automate the start and stop of such non-essential instances according to a schedule. 

EC2 instance scheduling in itself has become a best practice for optimizing instance usage and costs; but we’ve realized that the process of scheduling can also intrinsically be optimized, with certain best practices to define it. The savings that you generate just through basic scheduling during regular business hours can run up to almost 70%, imagine what happens if you go a step further. Here are some best practices to follow when it comes to scheduling your instances.


1. Find the right instances to schedule

The prefix to setting up a schedule is identifying the instances that need to be subjected to a schedule in the first place. As we’ve said earlier, instances being used for dev, staging or testing purposes are ideal for scheduling. It becomes essential to ensure that no critical instances (prod) are incorrectly selected for scheduling. Certain prod instances can also be scheduled, if it’s uptime is predictable and limited. 


2. Tag correctly 

Standardized naming conventions or tags for all your instances assists in being able to differentiate between prod and dev instances. To enable easier scheduling, it is advised to set server hostnames based on environment type (staging, test, prod, etc.). This way the non-essential resources can be filtered out easily. You can obtain a report of untagged resources through a simple workflow!

Additionally, you can also attach the schedule to the tag, to ensure the right instances are selected. For instance, if you want your instance to start at 7am and stop at 6pm from Monday to Friday, your tag value could be something along the lines of “700;1800;mon-fri”. 


3. Find the ideal scheduling time 

Once you’ve identified the instances that qualify as non-essential, it’s imperative to assign the right schedule to these instances. In most cases, you can hypothesize the running times for non-essential instances like staging and dev. Chances are, that such instances only need to be running between 8am to 5pm; at the max. These timings can be substantiated through instance usage reports, that TotalCloud can generate for you in a single workflow. 


4. Enable scheduling in real time (auto-scheduling)

A basic 9 hour a day schedule means your instances are running 45/168 hours in a week. But in reality, the actual usage will be only about 30-40%, that’s 18-20 hours. This means that despite scheduling, you’re paying for more than what you use. Real-time auto-scheduling (a unique TotalCloud feature!) can assist in shutting down an instance based on actual metric usage; for instance, if you define the CPU utilization threshold to be less than 10% for a period of 30 minutes or more, the instance will shut down when it becomes true. Imagine the magnitude of savings if you schedule for 20 hours instead of 45!? 

 

5. Implement manual schedule overrides 

At any given point in time, having an option to manually override a schedule counts as a safety measure. In case of any ad hoc usage changes or during maintenance activities, you can instantly start or stop the instance to maintain more uptime or downtime, as required. 


6. Take into account instance restart behaviour

When an instance is restarted, certain configurations need to be accounted for. 

  • IP Address: An instance’s Public IP address changes upon restart and certain hard coded servers will be unable to find each other’s IPs after restart. It becomes imperative to structure your AWS architecture in a way that will minimize the effect of this issue.  
  • Elastic IP: If your instance is attached to an EIP, the instance needs to be reattached to the EIP upon restart (VPC instances keep EIPs associated through stop/start.)
  • ELB: If the instance was attached to an ELB, ensure that it is re-registered to the ELB upon restart. 
  • ASG: Similarly, if an instance was part of an ASG, the ASG settings need to be configured to accommodate the scheduled instance


7. Enable Notifications and Approval

It serves you better to be kept informed of when an instance’s start/stop action has been executed, so you can track whether the tagging is accurate and if any changes need to be made. In certain cases, you can also set up user approval before scheduling, so you are made aware of when an instance is about to be stopped or started and can authenticate it.   


In conclusion…


With cloud users leveraging every available opportunity to save money on the cloud, the importance of resource scheduling has shot up. It gets even easier when you let us completely automate it for you, from basic scheduling to auto-scheduling to fully customized scheduling. The cost you incur on us will be offset by the incredible amount of money you save on your instances. You can sign up for a free trial to find out how this works!

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

Product
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
Sayonee
AWS Use Case Files
Increase AWS EBS Volume size (Auto-remediation)
Learn how a simple workflow can auto-remediate and increase the EBS volume size when disk utilization goes beyond 90%
December 2, 2019
Sayonee
AWS Use Case Files
Instance CPU Utilization Report
Learn how a single workflow can be used to generate a CPU Utilization Report for EC2 Instances. This enables you to stay on top of EC2 utilization efficiency, and ensure you aren't over or underutilizing them.
October 24, 2019
Sayonee
AWS Use Case Files
Lambda Daily Cost Predictor
Learn how a simple workflow can be used to predict daily lambda costs, that can help prevent 'bill-shocks' and optimize your costs better.
October 24, 2019
Sayonee
Cloud Automation
Putting DevOps on autopilot with LEGO-like automation
The post explains our flagship product, the TotalCloud Workflow Editor. The Editor assists you to do practically anything you want on your AWS infrastructure. It primarily enables you to create completely customized workflows from scratch to automate all cloud actions. Learn how to leverage the easy-to-use editor and save loads of time and costs.
October 24, 2019
Sayonee
AWS Use Case Files
Reporting Security Groups with TCP Port 22 (SSH) access from public IP
Learn how to use a simple workflow to generate a report of Security Groups with unrestricted Port 22 access from Public IP. Similarly, workflows can be generated to identify SGs with any open ports.
October 24, 2019
Sayonee