DEV Community: Jorel Fermin

Idle load balancers: the ~$16/month each you forgot to delete"

Jorel Fermin — Wed, 19 Aug 2026 18:35:59 +0000

Short version: An Application or Network Load Balancer costs ~$0.0225/hour, about $16/month, just to exist, plus capacity units. Classic Load Balancers run ~$18/month. Load balancers outlive the services behind them: the app gets torn down, the ALB keeps billing. Here's how to find load balancers with no real traffic or no healthy targets, and remove them safely.

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 isn't always dead - it might be a disaster-recovery endpoint, a rarely-hit admin panel, or the target of a DNS record 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.

Doing it across every account, automatically

Pulling CloudWatch for every load balancer by hand doesn't scale. It's one of the checks in a read-only CLI I built, Cloud Cost Analyzer - its idle-load-balancer rule flags load balancers serving fewer than 100 requests/day over a 7-day window, alongside 89 other AWS cost rules:

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

It runs in your environment with read-only access, so your AWS credentials never leave it. Free tier if you want to try it on one account, and dashboards if you want to review or share reports.

Originally published on the Dragon Fractal Cloud Cost Analyzer blog.

Migrate EBS gp2 volumes to gp3 and cut storage cost by about 20%

Jorel Fermin — Wed, 19 Aug 2026 17:27:10 +0000

Short version: AWS gp3 EBS volumes cost about ~20% less per GB than gp2 ($0.08 vs $0.10 per GB-month in us-east-1) and includes 3,000 IOPS and 125 MB/s of baseline performance for free. You can convert a volume from gp2 to gp3 online, with no downtime and no snapshot with a single modify-volume call. For most volumes, it's a real savings. Here's how to find those volumes, migrate them, and the one caveat to keep in mind.

Why gp3 is cheaper (and usually faster)

gp2 pricing couples performance to its size: you get 3 IOPS per GB, so the only way to get more IOPS on gp2 is to over-provision storage you don't need. gp3 removes that coupling:

	gp2	gp3
Storage	$0.10 / GB-month	$0.08 / GB-month (-20%)
Baseline IOPS	3 IOPS/GB (burst to 3,000)	3,000 included at any size
Baseline throughput	scales with size	125 MB/s included
Extra IOPS / throughput	not possible	provision independently

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

For a 500 GB volume, that's $50/month to $40/month, i.e., $120/year saved, per volume, with equal or better performance. Now multiply this 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 and then wait before 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 usually still cheaper than the equivalent gp2, but check CloudWatch VolumeReadOps/VolumeWriteOps before assuming you need the headroom. Volumes under ~1 TB with normal workloads are a straight 20% win.

Doing it across every account, automatically

Finding gp2 volumes and estimating the savings across every account and region by hand doesn't scale. It's one of the checks in a read-only CLI I built, Cloud Cost Analyzer. It flags every gp2 volume with the estimated monthly savings, alongside 89 other AWS cost rules:

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

It runs in your environment with read-only access, so your AWS credentials never leave it. Free tier if you want to try it on one account, and dashboards if you want to review or share reports.

Originally published on the Dragon Fractal Cloud Cost Analyzer blog.