Skip to main content

⭐ Repository → 📁 Compliance Engine → 📁 CloudAware → 📁 AWS → 📁 Auto Scaling

🛡️ AWS EC2 Auto Scaling Group behind ELB doesn't use ELB health check🟢

  • Contextual name: 🛡️ Auto Scaling Group behind ELB doesn't use ELB health check🟢
  • ID: /ce/ca/aws/autoscaling/group-with-elb-without-elb-health-check
  • Tags:
  • Policy Type: COMPLIANCE_POLICY
  • Policy Categories: RELIABILITY

Logic​

Similar Policies​

  • Internal: dec-x-71d45f32

Similar Internal Rules​

RulePoliciesFlags
✉️ dec-x-71d45f321

Description​

Open File

Description​

Ensure that AWS EC2 Auto Scaling Groups (ASGs) associated with Elastic Load Balancers (ELBs) are configured to use ELB health checks rather than the default EC2 health checks.

Rationale​

ELB health checks provide a more accurate and application-aware mechanism for determining instance health compared to standard EC2 status checks. By integrating directly with the load balancer, ELB health checks reflect the actual ability of instances to serve traffic. This enables Auto Scaling Groups to make more informed scaling and replacement decisions, leading to faster recovery from failures and improved application availability.

Configuring ASGs to use ELB health checks ensures that scaling decisions are based on the same health criteria used by the load balancer itself, promoting more consistent and reliable traffic distribution.

Impact​

May introduce additional configuration and management overhead compared to the default EC2 health check type.

Audit​

This policy flags an AWS EC2 Auto Scaling Group as INCOMPLIANT if:

... see more

Remediation​

Open File

Remediation​

From Command Line​

By default, Amazon EC2 Auto Scaling relies on EC2 status checks to determine instance health.

  1. To configure the ASG to use ELB health checks to ensure that instances failing load balancer health criteria are automatically replaced use update-auto-scaling-group command:
aws autoscaling update-auto-scaling-group \
--auto-scaling-group-name {{auto-scaling-group-name}} \
--health-check-type ELB
  1. (Optional but recommended) Configure a health check grace period (in seconds) to allow instances sufficient time to initialize before being evaluated by health checks:
aws autoscaling update-auto-scaling-group \
  --auto-scaling-group-name {{auto-scaling-group-name}} \
  --health-check-grace-period 300

policy.yaml​

Open File

Linked Framework Sections​

SectionSub SectionsInternal RulesPoliciesFlagsCompliance
💼 AWS Foundational Security Best Practices v1.0.0 → 💼 [AutoScaling.1] Auto Scaling groups associated with a load balancer should use ELB health checks11no data
💼 Cloudaware Framework → 💼 System Configuration35no data
💼 FedRAMP High Security Controls → 💼 CA-7 Continuous Monitoring (L)(M)(H)210no data
💼 FedRAMP High Security Controls → 💼 CP-2(2) Capacity Planning (H)2no data
💼 FedRAMP High Security Controls → 💼 SI-2 Flaw Remediation (L)(M)(H)2710no data
💼 FedRAMP Low Security Controls → 💼 CA-7 Continuous Monitoring (L)(M)(H)110no data
💼 FedRAMP Low Security Controls → 💼 SI-2 Flaw Remediation (L)(M)(H)10no data
💼 FedRAMP Moderate Security Controls → 💼 CA-7 Continuous Monitoring (L)(M)(H)210no data
💼 FedRAMP Moderate Security Controls → 💼 SI-2 Flaw Remediation (L)(M)(H)210no data
💼 NIST CSF v2.0 → 💼 DE.AE-02: Potentially adverse events are analyzed to better understand associated activities31no data
💼 NIST CSF v2.0 → 💼 DE.AE-03: Information is correlated from multiple sources46no data
💼 NIST CSF v2.0 → 💼 DE.CM-01: Networks and network services are monitored to find potentially adverse events118no data
💼 NIST CSF v2.0 → 💼 DE.CM-02: The physical environment is monitored to find potentially adverse events10no data
💼 NIST CSF v2.0 → 💼 DE.CM-03: Personnel activity and technology usage are monitored to find potentially adverse events81no data
💼 NIST CSF v2.0 → 💼 DE.CM-06: External service provider activities and services are monitored to find potentially adverse events31no data
💼 NIST CSF v2.0 → 💼 DE.CM-09: Computing hardware and software, runtime environments, and their data are monitored to find potentially adverse events137no data
💼 NIST CSF v2.0 → 💼 ID.IM-01: Improvements are identified from evaluations21no data
💼 NIST CSF v2.0 → 💼 ID.IM-02: Improvements are identified from security tests and exercises, including those done in coordination with suppliers and relevant third parties34no data
💼 NIST CSF v2.0 → 💼 ID.IM-03: Improvements are identified from execution of operational processes, procedures, and activities35no data
💼 NIST CSF v2.0 → 💼 ID.RA-01: Vulnerabilities in assets are identified, validated, and recorded27no data
💼 NIST CSF v2.0 → 💼 ID.RA-07: Changes and exceptions are managed, assessed for risk impact, recorded, and tracked28no data
💼 NIST SP 800-53 Revision 5 → 💼 CA-7 Continuous Monitoring610no data
💼 NIST SP 800-53 Revision 5 → 💼 CP-2(2) Contingency Plan _ Capacity Planning2no data
💼 NIST SP 800-53 Revision 5 → 💼 SI-2 Flaw Remediation667no data
💼 PCI DSS v3.2.1 → 💼 2.2 Develop configuration standards for all system components. Assure that these standards address all known security vulnerabilities and are consistent with industry-accepted system hardening standards.5330no data
💼 PCI DSS v4.0.1 → 💼 2.2.1 Configuration standards are developed, implemented, and maintained.11no data
💼 PCI DSS v4.0 → 💼 2.2.1 Configuration standards are developed, implemented, and maintained.11no data