Security groups attached to an AWS load balancer that control what traffic can reach it. In Kubernetes managed environments, the annotation chosen determines whether AWS keeps its default allow rules or replaces them with a more restrictive set, which directly affects internet exposure.
Expanded Definition
AWS Load Balancer security groups are the network access controls that decide which source addresses and ports may reach a load balancer before any application-level logic is involved. In practice, they shape the public or private exposure of the entry point itself, not the workload behind it. In AWS-managed Kubernetes environments, the chosen annotation can either preserve AWS default allow behaviour or replace it with a tighter security group pattern, which changes the load balancer’s reachable surface.
The boundary that is often missed is that these security groups do not authorise application users or API calls. They govern transport reachability. That means they should be read as a perimeter control, even when the application is strongly authenticated after the connection is established. For readers comparing adjacent controls, this is closer to infrastructure access filtering than to IAM, and it is distinct from backend instance security groups that protect targets after traffic is forwarded.
Where the term is discussed in machine-identity-heavy environments, the governance question is usually about whether the load balancer is intentionally internet-facing or only meant to serve trusted networks. The OWASP Non-Human Identity Top 10 is useful here only as a governance lens for the downstream machine-access consequences, not as the primary definition of the control itself.
Examples and Use Cases
Practitioners encounter AWS Load Balancer security groups in several common patterns:
- A public application load balancer is restricted to 443 from approved source ranges so the service is reachable without leaving the listener open to all traffic.
- An internal load balancer is limited to a VPC CIDR or peered network range, which keeps it off the public internet while still supporting private service-to-service access.
- A Kubernetes ingress controller applies an annotation that directs AWS to manage the security groups more tightly, reducing the chance that a default allow rule survives deployment.
- A migration from permissive testing to production uses distinct security groups so that the same load balancer pattern can be reused without inheriting the wrong exposure profile.
The practical tradeoff is simple: tighter rules improve exposure control, but they also make change management more sensitive. If source ranges, health check paths, or shared ingress assumptions are not maintained carefully, the load balancer can appear healthy while legitimate clients or cluster components lose reachability.
Security Implications
When AWS Load Balancer security groups are mismanaged, the failure is usually overexposure rather than silent compromise. A broad allow rule can make an internal service reachable from networks that were never intended to connect, while an overly narrow rule can break availability by blocking legitimate traffic, including health checks and approved client paths.
Because these groups sit at the entry layer, a mistake here can enlarge the blast radius before higher-layer controls ever get a chance to act. The operational symptom is often deceptively normal infrastructure status with the wrong audience able to connect, or with expected traffic being dropped at the edge. In environments that route through Kubernetes, the annotation choice becomes a control-plane decision as much as a network one, because it determines whether the platform leaves permissive defaults in place or forces a more explicit rule set.
The main practitioner observation is that exposure problems often start with convenience settings that were acceptable in development but were never revisited for production. That is especially important where multiple services share load balancer patterns, because one permissive configuration can be copied faster than it is reviewed.
Domain and Governance Relevance
From a cloud security perspective, this term matters because it defines the first enforceable trust boundary for inbound traffic to a load balancer. It is a governance control as much as a technical one: teams must decide whether the load balancer is meant to be public, private, or tightly segmented, and then keep that decision aligned with the deployment model.
In AWS and Kubernetes operations, the control also influences service ownership. A platform team may own the load balancer pattern, while application teams own the intended exposure. If those responsibilities are not explicit, security group drift can occur when annotations, templates, or defaults are changed without a review of the resulting reachability.
For NHIMG’s identity and machine-access lens, the relevant point is not that this is an identity control, but that it strongly conditions whether automated clients, agents, service accounts, or external integrations can even reach the trust boundary. That makes it a useful upstream safeguard in environments where non-human access is common, because a mistaken exposure decision can create access paths that no downstream authentication policy was designed to handle.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | 6 — Access Control Management | Security groups directly govern network access paths to the load balancer. |
| 4 — Secure Configuration of Enterprise Assets and Software | Annotation-driven defaults can leave overly permissive exposure in place. | |
| 12 — Network Infrastructure Management | This term concerns ingress segmentation and boundary filtering in cloud networking. | |
| Recommendation — Restrict inbound rules to approved sources and ports for each load balancer exposure pattern. Standardize secure load balancer baselines so permissive defaults are not carried into production. Track load balancer security group changes as part of network infrastructure governance. | ||
| NIST CSF 2.0 | PR.AC-3 — Remote Access is Managed | Load balancer security groups mediate who can reach remote-facing entry points. |
| PR.PT-4 — Communications and Control Networks are Protected | These controls protect network communications at the ingress boundary. | |
| Recommendation — Manage external reachability explicitly and review source-range changes before deployment. Apply network boundary protections to limit which traffic can reach the load balancer. | ||
