How to Schedule EC2 Instances Automatically

Why Schedule EC2 Instances?

A week has 168 hours. Your dev box, your staging environment, the QA cluster, that demo instance someone spun up in March: realistically those get touched for 40 to 50 hours. The other 120-odd hours, they sit there doing nothing and billing you anyway.

Stop them outside business hours, start them again when people clock in, and you cut the bill on those resources by 65% or more. Run ten m5.xlarge instances in non-production and that gap is thousands of dollars a month. You do not change how anyone works to get it. The instances are just off when nobody is logged in.

That is the whole pitch. The rest of this post is about how you actually wire it up, and there are three reasonable ways to do it.

Option 1: AWS Instance Scheduler

AWS ships an official solution for this, deployed through CloudFormation. You get a stack: Lambda functions to do the stopping and starting, a DynamoDB table that holds your schedule definitions, and EventBridge rules to fire the whole thing on a timer.

How it works

You deploy the CloudFormation template into every account and region that has instances you care about. Schedules live in the DynamoDB table (business hours, weekdays only, whatever you need). Then you tag each EC2 or RDS instance with the name of the schedule it should follow. From there the Lambda wakes up on its trigger, reads the tags, and stops or starts whatever matches.

Pros

It is effectively free. You pay for the Lambda invocations and DynamoDB reads, which round to nothing. It is AWS-supported, the docs are solid, and it covers RDS as well as EC2.

Cons

The setup is not gentle. CloudFormation, a DynamoDB schema, tagging conventions, all before anything turns off. You also redeploy it per account and per region, so multi-account shops are doing this several times over. There is no dashboard either, so "what is scheduled and how much did we save" is a question you answer by hand. And every time AWS revises the solution or your needs shift, that is maintenance landing back on you.

Option 2: Lambda + EventBridge (DIY)

Want full control? Build it yourself. A Lambda calls the EC2 StopInstances and StartInstances APIs, an EventBridge cron rule fires it on your schedule, done. That is the version that fits in a sentence. The real version has more to it.

What you are signing up to build and own:

• IAM roles scoped to stop/start EC2 and RDS
• Lambda functions with retries, timeouts, and error handling that actually handles errors
• EventBridge rules with cron expressions for each schedule
• Logging and alerting, because a scheduler that fails silently is worse than no scheduler
• Multi-region and multi-account plumbing, if that is your situation
• Some way to decide which instances are in scope: tags, resource groups, or a config file

The upside is genuine. You control every line, there are no external dependencies, and it does exactly what you tell it to. AWS-native, top to bottom.

The downside is that this is a real project, not an afternoon. And it does not end at launch. Lambda runtimes get deprecated, APIs change under you, and the edge cases you did not think of show up in production. Reliability and monitoring become your team's job forever. That is time not spent on the thing you actually sell.

Option 3: Managed Scheduling Tools

A managed service takes the whole problem off your plate. ParkMyAWS is one of these: you connect your AWS account with a read/write IAM role, pick the resources, set your hours, and it runs the schedule for you.

Pros

Setup is about 5 minutes. No CloudFormation, no Lambda, no EventBridge rules to babysit. Reliability, updates, and monitoring are the vendor's problem, not yours. You get a dashboard that shows every scheduled resource and the estimated savings next to it, plus alerts when an action succeeds or fails. It spans EC2 and RDS across multiple accounts and regions.

Cons

It costs money: a monthly subscription, though usually a small slice of what it saves you. And you are handing an IAM role to a third party, which is a trust decision you have to be comfortable making.

Choosing the Right Approach

There is no wrong answer here, and I mean that. It comes down to who is on your team, how much AWS infrastructure you enjoy maintaining, and where you would rather spend the hours.

If you are a solo developer who is comfortable in CloudFormation, the AWS Instance Scheduler hands you a proven setup without writing the logic from scratch. If you have DevOps capacity and want it built to your exact spec, the DIY Lambda + EventBridge route is yours. If you just want the bill to drop this week and never think about it again, a managed tool like ParkMyAWS gets you there in minutes.

All three land in the same place: your non-production instances stop running when nobody is using them. Pick the one whose tradeoffs you can live with.

Getting Started

Start with your most expensive non-production resources and ignore everything else for now. You do not have to schedule the whole account on day one. Park a handful of big instances and you are already saving real money.

Practically: find your dev and staging environments, look up their instance types and costs in Cost Explorer, and set a schedule around your team's hours. Most teams begin with weekdays 8 AM to 6 PM local time and tune it once they see what breaks (usually nothing).

The hard part is just starting. Every hour an idle instance keeps running is money you handed AWS for nothing.