Tools to Shut Down Non-Production Cloud After Hours, 2026

How we picked and checked these

We looked only at tools that stop resources on a timetable or on idleness. A tool that only reports idle spend is left out. For each one we read the vendor’s or cloud provider’s own documentation on 25 September 2026 and recorded four things: which resources it can stop, what triggers the stop, how a one-off exception works, and what it costs to run. Where a vendor page did not say, the table says “not stated” rather than guessing.

The list is grouped by type: native tools first, by cloud, then vendors in alphabetical order. ZopNight, which publishes this page, sits in that alphabetical order. The order is not a ranking.

At a glance

Native tools

Instance Scheduler on AWS

An AWS Solution you deploy from CloudFormation. It “leverages Amazon Web Services (AWS) resource tags and AWS Lambda” to stop and start instances across Regions and accounts (overview). RDS, Aurora, Neptune and DocumentDB “all count as one ‘RDS’ service” for its cost model (cost). AWS estimates the running cost at USD 13.15 a month in US East (N. Virginia). Full detail: Instance Scheduler on AWS compared.

• Good fit if you are AWS-only, comfortable with CloudFormation and tags, and your windows are simple weekday hours.
• Not a fit if you also run Azure or GCP, or you need EKS, ECS or Kubernetes namespaces on the same schedule.

AWS Systems Manager Resource Scheduler

A Quick Setup configuration that starts and stops tagged EC2 instances. AWS says “there is no cost to use Quick Setup”, and one configuration handles “up to 5,000 instances per Region” (user guide). If someone starts an instance by hand after its stop time, “Resource Scheduler will not stop the instance again”. See Resource Scheduler compared.

• Good fit if all you need is tagged EC2 off at night, with nothing to deploy.
• Not a fit if RDS or container services sit behind those instances; the guide covers EC2 only.

DIY: EventBridge Scheduler plus Lambda

A cron rule and a small function. Scheduler includes 14 million free invocations a month (pricing). A standard Lambda can run for at most 900 seconds (timeout), so a loop over a large fleet has to fit or fan out. Stopped RDS instances come back by themselves: after “seven consecutive days, RDS automatically starts your DB instance” (RDS docs), and your code has to notice. See what a DIY build has to handle.

• Good fit if you have one or two accounts, one time zone, and an engineer who will own the code.
• Not a fit if nobody wants to own retries, cross-account roles and a history of who stopped what.

Azure VM auto-shutdown

A per-VM setting in the portal. Microsoft notes that “Coordinated Universal Time (UTC) is the default setting for the time zone” (Microsoft Learn). In the portal you “set the time you want the virtual machine to shut down”; the documented portal steps set no start time. See auto-shutdown compared.

• Good fit if you have a few dev VMs that only need switching off.
• Not a fit if you need a scheduled morning start or anything beyond single VMs.

Azure Start/Stop VMs v2

Deployed into your subscription on Azure Functions and Logic Apps. It “starts or stops Azure Virtual Machines instances across multiple subscriptions”, and it can sequence VMs with sequencestart and sequencestop tags (overview). It is in maintenance mode: “No further development, enhancements, or updates will be available for Start/Stop v2 except when required to remain on supported versions”. See what running v2 involves.

• Good fit if your targets are Azure VMs and you are happy to maintain a Functions app.
• Not a fit if you want AKS or flexible database servers on the same schedule, or a product still gaining features.

Compute Engine instance schedules

A resource policy you attach to VMs. Google’s limits are specific (docs): VMs must be “in the same region as the instance schedule”, one schedule covers “up to 1,000 VM instances”, operations “might take up to 15 minutes past the scheduled time”, and you “can’t use instance schedules to stop an instance that has Local SSD disks”. See GCP instance schedules compared.

• Good fit if you have Compute Engine VMs in one region on a fixed weekday window.
• Not a fit if Cloud SQL or GKE are part of the environment, or VMs span regions.

Vendor tools

CAST AI

