Skip to main content
emnode
Compliance Medium severity

AWS Security Hub · ELB

ELB.6: Load balancers can be deleted by accident

Written and reviewed by Emnode · Last reviewed

What does AWS Security Hub ELB.6 check?

ELB.6 fails when an Application, Gateway, or Network Load Balancer has the deletion_protection.enabled attribute set to false. With protection off, a single DeleteLoadBalancer call removes the load balancer instantly.

Why does ELB.6 matter?

A load balancer is the front door to a whole tier of services. A misfired terraform destroy, a fat-fingered console click or an over-broad IAM policy can delete it in under a second, and the Route 53 alias then points at nothing until something is rebuilt; every in-flight request fails for the duration. Deletion protection forces a deliberate two-step before the resource can go, turning an instant outage into a blocked action.

How do I fix ELB.6?

  1. Audit load balancers and check deletion_protection.enabled across the account.
  2. Set it to true with modify-load-balancer-attributes on production resources.
  3. Default the attribute on in your IaC, and back it with an SCP or Config rule so it cannot be silently turned off.
  4. Remember the flag must be cleared deliberately before a legitimate decommission.

Remediation script · bash

# Enable deletion protection on every unprotected standalone RDS instance in a region.
for id in $(aws rds describe-db-instances \
  --query 'DBInstances[?DeletionProtection==`false`].DBInstanceIdentifier' --output text); do
  aws rds modify-db-instance --db-instance-identifier "$id" \
    --deletion-protection --apply-immediately
  echo "Protected RDS instance: $id"
done

# Termination-protect every production-tagged CloudFormation stack (eyeball the list first).
aws cloudformation describe-stacks \
  --query "Stacks[?Tags[?Key=='Environment' && Value=='production']].StackName" \
  --output text | tr '\t' '\n' | while read -r stack; do
  aws cloudformation update-termination-protection \
    --stack-name "$stack" --enable-termination-protection
  echo "Protected stack: $stack"
done

# Deletion-protect a production load balancer.
aws elbv2 modify-load-balancer-attributes --load-balancer-arn "$LB_ARN" \
  --attributes Key=deletion_protection.enabled,Value=true

Full walkthrough (console steps, edge cases and verification) in the lesson Enable deletion and termination protection.

Is ELB.6 a false positive?

Ephemeral load balancers are the legitimate exception: a per-pull-request preview stack, an ephemeral test environment, or a blue/green deployment whose old fleet is meant to be torn down by automation all want deletion protection off, because the whole point is that terraform destroy or a pipeline step can delete them cleanly. With the attribute off they fail ELB.6 even though that is exactly the intended state. Rather than enabling protection (which would break the teardown automation), tag these resources and suppress the finding (set the workflow status to SUPPRESSED, or exclude the tag-scoped resources from the control) and reserve the enabled requirement for long-lived, production load balancers where an accidental delete is a real outage.

Part of the learning path Lock down access
  • ELB.1 ALB serves HTTP without redirecting to HTTPS
  • ELB.2 CLB SSL/HTTPS listeners should use ACM certs
  • ELB.3 CLB listeners should use HTTPS/TLS termination
  • ELB.4 ALB accepts malformed HTTP headers
  • ELB.5 Load balancers are not writing access logs
  • ELB.7 CLBs should have connection draining
  • ELB.8 CLB SSL listeners should use strong policy
  • ELB.9 CLBs should have cross-zone balancing
  • ELB.10 CLBs should span multiple AZs
  • ELB.12 ALB desync mitigation mode
  • ELB.13 A single-AZ load balancer is a data-plane single point of failure
  • ELB.14 CLB desync mitigation mode