If you want the other side of this, where we actually fixed things and watched the invoice drop, read the realized case study. This post is the opposite end: not "here is what we saved," but "here is everything one scan finds before you touch anything."

The account​

A normal setup. EC2 for pipelines and services, Aurora and RDS, ElastiCache, a pile of Lambda functions, an EKS cluster, and the usual sediment of resources nobody has looked at in a year. One region, us-east-1. We ran the full rule set once, read-only, and looked at what came back.

First, the honest part​

That $2,681/month is a gross, identified number, not a realizable one. Two reasons it is not a shopping total you get to add up:

1. The big line items overlap. A single idle EC2 instance can show up three ways: buy a Savings Plan, cover it with a Reserved Instance, or right-size it. Those are not additive. You pick one. A cost tool will happily count all three.
2. Some findings are hygiene, not dollars. Seven unused security groups and four idle Step Functions saved $0.00 each. They are worth cleaning up, but they do not move the bill.

So read the ranking below as a map of where the account is soft, not a check you can cash. With that said, the map is the useful part.

The ranking (real numbers)​

Two patterns fall out of this​

The money is in commitment and right-sizing, and it overlaps. The top six lines, Spot, Savings Plans, idle EC2, ElastiCache, RI coverage, and RDS, are about $2,500/month between them. They are also the most entangled. The same handful of steady EC2 instances drives the Spot, Savings Plan, RI, and right-size numbers at once. The real, non-double-counted win here is smaller than the sum, and it starts with one decision: are these workloads staying? If yes, commit (Savings Plan). If they are bursty and fault-tolerant, Spot. If they are oversized, shrink them first, then commit to the smaller footprint. Do not buy a three-year commitment on an instance you are about to halve.

The volume is in hygiene, and it is nobody's job. Look at the counts, not the dollars: 80 unattached EBS volumes, 50 log groups with no retention cap, 45 old snapshots, 37 Route 53 zones holding nothing but default records, 36 VPC endpoints with no traffic. That is 248 findings for a few hundred dollars. Individually trivial, collectively a mess, and it accumulates because no single person owns "delete the thing we stopped using." A scan is how you find it, because you are never going to click through 1,358 resources by hand.

The modernization layer​

Three findings are not really about this month's bill, they are about not overpaying structurally:

• 15 instances on x86 with a Graviton equivalent ($229/mo here). Graviton is the lowest-effort price-performance lever AWS offers, roughly 20% cheaper for a family swap, and the current target is Graviton4 (m8g, c8g, r8g). More on this in the Graviton series.
• 17 previous-generation instances ($172/mo). m5, c5, r5 and older, quietly costing more than current-gen for the same work.
• 7 gp2 volumes that should be gp3 ($2/mo here, but it is a free 20% on storage and a zero-downtime change, so there is no reason not to).

Small numbers in this one account, but they are one-time migrations that keep paying, and they scale with fleet size.

One honest miss, because it is a good lesson​

The scan flagged 7 x86 Lambda functions that could move to arm64 for about 20% off, and reported $0.00 in savings for all of them. Not a bug. This account had no per-function cost data available to the scan, so the rule correctly emitted the recommendation with no dollar figure rather than inventing one. arm64 Lambda is still worth doing, a one-line architecture change, but it is a good reminder: a savings estimate is only as good as the cost data behind it, and a tool that makes up numbers when it has none is not doing you a favor.

What we would actually do first​

Not all 403. Three moves, in order:

1. Delete the orphans. Unattached volumes, unattached EIPs, empty Route 53 zones, dead VPC endpoints. Low risk, no downside, and it clears the noise so the real signal is easier to see.
2. Right-size, then commit. Shrink the oversized EC2, RDS, and ElastiCache first. Then put a Compute Savings Plan over the steady baseline that remains.
3. Take the free modernizations. gp2 to gp3, and the Graviton family swaps on anything that is already ARM-compatible.

Run it on your own account​

Every number above came from one read-only scan. You can run the same 89 checks against your account with Cloud Cost Analyzer. The free tier gives you the executive summary and finding counts, no credit card, and your credentials never leave your environment. If the surface area looks anything like this account, the ranking alone will tell you where to point your next afternoon.

This is the anchor post for a short Graviton series. The per-service guides (Lambda, Fargate, RDS and ElastiCache) build on this one.

What changed: Graviton4 is the default now​

Graviton is AWS's own ARM64 processor, and the ARM families are priced below their x86 counterparts for the same vCPU and memory. That part has not changed. What changed is the generation you should be targeting. Graviton4 shipped across the general families in 2024, so the 2026 map is:

Two notes on that table:

• m8g / c8g / r8g are Graviton4. If a specific size or region does not have the 8th-gen family yet, m7g / c7g / r7g (Graviton3) is the fallback, and still a clear win over x86.
• Burstable stays on t4g. AWS has not shipped a Graviton4 T family, so t4g (Graviton2) remains the ARM target for t2 / t3 / t3a.

Graviton also backs the managed services: RDS and Aurora (db.m8g, db.r8g), ElastiCache, and OpenSearch all offer Graviton classes at the same kind of discount. Those get their own post in this series.

Step 1: find x86 instances that could move​

aws ec2 describe-instances \
  --filters Name=instance-state-name,Values=running \
  --query 'Reservations[].Instances[].{ID:InstanceId,Type:InstanceType,Arch:Architecture}' \
  --output table

Anything with Architecture: x86_64 on an m, c, r, or t family is a candidate. When we ran our full scan across one real account, 15 running instances had a Graviton equivalent sitting right there.

Step 2: migrate safely​

The instance change itself is trivial (stop, modify type to the Graviton target, start):

aws ec2 stop-instances --instance-ids i-0abc123
aws ec2 modify-instance-attribute --instance-id i-0abc123 --instance-type m8g.large
aws ec2 start-instances --instance-ids i-0abc123

The real work is making sure your software runs on ARM64. In practice:

• Interpreted and JIT languages (Node, Python, Ruby, Go, Java, .NET) run on ARM with no code change. Just make sure native dependencies have ARM builds.
• Containers: build multi-arch images (docker buildx --platform linux/amd64,linux/arm64) and your ECS or EKS tasks run on Graviton unchanged.
• AMIs: use an ARM64 AMI for the new instances.

The caveat: test before you cut over​

The one thing that bites: a dependency with x86-only native code (an old binary, a proprietary agent, a compiled extension without an ARM build). Migrate a non-production instance first, run your test suite, and check any third-party agents (monitoring, security) support ARM. Once green, roll it out. The savings are permanent and require no ongoing work.

Do it automatically​

Cloud Cost Analyzer's graviton-migration-opportunities rule flags x86 instances with a Graviton target and estimates the savings (it only surfaces moves worth at least ~20%), alongside 89 other cost rules:

curl -sSL https://releases.dragonfractal.com/install.sh | sh
cca scan --provider aws

The agent runs in your environment with read-only access, so your AWS credentials never leave it. See the AWS setup and required IAM permissions

Next in the series​

• Move your x86 Lambdas to arm64 in one line
• Fargate on Graviton: ~20% off containers
• RDS and ElastiCache on Graviton
• The full Graviton migration playbook

How to approach it​

AWS Cost Explorer tells you what you spent. It does not walk your account and hand you a list of things to delete. So the loop that actually lowers the bill is:

1. Find the idle, orphaned, and over-provisioned resources across every service.
2. Rank them by monthly savings, not by how interesting they are to fix.
3. Fix the top of the list first - the boring $32/month items add up faster than one heroic re-architecture.
4. Prevent regressions by re-scanning on a schedule or in CI, so the same waste does not silently rebuild next quarter.

The checklist below is grouped by service area. Every item is a real, repeatable fix with a linked deep-dive.

Compute​

• Migrate x86 instances to Graviton (ARM). Graviton families cost up to ~20% less than the equivalent x86 for the same vCPU/memory, and often run faster per dollar. For most modern workloads it is a one-line instance-type swap. Deep dive: Graviton migration guide

Storage​

• Migrate EBS gp2 volumes to gp3. gp3 is ~20% cheaper than gp2 and usually faster, with an online migration and zero downtime. Deep dive: gp2 to gp3 migration
• Delete old EBS snapshots. Snapshots cost $0.05/GB-month and accumulate forever - especially orphaned ones from deleted volumes and deregistered AMIs. Deep dive: Clean up old EBS snapshots

Networking​

• Delete idle NAT Gateways. An idle NAT Gateway bills ~$32/month plus data charges for doing nothing. Many can be replaced with free VPC endpoints. Deep dive: Find and delete idle NAT Gateways
• Delete idle load balancers. An ALB or NLB with no traffic still bills its ~$16/month base rate. Look for near-zero requests and empty target groups. Deep dive: Delete idle load balancers
• Release unattached Elastic IPs. Since 2024 every public IPv4 address costs money, so an unattached Elastic IP bills ~$3.60/month for nothing. Deep dive: Stop paying for unattached Elastic IPs