CAST AI’s cluster hibernation scales “your cluster to zero nodes while preserving the control plane and cluster state”, with schedules that carry a time zone (docs). Pricing is by quote (pricing). See CAST AI compared.

• Good fit if your non-production spend is mostly whole Kubernetes clusters that can sleep together.
• Not a fit if the waste is in VMs and databases outside Kubernetes, or you need one team’s namespace off while the cluster stays up.

Cloud Toggle

A focused VM scheduler. Its homepage shows Microsoft Azure and Amazon Web Services logos under “works with” and publishes three plans: $49 a month (15 servers, with a 30-day free trial), $99 (50 servers) and $249 (200 servers) (cloudtoggle.com). See Cloud Toggle compared.

• Good fit if you want a known monthly price and to let non-engineers press start or stop without console access.
• Not a fit if you run GCP, which we did not find on its site, or you need databases and clusters scheduled.

Harness AutoStopping

Harness stops resources when they go idle, not on a clock. Rules take an “idle-time threshold” and “optional fixed schedules”, and users reach stopped resources through a load balancer, proxy or direct IP (AutoStopping docs). The supported list covers EC2, Auto Scaling groups, EKS, ECS services and RDS on AWS; on-demand VMs and AKS on Azure; GCE VMs, GKE and instance groups on GCP. See Harness compared.

• Good fit if usage is irregular and you want resources to wake when someone uses them.
• Not a fit if you would rather not route access through Harness’s proxy or load balancer to wake things.

nOps Scheduler

nOps recommends resources to schedule and “will automatically turn on/off instances via our integration with AWS EventBridge” (nOps). Its main product is commitment management across AWS, Azure and GCP. See nOps compared.

• Good fit if you want commitment purchasing handled and EC2 scheduling in the same tool.
• Not a fit if your off-hours waste is mostly on Azure or GCP; the scheduler page we read describes AWS EventBridge only.

Spot Ocean Shutdown Hours

For clusters managed by Ocean, outside the running hours you set “the underlying instances of the cluster’s nodes are scaled down to zero”, and Spot recommends it for non-production (docs). Elastigroup adds cron-based scheduling. Spot is now part of Flexera. See Spot compared.

• Good fit if you already run Ocean for spot capacity and want its clusters off at night.
• Not a fit if the resources you want stopped are not Ocean clusters or Elastigroups.

ZopNight

ZopNight is a cost platform (visibility, recommendations, showback, remediation) with a scheduler inside it. A schedule is one or more cron expressions in an IANA timezone, previewed on a weekly grid, and attached to single resources or to resource groups. It can stop EC2, RDS, EKS, ECS services, Auto Scaling groups, Compute Engine, Cloud SQL, GKE, Azure VMs (deallocated, not just stopped), AKS, Azure MySQL and PostgreSQL flexible servers, Databricks and single Kubernetes namespaces. Groups start in tiers (storage, then databases, then compute, then apps) and stop in reverse, with per-resource delays. An override keeps something on for a set window with a reason and then expires, and every state change records whether a schedule, a user or an override caused it. Start with EC2 scheduling or namespace scheduling.

• Good fit if one environment spans several resource types or clouds and you want one schedule model and one audit trail for all of it.
• Not a fit if you want wake-on-access, or you only need a handful of tagged EC2 instances off at night.

When not to pick ZopNight

• You only need tagged EC2 off overnight. SSM Resource Scheduler does that at no Quick Setup charge.
• You want resources to wake when someone connects. ZopNight’s schedules are clock-driven; Harness AutoStopping is built for idle detection and restart on access.
• You will not grant write access. A read-only ZopNight connection gives discovery and recommendations and lets you attach schedules, but ZopNight will not start or stop anything until the account is read and write.
• Your clusters are OpenShift on ROSA. ZopNight discovers ROSA clusters and machine pools but does not start or stop them.

One caution applies with every tool here: stopping an EC2 instance discards instance-store data, which “does not persist if the instance is stopped, hibernated, or terminated” (EC2 docs). EBS volumes persist.