Deploy the solution
This solution uses AWS CloudFormation templates and stacks to automate its deployment. The CloudFormation templates specify the AWS resources included in this solution and their properties. The CloudFormation stack provisions the resources that are described in the templates.
Deployment considerations
Before you launch the automated deployment, please review the architecture, configuration, 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 (5) 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
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 Instance Scheduler’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.
Deployment process overview
Important
This solution includes an option to send anonymized operational metrics to AWS. We use
this data to better understand how customers use this solution and related services and
products. AWS owns the data gathered though this survey. Data collection is subject to the
AWS Privacy Policy
To opt out of this feature, download the template, modify the AWS CloudFormation mapping section, and then use the AWS CloudFormation console to upload your updated template and deploy the solution. For more information, see the Anonymized data collection section of this guide.
Before you launch the solution, review the Cost ,Architecture overview ,Security, and other considerations discussed earlier in this guide. Follow the step-by-step instructions in this section to configure and deploy the solution into your account.
Time to deploy: Approximately 5-10 mins (not including configuration)
Step 1: Launch the instance scheduler hub stack
-
Launch the AWS CloudFormation template in your AWS account.
-
Enter values for the required parameters.
-
Review the other template parameters and adjust, if necessary.
Step 2 (Optional): Launch the remote stack in secondary accounts
-
Launch the AWS CloudFormation template in your AWS account.
-
Enter a value for the required parameter: Primary account.
Step 3: Configure schedules and periods
-
Create schedules and periods for your environment.
-
Apply the custom tag to applicable resources