Databases and analytics​

• Right-size over-provisioned DynamoDB. Provisioned capacity bills whether you use it or not. Single-digit utilization means you are overpaying - right-size, auto-scale, or switch to on-demand. Deep dive: Right-size over-provisioned DynamoDB
• Pause idle Redshift clusters. A cluster charges per node-hour regardless of query activity. Idle clusters from old analytics projects are pure waste - pause, snapshot, or move to Serverless. Deep dive: Idle Redshift clusters bill by the hour

Observability​

• Set CloudWatch Logs retention. Log groups default to infinite retention, so logs pile up forever at $0.03/GB-month. Set a sane policy on never-expiring groups. Deep dive: Your CloudWatch Logs never expire

What this checklist does not cover​

To keep it honest: this list is about waste you can delete or right-size today, which is where the fastest, lowest-risk savings live. It does not cover:

• Commitments - Reserved Instances and Savings Plans, which are a separate exercise once your steady-state usage is clean (buy commitments after you delete waste, not before, or you will commit to paying for waste).
• Architecture - moving to spot, serverless, or cheaper data-transfer paths, which are higher-effort structural changes.

Clean up the list above first. It is the cheapest money you will ever save.

Automate the whole loop​

Doing this by hand once is worth it. Doing it by hand every quarter is not. Cloud Cost Analyzer runs all of these checks (and 80+ more) as a single read-only CLI scan - it finds every item on this list across your account, ranks them by savings, and you can wire it into CI so new waste fails a build instead of quietly showing up on next month's invoice. Your credentials never leave your environment, with an air-gapped option for regulated teams.

Run your first scan free

The account​

A normal mid-size setup: Aurora and DocumentDB databases, EC2 for data pipelines, and the usual pile of resources nobody had looked at in a year. The scan flagged plenty. What matters is what happened after we acted on it and watched the invoice.

These are realized numbers, not "potential." A tool will happily tell you one instance could save money three ways: buy a Reserved Instance, turn it off, or right-size it. You get to pick one. Everything below is the actual run-rate change in Cost Explorer, so it is what the account stopped paying.

The two fixes that were 92% of it​

Aurora I/O-Optimized: $942/month​

The biggest one. The Aurora clusters were on the standard config and paying per-request I/O charges every month, flat and predictable at $1,218 to $1,245 across the prior quarter. I/O-Optimized drops the per-I/O charge for a higher flat instance and storage rate:

We watched the cluster for three days after the switch before calling it done. Nothing moved in the wrong direction:

If your Aurora I/O spend is high and steady, this is about the safest large win there is. The switch is a config change, not a migration, and it is reversible.

Decommission idle DocumentDB: $825/month​

Four DocumentDB instances across two clusters, sitting at roughly zero connections. The service that used them had already been moved off DocumentDB months earlier. We confirmed zero live connections with VPC Flow Log queries, took manual snapshots for rollback, and deleted the clusters. Cost went from $825.09 to $0.10. These were also end-of-life DocumentDB 3.6 clusters with a March 30 EOL deadline, so deleting them killed a forced upgrade at the same time.

The other four​

Migrating a data-pipeline instance from x86 to Graviton, stopping an idle dev instance and a dead SFTP box, and removing unused public-facing infrastructure. Smaller line items, but they came with wins that were not about cost (below).

The bill, month by month​

The savings landed on the targeted services and held. Cost Explorer, targeted services only:

One honest caveat: the whole account bill fell by less than $1,925, because unrelated services (EKS control plane, AWS Config) grew over the same months. The savings on the targeted resources are real and isolated. They do not mean the entire bill dropped by the same amount, and any cost report that pretends otherwise is selling you something.

What it cost in downtime​

Nothing. Zero production incidents. The original projection was $1,900 to $2,300/month; the realized $1,925.57 landed inside it. We validated the January baseline against the prior quarter first, to make sure it was a normal month and not a spike we were measuring against.

How the savings showed up​

The savings did not land all at once. They ramped as each fix went in, which is exactly what you want to see: the run rate moving with the actions, not before them. Cumulative savings against the January baseline:

By April the monthly run rate had settled at the full $1,925.57. Total realized in the first three months was $2,957.18 while the fixes were still phasing in.

The wins that were not about cost​

• 29 to 62% faster ETL on Graviton. Nightly pipelines that ran 8 to 18 minutes dropped by a third to two thirds. See the Graviton migration guide for how the move works.
• Killed an EOL deadline. The DocumentDB 3.6 clusters would have forced an upgrade by March 30. Deleting them made it moot.
• Smaller attack surface. An unused public-facing SFTP host is gone, and the new Graviton instance enforces IMDSv2.

