ALB Security


1. Important Points#

ALB security is a layered design. ALB itself handles TLS termination, listener rules, SG boundary, logging and WAF attachment. GuardDuty is not an ALB plugin; it is threat detection that can trigger investigation or response around workloads behind ALB.

ALB security layers:
    TLS listener policy
    security group
    listener rules
    ALB Auth, when needed
    AWS WAF web ACL
    Shield / Shield Advanced for DDoS posture
    access logs
    CloudTrail for config changes
    GuardDuty for threat findings around accounts/workloads

Good default:

public ALB:
    allow 443 from internet
    redirect 80 to 443
    WAF associated
    access logs enabled
    modern TLS policy
    target SG only allows ALB SG
    no direct target public access

2. Security Group#

ALB security group:

inbound:
    443 from 0.0.0.0/0 and ::/0 for public service
    80 from 0.0.0.0/0 only if redirect to 443 is required

outbound:
    target port to target security group

Target security group:

inbound:
    app port from ALB security group only

outbound:
    required downstream only where possible

Example target SG rule:

aws ec2 authorize-security-group-ingress \
  --group-id sg-target \
  --protocol tcp \
  --port 8080 \
  --source-group sg-alb \
  --region ap-east-1

3. TLS#

listener:
    use HTTPS listener
    use ACM certificate
    use modern TLS policy
    redirect HTTP to HTTPS

target:
    HTTP from ALB to target is common inside private VPC
    HTTPS to target when compliance or zero-trust requirement exists
    validate target cert lifecycle if HTTPS target is used

Set TLS policy:

aws elbv2 modify-listener \
  --listener-arn arn:aws:elasticloadbalancing:ap-east-1:111122223333:listener/app/prod-public-alb/abc123/listener123 \
  --ssl-policy ELBSecurityPolicy-TLS13-1-2-2021-06 \
  --certificates CertificateArn=arn:aws:acm:ap-east-1:111122223333:certificate/example \
  --region ap-east-1

4. WAF#

WAF is the normal L7 security control for public ALB.

use WAF for:
    managed rule groups
    IP reputation
    SQLi / XSS protection
    rate limiting
    geo match
    bot / scanner reduction
    emergency IP block

do not expect WAF to:
    fix vulnerable app code
    replace authentication
    replace authorization
    understand all business abuse

Baseline web ACL:

managed rule groups:
    AWSManagedRulesCommonRuleSet
    AWSManagedRulesKnownBadInputsRuleSet
    AWSManagedRulesAmazonIpReputationList

custom rules:
    rate limit by IP
    block known bad IPSet
    allowlist internal admin source IPs when needed

logging:
    WAF logs to CloudWatch Logs / S3 / Firehose
    redact sensitive headers and cookies

Associate WAF web ACL with ALB:

aws wafv2 associate-web-acl \
  --web-acl-arn arn:aws:wafv2:ap-east-1:111122223333:regional/webacl/prod-public-alb-web-acl/example \
  --resource-arn arn:aws:elasticloadbalancing:ap-east-1:111122223333:loadbalancer/app/prod-public-alb/abc123 \
  --region ap-east-1

Verify:

aws wafv2 get-web-acl-for-resource \
  --resource-arn arn:aws:elasticloadbalancing:ap-east-1:111122223333:loadbalancer/app/prod-public-alb/abc123 \
  --region ap-east-1

5. WAF Rate Limit#

Rate-based rule example:

{
  "Name": "RateLimitByIP",
  "Priority": 10,
  "Statement": {
    "RateBasedStatement": {
      "Limit": 2000,
      "AggregateKeyType": "IP"
    }
  },
  "Action": {
    "Block": {}
  },
  "VisibilityConfig": {
    "SampledRequestsEnabled": true,
    "CloudWatchMetricsEnabled": true,
    "MetricName": "RateLimitByIP"
  }
}

Tuning:

start with Count:
    observe sampled requests
    understand false positives
    then switch to Block

set limit by endpoint:
    public API may need higher threshold
    admin path should be lower
    login path may need bot-specific protection

6. WAF Logging#

Enable WAF logging for investigation:

