How to cut AWS cost waste

Start with the resources that bill whether or not they do work. Unattached Elastic IPs and "available" EBS volumes are pure metadata queries; an idle NAT gateway or load balancer needs a glance at CloudWatch traffic to confirm.

# Elastic IPs not associated with anything (AssociationId is null)
aws ec2 describe-addresses \
  --query 'Addresses[?AssociationId==`null`].[PublicIp,AllocationId]' --output table

# EBS volumes in the "available" state — attached to nothing, still billed
aws ec2 describe-volumes \
  --filters Name=status,Values=available \
  --query 'Volumes[].[VolumeId,Size,VolumeType]' --output table

# NAT gateway data processed over 30 days — near-zero means idle
aws cloudwatch get-metric-statistics \
  --namespace AWS/NATGateway --metric-name BytesOutToDestination \
  --dimensions Name=NatGatewayId,Value=nat-0example \
  --start-time "$(date -u -d '30 days ago' +%Y-%m-%dT%H:%M:%SZ)" \
  --end-time "$(date -u +%Y-%m-%dT%H:%M:%SZ)" \
  --period 2592000 --statistics Sum

Release unattached EIPs with aws ec2 release-address, snapshot then delete stray volumes, and delete idle NAT gateways or load balancers once you have confirmed nothing routes through them. For an idle ALB/NLB, check RequestCount / ActiveFlowCount in the AWS/ApplicationELB / AWS/NetworkELB namespaces.

gp3 is the newer general-purpose SSD family and AWS documents it as lower cost per GB than gp2 at the same baseline performance, with IOPS and throughput set independently of capacity. The switch is an in-place modify-volume — no snapshot, no downtime — but set an explicit baseline so you do not silently lose performance:

# List gp2 volumes to migrate
aws ec2 describe-volumes \
  --filters Name=volume-type,Values=gp2 \
  --query 'Volumes[].[VolumeId,Size]' --output table

# Convert in place; set a baseline (gp3 starts at 3000 IOPS / 125 MB/s)
aws ec2 modify-volume \
  --volume-id vol-0example \
  --volume-type gp3 --iops 3000 --throughput 125

Confirm your workload does not rely on gp2 burst-credit behaviour, then modify during a low-traffic window. The volume stays attached and readable throughout the optimisation.

Right-sizing on a hunch causes incidents; right-sizing on metrics does not. AWS Compute Optimizer reads your CloudWatch history and recommends EC2, EBS, Lambda, and RDS targets — turn it on and let it observe before you resize anything:

# Enable Compute Optimizer (account-level, opt-in)
aws compute-optimizer update-enrollment-status --status Active

# Read EC2 recommendations once it has data
aws compute-optimizer get-ec2-instance-recommendations \
  --query 'instanceRecommendations[].[instanceArn,finding,currentInstanceType,recommendationOptions[0].instanceType]' \
  --output table

# Manual cross-check: 14 days of average CPU for one instance
aws cloudwatch get-metric-statistics \
  --namespace AWS/EC2 --metric-name CPUUtilization \
  --dimensions Name=InstanceId,Value=i-0example \
  --start-time "$(date -u -d '14 days ago' +%Y-%m-%dT%H:%M:%SZ)" \
  --end-time "$(date -u +%Y-%m-%dT%H:%M:%SZ)" \
  --period 86400 --statistics Average Maximum

Sustained low average CPU with a low maximum means you can step down a size (or family). Change EC2 with a stop → modify-instance-attribute → start; change RDS with modify-db-instance in a maintenance window. Consider Graviton equivalents for a further efficiency gain where your workload supports arm64.

Once you have removed the waste, lower the rate on what remains. Savings Plans and Reserved Instances both trade a one- or three-year commitment for a discount on steady-state usage. Compute Savings Plans are the most flexible — they apply across instance family, size, region, and Fargate/Lambda. Commit only to the baseline you are confident stays up for the term, and audit existing commitments for underutilisation before buying more:

# What Savings Plans would AWS recommend for your steady usage?
aws ce get-savings-plans-purchase-recommendation \
  --savings-plans-type COMPUTE_SP --term-in-years ONE_YEAR \
  --payment-option NO_UPFRONT --lookback-period-in-days SIXTY_DAYS

# Are the commitments you already own being fully used?
aws ce get-reservation-utilization \
  --time-period Start=2026-06-01,End=2026-07-01

Keep bursty or uncertain capacity on-demand — a commitment you do not consume is its own kind of waste. Under ~80% utilisation on an existing Reserved Instance means you over-committed and should not renew at that level.

Waste with no owner never gets cleaned up. Tag every resource with an owner and a cost centre, then activate those as cost-allocation tags so they appear in Cost Explorer and the billing reports. Untagged spend becomes a visible bucket you can chase down:

# Tag a resource with an owner + cost centre
aws ec2 create-tags --resources i-0example \
  --tags Key=owner,Value=platform-team Key=cost-center,Value=cc-1042

# Activate the keys as cost-allocation tags (billing-console equivalent)
aws ce update-cost-allocation-tags-status \
  --cost-allocation-tags-status TagKey=owner,Status=Active \
                                TagKey=cost-center,Status=Active

Enforce tags going forward with a tag policy or an infrastructure-as-code default, so nothing new launches without an owner. Now every dollar has a name next to it.

The final guardrail catches new waste the day it appears. In the console it is Billing → Budgets → Create budget → Cost budget: set a monthly amount and alert thresholds (for example at 80% and 100% of the plan), and add the emails to notify. To keep it in version control, the Terraform below creates the same cost budget with two notifications:

resource "aws_budgets_budget" "monthly_cost" {
  name         = "monthly-cost-guardrail"
  budget_type  = "COST"
  limit_amount = "1000"      # your chosen monthly cap, in USD
  limit_unit   = "USD"
  time_unit    = "MONTHLY"

  notification {
    comparison_operator        = "GREATER_THAN"
    threshold                  = 80
    threshold_type             = "PERCENTAGE"
    notification_type          = "ACTUAL"
    subscriber_email_addresses = ["[email protected]"]
  }

  notification {
    comparison_operator        = "GREATER_THAN"
    threshold                  = 100
    threshold_type             = "PERCENTAGE"
    notification_type          = "FORECASTED"
    subscriber_email_addresses = ["[email protected]"]
  }
}

Budgets is alerting, not enforcement — it warns you the moment spend crosses a threshold; it does not cap or stop your account. Route the notification to a channel a human actually watches.