What we left on the table​

We stopped at the safe, high-value fixes and did not chase every dollar. A few smaller items are still open on purpose:

• A Reserved Instance or Savings Plan on the new Graviton instance, once its steady-state usage is confirmed (~$40/mo). Buy commitments after the waste is gone, not before.
• I/O-Optimized on the remaining dev and QA Aurora clusters (~$20/mo of residual I/O).
• Terminating two already-stopped instances to drop their lingering EBS charges.

None were worth rushing. There is almost always a long tail after the big wins, and it is fine to leave it for the next quarterly pass.

Find it in your own account​

Every fix here started as a line in a scan. Cloud Cost Analyzer runs the same checks, plus 80+ more, as one read-only pass:

curl -sSL https://releases.dragonfractal.com/install.sh | sh
cca scan --provider aws

The scan runs in your environment with read-only access, so your credentials never leave it. Then you do the part that actually saves money: fix the top of the list and check the result in Cost Explorer. The AWS cost optimization checklist walks through the fixes it looks for.

Why gp3 is cheaper (and usually faster)​

gp2 pricing couples performance to size: you get 3 IOPS per GB, so the only way to get more IOPS on gp2 is to over-provision storage you do not need. gp3 decouples them:

(Prices are us-east-1 list; the ratio holds across regions.)

For a 500 GB volume that is $50/month to $40/month, i.e. $120/year saved, per volume, with equal or better performance. Multiply by every gp2 volume in every account.

Step 1 - Find your gp2 volumes​

aws ec2 describe-volumes \
  --filters Name=volume-type,Values=gp2 \
  --query 'Volumes[].{ID:VolumeId,GiB:Size,AZ:AvailabilityZone,State:State}' \
  --output table

Run it per region. EBS is regional, so a volume only shows up in its own region:

for region in $(aws ec2 describe-regions --query 'Regions[].RegionName' --output text); do
  echo "== $region =="
  aws ec2 describe-volumes --region "$region" \
    --filters Name=volume-type,Values=gp2 \
    --query 'Volumes[].{ID:VolumeId,GiB:Size}' --output text
done

Step 2 - Migrate (online, no downtime)​

Converting the type is a live modify-volume. The volume stays attached and readable/writable the whole time; it briefly enters an optimizing state:

aws ec2 modify-volume --volume-id vol-0abc123def456 --volume-type gp3

To convert everything in a region at once:

for vol in $(aws ec2 describe-volumes \
  --filters Name=volume-type,Values=gp2 \
  --query 'Volumes[].VolumeId' --output text); do
  echo "migrating $vol"
  aws ec2 modify-volume --volume-id "$vol" --volume-type gp3
done

No snapshot, no detach, no reboot. (AWS allows one modification per volume per 6 hours, so migrate, then wait before re-modifying the same volume.)

The one caveat: high-IOPS / high-throughput volumes​

Because gp2 IOPS scale with size, a large gp2 volume may already deliver more than gp3's 3,000 baseline IOPS. A 2 TB gp2 volume provides 6,000 IOPS; if your workload actually uses them, migrate and provision matching performance on gp3:

aws ec2 modify-volume --volume-id vol-0abc123def456 \
  --volume-type gp3 --iops 6000 --throughput 250

The first 3,000 IOPS and 125 MB/s are free; beyond that, extra IOPS are $0.005/provisioned-IOPS-month and extra throughput $0.040/MB/s-month. Even fully matched, gp3 is normally still cheaper than the equivalent gp2, but check CloudWatch VolumeReadOps/VolumeWriteOps before assuming you need the headroom. Volumes ≤ ~1 TB with normal workloads are a straight 20% win.

Do it automatically​

Finding gp2 volumes and estimating the savings across every account and region by hand does not scale. That is exactly what Cloud Cost Analyzer's ebs-gp2-to-gp3-migration rule does: it flags every gp2 volume and estimates the monthly saving, alongside 89 other cost rules:

curl -sSL https://releases.dragonfractal.com/install.sh | sh
cca scan --provider aws

The agent runs in your environment with read-only access, so your AWS credentials never leave it. See the AWS setup and required IAM permissions

Why idle load balancers linger​

The hourly base charge is fixed - an ALB with zero requests bills the same ~$16/month as a busy one. Load balancers are usually created early (with an app or an IaC module) and deleted last, if ever. A handful of abandoned ALBs from old environments is real, recurring money.

Step 1 - List load balancers and their traffic​

