Skip to main content

🛡️ AWS ELB Load Balancer is not registered to multiple Availability Zones🟢

  • Contextual name: 🛡️ Load Balancer is not registered to multiple Availability Zones🟢
  • ID: /ce/ca/aws/elb/load-balancer-multiple-az
  • Tags:
  • Policy Type: COMPLIANCE_POLICY
  • Policy Categories: RELIABILITY

Logic​

Similar Policies​

Description​

Open File

Description​

This policy identifies AWS ELB Load Balancers (Classic, Application, Network, Gateway) that are not configured to distribute traffic across multiple Availability Zones.

Rationale​

Configuring a load balancer to span multiple Availability Zones enhances availability and fault tolerance. When a load balancer node is deployed in only one Availability Zone, it becomes a single point of failure. If that AZ experiences an outage, both the load balancer node and the associated application may become unavailable.

Impact​

A load balancer restricted to a single Availability Zone poses a significant risk of service interruption. Any outage in that zone can result in complete application downtime, potentially affecting user experience and business continuity.

Audit​

This policy flags an AWS ELB Load Balancer as INCOMPLIANT if its Availability Zones field includes only one AZ.

Remediation​

Open File

Remediation​

The Load Balancer should be configured to use subnets in at least two different Availability Zones.

Configure Subnets​

From Command Line​
For Application, Network and Gateway Load Balancers​
aws elbv2 set-subnets \
    --load-balancer-arn {{load-balancer-arn}} \
    --subnets {{subnet-id1}} {{subnet-id2}}
For a Classic Load Balancer​
aws elb attach-load-balancer-to-subnets \
    --load-balancer-name {{load-balancer-name}} \
    --subnets {{subnet-id1}} {{subnet-id2}}

policy.yaml​

Open File

Linked Framework Sections​

SectionSub SectionsInternal RulesPoliciesFlagsCompliance
💼 AWS Foundational Security Best Practices v1.0.0 → 💼 [ELB.10] Classic Load Balancer should span multiple Availability Zones1no data
💼 AWS Foundational Security Best Practices v1.0.0 → 💼 [ELB.13] Application, Network and Gateway Load Balancers should span multiple Availability Zones1no data
💼 AWS Well-Architected → 💼 PERF04-BP04 Use load balancing to distribute traffic across multiple resources3no data
💼 AWS Well-Architected → 💼 REL13-BP05 Automate recovery2no data
💼 Cloudaware Framework → 💼 System Configuration38no data
💼 FedRAMP High Security Controls → 💼 CP-6(2) Recovery Time and Recovery Point Objectives (H)7no data
💼 FedRAMP High Security Controls → 💼 CP-10 System Recovery and Reconstitution (L)(M)(H)28no data
💼 FedRAMP Low Security Controls → 💼 CP-10 System Recovery and Reconstitution (L)(M)(H)8no data
💼 FedRAMP Moderate Security Controls → 💼 CP-10 System Recovery and Reconstitution (L)(M)(H)18no data
💼 NIST CSF v2.0 → 💼 PR.IR-03: Mechanisms are implemented to achieve resilience requirements in normal and adverse situations14no data
💼 NIST CSF v2.0 → 💼 RC.RP-01: The recovery portion of the incident response plan is executed once initiated from the incident response process8no data
💼 NIST CSF v2.0 → 💼 RC.RP-02: Recovery actions are selected, scoped, prioritized, and performed8no data
💼 NIST CSF v2.0 → 💼 RC.RP-05: The integrity of restored assets is verified, systems and services are restored, and normal operating status is confirmed8no data
💼 NIST SP 800-53 Revision 5 → 💼 CP-6(2) Alternate Storage Site _ Recovery Time and Recovery Point Objectives7no data
💼 NIST SP 800-53 Revision 5 → 💼 CP-10 System Recovery and Reconstitution68no data
💼 NIST SP 800-53 Revision 5 → 💼 SC-5(2) Denial-of-service Protection _ Capacity, Bandwidth, and Redundancy7no data
💼 NIST SP 800-53 Revision 5 → 💼 SC-36 Distributed Processing and Storage25no data
💼 NIST SP 800-53 Revision 5 → 💼 SI-13(5) Predictable Failure Prevention _ Failover Capability7no data