Find and Cut Dev Environment Spend Using Cost Tags
You cannot reduce what you cannot isolate. Tag the dev estate, query it by service, then decide line by line.
“Reduce dev costs” usually starts with scheduling, but a schedule only helps resources that can be stopped and that bill by the hour. The first job is to see what dev actually spends money on, split by service, so each line gets the right lever. This guide does that on AWS with a cost allocation tag and the Cost Explorer CLI.
1. Make sure dev resources carry one tag key
Pick a single key, for example env, with dev as the value, and apply it everywhere dev resources are created (Terraform defaults, launch templates, CloudFormation stack tags). Mixed keys such as Env, environment and stage split the same estate into several buckets, because Cost Explorer groups by the exact key.
2. Activate the tag for billing
A resource tag does not appear in billing data until you activate it as a user-defined cost allocation tag. In the console: Billing and Cost Management, then Cost allocation tags, select the key, then Activate. The same activation from the CLI:
aws ce update-cost-allocation-tags-status \ --cost-allocation-tags-status TagKey=env,Status=ActiveAWS notes it can take up to 24 hours for a new tag key to appear on the page and up to another 24 hours to activate.
3. Query dev spend by service
aws ce get-cost-and-usage \ --time-period Start=2026-08-01,End=2026-09-01 \ --granularity MONTHLY \ --metrics UnblendedCost \ --filter '{"Tags":{"Key":"env","Values":["dev"]}}' \ --group-by Type=DIMENSION,Key=SERVICE \ --query "ResultsByTime[].Groups[].[Keys[0],Metrics.UnblendedCost.Amount]" \ --output text | sort -k2 -rnThe end date is exclusive, so this is all of August. Run it again grouped by Type=TAG,Key=env with no filter to see how much spend has no env value at all; that untagged share is the size of your blind spot.
4. Choose a lever per service line
Work down the sorted list and match each line to what the service actually allows:
| Line | Lever | What still bills |
|---|---|---|
| EC2 instances | Stop outside working hours | Attached EBS volumes and Elastic IPs |
| RDS instances | Stop, but AWS restarts a stopped instance after seven consecutive days | Provisioned storage, backups, public IPv4 |
EBS volumes in available state | Snapshot if needed, then delete | Snapshot storage |
| Oversized instances | Change instance type while stopped | Nothing extra |
Anything that has no stop operation belongs in the delete or resize rows, not in a schedule. Two RDS limits matter for dev databases: you cannot stop an instance that has a read replica or that is one, and the seven-day auto-start means a week-long shutdown needs a repeat stop.
5. Act on the top lines and re-run the query
Find unattached volumes, which bill in full and serve no instance:
aws ec2 describe-volumes --filters Name=status,Values=available \ --query "Volumes[].[VolumeId,Size,CreateTime]" --output tableFor the instance lines, set up a stop and start schedule (see automating EC2 stop and start) and check candidates for rightsizing. Then re-run the step 3 query for the following month and compare the same service lines, rather than the total, so a new project does not hide the change.
Doing this continuously
ZopNight reads billing data from AWS Cost Explorer, Azure Cost Management and the GCP BigQuery export and can attribute cost by cloud tags, GCP labels and Azure tags in its Tags report, which gives the same per-environment view without re-running queries. Its recommendations cover idle, orphaned and rightsizing findings alongside schedule suggestions, and schedules can be attached to EC2, RDS and the other supported types once the account is connected with read + write access. For the scheduling side of dev environments, see non-production environments and the RDS scheduling page.