A load balancing service that distributes incoming traffic across multiple backend targets. In cloud and network operations, an ELB presents a single front end, health checks targets, and forwards requests to instances, containers, or IPs to spread load and improve availability.
What an elastic load balancer does in practice
An elastic load balancer is the traffic distribution layer in front of a pool of backend targets. It gives clients a single front door, then routes requests across instances, containers, or IP addresses so no single target becomes the bottleneck or availability point of failure.
That simple function matters because the load balancer is usually where availability, health checking, and request steering converge. In cloud environments, it often sits on the critical path for every inbound request, so its configuration has direct operational and security consequences, not just performance consequences.
Health checks, routing logic, and failover behavior
ELB health checks are what let the service decide whether a target should keep receiving traffic. When a target fails health checks, the balancer can stop sending it new requests, which improves resilience, but only if the health check actually reflects the application path that matters to users.
Routing behavior also shapes how failures are experienced. A target can be technically alive while still serving broken dependencies, stale sessions, or partial errors. In those cases, the balancer may continue to treat it as healthy unless the check is designed to detect the real failure mode.
That is why load balancers are not just network plumbing. They are an active control plane for service availability, and their health criteria, timeout behavior, and target group design influence whether outages stay local or spread across an application tier.
Where ELB fits in cloud architectures
ELB is commonly used as the stable entry point for public web applications, internal service tiers, and horizontally scaled platforms. It absorbs churn in the backend fleet, which lets operators add or remove targets without changing the client-facing endpoint.
It also sits alongside other edge controls such as TLS termination, header handling, and logging. In well-managed environments, the load balancer is one of the first places where operators can enforce a consistent transport profile and observe request patterns before they reach backend workloads.
For teams running modern cloud estates, the load balancer becomes part of the service boundary itself. Its placement, listener rules, and target registrations affect how traffic is segmented, how quickly failures are isolated, and how much visibility the platform retains at the edge.
Security implications of exposing a shared front end
An ELB concentrates trust, availability, and often session handling into one externally reachable service. If it is misconfigured, attackers may be able to exploit weak TLS settings, exposed management paths, or unsafe forwarding behavior to reach backends that would otherwise remain harder to access.
It can also become a monitoring blind spot if teams assume the balancer is “just infrastructure” and do not review access patterns, target health anomalies, or header manipulation issues. The shared front end makes consistency easier, but it also means a single control point can amplify the impact of poor configuration.
Risk and Threat Considerations
Because an elastic load balancer sits at the entrance to an application tier, misconfiguration can turn it into both an availability risk and an attack path. The main danger is not the balancing function itself, but the trust placed in the front end, especially when TLS, health checks, listener rules, or forwarding behavior are weaker than the workloads behind it.
Failure mechanism: If the balancer accepts unsafe traffic, forwards malformed requests, or continues routing to degraded targets, it can expose backend systems, hide partial failures, or let attackers abuse a broadly trusted entry point.
Impact: The result can be service interruption, traffic interception, error amplification, or unintended access to internal application components that were meant to be shielded by the front door.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, NIST CSF 2.0 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SC-8 — Transmission Confidentiality and Integrity | ELB fronts network traffic and often terminates or forwards TLS, so transport protection is central. |
| SI-4 — System Monitoring | ELB logs, health checks, and traffic anomalies support detection at the service entry point. | |
| Recommendation — Enforce protected transit for listener and backend connections. Monitor load balancer traffic and health signals for anomalous routing or abuse. | ||
| NIST CSF 2.0 | PR.AA-05 — Network integrity is protected | An ELB is the edge trust boundary that shapes how inbound traffic is accepted and forwarded. |
| Recommendation — Use network integrity controls to limit and inspect traffic entering through the load balancer. | ||
| CIS Controls v8 | 12 — Network Infrastructure Management | Load balancers are managed network infrastructure whose configuration and exposure need tight control. |
| Recommendation — Harden and inventory load balancer configuration, access, and change management. | ||
| ISO/IEC 27001:2022 | A.8.20 — Network security | ELB is a network-facing control that must be configured to protect service boundaries and traffic flows. |
| Recommendation — Apply network security controls to the load balancer and its routed paths. | ||
Practitioner Guidance
Why practitioners should care: Treat the load balancer as a security-relevant control, not only an availability component. Its listeners, TLS policy, health checks, logging, and backend trust relationships directly shape both resilience and exposure.
What to watch for: Review whether the health check path truly represents application readiness, whether the frontend policy matches current transport requirements, and whether backend targets are isolated from direct public access. If the balancer is carrying session or header-sensitive traffic, verify that its request handling matches the application’s assumptions.
Practitioner takeaway: The most reliable ELB design is one where routing, health, and exposure are intentionally engineered together, rather than inherited from a default deployment.
Related resources from NHI Mgmt Group
- Guide: Elastic Security Guide
- How should security teams handle an Elastic Load Balancer that has no inbound rules in its security group?
- What happens when an Elastic Load Balancer is deployed without any inbound rules?
- Elastic Load Balancer Security Group
- How should security teams prevent Kubernetes load balancer annotations from exposing AWS security groups to the internet?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on November 3, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org