Stop Paying for Idle Dev Environments: Office-Hours Schedules for EC2 and RDS

A week has 168 hours. A development team works roughly 08:00 to 19:00, Monday to Friday: 55 hours. Every development, test and staging instance that runs around the clock is idle for the other 113 hours — 67% of the time you pay for it.

On-demand Linux instances and RDS databases bill by the second. Turn them off when nobody is using them and the bill follows.

Resource (us-east-1, on-demand)	Always on / month	Office hours only / month	Saved
EC2 m5.large	$70	$23	$47
EC2 m5.2xlarge	$280	$92	$188
RDS db.m5.large (single-AZ)	$125	$41	$84
A 20-instance dev environment of m5.large	$1,400	$460	$940

EBS volumes, snapshots and RDS storage are still billed while stopped, so the real saving is a little lower. It is still one of the largest and safest cost reductions a team can make in a day.

Opt in with a tag

The schedule should be something a team chooses for a resource, not something applied to an account and discovered on Monday morning. Use a tag:

Schedule = office-hours

Then two scheduled tasks do the work:

• At 19:00, Monday to Friday: stop running instances tagged Schedule=office-hours.
• At 08:00, Monday to Friday: start stopped instances tagged Schedule=office-hours.

A team that needs its environment tonight removes the tag, or changes it to Schedule=always-on. Nobody asks permission and nobody forgets to turn it back on: the tag is the state.

More schedules are just more tag values: Schedule=weekdays-extended for 07:00–22:00, Schedule=nightly-off for stop-only (people start it when they need it).

Five traps

1. Auto Scaling groups start what you stop

An instance in an Auto Scaling group that you stop is marked unhealthy and replaced. You pay for a new instance and the schedule achieves nothing. Exclude them: every ASG instance carries the tag aws:autoscaling:groupName, so make that an exemption. To schedule an ASG, scale its desired capacity instead.

2. RDS starts itself after seven days

A stopped RDS instance or Aurora cluster is started automatically by AWS after seven days, to apply maintenance. A stop-only schedule that runs once is therefore not enough. A daily stop task catches it again on the next evening.

3. Time zones and daylight saving

"19:00" means nothing without a time zone, and a fixed UTC offset drifts by an hour twice a year in most of Europe and North America. Either pick the offset deliberately and adjust it at the change, or schedule with a margin (18:30 stop, 08:30 start) so the drift never lands inside working hours.

4. Instance store and ephemeral data

Stopping an instance erases instance-store volumes and releases a public IPv4 address that is not an Elastic IP. Most development instances use only EBS, but check before tagging a machine that caches data on local NVMe or that someone reaches by its public address.

5. Stopping is not enough if nothing is watching

A schedule that fails silently — expired credentials, a changed role — goes unnoticed until the bill arrives. Every run should record what it stopped and started, and say clearly when it could not read the current state instead of acting on old data.

Start small

1. Pick one non-production account. Tag its instances Schedule=office-hours with the teams that own them.
2. Run the stop task as a dry run for a few days and read what it would have stopped.
3. Switch it to act, and add the start task.
4. Look at the next month's bill for that account. Expand to the next one.

How AWS Cloud Governance helps

AWS Cloud Governance ships these as scheduled task presets: Stop dev instances at night, Start them again in the morning and Stop dev databases overnight, all keyed on the same Schedule=office-hours tag.

• Tag-based opt-in and exemption tags — add aws:autoscaling:groupName to skip Auto Scaling instances.
• Daily times on chosen weekdays in your UTC offset, or every N minutes or hours.
• Fresh inventory before each run: the task reads the current state of your instances, across every onboarded account and region, before it stops or starts anything.
• Dry run, approval or automatic, with each stop recorded on the Actions page and reversible in one click.
• The EC2 Running Outside Schedule detection reports which instances are up outside working hours in the first place, so you know where a schedule pays off.

See pricing or start a free 3-month trial at https://trustpartners.tech.