Are you getting the most out of your AWS investment? Get your free AWS Well-Architected Assessment.

2021 Fillmore Street #1128


24/7 solutions

AWS Instance Scheduler

AWS Instance Scheduler

The Instance Scheduler solution assists you in controlling your Amazon Web Services (AWS) resource costs by creating start and stop schedules for your Amazon Elastic Compute Cloud (Amazon EC2) and Amazon Relational Database Service (Amazon RDS) instances.


With the help of the Instance Scheduler solution, you can better manage your Amazon Web Services (AWS) resource expenses by automating the start and stop of Amazon Elastic Compute Cloud instances of the Amazon Elastic Compute Cloud (Amazon EC2) and the Amazon Relational Database Service (Amazon RDS). It also contributes to the reduction of operational costs by turning off resources that are not in use and turning on resources when additional capacity is required. Example: A corporation can utilise AWS Instance Scheduler in a production setting to automatically halt instances outside of business hours on a daily basis, saving time and money. If you leave all of your instances running at 100% utilisation, this approach may result in a reduction in instance utilisation, which will result in a reduction in overall cost calculated according to the schedules that have been established for the various situations.

Overview of the AWS Solution

The following diagram illustrates an architecture that can be automatically deployed by following the instructions provided in the solution’s implementation guide and utilising the corresponding AWS CloudFormation template, as illustrated.

Image Sourced from Amazon Web Services

The design of the AWS Instance Scheduler.

  • An Amazon CloudWatch event will be generated by the AWS CloudFormation template at a frequency and duration that are specified by the user. This event acts as a trigger for the AWS Lambda function that is stored in the AWS Instance Scheduler, which is subsequently run. During the course of the configuration process, AWS Regions and accounts, in addition to a user-specified tag, are each defined. The AWS Instance Scheduler makes use of this tag in order to properly associate schedules with appropriate Amazon EC2 and Amazon RDS instances.

  • These values are saved in Amazon DynamoDB, and the Lambda function is responsible for retrieving them whenever it is invoked. After that, you will have the option to attach the custom tag to the instances that are suitable for it.

  • You will be asked to enter a tag key the first time you configure the Instance Scheduler. This key will be used to identify the Amazon EC2 and Amazon RDS instances that are relevant to the configuration. As a result of creating a schedule, the name you specify is utilised as the tag value, which uniquely identifies the schedule you wish to apply to the tagged resource that you created. It’s possible, using the solution’s default tag name (tag key) Schedule, for example, to create an appointment schedule called “uk-office hours”. In order to identify an instance that will utilise the uk-office-hours schedule, the user must include the Schedule tag key with the value uk-office-hours in the instance’s tag definition.
Free AWS Services Template

Download list of all AWS Services PDF

Download our free PDF list of all AWS services. In this list, you will get all of the AWS services in a PDF file that contains  descriptions and links on how to get started.


Scheduling instances across multiple accounts

This solution includes a template for building the Amazon Web Services (AWS) Identity and Access Management (IAM) roles that are necessary for launching and terminating instances in secondary accounts. This is one of the aspects of the solution.

Automated tagging of blanks

Any instances that the AWS Instance Scheduler begins or ends have the potential of having tags automatically added to them by the scheduler. Additionally, the solution has macros that provide you the ability to insert variable information into the tags that you create.

Using the Scheduler CLI, you can specify start and end times for scheduled events.

Through the command line interface (CLI) of this solution, users have access to a number of commands that may be used to configure schedules and periods. The CLI is available for usage by customers in order to generate cost reduction estimates for a given period of time.

The SSM maintenance window is where you set up your schedules and periods.

For EC2 instances, AWS Instance Scheduler can utilise SSM maintenance windows that have been created in the same Region as the instances, and it can start and stop the instances during the duration of the maintenance window.

Table for configuring the scheduler

An Amazon DynamoDB database is created during the installation of the AWS Instance Scheduler, which contains all of the system’s setup parameters. After the solution has been deployed, you can make changes to these global configuration parameters by updating the AWS CloudFormation stack. It is imperative that the values included in the DynamoDB table not be altered in any way. If you make changes to the values recorded in the DynamoDB table, you will cause a conflict between the stored parameters in the stack and the values stored in the database.

In the configuration database, global configuration items include a type attribute with the value config, which indicates that they are configuration items. This implies that the configuration database stores these items. In their respective definitions, schedules and periods both include type attributes that have values that correspond to the schedule type and, more specifically, the period type. It is possible to create, update, and remove schedules and periods from the configuration database by using the DynamoDB console or the command line interface provided by the solution.

Need help on AWS?

AWS Partners, such as AllCode, are trusted and recommended by Amazon Web Services to help you deliver with confidence. AllCode employs the same mission-critical best practices and services that power Amazon’s monstrous ecommerce platform.


Amazon Relational Database Service (Amazon RDS) and Amazon Elastic Compute Cloud (Amazon EC2) need to have their schedules set up. Each schedule needs to have its own name, and that name will serve as the value of the tag associated with the resource.


Every schedule necessitates the inclusion of a time interval specifying when the instance will execute. It is possible that the timetable includes multiple sessions. An appropriate start action is taken each time the Instance Scheduler determines that at least one of the period rules is valid.

Time zone

Additionally, the schedule gives you the option to select a time zone. Default time zone will be used if no time zone is specified when solution is launched.


It allows you to put stopped Amazon EC2 instances into hibernation.Your EC2 instances will have an AMI if the hibernate field is set to “yes” when you configure it. In the AEC User Guide for Linux Instances, you can find instructions on how to put your On-Demand or Reserved Linux Instance into hibernation. When you hibernate, the contents of your RAM are saved to the root disc of your Amazon Elastic Block Store. When the solution ends an instance, this field is set to true.

