📝 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
• Located in: 📁 AWS Auto Scaling

Flags

• 🟢 Policy with categories
• 🟢 Policy with type
• 🟢 Production policy

Our Metadata

• Policy Type: COMPLIANCE_POLICY
• Policy Category:
  • RELIABILITY

Similar Policies

• Internal
  • dec-x-71d45f32

Similar Internal Rules

Rule	Policies	Flags
✉️ dec-x-71d45f32	1

Logic

• 🧠 prod.logic.yaml 🟢
  • 📕 AWS EC2 Auto Scaling Group
  • 🔌 AWS EC2 Auto Scaling Group Tfc.Src.Link - object.extracts.yaml
  • 🔌 AWS EC2 Auto Scaling Group - object.extracts.yaml
  • 🧪 test-data.json

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

2. (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

Section	Sub Sections	Internal Rules	Policies	Flags
💼 AWS Foundational Security Best Practices v1.0.0 → 💼 [AutoScaling.1] Auto Scaling groups associated with a load balancer should use ELB health checks		1	1
💼 Cloudaware Framework → 💼 System Configuration			25
💼 FedRAMP High Security Controls → 💼 CA-7 Continuous Monitoring (L)(M)(H)	2		8
💼 FedRAMP High Security Controls → 💼 CP-2(2) Capacity Planning (H)			1
💼 FedRAMP High Security Controls → 💼 SI-2 Flaw Remediation (L)(M)(H)	2	7	9
💼 FedRAMP Low Security Controls → 💼 CA-7 Continuous Monitoring (L)(M)(H)	1		8
💼 FedRAMP Low Security Controls → 💼 SI-2 Flaw Remediation (L)(M)(H)			9
💼 FedRAMP Moderate Security Controls → 💼 CA-7 Continuous Monitoring (L)(M)(H)	2		8
💼 FedRAMP Moderate Security Controls → 💼 SI-2 Flaw Remediation (L)(M)(H)	2		9
💼 NIST CSF v2.0 → 💼 DE.AE-02: Potentially adverse events are analyzed to better understand associated activities			26
💼 NIST CSF v2.0 → 💼 DE.AE-03: Information is correlated from multiple sources			26
💼 NIST CSF v2.0 → 💼 DE.CM-01: Networks and network services are monitored to find potentially adverse events			83
💼 NIST CSF v2.0 → 💼 DE.CM-02: The physical environment is monitored to find potentially adverse events			8
💼 NIST CSF v2.0 → 💼 DE.CM-03: Personnel activity and technology usage are monitored to find potentially adverse events			59
💼 NIST CSF v2.0 → 💼 DE.CM-06: External service provider activities and services are monitored to find potentially adverse events			27
💼 NIST CSF v2.0 → 💼 DE.CM-09: Computing hardware and software, runtime environments, and their data are monitored to find potentially adverse events			89
💼 NIST CSF v2.0 → 💼 ID.IM-01: Improvements are identified from evaluations			10
💼 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 parties			23
💼 NIST CSF v2.0 → 💼 ID.IM-03: Improvements are identified from execution of operational processes, procedures, and activities			24
💼 NIST CSF v2.0 → 💼 ID.RA-01: Vulnerabilities in assets are identified, validated, and recorded			22
💼 NIST CSF v2.0 → 💼 ID.RA-07: Changes and exceptions are managed, assessed for risk impact, recorded, and tracked			24
💼 NIST SP 800-53 Revision 5 → 💼 CA-7 Continuous Monitoring	6		8
💼 NIST SP 800-53 Revision 5 → 💼 CP-2(2) Contingency Plan _ Capacity Planning			1
💼 NIST SP 800-53 Revision 5 → 💼 SI-2 Flaw Remediation	6	5	6
💼 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.	5	3	6
💼 PCI DSS v4.0.1 → 💼 2.2.1 Configuration standards are developed, implemented, and maintained.			2
💼 PCI DSS v4.0 → 💼 2.2.1 Configuration standards are developed, implemented, and maintained.			2