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

How the two annotations differ in control intent

The difference is operational, not semantic. Cloud Network Security Guide is useful background here because the choice determines whether you are replacing the load balancer’s default security group or extending it with additional groups.

Use aws-load-balancer-security-groups when you want the controller to attach the exact security groups you specify and stop relying on the AWS-created default group for that load balancer. Use aws-load-balancer-extra-security-groups when you want the default group to remain in place and add more security groups alongside it.

That distinction matters because the first annotation is a replacement control, while the second is an additive control. In practice, replacement is for teams that want tighter, explicit exposure control; additive is for teams that want to preserve existing baseline behaviour and layer on additional network policy.

What changes in exposure and rule ownership

The main difference is who owns the effective rule set. With the replacement annotation, the security groups you name become the primary enforcement point for inbound and outbound traffic to the load balancer. With the extra-security-groups annotation, AWS keeps the default group and you only supplement it, which reduces the chance of accidentally stripping away behaviour the platform expects.

Amazon VPC Security Guide is the closest companion for understanding how security groups behave in layered designs, especially when a load balancer sits in front of private targets and the team needs to decide where the authoritative ingress rules live.

This difference is especially important during migration. If an application already depends on the default group for reachability, replacing it can change access paths immediately. If you only need to add a constrained path for a new client, an extra group is usually the lower-risk change because it preserves the existing baseline and narrows the blast radius of the edit.

When to choose replacement versus extension

Choose replacement when you have a deliberate security design and can define the full rule set up front. That is the cleaner option when the load balancer should expose only a known set of ports, CIDRs, or peer security groups and you do not want inherited defaults to remain part of the design.

Choose extra security groups when the default group already supports a shared pattern and you need to add another control layer without reworking the existing one. This is often the safer choice in environments where multiple teams depend on the same ingress model and you want to avoid an unintended outage from over-tightening the load balancer too early.

AWS Security Guide is a good reference point for the broader AWS control model, but the key practitioner judgement here is simpler: use replacement when you need determinism, use extra groups when you need compatibility.

Risk and Threat Considerations

Security group choice can create either unnecessary exposure or accidental lockout. Replacement concentrates control in the named groups, so a mistake can expose the load balancer too broadly or block legitimate traffic entirely. Extension lowers that operational risk, but it can also leave inherited exposure in place if teams assume the extra groups override the default.

Failure mechanism: Teams confuse additive and replacement semantics, then either preserve an overly permissive default path or remove an implicit path that production traffic still needs.

Impact: The result can be unwanted public exposure, broken ingress, or a change window that looks safe in review but behaves differently after deployment.

Practitioner Guidance

What to verify: Confirm which security groups are actually attached after reconciliation, not just which annotation is present in the manifest. The effective state is what matters, especially after Helm changes, controller upgrades, or partial rollouts.

Decision rule: If you are standardising exposure for a load balancer, prefer the replacement annotation and document the full intended rule set. If you need to preserve an existing default posture while adding a constraint or exception, use the extra-security-groups annotation instead.

Practitioner takeaway: Treat the choice as an ownership decision for the effective firewall surface, because the safest annotation is the one that matches how much of the rule set you are prepared to define and maintain.

Related resources from NHI Mgmt Group

• Guide: Load Balancer Security Guide
• Load Balancer Security
• How should security teams prevent Kubernetes load balancer annotations from exposing AWS security groups to the internet?
• What do teams get wrong about AWS load balancer security groups in Kubernetes?
• Why does using the wrong AWS load balancer annotation create a larger exposure than teams expect?