Weekend and overnight shutdown: how much it actually saves

Quick answer

A 7am to 8pm weekday schedule runs 65 of 168 hours, so compute cost drops to about 39 percent, a 61 percent saving. A 9am to 6pm weekday schedule runs 45 hours, about 27 percent of the week, a 73 percent saving. Weekend only shutdown runs 120 hours, a 29 percent saving, and is the least disruptive starting point. Critically, only compute stops: attached block storage, snapshots, load balancers, NAT gateways, static IPs, and managed database storage all keep billing, so expect the realised saving on the total environment cost to be roughly half the compute percentage unless you also remove those.

Turning things off is the cost lever with the best ratio of saving to risk, and the one most often implemented badly. The arithmetic is simple, but the realised saving is usually smaller than the projection because people forget which resources keep billing while an instance is stopped.

The arithmetic

Schedule	Hours per week	Percent of week	Compute saving
Always on	168	100%	0%
Weekends off only	120	71%	29%
7am to 8pm weekdays	65	39%	61%
9am to 6pm weekdays	45	27%	73%
9am to 6pm, one timezone, holidays off	~42	25%	75%

On $50,000 a month of non-production compute, a 7am to 8pm weekday schedule returns about $30,500 a month and a 9am to 6pm schedule about $36,500. Those are large enough that the implementation detail is worth getting right rather than approximating.

What keeps billing while the instance is off

This is where projections and invoices diverge. On AWS, a stopped EC2 instance still bills its EBS volumes at $0.08 per GB-month for gp3, its snapshots at $0.05 per GB-month, and any Elastic IP at $0.005 per hour. The ALB in front of it keeps its $0.0225 per hour base charge, roughly $16.43 a month. A NAT gateway keeps its $0.045 per hour, roughly $32.85 a month, even with zero traffic. On Azure, a VM must be deallocated, not merely stopped, or compute keeps billing, and managed disks bill either way. On GCP, persistent disks and reserved static external IPs at about $0.010 per hour keep billing while the instance is stopped.

For a typical dev stack where compute is 60 percent of the environment cost and storage plus networking is 40 percent, a 61 percent compute saving is only about a 37 percent saving on the environment. To get closer to the headline number you also have to delete the load balancer and NAT gateway for environments that are off, or destroy the environment entirely rather than stopping it.

Implementation in order of effort

Start with native schedulers. Azure has per VM auto-shutdown built in and DevTest Labs schedules. GCP has instance schedules you attach directly to Compute Engine instances. AWS has the Instance Scheduler solution, or a scheduled Lambda that filters on a tag. Whichever you use, drive it from a tag such as schedule equals office-hours so the policy lives with the resource rather than in a separate list that drifts.

For autoscaling groups and Kubernetes node pools, set scheduled scaling actions rather than stopping instances: scale minimum and desired to zero at 8pm and back at 7am. On Kubernetes this is cleaner than stopping nodes because the scheduler handles pod eviction, and it composes with the cluster autoscaler behaviour described in autoscaling cost versus performance.

Managed databases are the most awkward part. RDS instances can be stopped for at most 7 days before AWS restarts them automatically, so schedules need a weekly restart cycle or you use Aurora Serverless, which scales capacity down on idle instead. Azure SQL serverless auto pauses. Cloud SQL instances can be stopped but keep billing storage.

The friction problem and its fix

Every shutdown program dies the same way: an engineer needs the environment at 9pm, cannot start it, files a ticket, and the exemption list grows until nothing is scheduled. Prevent this with a self service override. A Slack command or a pipeline job that starts the environment and sets a 4 hour extension solves 95 percent of cases. Log the overrides: if one environment is woken every night, it should not be on a schedule, and if nobody wakes an environment for a month, it should be deleted rather than scheduled.

Where not to apply it

Production, obviously. CI runners, where a queued build at 2am is worth far more than the compute. Anything a nightly batch, backup, or data pipeline depends on, which is the most common cause of a shutdown program breaking something. Cross timezone teams, where 7am to 8pm in one region is the middle of the night in another, so scope schedules per environment and per team rather than globally. And anything with a slow cold start, such as a large cache that takes 40 minutes to warm, where the wake cost exceeds the saving.

Rolling it out

Week one, apply weekend only shutdown to all non-production and measure. It is the least disruptive schedule and returns 29 percent on its own. Week three, extend to overnight on environments with no complaints. Week five, review the override log and either delete the never used environments or remove the schedule from the always used ones. Then stop the regrowth by making the schedule tag a required field on new environments and pricing the Terraform that creates them against the resource catalog before merge.

FAQ

How much does shutting down instances at night and weekends save?

A 7am to 8pm weekday schedule runs 65 of the week's 168 hours, about 39 percent, so compute drops by roughly 61 percent. A 9am to 6pm weekday schedule runs 45 hours, about 27 percent, a 73 percent saving. Weekend only shutdown runs 120 hours for a 29 percent saving and is the least disruptive starting point for a rollout.

What keeps billing when an instance is stopped?

Storage and networking. On AWS a stopped EC2 instance still bills EBS volumes at $0.08 per GB-month for gp3, snapshots at $0.05 per GB-month, and Elastic IPs at $0.005 per hour, while the ALB keeps its roughly $16.43 a month base charge and a NAT gateway keeps its roughly $32.85 a month with zero traffic. On Azure a VM must be deallocated, not just stopped, or compute keeps billing.

Why is my realised shutdown saving lower than projected?

Because only compute stops. In a typical dev stack where compute is 60 percent of the environment cost and storage plus networking is 40 percent, a 61 percent compute saving is only about 37 percent of the environment. To approach the headline number you also have to delete the load balancer and NAT gateway for off environments, or destroy the environment entirely rather than stopping it.

Can I stop managed databases on a schedule?

Partly. RDS instances can be stopped for at most 7 days before AWS restarts them automatically, so a schedule needs a weekly restart cycle. Aurora Serverless scales capacity down on idle instead, and Azure SQL serverless auto pauses, which are both cleaner fits. Cloud SQL instances can be stopped but keep billing their storage, so the saving is compute only.

How do I stop a shutdown program from being abandoned?

Give engineers a self service override. A Slack command or pipeline job that starts an environment and grants a 4 hour extension solves almost every case where someone needs access outside hours. Log the overrides: an environment woken every night should not be on a schedule, and one nobody has woken in a month should be deleted rather than scheduled.

Which workloads should never be scheduled off?

Production, CI runners where a queued build at 2am costs more than the compute, anything a nightly batch or backup pipeline depends on (the most common cause of a shutdown breaking something), environments shared across timezones where business hours differ, and workloads with slow cold starts such as a large cache that takes 40 minutes to warm, where the wake cost exceeds the saving.

What to do next

Make the schedule a required field. C3X prices new environments from Terraform against a live resource catalog. Start with the quickstart.