

# AWS Managed Services Resource Scheduler
<a name="ams-resource-scheduler"></a>

Use AWS Managed Services (AMS) Resource Scheduler to schedule the automatic start and stop of AutoScaling groups, Amazon EC2 instances, and RDS instances in your account. This helps reduce infrastructure costs where the resources are not meant to be running 24/7. The solution is built on top of [Instance Scheduler on AWS](https://aws.amazon.com/solutions/implementations/instance-scheduler/), but contains additional features and customizations specific to AMS needs.

**Note**  
By default, AMS Resource Scheduler doesn't interact with resources that aren't part of an AWS CloudFormation stack. The resource must be part of a stack that starts with "stack-" , "sc-" or "SC-". To schedule the resources that are not part of a CloudFormation stack, you can update the Resource Scheduler stack parameter `ScheduleNonStackResources` to `Yes`.

AMS Resource Scheduler uses periods and schedules:
+ *Periods* define the times when Resource Scheduler runs, such as start time, end time, and days of the month.
+ *Schedules* contain your defined periods, along with additional configurations, such as SSM maintenance window, timezone, hibernate setting, and so forth; and specify when resources should run, given the configured period rules. 

You can configure these periods and schedules using AMS Resource Scheduler's automated change types (CTs).

For full details on the settings available for AMS Resource Scheduler, see the corresponding AWS Instance Scheduler documentation at [Solution components](https://docs.aws.amazon.com/solutions/latest/instance-scheduler-on-aws/components.html). For an architectural view of the solution, see the corresponding AWS Instance Scheduler documentation at [Architecture overview.html](https://docs.aws.amazon.com/solutions/latest/instance-scheduler-on-aws/architecture-overview.html).

# Deploying AMS Resource Scheduler
<a name="res-sched-deploying"></a>

To deploy AMS Resource Scheduler, use the automated change type (CT) : Deployment \$1 AMS Resource Scheduler \$1 Solution \$1 Deploy (ct-0ywnhc8e5k9z5) to raise an RFC that then deploys the solution in your account. Once the RFC is executed, a CloudFormation stack containing AMS Resource Scheduler resources with default configuration, is automatically provisioned into your account. For more on Resource Scheduler change types, see [AMS Resource Scheduler](https://docs.aws.amazon.com/managedservices/latest/ctref/deployment-ams-resource-scheduler-section.html).

**Note**  
To find out if AMS Resource Scheduler is already deployed in your account, check the AWS Lambda console for that account and look for the **AMSResourceScheduler ** function.

After the AMS Resource Scheduler is provisioned in your account, we recommend you review the default configuration and, if required, customize configurations such as tag key, timezone, scheduled services, and so forth, based on your preferences. For details on the recommended customizations, see [Customizing AMS Resource Scheduler](res-sched-customize.md), next.

To make the custom configurations, or just confirm the Resource Scheduler configuration, 

# Customizing AMS Resource Scheduler
<a name="res-sched-customize"></a>

We recommend you customize the following properties of AMS Resource Scheduler using the update AMS Resource Scheduler change types, see [AMS Resource Scheduler](https://docs.aws.amazon.com/managedservices/latest/ctref/management-ams-resource-scheduler-section.html).
+ **Tag name**: The name of the tag that Resource Scheduler will use to associate instance schedules with resources. The default value is Schedule.
+ **Scheduled Services**: A comma-separated list of services that Resource Scheduler can manage. The default value is "ec2,rds,autoscaling". Valid values are "ec2", "rds" and "autoscaling"
+ **Default timezone**: Specify the default time zone for the Resource Scheduler to use. The default value is UTC.
+ **Use CMK**: A comma-separated list of Amazon KMS Customer Managed Key (CMK) ARNs that Resource Scheduler can be granted permissions to.
+ **Use LicenseManager**: A comma-separated list of AWS Licence Manager ARNs to that Resource Scheduler can be granted permissions to.

**Note**  
AMS may, time to time, release features and fixes to keep AMS Resource Scheduler up to date in your account. When this happens, any customization that you make to the AMS Resource Scheduler are preserved.

# Using AMS Resource Scheduler
<a name="res-sched-using"></a>

To configure AMS Resource Scheduler after the solution is deployed, use the automated Resource Scheduler CTs to create, delete, update, and describe (get details on) AMS Resource Scheduler periods (the times when Resource Scheduler runs) and schedules (the configured periods and other options). For an example of using the AMS Resource Scheduler change types, see [AMS Resource Scheduler](https://docs.aws.amazon.com/managedservices/latest/ctref/management-ams-resource-scheduler-section.html).

To select resources to be managed by AMS Resource Scheduler, following deployment and schedule creation, you use the AMS Tag Create CTs to tag Auto Scaling groups, Amazon RDS stacks, and Amazon EC2 resources with that tag key you provided during deployment, and the defined schedule as the tag value. After the resources are tagged, the resources are scheduled for start or stop per your defined Resource Scheduler schedule.

There is no additional cost to using AMS Resource Scheduler. However the solution makes use of several AWS services and you're charged for these resources as they are used. For more details, see [Architecture overview](https://docs.aws.amazon.com/solutions/latest/instance-scheduler-on-aws/architecture-overview.html).

To opt out of AMS Resource Scheduler:
+ For temporary opt-out or disabling: Submit an RFC using the automated Management \$1 AMS Resource Scheduler \$1 State \$1 Disable change type (ct-14v49adibs4db)
+ For permanent removal: Submit a Management \$1 Other \$1 Other \$1 Update (review required) (ct-0xdawir96cy7k) RFC requesting removal from the Resource Scheduler release automation system

# AMS Resource Scheduler cost estimator
<a name="resource-scheduler-cost-est"></a>

In order to track cost savings, AMS Resource Scheduler features a component that hourly calculates the estimated cost savings for Amazon EC2 and RDS resources that are managed by scheduler. This cost savings data is then published as a CloudWatch metric (`AMS/ResourceScheduler`) to help you track it. The cost savings estimator only estimates savings on instance running hours. It does not account any other cost, such as data transfer costs associated with a resource.

The cost savings estimator is enabled with Resource Scheduler. It runs hourly and retrieves cost and usage data from AWS Cost Explorer. From that data it calculates the average cost per hour for each instance type and then projects the cost for a full day if it was running without being scheduled. The cost savings is the difference between the projected cost and the actual reported cost from Cost Explorer for a given day.

For example, if instance A is configured with Resource Scheduler to run from 9 a.m. to 5 p.m., that is eight hours on a given day. Cost Explorer reports the cost as \$11 and usage as 8. The average cost per hour is therefore \$10.125. If the instance was not scheduled with Resource Scheduler, then the instance would run 24 hours on that day. In that case, the cost would have been 24x0.125 = \$13. Resource Scheduler helped you achieve a cost savings of \$12.

In order for the cost savings estimator to retrieve cost and usage only for resources managed by Resource Scheduler from Cost Explorer, the tag key that Resource Scheduler uses to target resources needs to be activated as the **Cost allocation** tag in the Billing Dashboard. If the account belongs to an organization, the tag key needs to be activated in the Management account of the organization. For information on doing this, see [Activating User-Defined Cost Allocation Tags](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/activating-tags.html) and [User-Defined Cost Allocation Tags](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/custom-tags.html)

After the tag key is activated as Cost Allocation Tag, AWS billing starts tracking cost and usage for resources managed by Resource Scheduler, and after that data is available, the cost savings estimator starts to calculate the cost savings and publish the data under the `AMS/ResourceScheduler` metric namespace in CloudWatch. 

# Cost estimator tips
<a name="resource-scheduler-cost-est-faqs"></a>

Cost Savings Estimator does not accept discounts such as reserved instances, savings plans, and so forth, into consideration in its calculation. The Estimator takes usage costs from Cost Explorer and calculates the average cost per hour for the resources. For more details, see [ Understanding your AWS Cost Datasets: A Cheat Sheet](https://aws.amazon.com/blogs/aws-cost-management/understanding-your-aws-cost-datasets-a-cheat-sheet/)

In order for the cost savings estimator to retrieve cost and usage only for resources managed by Resource Scheduler from Cost Explorer, the tag key that Resource Scheduler uses to target resources needs to be activated as the **Cost Allocation** tag in the Billing Dashboard. If the account belongs to an organization, the tag key needs to be activated in the management account of the organization. For information on doing this, see [User-Defined Cost Allocation Tags](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/custom-tags.html). If the cost allocation tag is not activated, the estimator is not able to calculate the savings and publish the metric, even if it is enabled.

# AMS Resource Scheduler best practices
<a name="resource-scheduler-bp"></a>

**Scheduling Amazon EC2 Instances**
+ Instance shut down behavior must be set to `stop` and not to `terminate`. This is pre-set to `stop` for instances that are created with the AMS Amazon EC2 Create automated change type (ct-14027q0sjyt1h) and can be set for Amazon EC2 instances created with AWS CloudFormation ingestion, by setting the `InstanceInitiatedShutdownBehavior` property to `stop`. If instances have shut down behavior set to `terminate`, then the instances will end when the Resource Scheduler stops them and the scheduler won't be able to start them back up.
+ Amazon EC2 instances that are part of an Auto Scaling group aren't processed individually by AMS Resource Scheduler, even if they are tagged.
+ If the target instance root volume is encrypted with a KMS customer master key (CMK), an additional `kms:CreateGrant` permission needs to be added to your Resource Scheduler IAM role, for the scheduler to be able to start such instances. This permission is not added to the role by default for improved security. If you require this permission, submit an RFC with the Management \$1 AMS Resource Scheduler \$1 Solution \$1 Update change type, and specify a comma separated list of ARNs of the KMS CMKs.

**Scheduling Auto Scaling groups**
+ AMS Resource Scheduler starts or stops the auto scaling of Auto Scaling groups, not individual instances in the group. That is, the scheduler restores the size of the Auto Scaling group (start) or sets the size to 0 (stop). 
+ Tag AutoScaling group with the specified tag and not the instances within the group.
+ During stop, AMS Resource Scheduler stores the Auto Scaling group's Minimum, Desired, and Maximum capacity values and sets the Minimum and Desired Capacity to 0. During start, the scheduler restores the Auto Scaling group size as it was during the stop. Therefore, Auto Scaling group instances must use an appropriate capacity configuration so that the instances' termination and relaunch don't affect any application running in the Auto Scaling group.
+ If the Auto Scaling group is modified (the minimum or maximum capacity) during a running period, the scheduler stores the new Auto Scaling group size and uses it when restoring the group at the end of a stop schedule.

**Scheduling Amazon RDS instances**
+ The scheduler can take a snapshot before stopping the RDS instances (does not apply to Aurora DB cluster). This feature is turned on by default with the **Create RDS Instance Snapshot** CloudFormation template parameter set to **true**. The snapshot is kept until the next time the Amazon RDS instance is stopped and a new snapshot is created.

  Scheduler can start/stop Amazon RDS instance that are part of a cluster or Amazon RDS Aurora database or in a multi availability zone (Multi-AZ) configuration. However, check Amazon RDS limitation when the scheduler won't be able to stop the Amazon RDS instance, especially Multi-AZ instances. To schedule Aurora Cluster for start or stop use the **Schedule Aurora Clusters** template parameter (default is **true**). The Aurora cluster (not the individual instances within the cluster) must be tagged with the tag key defined during initial configuration and the schedule name as the tag value to schedule that cluster.

  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 scheduler allows specifying 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.

**Note**  
The Scheduler doesn't validate that a resource is started or stopped. It makes the API call and moves on. If the API call fails, it logs the error for investigation.