Trim load balancer and public IP costs on AWS

Why this matters

Load balancers and public IPv4 addresses are quiet line items on an AWS bill. A team creates an Application Load Balancer for a new service, a Network Load Balancer for a test, and an Elastic IP for a migration. The service goes away, but the hourly and address charges stay. The resources also spread your traffic surface, so no one can say which DNS name points where.

The usual pattern is one load balancer per service, per environment, plus a few from a Kubernetes ingress controller. Some are internal and never face the internet. Others are public but carry little traffic. Public addresses pile up too: idle Elastic IPs, old bastion hosts, and public IPs on instances that should sit in private subnets.

Trimming starts with inventory, not accounting. You need the owner, DNS records, traffic pattern and rollback path for each load balancer. Done carefully, the work cuts fixed hourly charges and address charges, and it leaves a shorter list for the next review.

Before you start

Get read access to EC2, Elastic Load Balancing, Route 53, CloudWatch and Cost Explorer. You don't need write access to start. Pull every load balancer, target group, listener, Elastic IP and public IPv4 address. Include account, Region, VPC, scheme and tags.

Find the owners. Check tags, then ask the service teams. A load balancer with no owner tag is a review candidate, not an automatic delete. Get a maintenance window and a rollback plan for production traffic. Avoid changes during a release or peak period.

Capture a baseline. In Cost Explorer, group by service and usage type, then filter to Elastic Load Balancing and public IPv4. Save current DNS records and certificate ARNs. If Terraform, CloudFormation or a Kubernetes controller manages the resource, change the source, not the console.

How to do it

Work from the inventory. Classify each load balancer as public, internal, active, idle or unknown. For each public address, record whether it is attached, to what, and who owns it. Then move in small batches: share HTTP services behind one ALB, retire idle balancers, release unused addresses, and add guardrails.

Do not start by deleting. Map DNS and traffic first. A load balancer with low request count may be a failover target. A public address with no traffic may be in a customer allowlist. Check dependencies before you change a record or release an address.

Keep the blast radius small when you consolidate. Put related services behind one ALB with host based rules, but do not put every service behind a single balancer. Use separate ALBs for separate security boundaries. For internal services, use an internal ALB in private subnets so you do not pay for public addresses you do not need.

1. Export the inventory. Run the AWS CLI calls for describe-load-balancers, describe-listeners, describe-target-groups and describe-addresses. Include Classic Load Balancers if any remain. Save account, Region, scheme, DNS name and tags.
2. Map DNS and traffic. Check Route 53 records, external DNS and CloudFront origins that point at each balancer. Pull RequestCount, ActiveConnectionCount and HealthyHostCount from CloudWatch over a full month. Mark a balancer idle only after you confirm no failover or allowlist dependency.
3. Tag owner and decision. Add an owner tag and a lifecycle tag such as keep, merge or retire. Put the review date in the tag or your tracking system. This turns the next cleanup into a report.
4. Share HTTP load balancers. Move related HTTP services behind one ALB with host rules, path rules, SNI certificates and separate target groups. In Kubernetes, use the ingress group annotation to share one ALB. Shift one service at a time with weighted DNS or a canary.
5. Pick the right type. Use ALB for HTTP and HTTPS routing, NLB for TCP or UDP, static IPs, PrivateLink or very high throughput. Replace Classic Load Balancers where the feature set allows. Use Gateway Load Balancer only for appliance chains.
6. Retire idle balancers. Remove unused listeners and certificates first, then delete the balancer after DNS TTLs expire and traffic has moved. Keep the old configuration in version control for rollback. Check for leftover target groups and security group rules.
7. Release public addresses. Release Elastic IPs with no association and public IPv4 addresses on instances that no longer need them. Move public web tiers to an ALB and private subnets. For internal services, use internal load balancers and private connectivity.
8. Add guardrails. Require an owner tag at creation with AWS Tag Policies or your deployment pipeline. Set AWS Budgets alerts for Elastic Load Balancing and public IPv4. Run a monthly report of untagged balancers and unassociated addresses.

How to check it worked

Compare the next full month in Cost Explorer against the baseline. Filter to Elastic Load Balancing and public IPv4, then group by usage type and account. Load balancer hours should fall where you deleted or merged. Public IPv4 counts should fall where you released addresses. Watch for new data processing charges if traffic moved.

Check traffic health. Route 53 health checks, target response time, HTTP 5xx counts and healthy host counts should stay in line. Test host names and certificate chains from outside the VPC. Confirm redirects and WebSocket upgrades still work where you use them.

Re-run the inventory. Count load balancers, public IPv4 addresses and unassociated Elastic IPs. Confirm every remaining balancer has an owner tag and a DNS record you can trace. If a deleted balancer reappears after a deploy, fix the infrastructure code.

Mistakes to avoid

Deleting a load balancer before DNS has moved is the common mistake. Lower the TTL, shift traffic, watch the old target group, then wait for the TTL to expire. Keep a rollback path until the new setup has run through a full traffic cycle.

Do not assume one load balancer type is always cheaper. NLB has different capacity units and cross-zone behavior. ALB cross-zone load balancing is always on, while NLB cross-zone is optional and can add data charges. Match the type to protocol and traffic, then check the bill lines.

Do not over-share a single ALB. Listener rule limits, certificate limits, security group rules and blast radius matter. A shared ALB for one product team is reasonable. One ALB for every team creates a change queue.

Do not forget addresses on NAT gateways and old bastion hosts, and do not leave idle Elastic IPs after a migration. Update the infrastructure code, or the next deploy will bring resources back. For a broader pass, the Cloud cost audit at $4,500/month covers a read-only review and a ranked savings report.

Frequently asked questions