Elastic Load Balancer with Only One EC2 Instance

In this configuration, the ELB adds complexity and cost without improving availability, scalability, or fault tolerance. This setup is often the result of premature scaling design or misunderstood architecture patterns. If there's no plan to horizontally scale the application, the ELB can often be removed entirely without user impact.

All ELB types are billed for each hour or partial hour the load balancer runs. Application, Network, and Gateway Load Balancers add a capacity-unit charge (LCU, NLCU, or GLCU) based on dimensions such as new and active connections and bytes processed, while Classic Load Balancers add a per-GB data processing charge. The hourly charge applies regardless of the number of targets or the actual volume of traffic being handled. Running an ELB with only a single EC2 instance incurs fixed costs without delivering the intended benefits of load distribution or redundancy.

• Identify load balancers with only one healthy or active EC2 instance registered
• Check ELB metadata and target group configurations to validate instance count
• Review deployment patterns to determine whether the architecture expects scaling but hasn't implemented it
• Assess whether the ELB is used for static routing or simply passing traffic to a single backend

• If no scaling is planned or needed, first confirm the load balancer is not providing TLS termination with ACM certificates, AWS WAF, user authentication, or health-check based replacement through an Auto Scaling group; only then remove the ELB and route traffic directly to the EC2 instance using an Elastic IP or DNS entry
• If future scaling is expected, consider retaining the ELB but update documentation and monitoring to ensure it doesn't remain in this state long-term
• Document architectural decisions around ELB usage to prevent future misconfigurations

Elastic Load Balancing Pricing