aws elbv2 describe-load-balancers \
  --query 'LoadBalancers[].{Name:LoadBalancerName,Type:Type,ARN:LoadBalancerArn}' \
  --output table

For an ALB, check request volume over the last 7 days (the metric dimension is the tail of the ARN, e.g. app/my-alb/50dc6c495c0c9188):

aws cloudwatch get-metric-statistics \
  --namespace AWS/ApplicationELB \
  --metric-name RequestCount \
  --dimensions Name=LoadBalancer,Value=app/my-alb/50dc6c495c0c9188 \
  --start-time "$(date -u -d '7 days ago' +%Y-%m-%dT%H:%M:%SZ)" \
  --end-time "$(date -u +%Y-%m-%dT%H:%M:%SZ)" \
  --period 86400 --statistics Sum \
  --query 'Datapoints[].Sum'

Near-zero request counts over a week is a strong idle signal. (For NLBs, use the AWS/NetworkELB namespace and ActiveFlowCount.)

Step 2 - Check for empty or unhealthy target groups​

A load balancer with no healthy targets is doing nothing useful:

for tg in $(aws elbv2 describe-target-groups \
  --load-balancer-arn <lb-arn> \
  --query 'TargetGroups[].TargetGroupArn' --output text); do
  echo "== $tg =="
  aws elbv2 describe-target-health --target-group-arn "$tg" \
    --query 'TargetHealthDescriptions[].TargetHealth.State' --output text
done

Empty output (no targets) or all unhealthy alongside near-zero requests is a confident "delete me."

Step 3 - Delete safely​

aws elbv2 delete-load-balancer --load-balancer-arn <lb-arn>

Caveat: a load balancer with no requests is not always dead - it might be a disaster-recovery endpoint, a rarely-hit admin panel, or the target of a DNS record that something depends on. Before deleting, check Route 53 (and any external DNS) for records pointing at the load balancer's DNS name, and confirm nothing references it:

aws elbv2 describe-load-balancers --load-balancer-arn <lb-arn> \
  --query 'LoadBalancers[].DNSName' --output text

Then grep your DNS zones for that name. No references + no traffic + no healthy targets = safe to remove.

Do it automatically​

Cloud Cost Analyzer's idle-load-balancer rule flags load balancers serving fewer than 100 requests/day over a 7-day window, so you are not manually pulling CloudWatch for each one - alongside 89 other cost rules:

curl -sSL https://releases.dragonfractal.com/install.sh | sh
cca scan --provider aws

The agent runs in your environment with read-only access, so your AWS credentials never leave it. See the AWS setup and required IAM permissions

Why NAT Gateways get expensive quietly​

A NAT Gateway has two costs (us-east-1):

• Hourly: $0.045/hour ≈ $32/month, flat, whether it moves 0 bytes or 0 GB.
• Data processing: $0.045 per GB that passes through it.

The trap is the hourly charge. A common HA pattern puts one NAT Gateway in each Availability Zone - three AZs is ~$96/month in fixed cost. Leftovers from deleted environments, or NATs in subnets that no longer send traffic, bill the full $32/month indefinitely.

Step 1 - List your NAT Gateways​

aws ec2 describe-nat-gateways \
  --filter Name=state,Values=available \
  --query 'NatGateways[].{ID:NatGatewayId,VPC:VpcId,Subnet:SubnetId}' \
  --output table

Across all regions:

for region in $(aws ec2 describe-regions --query 'Regions[].RegionName' --output text); do
  echo "== $region =="
  aws ec2 describe-nat-gateways --region "$region" \
    --filter Name=state,Values=available \
    --query 'NatGateways[].NatGatewayId' --output text
done

Step 2 - Check whether each one is actually used​

Idle means little to no traffic. Pull the last 7 days of bytes from CloudWatch for a given NAT Gateway:

aws cloudwatch get-metric-statistics \
  --namespace AWS/NATGateway \
  --metric-name BytesOutToDestination \
  --dimensions Name=NatGatewayId,Value=nat-0abc123def456 \
  --start-time "$(date -u -d '7 days ago' +%Y-%m-%dT%H:%M:%SZ)" \
  --end-time "$(date -u +%Y-%m-%dT%H:%M:%SZ)" \
  --period 86400 --statistics Sum \
  --query 'Datapoints[].Sum'

Near-zero sums over a week means nothing is using it. Also confirm no route table still points 0.0.0.0/0 at it:

aws ec2 describe-route-tables \
  --query "RouteTables[?Routes[?NatGatewayId=='nat-0abc123def456']].RouteTableId" \
  --output text

