Auto Scaling with ELB integration in AWS - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Architecture

intermediate

How does an Auto Scaling group interact with an Elastic Load Balancer?

When you attach an Auto Scaling group to an Elastic Load Balancer (ELB), what happens to the instances launched by the Auto Scaling group?

A The instances must be manually registered with the ELB after launch to receive traffic.

B The instances are automatically registered with the ELB and receive traffic based on health checks.

C The ELB only routes traffic to instances outside the Auto Scaling group.

D The Auto Scaling group disables ELB health checks and uses its own only.

💡 Hint

Think about how ELB and Auto Scaling work together to distribute traffic.

When an Auto Scaling group is attached to an ELB, instances launched by the group are automatically registered with the ELB. The ELB then routes traffic only to healthy instances based on health checks.

❓ service_behavior

intermediate

What happens when an instance fails ELB health checks in an Auto Scaling group?

If an instance in an Auto Scaling group attached to an ELB fails the ELB health checks, what is the expected behavior?

A The instance remains running but is removed from the ELB's routing until healthy again.

B The Auto Scaling group disables the ELB health checks and relies on EC2 status checks.

C The ELB ignores the health check failure and continues routing traffic to the instance.

D The instance is immediately terminated and replaced by the Auto Scaling group.

💡 Hint

Consider how ELB and Auto Scaling handle instance health separately.

When an instance fails ELB health checks, the ELB stops sending traffic to it but the instance remains running. The Auto Scaling group may terminate it only if EC2 health checks fail or scaling policies trigger.

❓ security

advanced

Which security group configuration allows Auto Scaling instances to register with an ELB?

You have an Auto Scaling group and an ELB in the same VPC. Which security group rule is required to allow the ELB to send traffic to the instances?

A Allow inbound traffic on all ports from the instances' security group in the ELB's security group.

B Allow inbound traffic on the ELB listener port from 0.0.0.0/0 in the instances' security group.

C Allow outbound traffic on all ports from the instances' security group to 0.0.0.0/0.

D Allow inbound traffic on the ELB listener port from the ELB's security group in the instances' security group.

💡 Hint

Think about how security groups reference each other for traffic control.

The instances' security group must allow inbound traffic on the ELB listener port from the ELB's security group. This allows the ELB to send traffic securely to instances.

❓ Configuration

advanced

What is the effect of setting ELB health check grace period in Auto Scaling?

In an Auto Scaling group attached to an ELB, what does setting a health check grace period do?

A It forces immediate termination of instances failing ELB health checks during the grace period.

B It disables ELB health checks permanently for all instances in the group.

C It delays the start of ELB health checks on new instances to allow them to initialize.

D It sets the timeout for ELB health checks to wait for a response from instances.

💡 Hint

Consider why new instances might need time before health checks start.

The health check grace period delays ELB health checks on new instances to give them time to start up and become healthy before being evaluated.

✅ Best Practice

expert

How to ensure zero downtime during Auto Scaling group updates with ELB?

You want to update the launch configuration of an Auto Scaling group attached to an ELB without causing downtime. Which approach ensures zero downtime?

A Create a new Auto Scaling group with the updated launch configuration and gradually shift traffic using ELB target group deregistration delay.

B Update the launch configuration and immediately terminate all instances to force replacement.

C Detach the ELB from the Auto Scaling group during update and reattach after all instances are replaced.

D Manually deregister instances from the ELB before terminating them to avoid traffic loss.

💡 Hint

Think about how to replace instances gradually without dropping traffic.

Creating a new Auto Scaling group with the updated launch configuration and shifting traffic gradually using ELB's deregistration delay allows zero downtime updates.

Practice

1. What is the main purpose of integrating an Auto Scaling group with an Elastic Load Balancer (ELB)?

easy

A. To distribute incoming traffic evenly across all running instances

B. To store data persistently across instances

C. To create backups of instances automatically

D. To monitor the health of the database

Solution

1. Step 1: Understand Auto Scaling and ELB roles

   Auto Scaling adjusts the number of servers based on demand. ELB distributes user traffic across these servers.

2. Step 2: Identify integration benefit

   Linking Auto Scaling with ELB ensures traffic is balanced only to healthy, running instances, improving availability.

3. Final Answer:

   To distribute incoming traffic evenly across all running instances -> Option A

4. Quick Check:

   Auto Scaling + ELB = balanced traffic [OK]

Hint: ELB balances traffic; Auto Scaling adjusts servers [OK]

Common Mistakes:

• Confusing ELB with storage or backup services
• Thinking Auto Scaling manages data persistence
• Assuming ELB monitors databases

2. Which of the following is the correct way to attach an Auto Scaling group to an ELB target group in AWS CLI?

easy

A. aws elb attach-instances --group-name my-asg --target-group-arn arn:aws:elasticloadbalancing:region:123456789012:targetgroup/my-target-group/abcdef123456

B. aws elb create-auto-scaling-group --name my-asg --target-group my-target-group

C. aws autoscaling create-target-group --name my-target-group --auto-scaling-group my-asg

