Uptime Scheduler vs Instance Scheduler on AWS

AWS publishes a free scheduler — Instance Scheduler on AWS — and for a lot of accounts it is the right tool. This page is the honest version of the comparison: what each does, where they genuinely differ, and the cases where you should skip us and deploy the free one.

What Instance Scheduler on AWS actually is

Instance Scheduler on AWS is an AWS Solutions Implementation — a supported reference architecture you deploy from a CloudFormation template into your own account. Under the hood it is a Lambda function invoked by an EventBridge rule (every five minutes by default) that reads schedule and period definitions from a DynamoDB configuration table and enforces the desired running state on any resource carrying the configured tag (default key Schedule).

It handles EC2 instances and RDS / Aurora databases, supports cross-account and cross-region enforcement through IAM roles, and is actively maintained by AWS. Because the Lambda re-evaluates desired state on every interval, it is a true reconciler rather than a one-shot stop — a distinction that matters below.

It is free of license cost. You pay for the Lambda invocations, the DynamoDB table, and the CloudWatch logs it produces — a few dollars a month in most accounts. What you own in return is its operation: deploying it, upgrading it, wiring the config table, and debugging it when a schedule does not fire.

Feature comparison

Where the two genuinely differ

ECS services

Instance Scheduler does not touch ECS. If your non-production environments run services on ECS — whether Fargate or EC2 launch type — the scheduler cannot scale them down for you. Uptime Scheduler sets a service's desiredCount to zero on the off-window and restores it on the on-window. On Fargate that is a direct compute saving of $0.04048/vCPU-hour and $0.004445/GB-hour (us-east-1) for every task that would otherwise idle overnight.

NAT Gateways

A NAT Gateway has no stop API. It bills at $0.045/hour — about $32.40/month per gateway in us-east-1 — plus $0.045/GB processed, every hour of the year, whether or not anything behind it is awake. Instance Scheduler cannot schedule it. Uptime Scheduler handles it the only way AWS allows: delete the gateway on the off-window and recreate it, re-associating the same Elastic IP, on the on-window. For a multi-AZ environment with two or three gateways sitting idle every night and weekend, this is frequently the single largest line item scheduling recovers. See the NAT Gateway cost guide for the arithmetic.

The RDS 7-day auto-restart — and why it is not a differentiator here

AWS force-starts any stopped RDS instance after seven days. This breaks homegrown cron/Lambda scripts that issue a single stop and assume it sticks. It does not break Instance Scheduler, because Instance Scheduler re-evaluates desired state every interval and will stop the instance again at the next run. Uptime Scheduler reconciles the same way. We call this out because it is a real trap — just not one that separates these two tools. If you are comparing against your own script rather than Instance Scheduler, read stopping RDS on a schedule.

Savings reporting

Instance Scheduler enforces schedules; it does not report savings. To answer "how much did this save last month" you build it yourself from the Cost and Usage Report or Cost Explorer. Uptime Scheduler shows realized savings from actual Cost Explorer figures, broken down by account and resource type — the format a finance team will accept without a spreadsheet exercise.

Operational burden

This is the quiet one. Instance Scheduler is free software you run. Someone deploys the stack, keeps it patched, manages the DynamoDB config schema, and is on the hook when a schedule silently stops firing. On a small platform team that is real time. Uptime Scheduler is managed: you deploy a CloudFormation stack once, and there is nothing to patch. Whether that trade is worth a subscription depends entirely on what your team's time is worth.

When Instance Scheduler on AWS is the right choice

We would rather you deploy the free tool than pay us for something you do not need. Choose Instance Scheduler on AWS if:

• Your estate is EC2-only (or EC2 + RDS). That is exactly its coverage, and it does it well.
• You have a firm policy against any third party in the account. Instance Scheduler is first-party AWS; nothing leaves your boundary and there is no external vendor at all.
• You have the engineering time to own it. If deploying, configuring, and maintaining a scheduler is a comfortable afternoon and an occasional upkeep task for your team, the free tool is the economical answer.

When Uptime Scheduler earns its fee

The case for paying us is narrow and specific: a mixed estate. When your non-production footprint is ECS services and NAT Gateways alongside EC2 and RDS, the coverage gap, the NAT handling, and the reporting are all work you would otherwise build and maintain yourself. If that is your environment, the subscription buys back the engineering time; if it is not, it does not, and you should use the free one.

FAQ