aws wafv2 put-logging-configuration \
  --logging-configuration '{
    "ResourceArn": "arn:aws:wafv2:ap-east-1:111122223333:regional/webacl/prod-public-alb-web-acl/example",
    "LogDestinationConfigs": [
      "arn:aws:logs:ap-east-1:111122223333:log-group:aws-waf-logs-prod-public-alb"
    ],
    "RedactedFields": [
      {"SingleHeader": {"Name": "authorization"}},
      {"SingleHeader": {"Name": "cookie"}}
    ]
  }' \
  --region ap-east-1

Operational query ideas:

investigate:
    top blocked IP
    top blocked URI
    top terminating rule
    country distribution
    user-agent distribution
    correlation with ALB 4xx / 5xx

7. GuardDuty Relationship#

GuardDuty does not attach to ALB like WAF. Use it as detection and response input.

GuardDuty can help with:
    suspicious EC2 behavior behind ALB
    compromised IAM credential activity
    reconnaissance and brute force findings
    malware / runtime / EKS findings when enabled
    suspicious source IP enrichment for investigation

GuardDuty does not directly do:
    ALB request blocking
    path-based WAF rule evaluation
    ALB listener protection

Practical integration pattern:

GuardDuty finding
    -> EventBridge rule
        -> Lambda / Step Functions
            -> decide if source IP should be blocked
            -> update WAF IPSet
            -> notify security channel
            -> open incident ticket

EventBridge pattern:

{
  "source": ["aws.guardduty"],
  "detail-type": ["GuardDuty Finding"],
  "detail": {
    "severity": [4, 5, 6, 7, 8]
  }
}

Response IAM policy fragment for updating a WAF IPSet:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "UpdateWafIpSet",
      "Effect": "Allow",
      "Action": [
        "wafv2:GetIPSet",
        "wafv2:UpdateIPSet"
      ],
      "Resource": "arn:aws:wafv2:ap-east-1:111122223333:regional/ipset/prod-blocked-ipset/example"
    }
  ]
}

Important guardrail:

do not blindly block every GuardDuty IP:
    findings can contain shared infrastructure IPs
    NAT / proxy / CDN source can affect many users
    add expiry to emergency blocks
    record reason and finding id
    prefer manual approval for medium severity

8. Shield#

Shield Standard:
    automatic L3/L4 DDoS protection for AWS services

Shield Advanced:
    paid service
    better DDoS visibility and response support
    useful for high-risk public applications
    commonly paired with CloudFront / Route 53 / ALB / WAF

When to consider Shield Advanced:

use when:
    business-critical public endpoint
    frequent DDoS risk
    public brand / gaming / fintech / high-risk workload
    need DDoS Response Team support

9. Security Monitoring#

Signal Source Response
WAF blocked spike AWS/WAFV2 metric inspect WAF logs
WAF allowed spike AWS/WAFV2 metric possible attack not blocked
ALB 4xx spike ALB metric/logs check path/user-agent/source
ALB 5xx spike ALB metric/logs check app and target health
GuardDuty high severity GuardDuty/EventBridge incident workflow
ALB config change CloudTrail verify authorized change
TLS policy changed CloudTrail/Config rollback if weaker

CloudTrail event names to watch:

elasticloadbalancing:
    CreateLoadBalancer
    DeleteLoadBalancer
    CreateListener
    ModifyListener
    CreateRule
    ModifyRule
    DeleteRule
    ModifyLoadBalancerAttributes

wafv2:
    AssociateWebACL
    DisassociateWebACL
    UpdateWebACL
    UpdateIPSet

10. Production Checklist#

network:
    ALB SG inbound is minimal
    target SG only allows ALB SG
    targets are not directly public

tls:
    HTTPS listener uses modern TLS policy
    HTTP redirects to HTTPS
    ACM certificate expiry monitored

waf:
    web ACL associated
    managed rules enabled
    rate limit rule tested
    WAF logs enabled
    false positive process exists

guardduty:
    GuardDuty enabled organization-wide
    high severity finding routes to incident workflow
    optional WAF IPSet automation has expiry and approval

logs:
    ALB access logs enabled
    WAF logs enabled
    CloudTrail captures ELB/WAF config changes
    Athena queries or SIEM parser ready
Backward ALB Auth