Instance Scheduling - automatically stop non-production instances overnight
Feature description
This feature automatically stops non-production EC2 and RDS instances overnight and over each weekend, in order to save on AWS costs and reduce environmental impact. Stopped instances don’t incur charges, but Elastic IP addresses or EBS volumes attached to those instances do.
The instances will be automatically stopped each weekday at 21:00 and started at 06:00 each weekday morning, which includes shut down on Friday night and startup on Monday morning. By default, this includes every EC2 and RDS instance in every non-production environment (development, test, preproduction) without requiring any configuration from the end user. Users can customise the default behaviour by attaching the instance-scheduling tag to EC2 and RDS instances with one of the following values:
default- Automatically stop the instance overnight and start it in the morning. Absence of theinstance-schedulingtag will have the same effect.skip-scheduling- Skip auto scheduling for the instanceskip-auto-start- Stop the instance at night, but skip starting it in the morning. This could be useful for the instances we want to make sure are automatically stopped every night, but we are happy to manually start when needed.skip-auto-stop- Start the instance in the morning, but skip stopping it at night.
Here’s a Terraform example of how to add the relevant tag for any EC2 and RDS instance that should not be automatically stopped overnight.
tags = merge(
local.tags,
{ instance-scheduling = "skip-scheduling" }
)
EC2 instances that are part of an Auto Scaling group, will be skipped automatically. The presence of the tag
aws:autoscaling:groupNameindicates that the EC2 instance is part of an Auto Scaling group.
Ordering instances and automatically stopping them on public holidays is not supported using this option.
Custom Shutdown & Startup Schedules
For those teams that require the shutdown & startup of ec2 & rds resources in a specific order or at different times, the option exists to make use of github workflows & cron schedules to stop & start services.
These workflows can be run from the application source github via the use of oidc for authentication to the Modernisation Platform. It is recommended to hold the AWS account number for the member account as a github secret, especially if the repo is public.
An example of how to use a github workflow to meet this requirement can be found here. Note that the workflow uses a separate script to run the AWS CLI commands for shutdown & startup. These can be easily reused & customised to meet specific needs.
EC2 or RDS resources that are stopped or started in this manner must have the
skip-schedulingtag added as described above.Note that there are some restrictions that come with using github schedules - most importantly that github themselves do not guarantee execution of the action at the specified time. Actions can be delayed at busy times or even dropped entirely so it is recommended to avoid schedules running on-the-hour or half-hour.
Further information regarding github schedule events can be found here.