Step 3 - Delete it safely​

If no route table depends on it and traffic is flat, delete it:

aws ec2 delete-nat-gateway --nat-gateway-id nat-0abc123def456

Then release the Elastic IP it held (that is billable too - see the unattached Elastic IP post).

Caveat: a NAT Gateway provides outbound internet for private subnets. If a workload in that subnet needs egress (package installs, external APIs, updates), deleting the NAT breaks it. Verify traffic is genuinely flat and no active route depends on it before deleting. In multi-AZ setups, deleting one AZ's NAT sends that AZ's traffic cross-AZ (added data cost) or breaks it - decide deliberately.

Cut NAT data charges for free​

Traffic to S3 and DynamoDB does not need a NAT Gateway at all. A VPC gateway endpoint routes it privately, for free, and removes those bytes from your NAT data-processing bill:

aws ec2 create-vpc-endpoint \
  --vpc-id vpc-0abc123 \
  --service-name com.amazonaws.us-east-1.s3 \
  --route-table-ids rtb-0abc123

Do it automatically​

Checking NAT traffic across every VPC, subnet, and region by hand does not scale. Cloud Cost Analyzer's idle-nat-gateway rule flags any NAT Gateway moving less than 1 GB/day over a 7-day window, alongside 89 other cost rules:

curl -sSL https://releases.dragonfractal.com/install.sh | sh
cca scan --provider aws

The agent runs in your environment with read-only access, so your AWS credentials never leave it. See the AWS setup and required IAM permissions

Why this line item appeared​

AWS used to give you one free public IPv4 per running instance and only charged for idle Elastic IPs. As of 1 February 2024, all public IPv4 addresses cost $0.005/hour (~$3.60/month). Attached ones you are presumably using - but an unattached EIP is billing you for an address doing nothing. Orphaned ENIs left behind by deleted Lambdas, load balancers, or instances frequently hold these.

Step 1 - Find unattached Elastic IPs​

An EIP with no AssociationId is not attached to anything:

aws ec2 describe-addresses \
  --query 'Addresses[?AssociationId==`null`].{IP:PublicIp,AllocId:AllocationId}' \
  --output table

Across all regions:

for region in $(aws ec2 describe-regions --query 'Regions[].RegionName' --output text); do
  echo "== $region =="
  aws ec2 describe-addresses --region "$region" \
    --query 'Addresses[?AssociationId==`null`].PublicIp' --output text
done

Step 2 - Find orphaned network interfaces​

ENIs in the available state are detached and just sitting there:

aws ec2 describe-network-interfaces \
  --filters Name=status,Values=available \
  --query 'NetworkInterfaces[].{ENI:NetworkInterfaceId,AZ:AvailabilityZone,Desc:Description}' \
  --output table

Beyond cost, orphaned ENIs commonly block security group deletion ("resource in use"), so clearing them untangles cleanup too.

Step 3 - Release / delete safely​

Release an unattached EIP:

aws ec2 release-address --allocation-id eipalloc-0abc123def456

Delete an available ENI:

aws ec2 delete-network-interface --network-interface-id eni-0abc123def456

Caveat - the one that bites people: releasing an Elastic IP gives up that IP address permanently. You will almost certainly get a different one next time. If the IP is allow-listed in a partner's firewall, hardcoded in DNS, or referenced by a third party, releasing it breaks that integration. Confirm the address is not referenced anywhere before releasing. Deleting a detached ENI is low-risk (it is already attached to nothing), but double-check the description to be sure it is not a reserved interface for a service you are about to launch.

Do it automatically​

Cloud Cost Analyzer's unattached-network-interface rule flags detached ENIs and tells you which ones are holding a billable Elastic IP, so you can clear both in one pass - alongside 89 other cost rules:

curl -sSL https://releases.dragonfractal.com/install.sh | sh
cca scan --provider aws

The agent runs in your environment with read-only access, so your AWS credentials never leave it. See the AWS setup and required IAM permissions

Why snapshots pile up​

Snapshots are incremental, so the first one is full-size and later ones only store changed blocks - which makes them feel cheap. But they never expire on their own, and automation (AMI bakes, backup jobs, create-image) generates them constantly. Delete the volume or deregister the AMI and the underlying snapshots often stay, billing indefinitely. A multi-year account routinely has thousands.

Step 1 - Find old snapshots you own​

aws ec2 describe-snapshots --owner-ids self \
  --query 'sort_by(Snapshots, &StartTime)[].{ID:SnapshotId,GiB:VolumeSize,Started:StartTime,Desc:Description}' \
  --output table

