Deployment considerations
Before you launch the automated deployment, review Cost, Architecture, Security, and other considerations discussed in this guide. Follow the step-by-step instructions in this section to configure and deploy Instance Scheduler into your account.
Time to deploy: Approximately five minutes
Partial automation
Users have the option to implement a partially automated solution by default (for example, configure start-only or stop-only actions). An example of this is a team that needs the flexibility to start instances at varying times (manually) but must stop those instances at the end of each day, or vice versa. Refer to Schedules for an example of how this can be done.
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 you can modify this behavior. Therefore, make sure that the instances you
control using the AWS Instance Scheduler are configured with a Stop
shutdown behavior, otherwise they will be terminated.
Amazon RDS
This solution is designed to automatically stop, not delete, Amazon RDS instances. You can use the Create RDS Instance Snapshot AWS CloudFormation template parameter to create snapshots of RDS instances before the solution stops the instances. Snapshots are kept until the next time the instance is stopped and a new snapshot is created. Note that snapshots are not available for Amazon Aurora clusters.
You can use the Schedule Aurora Clusters template parameter to start and stop RDS instances that are part of an Aurora cluster or that manage Aurora databases. You must tag the cluster (not the individual instances) with the tag key you defined during initial configuration and the schedule name as the tag value to schedule that cluster.
For more information about limitations to starting and stopping an Amazon RDS instance, refer to 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 solution 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, refer to Maintaining a DB instance 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.
Performance
If the solution's 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, you 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 15-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 Solution's main AWS Lambda function using the Memory Size parameter.
Encrypted Amazon EBS volumes
If your Amazon EC2 instances contain encrypted Amazon Elastic Block Store (Amazon EBS) volumes, you must grant
Instance Scheduler permission to use the customer master key (CMK) to start and stop
instances. Add the kms:CreateGrant permission to Instance Scheduler role
(<stackname>-SchedulerRole-<id>
Logging and notifications
Instance Scheduler on AWS leverages Amazon CloudWatch Logs for logging. This 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, refer to Solution resources.
Warning and error messages are also published to a solution-created Amazon SNS topic, which sends messages to a subscribed email address. For details, refer to What is Amazon SNS? in the Amazon SNS Developer Guide . You can find the name of the Amazon SNS topic in the Outputs tab of the solution stack.
