← All articles

Advanced Cloud Cost Optimization Strategy: Automated Instance Scheduling

Why idle compute is the biggest silent cost driver

Most engineering and platform teams focus on obvious levers—right‑sizing instances, buying Reserved Instances, or turning off unused EBS volumes. Those actions capture low‑hanging fruit, but the largest recurring waste often hides in resources that appear to be in use while delivering no business value. A typical example is a development or test environment that runs 24/7 even though developers work only 8‑hour days. The cost of those idle hours adds up quickly:

• An m5.large EC2 instance in us-east-1 costs roughly $0.096 per hour. Running it 16 hours a day for a month adds about $46.
• An db.t3.medium RDS instance costs $0.067 per hour, which translates to $30 per month when left on overnight.
• Redshift clusters, even when paused, still accrue storage fees.

Because these resources are running, they show up in the bill as normal compute spend, making it hard to spot the waste without a dedicated analysis. The advanced tactic described below automates the shutdown and start‑up of such resources based on business‑defined schedules, eliminating the idle cost without manual effort.

The advanced tactic: Automated instance scheduling with AWS Instance Scheduler and Lambda

AWS provides a fully managed solution called AWS Instance Scheduler that uses CloudWatch Events, DynamoDB, and Lambda to start and stop EC2, RDS, and Redshift resources on a schedule you define. By coupling the Scheduler with a tagging strategy, teams can apply different schedules per environment (dev, test, prod) and even override schedules for special events.

Prerequisites and permissions

Before deploying the solution, ensure you have the following:

1. An AWS account with AdministratorAccess or a custom IAM policy that includes: - ec2:StartInstances, ec2:StopInstances - rds:StartDBInstance, rds:StopDBInstance - redshift:ResumeCluster, redshift:PauseCluster - dynamodb:PutItem, dynamodb:GetItem, dynamodb:Query - lambda:InvokeFunction, lambda:CreateFunction, lambda:UpdateFunctionCode - cloudwatch:PutRule, cloudwatch:PutTargets
2. AWS CLI version 2 installed and configured with aws configure.
3. A CloudFormation stack name you will use (e.g., instance-scheduler-stack).

Deploying the AWS Instance Scheduler solution

AWS publishes a ready‑to‑use CloudFormation template. Follow these steps to launch it:

# 1. Download the latest template URL (as of today)
TEMPLATE_URL="https://s3.amazonaws.com/solutions-reference/aws-instance-scheduler/latest/aws-instance-scheduler.template"

# 2. Create the stack (replace <stack-name> with your preferred name)
aws cloudformation create-stack \
  --stack-name instance-scheduler-stack \
  --template-url $TEMPLATE_URL \
  --capabilities CAPABILITY_IAM CAPABILITY_NAMED_IAM \
  --parameters ParameterKey=TagName,ParameterValue=Schedule \
               ParameterKey=DefaultSchedule,ParameterValue=none

# 3. Wait for the stack to finish
aws cloudformation wait stack-create-complete --stack-name instance-scheduler-stack

The template creates: - A DynamoDB table (InstanceScheduler) that stores schedule definitions. - Two Lambda functions (StartInstances and StopInstances). - CloudWatch Event rules that trigger the Lambdas based on the schedule. - An IAM role with the minimal permissions required for the Lambdas.

Customizing schedules per environment using tags

The Instance Scheduler works by reading a tag on each resource. The default tag key is Schedule, but you can change it during stack creation. Tag your resources like this:

# Tag a dev EC2 instance to shut down at 20:00 UTC and start at 08:00 UTC
aws ec2 create-tags \
  --resources i-0abcd1234efgh5678 \
  --tags Key=Schedule,Value=dev-hours

# Tag a test RDS instance with a different schedule
aws rds add-tags-to-resource \
  --resource-name arn:aws:rds:us-east-1:123456789012:db:test-db \
  --tags Key=Schedule,Value=test-hours

Next, define the schedules in the DynamoDB table. You can do this via the AWS console or CLI. Example using CLI:

aws dynamodb put-item \
  --table-name InstanceScheduler \
  --item '{
    "ScheduleName": {"S": "dev-hours"},
    "StartTime": {"S": "08:00"},
    "StopTime": {"S": "20:00"},
    "Timezone": {"S": "UTC"}
  }'

