# EC2 Heatmap-Based Schedule Opportunity

> Suggests start/stop schedules for non-production EC2 instances from a 21-day usage heatmap, priced on measured running hours.

Source: https://zop.dev/integrations/aws/recommendations/ec2-heatmap-based-schedule-opportunity

---

## A stopped instance stops the compute bill

Amazon Linux, Windows, RHEL and Ubuntu instances bill by the second while they run, with a 60-second minimum, per
[EC2 pricing](https://aws.amazon.com/ec2/pricing/). Once an instance is stopped,
[AWS does not charge](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/how-ec2-instance-stop-start-works.html)
for its usage or data transfer; its EBS volumes and any Elastic IP addresses keep billing. A development server that nobody
uses from 8 p.m. to 8 a.m. and all weekend is idle for most of the week's 168 hours.

## Seeing the weekly pattern yourself

Pull three weeks of hourly traffic and look for hours that are quiet every week:

```bash
aws cloudwatch get-metric-statistics --namespace AWS/EC2 --metric-name NetworkIn \
  --dimensions Name=InstanceId,Value=i-0123456789abcdef0 \
  --start-time 2026-09-04T00:00:00Z --end-time 2026-09-25T00:00:00Z \
  --period 3600 --statistics Average
```

## How the heatmap is built and trusted

ZopNight scores each hour of each weekday as active or idle. An hour counts as idle when traffic is
low compared with the instance's own busy level, which tolerates health checks and agent chatter.
Hours with no data at all, when the instance was already stopped, are treated as off and are never
counted as savings. The evidence must pass five checks inside the latest 21 days:

1. The newest data point is no more than 3 days old.
2. The oldest reaches back at least 18 days.
3. At least 7 distinct days have data.
4. There are at least 24 data points.
5. No gap inside the window is longer than 3 consecutive days, so weekends and a long holiday break pass
   but a broken data feed does not.

## Instances the rule protects

The instance must be running, and anything named or tagged as production is skipped. Names that
suggest a disaster-recovery, backup, standby, failover or replica role are skipped, as are
self-managed stateful workloads such as databases, Kafka, Elasticsearch or Redis. Instances covered
by a Reserved Instance or Savings Plan are skipped because a stop does not reduce committed spend.
An instance idle 95% or more of the week is routed to the idle-instance rules instead.

When the heatmap is solid but ZopNight cannot verify the instance's running hours, or the instance
already runs within the suggested window, it shows the schedule as a no-dollar advisory, so you can
still adopt it.

## Hours the schedule actually removes

```text
saving = effective hourly rate x running hours outside the suggested window
capped at the monthly instance cost
```

For billing-connected accounts, the hourly rate is the last 30 days of billed cost divided by
measured running hours, so discounts are included. The start of the window keeps a buffer hour,
which is never counted.

## Applying a schedule

1. Check the suggested start and stop times and time zone against the team's working hours.
2. Apply the schedule from the recommendation; ZopNight then stops and starts the instance.
3. Revisit after two weeks and confirm nobody needed the instance during the off window.