Unconsolidated Application Load Balancers per Service

In practice many organizations give every microservice, environment or team its own ALB. On Amazon EKS the AWS Load Balancer Controller creates a separate ALB for each Ingress unless Ingresses are grouped, which AWS notes can result in more load balancers than necessary and recommends sharing ALBs across Ingresses to reduce costs. ECS services and infrastructure-as-code modules often follow the same one-service-one-ALB pattern.

Every ALB carries its own hourly charge for as long as it exists, plus LCU charges, and each internet-facing ALB also consumes public IPv4 addresses that are billed separately. For low-traffic services the fixed hourly charge dominates, so dozens of lightly used ALBs cost much more than a few shared ones handling the same requests.

ALB-hour

Each Application Load Balancer is billed for every hour or partial hour it runs; AWS lists $0.0225 per ALB-hour in US East (N. Virginia)

LCU-hour

Billed on the highest of new connections, active connections, processed bytes and rule evaluations; the first 10 processed rules per request are free

Public IPv4 addresses

Internet-facing load balancers incur standard public IPv4 address charges for every address they consume

• Inventory ALBs per account, Region and VPC and compare their counts with the number of distinct applications; many ALBs with low RequestCount and ConsumedLCUs in CloudWatch are consolidation candidates
• Flag ALBs with a single listener rule or a single target group, which typically front one small service
• In EKS clusters, list Ingresses with ingressClassName alb (or the legacy class annotation) that lack the alb.ingress.kubernetes.io/group.name annotation; each of these gets its own ALB
• In ECS, list services that each reference a target group on a different ALB even though they share a domain, VPC and security posture
• Count public IPv4 addresses attributed to load balancers in the VPC IP Address Manager or Cost and Usage Report to see the address charges each additional internet-facing ALB adds

• Consolidate compatible low-traffic services onto shared ALBs using host-header and path-pattern listener rules, one target group per service
• In EKS, add the same alb.ingress.kubernetes.io/group.name annotation to Ingresses that should share an ALB and use group.order to control rule precedence; only do this when everyone with permission to create or modify Ingresses is within the same trust boundary, because any member can add or override rules on the shared ALB
• Stay within ALB quotas when consolidating, such as 100 rules per ALB (adjustable), 100 target groups per ALB and 25 certificates per ALB (adjustable), and account for rule-evaluation LCUs when a shared ALB has many rules
• Keep separate ALBs where isolation genuinely matters, such as different security or WAF policies, compliance boundaries, blast-radius limits, or internal versus internet-facing exposure
• Delete the redundant ALBs and their listeners after DNS and target traffic have moved to the shared load balancers

• Elastic Load Balancing pricingaws.amazon.com
• Condition types for listener rulesdocs.aws.amazon.com
• Quotas for your Application Load Balancersdocs.aws.amazon.com
• A deeper look at Ingress Sharing and Target Group Binding in AWS Load Balancer Controlleraws.amazon.com
• Ingress annotations - AWS Load Balancer Controllerkubernetes-sigs.github.io