Auto Scaling

No extra group configuration

Create the check in EC2, associate it with aws:autoscaling:groupName, and keep aggregation includedincluded
Default aggregation setting: the check contributes to overall application status. impaired overall status can replace Auto Scaling instances.. Auto ScalingAuto Scaling
Amazon EC2 Auto Scaling. With aggregation included, the group replaces instances whose overall application status is impaired — no extra HealthCheckType. terminates instances whose overall application statusoverall application status
Instance-level application status from included checks: ok, impaired, initializing, insufficient-data, not-applicable, or suppressed. Auto Scaling acts only on impaired. is impaired and launches replacements to desired capacity.

It does not act on individual check status. Excluded or suppressed checks do not drive replacements.

Two grace periods

Knob	Where	Role
InitializationGracePeriodSecondsInitializationGracePeriodSeconds Seconds to wait after launch before the probe evaluates (default 300, max 600). Too short causes Auto Scaling thrash.	Application status check	Wait after launch before this probe evaluates (default 300, max 600)
Health check grace period	Auto Scaling group	Wait before the group treats the instance as unhealthy

If either window is shorter than app startup, new instances get replaced in a loop. Increase both for slow JVM, container, or migration boots.

Caution

Reboots fail application status checks until the process answers again. A rolling reboot without suppressionsuppression
Pause evaluation on an instance for a duration so deploys and reboots do not look impaired. or a long enough grace period looks like an impaired fleet.

ELB health checks still matter

If the group already uses Elastic Load Balancing health checks, keep them.

• ALBALB
  Application Load Balancer — steers traffic with its own target-group health checks. Complementary to application status checks, which decide whether the instance should exist. and NLB decide who receives traffic and can probe as often as every 5 seconds.
• Application status checks decide whether the instance should still exist, including for groups without a load balancer.

Running both is complementary. Replacing ALB health checks on a public web tier is not. If ALB :443 forwards to instance :8081, the application status check uses --port 8081 (the instance), not 443 (the ALB).

Custom health checks

You can still call SetInstanceHealth for conditions this feature cannot see (TCP-only listeners, queue depth, sidecar agents). Application status checks do not replace that API.

Optional lab: watch a replacement

Requires Create VPC and EC2, a check with aggregation included, and the instance’s user data / IAM profile.

aws ec2 create-launch-template \
  --launch-template-name "$NAME" \
  --launch-template-data "{
    \"ImageId\": \"${AMI_ID}\",
    \"InstanceType\": \"t3.micro\",
    \"IamInstanceProfile\": {\"Name\": \"${NAME}-ssm\"},
    \"NetworkInterfaces\": [{
      \"DeviceIndex\": 0,
      \"SubnetId\": \"${SUBNET_ID}\",
      \"Groups\": [\"${SG_ID}\"],
      \"AssociatePublicIpAddress\": true
    }],
    \"UserData\": \"$(base64 -w0 /tmp/${NAME}-userdata.sh)\"
  }"

aws autoscaling create-auto-scaling-group \
  --auto-scaling-group-name "$NAME" \
  --launch-template LaunchTemplateName="$NAME",Version='$Latest' \
  --min-size 1 --max-size 1 --desired-capacity 1 \
  --vpc-zone-identifier "$SUBNET_ID" \
  --health-check-grace-period 90 \
  --tags "Key=asc-lab,Value=true,PropagateAtLaunch=true"

aws ec2 associate-application-status-check \
  --application-status-check-id "$ASC_ID" \
  --target-tag-associations Key=aws:autoscaling:groupName,Value="$NAME"

aws ec2 modify-application-status-check \
  --application-status-check-id "$ASC_ID" \
  --aggregation included

Wait until the ASG instance is InService, SSM is online, and overall application status is ok. Status and alarms shows Application status Check passed with aggregation Included (the group tag picked up the check; no extra Auto Scaling health-check type).

Terminate the original standalone instance if it is not in the group. Then stop /health on the ASG instance (SSM pkill as on Verify). Application status fails with ConnectionRefused. Auto Scaling then terminates that instance and launches a replacement — the console can show Check failed on Application status while system/instance already say Shutting-down.

Watch the replace:

aws autoscaling describe-scaling-activities \
  --auto-scaling-group-name "$NAME" \
  --max-records 5

You should see a terminate of the impaired instance and a launch of a new one. No extra Auto Scaling HealthCheckType is required.

The replacement starts in Initializing (system, instance, and application) until init grace and the first successes finish. That is expected, not a failed replace.

After two successes, Application status is Check passed again on the new instance.

Delete the group and launch template in Teardown.