Just the ones older than 90 days:

cutoff=$(date -u -d '90 days ago' +%Y-%m-%dT%H:%M:%SZ)
aws ec2 describe-snapshots --owner-ids self \
  --query "Snapshots[?StartTime<='${cutoff}'].{ID:SnapshotId,GiB:VolumeSize,Started:StartTime}" \
  --output table

Step 2 - Check before you delete​

The critical check: is a snapshot backing an AMI? Deleting one that is breaks the AMI. List snapshots referenced by your AMIs:

aws ec2 describe-images --owners self \
  --query 'Images[].BlockDeviceMappings[].Ebs.SnapshotId' --output text | tr '\t' '\n' | sort -u

Anything in that list is in use - leave it (or deregister the AMI first if the AMI itself is obsolete).

Step 3 - Delete or archive​

Delete a truly dead snapshot:

aws ec2 delete-snapshot --snapshot-id snap-0abc123def456

For compliance/DR snapshots you must keep but rarely restore, move them to the archive tier instead of deleting:

aws ec2 modify-snapshot-tier --snapshot-id snap-0abc123def456 --storage-tier archive

Caveats: deleting an incremental snapshot is safe - AWS re-parents the blocks later snapshots need, so you never corrupt a chain. The real risk is AMIs (above). Archive has a 90-day minimum and restore takes 24-72h plus a retrieval fee, so only archive things you genuinely will not need quickly.

Do it automatically​

Cloud Cost Analyzer's ebs-snapshot-archive rule surfaces old, large, rarely accessed snapshots and estimates the archive/delete savings - alongside 89 other cost rules:

curl -sSL https://releases.dragonfractal.com/install.sh | sh
cca scan --provider aws

The agent runs in your environment with read-only access, so your AWS credentials never leave it. See the AWS setup and required IAM permissions

Why idle Redshift is expensive​

Provisioned Redshift charges for compute by node, continuously. An ra3.xlplus node is $1.086/hour; a modest 2-node cluster is **$1,560/month** even if it is queried once a week. Analytics clusters are prime candidates to go idle - a dashboard project ships, the team moves on, and the cluster keeps running.

Step 1 - Find your clusters​

aws redshift describe-clusters \
  --query 'Clusters[].{ID:ClusterIdentifier,Node:NodeType,Count:NumberOfNodes,Status:ClusterStatus}' \
  --output table

Step 2 - Check query activity​

Idle means almost no queries. Pull the last 7 days of query volume from CloudWatch:

aws cloudwatch get-metric-statistics \
  --namespace AWS/Redshift --metric-name QueriesCompletedPerSecond \
  --dimensions Name=ClusterIdentifier,Value=my-cluster \
  --start-time "$(date -u -d '7 days ago' +%Y-%m-%dT%H:%M:%SZ)" \
  --end-time "$(date -u +%Y-%m-%dT%H:%M:%SZ)" \
  --period 86400 --statistics Sum \
  --query 'Datapoints[].Sum'

Near-zero over a week is a clear idle signal.

Step 3 - Pick a fix​

• Used occasionally -> pause it. Paused clusters stop compute billing (you still pay for storage) and resume in minutes:

  aws redshift pause-cluster --cluster-identifier my-cluster
  

• Not needed, but keep the data -> snapshot and delete. You can restore later from the snapshot:

  aws redshift delete-cluster --cluster-identifier my-cluster \
    --final-cluster-snapshot-identifier my-cluster-final
  

• Sporadic, unpredictable use -> move to Redshift Serverless, which bills for compute only while queries run.

The caveat: know what depends on it​

Before pausing or deleting, check what talks to the cluster - scheduled ETL jobs, BI tools (QuickSight, Tableau), and downstream dashboards will fail against a paused or deleted cluster. Pausing is reversible and low-risk; deleting requires the final snapshot (always take it) and confirmation that no automated job expects the cluster to be live.

Do it automatically​

Cloud Cost Analyzer's idle-redshift rule flags clusters running fewer than ~10 queries/day so you can pause or retire them - alongside 89 other cost rules:

curl -sSL https://releases.dragonfractal.com/install.sh | sh
cca scan --provider aws

The agent runs in your environment with read-only access, so your AWS credentials never leave it. See the AWS setup and required IAM permissions

Why over-provisioning happens​

Someone sets a table to 1,000 RCU / 1,000 WCU during a launch or load test, traffic never materializes, and the provisioned numbers are never revisited. You keep paying for 1,000 units while consuming 50. Because DynamoDB does not bill a big scary line item, it hides.

