EC2 Scheduling Best Practices

Original Post: https://blog.totalcloud.io/post/ec2-scheduling-best-practices?utm_source=dev-to&utm_medium=syndication&utm_campaign=scheduling

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.

1. 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.

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”.

1. 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.

1. 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!?

1. 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.

1. 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

1. 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!