If you activate hibernation in the solution but your instances aren’t enabled or don’t satisfy the conditions, the solution will report a warning and immediately stop those instances without hibernating them. Hibernate your On-Demand or Reserved Linux Instance can be found in the AEC Linux User Guide for extra information and explanation.

Field Enforced

A feature known as “enforced” is included in schedules, and its purpose is to prohibit instances from being manually started or stopped while a running period is still in progress. If the value in this field is set to “true,” and a user manually starts an instance outside of a running period, the solution will terminate the instance. If the value in this field is set to true, all instances that were terminated by the user while the programme was still running would be restarted.

Keep running field

if the solution was initiated manually prior to the period beginning, it prevents it from finishing You cannot manually start an instance that runs from 9 am to 5 pm before 9 am.

The SSM window of maintenance

In order to arrange an AWS Systems Manager maintenance window, the field ssm-maintenance-window can be used. Before and after a maintenance window in the same AWS account and region as your deployed stack, your Amazon EC2 instances will be scheduled to operate. Instances will be started and stopped automatically if there are no other running periods and if a maintenance event has been successfully completed by the solution. AWS Lambda frequency, which you specified when configuring the solution at the outset, is used by the solution to calculate how far in advance of the maintenance window you should start your instance. For instance, if Frequency AWS CloudFormation parameter is set to 10 minutes or less, the solution will start the instance at least 10 minutes before the maintenance window. The scheduler will restart the instance every 10 minutes if the frequency is set to higher than 10 minutes.Set the frequency of your schedulers to 30 minutes and they will start running 30 minutes before planned maintenance. SSM maintenance windows should be loaded into a DynamoDB database using the CloudFormation option Enable SSM Maintenance windows to begin when the AWS Lambda function is started.

The status field can be overridden.

Schedules feature an override status field that can be used to temporarily override the start and stop of operations. If you leave this field set to “running,” the solution will start, but it will not shut down when you press Enter. Unless manually ended, the instance will continue to run. A solution, on the other hand, does not truly halt the relevant situation. No stopping or restarting an instance after it has begun.

Override status is running, but enforced is used to prevent an instance from being manually started outside of the running period. The solution terminates an instance if this occurs. Enforced prevents the instance from being manually terminated while it is still running by restarting it if override status is set to halted.

Instance Type

Scheduling simply allows you to specify an optional Amazon EC2 instance type for each period. An Amazon EC2 instance will be created based on the type of instance you choose in the timeframe.

To indicate an instance type, use period name@instance type syntax. Weekends at t2.nano, for example. It is not possible to schedule Amazon RDS instances if you select a different instance type from the one that is used to plan instances on Amazon EC2 at that moment.

It’s possible that the solution will stop a running instance and then restart it with a different instance type if it’s not possible to make that change without destroying data or corrupting other ongoing instances.

AWS Architect

AWS Service Business Continuity Plan

Thousands of businesses are lose an unprecedented amount of money every quarter - don’t let yours! Protect your AWS services with this FREE AWS Business Continuity Plan. Learn More

Aspects of Design

Partially automated

Automated solutions are the norm for most people (i.e., configure start-only or stop-only actions). There are many situations when flexibility is needed, such as when a team wishes to be able to halt instances (manually) yet must start them at the same time each morning.

The Amazon Elastic Compute Cloud (EC2).

Instead of terminating an Amazon Elastic Compute Cloud (Amazon EC2) instance, this solution assumes that an instance shutdown action of Stop will be performed. It’s important to know that Amazon EC2 instances that have been deactivated cannot be resumed.

Configuring Amazon EC2 instances to pause rather than terminate when shut down allows you to bypass this default behaviour. It is possible for AWS Instance Scheduler to terminate instances that do not have a Stop shutdown behaviour configured in their instance scheduler settings.

Amazon Real-time Distribution Service (RDS)

This approach allows Amazon RDS instances to be automatically shut down, but not erased. This is the only use for which it was intended. Using the Make RDS Instance Snapshot AWS CloudFormation template parameter, you may make snapshots of the RDS infrastructure before shutting down the RDS instances. However, when the instance is shut down, the snapshots are removed from the system. Instead of supporting snapshots, Amazon Aurora clusters don’t.


If the Instance Scheduler AWS Lambda function does not process all scheduled instances before its next execution, the solution logs the issue in Amazon CloudWatch Logs and sends an Amazon Simple Notification Service (Amazon SNS) notification to the error SNS topic. You can either change the default interval at which the Lambda function runs or create several deployments of the solution with distinct tag names to ensure that all instances are handled before the next call.


Free AWS Services Template

Text AWS to (415) 890-6431

Text us and join the 700+ developers that have chosen to opt-in to receive the latest AWS insights directly to their phone. Don’t worry, we’ll only text you 1-2 times a month and won’t send you any promotional campaigns - just great content!

Related Articles

Models of Migration on AWS

Models of Migration on AWS

Cloud computing does offer many benefits to users who are just starting to put together applications and solutions. Having an existing solution will not preclude an organization from being able to take advantage of the cloud. Migrating those solutions to a cloud environment can prove to be tricky for users who haven’t planned in advance.

What is DevOps and How Developers Benefit

What is DevOps and How Developers Benefit

DevOps is a composition of best practices, principles, and company cultural concepts that are tailored to improve coordination in either development or IT teams in an organization. These standards help to streamline and automate the delivery cycle and allow teams to deploy applications sooner. In the case of arising issues, teams can respond faster and develop fixes sooner.