AWS Instance Scheduler

Advantages

Scheduling instances across multiple accounts

In the AWS Instance Scheduler solution, IAM roles play a crucial role in managing resources across multiple accounts. The solution includes a template specifically designed for building the necessary IAM roles within the Amazon Web Services (AWS) Identity and Access Management (IAM) service. These roles are essential for the smooth launch and termination of instances within secondary accounts.

The IAM roles created by the solution are integrated into the AWS Instance Scheduler, which is deployed as a CloudFormation template. This powerful combination allows users to efficiently control and oversee resources in multiple accounts from a single scheduler stack. By configuring IAM roles within the scheduler stack, users gain the ability to launch and terminate instances seamlessly across various accounts.

The AWS Instance Scheduler further enhances its functionality by providing multiple methods for managing periods and schedules. Users can conveniently create and manage these parameters using custom resources in CloudFormation, directly edit DynamoDB tables, or even utilize the dedicated AWS Instance Scheduler CLI tool. This flexibility ensures that users have a range of options to suit their specific needs and preferences.

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.

Cost Reductions

The AWS Instance Scheduler offers a range of features to help reduce costs associated with instance usage. One such feature is the ability to create schedules with specific time intervals for instance execution. These schedules can include multiple sessions, allowing for flexibility in defining when instances should be active. Users also have the option to select a time zone for their schedules, with a default time zone available if no specific one is specified.

To ensure optimal cost savings, the Instance Scheduler includes an “enforced” feature. When enabled, this feature prohibits manual starting or stopping of instances while a running period is in progress. If a user attempts to manually start an instance outside of a running period, the solution will terminate the instance. This ensures that instances are only active during the specified periods, preventing unnecessary costs.

Along with managing instance availability, the Instance Scheduler allows users to specify an optional Amazon EC2 instance type for each period. This means that users can choose the most cost-effective instance type for different timeframes, further optimizing cost-efficiency.

Schedules

The AWS Instance Scheduler is a powerful tool designed to optimize the management of Amazon Relational Database Service (Amazon RDS) and Amazon Elastic Compute Cloud (Amazon EC2) instances. Automating the stopping and starting of these instances helps users significantly reduce operational costs within their AWS environment. This tool not only ensures cost efficiency but also enhances resource management through precise scheduling.

Periods

Each schedule assigned to Amazon RDS and Amazon EC2 needs a unique name, which serves as the value of the associated resource tag, facilitating proper organization and identification within the system. The operational flexibility of the Instance Scheduler is evident as every schedule requires the inclusion of a time interval, specifying when the instance will execute. Importantly, a timetable can consist of multiple sessions, allowing for versatility in scheduling.

Time zone

To ensure seamless execution, the Instance Scheduler initiates appropriate start actions whenever a valid period rule is identified. This gives users precise control over when instances are activated, ensuring optimal resource utilization. The scheduler also allows the selection of a specific time zone for scheduling, accommodating diverse geographical requirements and ensuring accurate operations across different regions.

Hibernate

It allows you to put stopped Amazon EC2 instances into hibernation. If the hibernate field is set to “yes” when you configure it, your EC2 instances will have an AMI. The AEC User Guide for Linux Instances provides 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, which 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. To enforce scheduling restrictions, the solution includes a feature known as ‘enforced.’ When this field is set to ‘true,’ manual starting or stopping instances outside a running period is prohibited. If a user attempts to start an instance manually, the solution will automatically terminate it, ensuring adherence to the predefined schedule and further enhancing cost control by preventing unscheduled usage.

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

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 the 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.

The solution may stop running an 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.

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.

Performance

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.

Related Articles