What is the difference between aws-load-balancer-security-groups and aws-load-balancer-extra-security-groups?

The first annotation sets the load balancer’s security groups and replaces the default group created by AWS. The second annotation adds additional security groups alongside the default one. That means the first is used when you want explicit control over exposure, while the second is used when you want to keep the default rule set and layer on more controls.

Why These Two Annotations Behave Differently

The distinction matters because Kubernetes and AWS load balancer controllers treat the security boundary differently depending on whether you are replacing the default security group or layering another one on top. If you want a precise exposure profile, you need to understand whether the annotation is defining the full set of groups or only extending an existing set. That affects how inbound traffic is filtered, how change control is reviewed, and how easily teams can reason about who is allowed to reach the service.

For teams that manage internet-facing services, the difference also affects operational ownership: one setting can remove the controller-created baseline and make the manifest the source of truth, while the other preserves the baseline and adds policy depth. The OWASP Non-Human Identity Top 10 is relevant here only insofar as controller-managed access paths and automation tokens can become part of the trust chain, but the primary issue is still load balancer exposure and security group composition. In practice, many teams only notice the difference after a service becomes unreachable or more exposed than intended, rather than during the initial deployment review.

How the Two Settings Change Real Load Balancer Exposure

aws-load-balancer-security-groups is the more forceful option: it tells the controller which security groups should be attached to the load balancer and, in doing so, replaces the automatically created group that would otherwise be used. That makes it useful when the organisation wants the AWS-side network policy to be fully explicit and managed outside the default controller behaviour. It also means the team must ensure the chosen groups still allow all required client, health check, and backend paths. If they do not, the load balancer can be deployed successfully but still fail to pass traffic.

aws-load-balancer-extra-security-groups is additive. It keeps the default controller-managed group and attaches extra groups alongside it. The practical advantage is that you preserve the baseline controller behaviour while adding narrower rules, shared policy groups, or environment-specific restrictions. That can reduce the risk of breaking service availability during change, but it can also create confusion if teams assume the extra groups are the only active controls. The effective exposure is the union of all attached groups, not just the custom one.

A useful way to think about the difference is:

Use the first annotation when you want the manifest to define the complete load balancer group set.
Use the second annotation when you want to preserve the default group and add supplementary controls.
Review both inbound client access and health check paths, because a restrictive rule set can block one while allowing the other.
Check for governance drift if multiple teams can modify attached groups outside the application deployment process.

The guidance breaks down when organisations treat security groups as interchangeable policy wrappers and do not validate which paths are actually required by the service.

When the Choice Gets Tricky in Production

Tighter network control often improves exposure management, but it also increases the chance of accidental outage, so teams have to balance precision against operational simplicity. That trade-off becomes most visible in shared clusters, platform-managed ingress, and environments where several teams contribute rules to the same load balancer.

There is also a governance difference. If the default group is preserved, you need to know who owns the baseline rules and who is allowed to append more groups. If the default group is replaced, you need stronger review discipline because the manifest now carries the whole exposure decision. Different teams may prefer different patterns, and there is no universal consensus that one is always safer; the right choice depends on whether your main concern is explicit least privilege or resilience during change.

Edge cases usually involve inherited rules, shared services, or legacy dependencies. A group that looks “extra” may still carry broad allow rules, which means the system can be more exposed than the annotation name suggests. Conversely, replacing the default group can be safer from a policy clarity perspective, but only if the replacement set is complete and continuously reviewed. If the team cannot reliably explain which group is enforcing which path, the configuration is already too complex.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

MITRE ATT&CK address the attack and risk surface, while 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	5.3 — Account Management	Security group ownership and rule changes require clear accountability.
	4.1 — Secure Configuration of Enterprise Assets and Software	The annotations change effective network configuration for the service.
Recommendation — Restrict who can modify load balancer security groups and review changes for least privilege. Baseline and validate the active security group configuration after each deployment.
NIST CSF 2.0	PR.AC-4 — Access Permissions and Authorizations Are Managed	The setting determines which network access paths are authorised for the load balancer.
	CM-2 — Baseline Configuration	Choosing replace versus add changes the baseline exposure model.
Recommendation — Manage the attached security groups so only intended network paths remain authorised. Define and maintain the approved security group baseline for each load balancer.
MITRE ATT&CK	T1190 — Exploit Public-Facing Application	Overly permissive load balancer rules can expose services to external attack paths.
Recommendation — Hunt for exposed services and remove unnecessary public access paths from the load balancer.

Practitioner Guidance

What to verify: Confirm which security groups are actually attached to the load balancer after reconciliation, not just which annotation appears in the manifest. The meaningful question is whether the active group set matches the intended exposure model and still permits health checks.

Common mistake: Assuming “extra” means “additional restrictions only.” In practice, the effective policy is the combined behaviour of every attached security group, so a permissive inherited rule can quietly override the intent of the added one.

Decision rule: If the service needs a fully declared network boundary, prefer the replacement-style setting and manage the complete group set deliberately. If the service depends on the controller’s default behaviour for stability, use the additive setting and treat the inherited group as part of the control surface.

Practitioner takeaway: The right choice is less about naming and more about control ownership, because the safer configuration is the one your team can explain, reconcile, and audit without guessing which security group is carrying the real exposure.