Switch off dev and staging at night: how to schedule it with AAA Sentinel and what you really save

At eight in the evening the team closes their laptops. The development and staging machines do not: they keep running all night and all weekend, billing every hour while nobody uses them. It is one of the easiest leaks to close because it needs no change to your architecture, only stopping and starting at the right time. In this article we show how to do it with AAA Sentinel: where to find the candidates, how to size the saving without inflating it, and how to leave the shutdown scheduled.

The problem: machines that work 60 hours and bill 168

A week has 168 hours. A team working Monday to Friday from 08:00 to 20:00 uses its environments for 60 of them. The other 108, 64% of the week, are nights and weekends in which those machines only produce a bill:

• On AWS, a stopped EC2 instance pays no compute. On Azure, neither does a deallocated VM. On Google Cloud, a stopped instance stops paying for CPU and memory.
• What keeps being charged is disks and some IP addresses, as you will see below. That is why the real saving is lower than 64% of the environment's total bill.
• Nobody stops machines by hand every day. It works for a week and then it is forgotten: the shutdown has to be scheduled.

What you get

Scheduling the shutdown of non-production environments pays off beyond the figure itself:

• A recurring saving that does not depend on someone remembering.
• No change to code or architecture: the machines stay the same, only their running hours change.
• A clear list of what is development and what is production, because you have to decide it to schedule anything.
• A record of every stop and every start, with its result, so you know the plan is being followed.

Before you start: what you pay even when the machine is off

So as not to promise more than you will see on the bill, keep these points in mind:

• EBS volumes (and managed disks on Azure or Google Cloud) are still charged while the instance is stopped.
• AWS charges every public IPv4 address by the hour, including an Elastic IP attached to a stopped instance.
• If the instance is covered by a Reserved Instance or a Savings Plan, stopping it saves nothing: the commitment is paid anyway.
• Stopping an instance wipes its instance store, and the public IP changes on the next start unless it is an Elastic IP.
• If the instance belongs to an Auto Scaling group, the group may mark it unhealthy and replace it. These instances are not good candidates.

How AAA Sentinel solves it: three pieces

The full flow uses three screens, each in its own plan:

• Active findings, on every plan: the scan detects instances with very low CPU and instances that are already stopped while their disks keep billing. That is your list of candidates.
• Savings simulator, on the Pro plan: before touching anything, you work out how much switching dev and staging off at night would save.
• AI Agent → Automations, on the Business plan: you create the stop and start schedule, and the platform runs it every day and records it in the history.

Worked example: ACME's environments

ACME is a fictional company with a development team in Madrid. It has six development machines and two staging machines on AWS, in us-east-1, running day and night. Prices are approximate on-demand Linux list prices:

Step 1: find candidates in Active findings

After the account's first scan, open Active findings. Three rules help you spot environments that are not needed at night:

• "Underused CPU": average CPU below 5% over the last 7 days. A development machine that only works a few hours a day often shows up here.
• "Stopped instances with volumes": someone already stopped it by hand, but its disks keep billing. Decide whether you will use it again (then schedule it) or whether it is surplus (then terminate it, after taking a snapshot if you want to keep the data).
• "Untagged resources": the resource has fewer than two of these tags: Environment, Project, Owner, CostCenter or Team. Tagging Environment=dev or Environment=staging is what later lets you separate what can be switched off from what cannot.

Step 2: size the saving in the Simulator

In Savings overview → Savings simulator, pick the account and enable the "Shut down Dev/Staging at night" scenario. It has two fields:

• "Dev EC2 cost (USD/mo)": it comes pre-filled with 40% of the account's total cost, which is only a starting point. Replace it with the real cost of your development and staging machines; ACME enters 645.
• "Off hours/day": the hours they would be off each working day. From 20:00 to 08:00 is 12.

The full numbers, weekends included

With a schedule that stops at 20:00 and starts at 08:00 from Monday to Friday, the machines stop on Friday night and do not start again until Monday morning. These are ACME's numbers:

• The saving comes from compute; disks cost the same. That is why 64% of hours off becomes 58% of the environment's bill.
• If any of those machines were covered by a Reserved Instance or a Savings Plan, it would have to be taken out of the calculation.

Step 3: prepare the account so the agent can act

The role you connected the account with is read-only and cannot stop anything. Automations need two more things:

• On AWS, the agent role. It is installed in the last step of the connection wizard, "Enable autonomous agent (optional)", with the "Install agent role in AWS" button: a second CloudFormation stack that creates the FinOpsSentinelAgent role. If you skipped it, you can install it later from My cloud accounts.
• On AWS, the tag FinOpsSentinelManaged=true on every instance you want to schedule. The agent role can only start and stop instances carrying that tag, and it cannot tag itself: you do it.
• On Azure and Google Cloud, the write permissions from the same wizard step. On Azure the VM is deallocated, not just stopped, so it stops paying for compute; on Google Cloud the instance is stopped.

Step 4: create the automation

In AI Agent → Automations, click "New schedule". This is how ACME fills it in:

• The days apply to both stop and start. With Monday to Friday, Friday's stop has no start until Monday: the weekend is covered with nothing else to do.
• "Estimated savings ($/mo)" is the figure you declare, from the previous step. The platform shows it on the card and adds it to the total for active automations; it is not a measurement.
• Creating, pausing or deleting an automation requires write permission on the agent, which the owner and admin roles have.

Step 5: check that it runs

Once created, the automation shows as "Active" with its schedule, timezone, number of instances and declared saving. From then on:

• The card shows when it last ran and how many runs it has.
• Every stop and every start is recorded in AI Agent → History, as completed or failed, with the error if there was one (for example, an instance without the tag).
• The "Pause" switch stops the automation without deleting it. Note that pausing does not start the machines; if someone needs the environment that night, start it by hand.
• Deleting the automation removes its two scheduled rules. The machines stay in whatever state they were in.

What it does not do yet

So you know what to expect:

• It only starts and stops instances: EC2 on AWS, virtual machines on Azure and Compute Engine instances on Google Cloud. It does not schedule RDS databases, Auto Scaling groups or Kubernetes nodes.
• There is no holiday calendar: the schedule is defined by days of the week.
• Each automation accepts up to 50 instances, and an organization can have up to 200 automations.
• The form offers five timezones: Europe/Madrid, three US time zones and UTC.
• The saving on the card is the one you declare, not one measured on the bill.
• If the subscription expires, automations stop running.

Checklist to get started

With this in place, your development environments will stop paying for nights and weekends without anyone having to remember:

• Account connected and scanned; candidates reviewed in Active findings.
• Environments tagged Environment=dev or Environment=staging.
• Saving sized in the Savings simulator and completed by hand with the weekends.
• Checked that no candidate is covered by a reservation or sits inside an Auto Scaling group.
• Business plan, agent role installed and FinOpsSentinelManaged=true on every instance.
• Automation created and its first run verified in the History.