aws dynamodb put-item \
  --table-name InstanceScheduler \
  --item '{
    "ScheduleName": {"S": "test-hours"},
    "StartTime": {"S": "07:00"},
    "StopTime": {"S": "19:00"},
    "Timezone": {"S": "UTC"}
  }'

Now the Lambda functions will automatically start and stop the tagged resources according to the defined windows.

Integrating with CloudWatch Events for on‑demand overrides

Sometimes you need to keep a dev environment running for a sprint demo. The Instance Scheduler supports override tags that temporarily suspend the schedule. Add a tag ScheduleOverride with value always-on to any resource you want to keep running:

aws ec2 create-tags \
  --resources i-0abcd1234efgh5678 \
  --tags Key=ScheduleOverride,Value=always-on

The Lambda logic checks for this tag before stopping an instance. To remove the override, simply delete the tag.

Measuring the dollar impact with CloudBudgetMaster’s free AWS waste finder

After the scheduler is live, you need a way to verify the cost savings. CloudBudgetMaster offers a free AWS waste finder that scans your account in read‑only mode, identifies idle resources, and estimates the monthly dollar impact. To run the scan:

1. Visit the free AWS waste finder.
2. Connect your AWS account using an IAM role with ReadOnlyAccess.
3. Review the generated report; it lists resources that were stopped by the scheduler and shows the saved amount.

Because the scanner works without any write permissions, it is safe to run in production accounts. The report also highlights any resources that were missed by the scheduler, giving you a feedback loop to refine tag assignments.

Comparison of scheduling approaches

The table shows why the native Instance Scheduler is often the sweet spot for teams that want automation without extra cost or vendor lock‑in.

Best practices to avoid common pitfalls

• Tag consistently – Use a single tag key (Schedule) across all accounts. Enforce the tag via an IAM policy that denies StartInstances/StopInstances unless the tag exists.
• Test in a sandbox – Deploy the scheduler in a non‑production account first. Verify that stop actions do not affect workloads with persistent state (e.g., databases with open connections).
• Leverage CloudWatch Logs – The Lambda functions write start/stop events to a dedicated log group. Set up an alarm on ERROR entries to catch failed attempts.
• Consider instance hibernation – For workloads that need to retain in‑memory state, enable EC2 hibernation instead of a full stop. Update the DynamoDB schedule to call StartInstances with the Hibernate flag.
• Combine with Savings Plans – After you have a predictable on‑off schedule, purchase Compute Savings Plans that match the active hours. This reduces the on‑hour rate while still allowing the scheduler to turn resources off during idle periods.
• Document overrides – Keep a wiki page that lists any ScheduleOverride tags and the reason they exist. Periodically audit the list to ensure overrides are removed when no longer needed.

Frequently asked questions

How does the Instance Scheduler know which time zone to use?

The DynamoDB schedule entry includes a Timezone attribute (e.g., UTC, America/Los_Angeles). The Lambda functions convert the schedule to UTC before evaluating start/stop times, so you can define schedules in the region’s local time.

Will stopping an RDS instance delete my data?

No. Stopping an RDS instance preserves the underlying storage and automated backups. When you start the instance again, the data is intact. However, the instance will incur storage charges while stopped.

Can the scheduler handle spot instances?

Spot instances can be started and stopped like on‑demand instances, but you must ensure the instance is not part of an Auto Scaling group that automatically replaces terminated nodes. Tag the Auto Scaling group itself if you want the scheduler to manage the group’s desired capacity.

What if a scheduled stop conflicts with a running job?

Add a temporary ScheduleOverride tag (always-on) to the affected resource before the job starts. You can automate this with a short Lambda that reacts to a custom CloudWatch Event (e.g., a CodeBuild start) and adds the override, then removes it when the job finishes.

Key takeaways

• Idle compute accounts for a large portion of hidden cloud spend.
• AWS Instance Scheduler provides a native, tag‑driven way to start and stop EC2, RDS, and Redshift resources on a schedule.
• Deploy the solution with a single CloudFormation stack, then manage schedules via DynamoDB and resource tags.
• Use CloudBudgetMaster’s free AWS waste finder to quantify the dollar impact of your new scheduling policy.
• Follow best‑practice guidelines—consistent tagging, sandbox testing, and regular override audits—to keep the system reliable.

CloudBudgetMaster automates the entire workflow: it scans AWS accounts in read‑only mode, identifies idle and wasted resources, and reports the exact dollar impact. Today the platform supports AWS scanning; GCP, Azure, and Snowflake support are coming soon. To try the automation, create a free account.