AWS Instance Scheduler | Overview & Hands-On.

An Overview of AWS Instance Scheduler.

Focus:

•        Tailored for DevOps / Cloud / Platform / FinOps.
•       Aligned to how it works internally, what it can (and can’t) control, cost impact, security, and production design patterns.

Breakdown:

•        Intro,
•        Key Features and Benefits,
•        How It Works,
•        The concept: AWS Instance Scheduler,
•        Mental Model (Critical),
•        Resources It Can Control,
•        Architecture (Under the Hood),
•        Schedule Definitions (The Heart of It),
•        Tag-Based Control (Powerful & Risky),
•        EC2 Scheduling – Deep Behavior,
•        RDS & Aurora Scheduling (Gotchas),
•        Cost Savings (Why This Exists),
•        Instance Scheduler vs DIY Lambda Cron,
•        Multi-Account & Org-Wide Scheduling,
•        Security & IAM (DevSecOps Angle),
•        Observability & Operations,
•        Anti-Patterns (Seen in Real Life),
•        Instance Scheduler vs Alternatives,
•        Best-Practice Reference Architecture,
•        When NOT to Use Instance Scheduler,
•        Final Tip,
•        Insight.

Intro:

•        AWS Instance Scheduler is an automated solution (Not a service) provided by AWS that helps to reduce operational costs by automatically stopping and starting Amazon EC2 and RDS instances on a defined schedule.
•        The solution (AWS Instance Scheduler) uses AWS Lambda, Amazon DynamoDB, and Amazon EventBridge to manage instances across multiple accounts and regions based on tags you apply to your resources.

Key Features and Benefits

Cost Optimization:

•          By stopping instances when they are not in use (e.g., during off-hours or weekends), twtech only pay for the compute capacity it consumes.

Automation:

•          It eliminates the need for manual start/stop processes or writing custom automation scripts.

Centralized Management:

•          twtech can manage schedules for instances across multiple AWS accounts using a single "hub" account deployment.

Tag-Based Control:

•          The solution uses resource tags (by default, a tag key of Schedule) to identify which instances to manage and which schedule to apply.

Support for Multiple Services: 

•         It supports scheduling for Amazon EC2 instances, RDS DB instances, and Aurora clusters.

How It Works

Deployment:

•        twtech deploy the solution using an AWS CloudFormation template provided in the AWS Solutions Library.
•        This sets up the necessary infrastructure, including the Lambda function, DynamoDB tables for configuration, and an EventBridge rule to trigger the function periodically.

Configuration:

•        twtech define "periods" (specific times, e.g., 9 AM to 5 PM) and "schedules" (combinations of periods for weekdays, weekends, etc.) in a DynamoDB table.

Tagging: 

•        twtech apply a specific tag (e.g., schedule: office-hours) to its EC2 or RDS instances to link them to the desired schedule.

Execution: 

•        The Lambda function runs on a set interval (default is every five minutes) and checks the tags on twtech instances against the defined schedules in DynamoDB, performing start or stop actions as needed. 

Link to official documentation:

https://aws.amazon.com/solutions/implementations/instance-scheduler-on-aws/

1.The concept: AWS Instance Scheduler

AWS Instance Scheduler is a serverless automation solution that:

•         Automatically starts and stops AWS resources on a schedule
•         Reduces non-production infrastructure cost
•         Is tag-driven
•         Is deployed as a CloudFormation solution, not a managed AWS service

NB:

Think of it as “policy-based resource lifecycle automation”, not just EC2 start/stop scripts.

2. Mental Model (Critical)

NB:

 The scheduler does nothing unless:

•         The resource is tagged
•         The tag references a valid schedule

3. Resources It Can Control

Supported (as of current solution design)

•         ✅   EC2 instances
•         ✅   EBS volumes (indirectly)
•         ✅   RDS instances
•         ✅   Aurora clusters (limited)
•         ⚠️ Auto Scaling Groups (with care)

Not Supported / Dangerous

•         ❌   EKS node groups (natively)
•         ❌   ECS services
•         ❌   Lambda
•         ❌   Always-on production systems

4. Architecture (Under the Hood)

AWS Instance Scheduler deploys:

Component	Purpose
Lambda functions	Core scheduling logic
DynamoDB	Stores schedules & state
CloudWatch Events / EventBridge	Triggers execution
IAM roles	Cross-service permissions
CloudFormation	Lifecycle management

NB:

No EC2 servers. No cron hosts. Fully serverless.

5. Schedule Definitions (The Heart of It)

• Schedules are stored in DynamoDB.

Sample Schedule

# json

{

  "Name": "twtech-office-hours",

  "Periods": [

    {

      "BeginTime": "09:00",

      "EndTime": "18:00",

      "WeekDays": ["mon-fri"]

    }

  ]

}

# This defines:

·        Start at 9 AM

·        Stop at 6 PM

·        Monday–Friday only

6. Tag-Based Control (Powerful & Risky)

Required Tag

Schedule = office-hours

Applied to:

•         EC2
•         RDS
•         ASGs (carefully)

Optional Tags