Step 1 - Compare provisioned vs consumed​

Check a table's provisioned capacity:

aws dynamodb describe-table --table-name my-table \
  --query 'Table.ProvisionedThroughput.{Read:ReadCapacityUnits,Write:WriteCapacityUnits}'

Then pull actual consumption over the last week from CloudWatch:

aws cloudwatch get-metric-statistics \
  --namespace AWS/DynamoDB --metric-name ConsumedReadCapacityUnits \
  --dimensions Name=TableName,Value=my-table \
  --start-time "$(date -u -d '7 days ago' +%Y-%m-%dT%H:%M:%SZ)" \
  --end-time "$(date -u +%Y-%m-%dT%H:%M:%SZ)" \
  --period 86400 --statistics Average Maximum \
  --query 'Datapoints[].{Avg:Average,Max:Maximum}'

Average consumption far below provisioned (say, under 20%) means you are overpaying.

Step 2 - Pick the right fix​

• Steady, predictable traffic that is just set too high -> lower the provisioned numbers to match reality:

  aws dynamodb update-table --table-name my-table \
    --provisioned-throughput ReadCapacityUnits=100,WriteCapacityUnits=100
  

• Variable-but-known daily pattern -> enable auto-scaling so capacity tracks demand instead of sitting at a fixed ceiling.
• Spiky or unpredictable, low-average traffic -> switch to on-demand, which bills per request with no reserved capacity:

  aws dynamodb update-table --table-name my-table --billing-mode PAY_PER_REQUEST
  

The caveat: on-demand is not always cheaper​

On-demand costs roughly 5-7x more per request than provisioned. It wins for spiky, low-average, or unpredictable workloads (you pay nothing when idle), but for steady high throughput provisioned + auto-scaling is far cheaper. Right-size based on the consumption pattern, not a blanket switch. You can change billing mode once per 24 hours, so decide deliberately.

Do it automatically​

Cloud Cost Analyzer's dynamodb-over-provisioned rule flags tables running below 20% utilization and estimates the right-sizing savings - alongside 89 other cost rules:

curl -sSL https://releases.dragonfractal.com/install.sh | sh
cca scan --provider aws

The agent runs in your environment with read-only access, so your AWS credentials never leave it. See the AWS setup and required IAM permissions

Why this quietly grows​

Two things bill on CloudWatch Logs: ingestion ($0.50/GB, one-time) and storage ($0.03/GB-month, forever). New log groups are created with retentionInDays unset, meaning never expire, so storage grows without bound. Nobody notices because it is a slowly rising line, not a spike. Debug logs from 2022 are still costing you money today.

Step 1 - Find log groups with no retention set​

aws logs describe-log-groups \
  --query 'logGroups[?retentionInDays==`null`].{Name:logGroupName,Bytes:storedBytes}' \
  --output table

Sort by size to find the worst offenders first:

aws logs describe-log-groups \
  --query 'reverse(sort_by(logGroups[?retentionInDays==`null`], &storedBytes))[:20].[logGroupName,storedBytes]' \
  --output table

Step 2 - Set a retention policy​

Pick a sane default (30/90/365 days depending on the log's purpose) and apply it:

aws logs put-retention-policy \
  --log-group-name /aws/lambda/my-function \
  --retention-in-days 90

Apply 90 days to every never-expiring group at once:

for lg in $(aws logs describe-log-groups \
  --query 'logGroups[?retentionInDays==`null`].logGroupName' --output text); do
  echo "setting 90d on $lg"
  aws logs put-retention-policy --log-group-name "$lg" --retention-in-days 90
done

Retention applies going forward and prunes existing logs older than the window, so storage drops on its own after you set it.

The caveat: audit and compliance logs​

Do not blanket-expire everything. CloudTrail, VPC Flow Logs, and anything under a compliance regime (PCI, HIPAA, SOC 2) may have a required minimum retention. For those, keep a longer window - or better, export to S3 (or S3 Glacier) for long-term retention at a fraction of CloudWatch's storage price, then expire the CloudWatch copy. Separate "I might debug this" logs (short retention) from "I must retain this" logs (export + policy).

Do it automatically​

Cloud Cost Analyzer's cloudwatch-logs-retention rule flags log groups with infinite (or excessive) retention and estimates the savings from capping them - alongside 88 other cost rules:

curl -sSL https://releases.dragonfractal.com/install.sh | sh
cca scan --provider aws

The agent runs in your environment with read-only access, so your AWS credentials never leave it. See the AWS setup and required IAM permissions