AWS Instance Scheduler
AWS Instance Scheduler

Design Considerations

Partial Automation

Users have the option to implement a partially automated solution by default (i.e., configure start-only or stop-only actions). An example of this is a team that needs the flexibility to stop instances at varying times (manually) but must start those instances simultaneously each morning, or vice versa.

Instance Shutdown Behavior

Amazon EC2

This solution is designed to automatically stop Amazon Elastic Compute Cloud (Amazon EC2) instances and assumes that instance shutdown behavior is set to Stop, not Terminate. Note that you cannot restart an Amazon EC2 instance after it is terminated.

By default, Amazon EC2 instances are configured to stop, not terminate, when shut down, but customers can modify this behavior. Therefore, make sure that the instances you control using the Instance Scheduler are configured with a Stop shutdown behavior, otherwise they will be terminated.

Amazon RDS

Note that this solution is designed to automatically stop, not delete, Amazon Relational Database Service (Amazon RDS) instances. Before the Instance Scheduler stops an RDS instance, it creates a snapshot of the instance. The snapshot is kept until the next time the instance is stopped and a new snapshot is created.


The scheduler will not start or stop RDS instances that are part of a cluster, or that manage Amazon Aurora databases. Tagged instances that cannot be scheduled are logged in Amazon CloudWatch. For more information about limitations to starting and stopping an Amazon RDS instance, see Stopping an Amazon RDS DB Instance Temporarily in the Amazon RDS User Guide.

When an Amazon RDS instance is stopped, the cache is cleared which might lead to slower performance when the instance is restarted.

Amazon RDS Maintenance Window

Every Amazon RDS instance has a weekly maintenance window during which any system changes are applied. During the maintenance window, Amazon RDS will automatically start instances that have been stopped for more than seven days to apply maintenance. Note that Amazon RDS will not stop the instance once the maintenance event is complete.

The Instance Scheduler allows you to specify whether to add the preferred maintenance window of an Amazon RDS instance as a running period to its schedule. The solution will start the instance at the beginning of the maintenance window and stop the instance at the end of the maintenance window if no other running period specifies that the instance should run, and if the maintenance event is completed.

If the maintenance event is not completed by the end of the maintenance window, the instance will run until the scheduling interval after the maintenance event is completed. For more information about the Amazon RDS maintenance window, see Amazon RDS Maintenance in the Amazon RDS User Guide.

Global Configuration Settings

When you deploy the Instance Scheduler’s AWS CloudFormation template, global configuration settings are stored in an Amazon DynamoDB table (ConfigTable). To modify these settings, update the solution stack using the AWS CloudFormation template. Do not change these settings in the DynamoDB table.


If the Instance Scheduler AWS Lambda function does not process all scheduled instances before its next invocation, the solution logs the error in Amazon CloudWatch Logs, and sends an Amazon Simple Notification Service (Amazon SNS) notification to the error SNS topic. To help ensure that all instances are processed before the next invocation, customers can change the default interval at which the Lambda function runs or launch multiple deployments of the solution with different tag names.

If you increase the default interval, this might reduce the granularity of your schedules. For example, a Lambda function set to run on a fifteen-minute interval will only perform start and stop actions every 15 minutes.

To schedule a large number of instances, we recommend using an interval of at least five minutes and increasing the memory size of the Instance Scheduler’s main AWS Lambda function using the Memory Size parameter.

Regional Deployments

Customers can deploy the Instance Scheduler in any AWS Region. Once deployed, the Instance Scheduler applies the appropriate start or stop actions to tagged Amazon EC2 and Amazon RDS instances in all regions of a customer’s account. If you enable cross-account instance scheduling, the solution will apply actions to instances in all regions in all accounts.


Instance Scheduler actions will affect appropriately tagged instances in all AWS Regions of your account, even though the Lambda function is running in a single region.

You can use multiple deployments of the solution to schedule a large number of instances, or instances in many accounts and regions. When you deploy multiple schedulers, use a different tag name for each stack, and configure a set of non-overlapping regions for each deployment. Each deployment checks every instance in every region in an account for the tag key that identifies resources it should schedule. If the regions for multiple deployments overlap, each instance will be checked by multiple deployments.

Logging and Notifications

The Instance Scheduler leverages Amazon CloudWatch Logs for logging. The solution logs processing information for each tagged instance; the results of the period rule evaluation for the instance; the desired state of the instance during that period; the applied action; and debugging messages. For more information, see Appendix B.

Warning and error messages are also published to a solution-created Amazon SNS topic which sends messages to a subscribed email address (see Subscribe to a Topic in the Amazon SNS Developer Guide). You can find the name of the Amazon SNS topic in the Outputs tab of the solution stack.