Tag	Purpose
ScheduleTimezone	Override default TZ
ScheduleStartTime	Offset start
ScheduleStopTime	Offset stop

NB:

•  Tags are the API of Instance Scheduler.

7. EC2 Scheduling – Deep Behavior

When stopping EC2:

• ·        Instance is stopped (not terminated)
• ·        EBS volumes persist
• ·        Elastic IPs remain (unless released)
• ·        Instance store data is lost

When starting EC2:

• ·        Same instance ID
• ·        Same private IP
• ·        Public IP may change (unless EIP)

8. RDS & Aurora Scheduling (Gotchas)

RDS

• ·        Start/stop supported
• ·        Max stopped duration = 7 days
• ·        Automated backups continue
• ·        Storage cost still applies

Aurora

• ·        Cluster-level stop/start
• ·        Reader/writer behavior matters
• ·        Not suitable for frequent toggling

NB:

 Do not schedule production databases blindly.

9. Cost Savings (Why This Exists)

Typical Savings

Environment	Savings
Dev	60–75%
QA	50–70%
Staging	30–50%

Example

A dev EC2 running:

•         10 hrs/day instead of 24
•         Saves ~58% compute cost

Multiply by:

•         Dozens of instances
•         Multiple accounts

10. Instance Scheduler vs DIY Lambda Cron

Feature	Instance Scheduler	Custom Lambda
Setup	Medium	Low
Governance	High	Low
Multi-account	✅	⚠️
Auditability	High	Medium
Custom logic	Limited	Unlimited

NB:

•  Scheduler wins for standardization.

11. Multi-Account & Org-Wide Scheduling

Instance Scheduler supports:

•         Cross-account role assumption
•         Centralized scheduling account
•         Org-wide cost governance

Typical setup:

NB:

• This is very powerful for enterprises.

12. Security & IAM (DevSecOps Angle)

IAM Risks

•         Scheduler needs broad permissions:
•    ec2:StartInstances
•    ec2:StopInstances
•    rds:StartDBInstance
•    rds:StopDBInstance

Best Practices

•         Dedicated IAM role
•         SCPs to block prod tagging
•         Tag-based conditions
•         Separate prod accounts

NB:

 Tag abuse = outage risk

13. Observability & Operations

Monitoring

• ·        CloudWatch logs (Lambda)
• ·        EventBridge execution
• ·        DynamoDB schedule state

Common Failures

Issue	Cause
Instance didn’t start	Wrong timezone
Instance stopped unexpectedly	Wrong tag
RDS fails to stop	Backup window conflict

14. Anti-Patterns (Seen in Real Life)

❌    Scheduling production workloads
❌    Tagging Auto Scaling Groups without safeguards
❌    Using scheduler as HA control
❌    Ignoring timezone differences
❌    Letting developers self-tag prod

15. Instance Scheduler vs Alternatives

Tool	Comparison
EventBridge + Lambda	More flexible
Terraform schedules	Static
AWS Auto Scaling	Capacity-based
Spot Instances	Runtime cost optimization

NB:

•  Scheduler is time-based, not load-based.

16. Best-Practice Reference Architecture

Add:

•         SCPs
•         Cost Explorer
•         Tag compliance rules

17. When NOT to Use Instance Scheduler

❌    Production systems
❌    Customer-facing workloads
❌    Stateless auto-scaled services
❌    EKS/ECS managed platforms

18. Final Tip

• AWS Instance Scheduler is one of the highest-ROI cost-optimization tools in AWS — when used with discipline.

It:

•         Saves real money
•         Enforces governance
•         Reduces waste

But:

•         It can cause outages if misused
•         Requires strong tagging standards
•         Must be isolated from production

Project: Hands-On

How twtech creates and use AWS instance scheduler (Solution) in its environment to:

•        Reduce operational costs by automatically stopping and starting Amazon EC2 and RDS instances on a defined schedule.
•         Manage instances across multiple accounts and regions based on tags twtech apply to its resources with help of integrated services as AWS Lambda, Amazon DynamoDB, and Amazon EventBridge.

Google for the Solution: Instance scheduler AWS

·       Click open the link to the solution: https://aws.amazon.com/solutions/implementations/instance-scheduler-on-aws/

On the Solution web page, Navigate to Tab, do a quick Search for instance scheduler on aws

Navigate to: View Implementation guide

Automate starting and stopping AWS instances

From the left Panel, naviage to: Getting started/ step1: Launch Instance scheduler hub stack

Launch solution

NB:

•        This takes twtech directly to CloudFormation Page in its account.
•        Login and authentication would be required if the twtech was not initially login to aws,console.
•        The instance template and S3 URL is auto-filled,
•        This deploys the solution  from the CloudFormation template.

Specify stack details

1. Assign the name: twtech-InstanceScheduler-1

Schedule tag key

GlobalSettings

Hub-Account Scheduling

Monitoring

Configure stack options

Review and create

Submit the stack to:  CloudFormation with all the solutions.

• From: Create-in-Progress:

This may take a couple of minutes to deploy all the resources included in the template.

To: Create_Completed