Skip to main content
MEDIUMAuto ScalingReliability

AutoScaling Group Not Using ELB Health Checks

autoscaling-group-no-elb-healthcheck

What this rule checks

Detects AWS::AutoScaling::AutoScalingGroup resources attached to a load balancer (LoadBalancerNames or TargetGroupARNs) but using EC2 health checks. EC2 health checks miss app-level outages the load balancer would otherwise detect.

How to fix it

  1. 1Set HealthCheckType to ELB on the AutoScalingGroup
  2. 2Set HealthCheckGracePeriod to give instances time to bootstrap before the LB starts probing
  3. 3Verify the ALB / NLB target group has appropriate health-check thresholds
FlaggedThe ASG is attached to a load balancer target group but its HealthCheckType defaults to EC2. EC2 health checks only catch instance-level failures and miss application-level outages the load balancer would otherwise detect.
import { App, Stack } from 'aws-cdk-lib';
import { Construct } from 'constructs';
import * as asg from 'aws-cdk-lib/aws-autoscaling';

// FLAGGED: ASG behind a target group but using EC2 health checks.
new asg.CfnAutoScalingGroup(this, 'Asg', {
  minSize: '1',
  maxSize: '3',
  availabilityZones: ['us-east-1a'],
  targetGroupArns: ['arn:aws:elasticloadbalancing:us-east-1:123456789012:targetgroup/app/abc'],
  launchConfigurationName: 'app-launch-config',
});
FixedSetting HealthCheckType to ELB lets the load balancer's health checks drive instance replacement, so unhealthy-but-running instances are recycled. The grace period gives new instances time to bootstrap before probing begins.
import { App, Stack } from 'aws-cdk-lib';
import { Construct } from 'constructs';
import * as asg from 'aws-cdk-lib/aws-autoscaling';

// FIXED: ASG uses ELB health checks with a grace period.
new asg.CfnAutoScalingGroup(this, 'Asg', {
  minSize: '1',
  maxSize: '3',
  availabilityZones: ['us-east-1a'],
  targetGroupArns: ['arn:aws:elasticloadbalancing:us-east-1:123456789012:targetgroup/app/abc'],
  launchConfigurationName: 'app-launch-config',
  healthCheckType: 'ELB',
  healthCheckGracePeriod: 120,
});

CDK Insights pinpoints the exact file and line in your CDK source for every finding, so you can jump straight to the fix.

Affected resource types

AWS::AutoScaling::AutoScalingGroup

AWS documentation

Read the AWS guidance

Intentional? Suppress this finding

Sometimes a flag is deliberate โ€” a genuinely public endpoint, say. You can dismiss autoscaling-group-no-elb-healthcheck and the reason is kept in the report, not silently hidden.

In .cdk-insights.json:

{
  "ignoreRules": [
    { "id": "autoscaling-group-no-elb-healthcheck", "reason": "Why this is intentional" }
  ]
}

Or inline in your CDK code:

Validations.of(scope).acknowledge({
  id: 'cdk-insights::autoscaling-group-no-elb-healthcheck',
  reason: 'Why this is intentional',
});

Use the rule ID autoscaling-group-no-elb-healthcheck shown above โ€” not the CDK-* ID from SARIF / GitHub code scanning. To dismiss every finding on one construct instead, use ignorePaths. Suppression docs โ†’

Catch this in your stack

$ npx cdk-insights scan

CDK Insights runs this and 118+ other rules locally against your synthesised CDK app โ€” free, no account, your code never leaves your machine.

More Auto Scaling rules