D. aws autoscaling attach-load-balancer-target-groups --auto-scaling-group-name my-asg --target-group-arns arn:aws:elasticloadbalancing:region:123456789012:targetgroup/my-target-group/abcdef123456

Solution

1. Step 1: Identify correct AWS CLI command

   The command to attach an Auto Scaling group to an ELB target group is 'aws autoscaling attach-load-balancer-target-groups'.

2. Step 2: Verify command parameters

   It requires the Auto Scaling group name and the target group ARN, matching aws autoscaling attach-load-balancer-target-groups --auto-scaling-group-name my-asg --target-group-arns arn:aws:elasticloadbalancing:region:123456789012:targetgroup/my-target-group/abcdef123456.

3. Final Answer:

   aws autoscaling attach-load-balancer-target-groups --auto-scaling-group-name my-asg --target-group-arns arn:aws:elasticloadbalancing:region:123456789012:targetgroup/my-target-group/abcdef123456 -> Option D

4. Quick Check:

   Attach ASG to ELB target group uses attach-load-balancer-target-groups [OK]

Hint: Use 'attach-load-balancer-target-groups' with ASG name and target group ARN [OK]

Common Mistakes:

• Using ELB commands instead of Auto Scaling commands
• Confusing target group ARN with target group name
• Trying to create target groups via Auto Scaling CLI

3. Given this AWS Auto Scaling group configuration snippet:

{
  "AutoScalingGroupName": "web-asg",
  "TargetGroupARNs": ["arn:aws:elasticloadbalancing:region:123456789012:targetgroup/web-tg/abc123"],
  "MinSize": 2,
  "MaxSize": 4,
  "DesiredCapacity": 3
}

What happens when one instance fails health checks in the ELB target group?

medium

A. Auto Scaling terminates the unhealthy instance and launches a new one to maintain desired capacity

B. ELB stops sending traffic but Auto Scaling does not replace the instance

C. Auto Scaling increases MaxSize to 5 automatically

D. Nothing happens until manual intervention

Solution

1. Step 1: Understand health check integration

   When an instance fails ELB health checks, Auto Scaling detects it as unhealthy.

2. Step 2: Auto Scaling response

   Auto Scaling terminates the unhealthy instance and launches a new one to keep the desired capacity at 3.

3. Final Answer:

   Auto Scaling terminates the unhealthy instance and launches a new one to maintain desired capacity -> Option A

4. Quick Check:

   Unhealthy instance triggers replacement by Auto Scaling [OK]

Hint: Auto Scaling replaces unhealthy instances to keep desired capacity [OK]

Common Mistakes:

• Thinking ELB alone replaces instances
• Assuming MaxSize changes automatically
• Believing manual steps are needed

4. You configured an Auto Scaling group with an ELB target group, but new instances are not receiving traffic. What is the most likely cause?

medium

A. The ELB is in a different AWS region than the Auto Scaling group

B. The Auto Scaling group has MinSize set to zero

C. The instances are not registered with the ELB target group

D. The instances do not have public IP addresses

Solution

1. Step 1: Check ELB and Auto Scaling integration

   If instances are not registered with the ELB target group, ELB cannot send traffic to them.

2. Step 2: Evaluate other options

   MinSize zero means no instances; region mismatch prevents communication; public IP not required for ELB internal routing.

3. Final Answer:

   The instances are not registered with the ELB target group -> Option C

4. Quick Check:

   Instances must be registered with ELB target group to get traffic [OK]

Hint: Check instance registration in ELB target group first [OK]

Common Mistakes:

• Assuming public IP is required for ELB traffic
• Ignoring instance registration status
• Confusing region mismatch with availability zone issues

5. You want to ensure your Auto Scaling group scales out only when the average CPU usage across all instances exceeds 70%, and also that new instances are healthy in the ELB before receiving traffic. Which combination of settings achieves this?

hard

A. Configure scaling policy on network traffic, and skip ELB health checks

B. Create a scaling policy based on CPU > 70%, enable ELB health checks with grace period

C. Use ELB health checks only, no CPU-based scaling policy

D. Set MinSize to 0, MaxSize to 10, and disable ELB health checks

Solution

1. Step 1: Define scaling trigger

   Scaling based on average CPU > 70% ensures scale out matches demand.

2. Step 2: Ensure instance health before traffic

   Enabling ELB health checks with a grace period lets new instances become healthy before receiving traffic.

3. Step 3: Combine both for smooth scaling

   This combination prevents traffic to unhealthy instances and scales only when needed.

4. Final Answer:

   Create a scaling policy based on CPU > 70%, enable ELB health checks with grace period -> Option B

5. Quick Check:

   CPU scaling + ELB health checks = safe, demand-based scaling [OK]

Hint: Combine CPU scaling policy with ELB health checks and grace period [OK]

Common Mistakes:

• Disabling ELB health checks causing traffic to unhealthy instances
• Using wrong metric like network traffic for CPU-based scaling
• Not setting grace period causing premature traffic routing