Auto Scaling & ELB

• Auto Scaling & ELB
  • makes it easy to route traffic across a dynamically changing fleet of EC2 instances
  • acts as a single point of contact for all incoming traffic to the instances in an Auto Scaling group.
• Auto Scaling dynamically adds and removes EC2 instances, while Elastic Load Balancing manages incoming requests by optimally routing traffic so that no one instance is overwhelmed
• Auto Scaling helps to automatically increase the number of EC2 instances when the user demand goes up, and decrease the number of EC2 instances when demand goes down
• ELB service helps to distribute the incoming web traffic (called the load) automatically among all the running EC2 instances
• ELB uses load balancers to monitor traffic and handle requests that come through the Internet.
• Using ELB & Auto Scaling
  • makes it easy to route traffic across a dynamically changing fleet of EC2 instances
  • load balancer acts as a single point of contact for all incoming traffic to the instances in an Auto Scaling group.
• Elastic Load Balancing provides four types of load balancers:
  • Application Load Balancer (ALB) – Routes at the application layer (HTTP/HTTPS), supports path-based and host-based routing, and uses target groups.
  • Network Load Balancer (NLB) – Routes at the transport layer (TCP/UDP/TLS), handles millions of requests per second with ultra-low latency, and uses a static IP per AZ.
  • Gateway Load Balancer (GWLB) – Distributes traffic to third-party virtual appliances (firewalls, IDS/IPS) using the GENEVE protocol.
  • Classic Load Balancer (CLB) – Previous generation; AWS recommends migrating to ALB or NLB.

Attaching/Detaching ELB with Auto Scaling Group

• Auto Scaling integrates with Elastic Load Balancing and enables attaching one or more load balancers to an existing Auto Scaling group.
• With Application Load Balancers, Network Load Balancers, and Gateway Load Balancers, instances are registered as targets with a target group, and the target group is attached to the Auto Scaling group.
• With Classic Load Balancers, instances are registered directly with the load balancer.
• ELB registers the EC2 instance using its IP address and routes requests to the primary IP address of the primary interface (eth0) of the instance.
• After the ELB is attached, it automatically registers the instances in the group and distributes incoming traffic across the instances
• When ELB is detached, it enters the Removing state while deregistering the instances in the group.
• If connection draining (deregistration delay) is enabled, ELB waits for in-flight requests to complete before deregistering the instances.
• Instances remain running after they are deregistered from the ELB
• Auto Scaling adds instances to the ELB as they are launched, but this can be suspended. Instances launched during the suspension period are not added to the load balancer, after the resumption, and must be registered manually.

Launch Templates (Replaces Launch Configurations)

• Launch Configurations are deprecated. As of October 1, 2024, new AWS accounts cannot create launch configurations using any method (console, API, CLI, or CloudFormation).
• Launch Templates are the recommended replacement and support all new EC2 features including:
  • Multiple instance types and purchase options (mixed instances policy)
  • Attribute-based instance type selection
  • Versioning – create multiple versions and set a default
  • T2/T3 Unlimited mode configuration
  • Dedicated Hosts placement
• As of January 1, 2023, new instance types added to AWS Regions are not supported in launch configurations.
• Existing launch configurations continue to work for existing accounts, but no new features will be added.

High Availability & Redundancy

• Auto Scaling can span across multiple AZs, within the same region.
• When one AZ becomes unhealthy or unavailable, Auto Scaling launches new instances in an unaffected AZ.
• When the unhealthy AZ recovers, Auto Scaling redistributes the traffic across all the healthy AZ.
• Elastic Load balancer can be set up to distribute incoming requests across EC2 instances in a single AZ or multiple AZs within a region.
• Using Auto Scaling & ELB by spanning Auto Scaling groups across multiple AZs within a region and then setting up ELB to distribute incoming traffic across those AZs helps take advantage of the safety and reliability of geographic redundancy.
• Incoming traffic is load balanced equally across all the AZs enabled for ELB.

Zonal Shift & Zonal Autoshift (New – 2024)

• EC2 Auto Scaling now supports Amazon Application Recovery Controller (ARC) zonal shift to rapidly recover from AZ impairments.
• Zonal shift allows you to manually shift traffic and instances away from an impaired AZ.
• Zonal autoshift automatically shifts traffic away from an AZ when AWS detects potential issues – no operator intervention needed.
• When a zonal shift is active, Auto Scaling suspends AZ rebalancing for the shifted zone to prevent launching instances back into the impaired AZ.
• Works with both ALB and NLB, with or without cross-zone load balancing enabled.

Health Checks

• Auto Scaling group determines the health state of each instance by periodically checking the results of EC2 instance status checks.
• Auto Scaling marks the instance as unhealthy and replaces the instance if the instance fails the EC2 instance status check.
• ELB also performs health checks on the EC2 instances that are registered with it for e.g. the application is available by pinging a health check page
• ELB health check with the instances should be used to ensure that traffic is routed only to the healthy instances.
• Auto Scaling, by default, does not replace the instance, if the ELB health check fails.
• After a load balancer is registered with an Auto Scaling group, it can be configured to use the results of the ELB health check in addition to the EC2 instance status checks to determine the health of the EC2 instances in the Auto Scaling group.
• Health check grace period allows newly launched instances time to warm up before health checks begin evaluating them.

Instance Refresh

• Instance Refresh allows rolling updates of instances in an Auto Scaling group when a launch template is updated (e.g., new AMI).
• Supports minimum healthy percentage to control how many instances remain in service during updates.
• Supports checkpoints and rollback for safe deployments.
• ReplaceRootVolume strategy (Nov 2025): Updates the root volume of an instance without stopping or terminating it, preserving network interfaces, non-root EBS volumes, and instance store data.
• Instance refresh only replaces instances where the AMI IDs don’t match, allowing it to skip already-updated instances.

Instance Maintenance Policy

• Controls how Auto Scaling replaces instances during health check failures, Spot interruptions, or instance refresh operations.
• Three options:
  • Launch before terminating – Provisions new instance before terminating the old one (favors availability over cost).
  • Terminate and launch – Terminates existing instance and launches new one simultaneously (favors cost over availability).
  • Custom policy – Set a custom min/max range for capacity during replacements.
• Without an instance maintenance policy, Auto Scaling uses default replacement behaviors.

Warm Pools

• Warm pools maintain pre-initialized EC2 instances ready for rapid scale-out, reducing application startup latency.
• Instances in the warm pool can be in Stopped (lower cost, longer transition) or Running (higher cost, faster transition) state.
• When demand increases, instances transition from the warm pool to the Auto Scaling group without repeating the full cold-start sequence.
• Useful for applications with long boot times due to complex initialization or software dependencies.
• As of April 2026, also supported with Amazon EKS managed node groups.

Predictive Scaling

• Uses machine learning to predict future traffic patterns and proactively provision capacity ahead of demand.
• Learns from past patterns and launches instances in advance, giving them time to warm up.
• Enhances existing scaling policies (Target Tracking, Simple Scaling) by adding forecast-based scaling.
• Expanded to additional AWS regions in October 2025.
• Also available for Amazon ECS services (Nov 2024).

Monitoring

• Elastic Load Balancing sends data about the load balancers and EC2 instances to CloudWatch. CloudWatch collects data about the performance of your resources and presents it as metrics.
• After registering one or more load balancers with the Auto Scaling group, the Auto Scaling group can be configured to use ELB metrics (such as request latency or request count) to scale the application automatically.
• For ALB, the ALBRequestCountPerTarget metric is commonly used for target tracking scaling policies.

AWS Certification Exam Practice Questions

• Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
• AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
• AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
• Open to further feedback, discussion and correction.

1. A company is building a two-tier web application to serve dynamic transaction-based content. The data tier is leveraging an Online Transactional Processing (OLTP) database. What services should you leverage to enable an elastic and scalable web tier?
   1. Elastic Load Balancing, Amazon EC2, and Auto Scaling
   2. Elastic Load Balancing, Amazon RDS with Multi-AZ, and Amazon S3
   3. Amazon RDS with Multi-AZ and Auto Scaling
   4. Amazon EC2, Amazon DynamoDB, and Amazon S3
2. You have been given a scope to deploy some AWS infrastructure for a large organization. The requirements are that you will have a lot of EC2 instances but may need to add more when the average utilization of your Amazon EC2 fleet is high and conversely remove them when CPU utilization is low. Which AWS services would be best to use to accomplish this?
   1. Amazon CloudFront, Amazon CloudWatch and Elastic Load Balancing
   2. Auto Scaling, Amazon CloudWatch and AWS CloudTrail
   3. Auto Scaling, Amazon CloudWatch and Elastic Load Balancing
   4. Auto Scaling, Amazon CloudWatch and AWS Elastic Beanstalk
3. A user has configured ELB with Auto Scaling. The user suspended the Auto Scaling AddToLoadBalancer, which adds instances to the load balancer. process for a while. What will happen to the instances launched during the suspension period?
   1. The instances will not be registered with ELB and the user has to manually register when the process is resumed
   2. The instances will be registered with ELB only once the process has resumed
   3. Auto Scaling will not launch the instance during this period due to process suspension
   4. It is not possible to suspend only the AddToLoadBalancer process
4. You have an Auto Scaling group associated with an Elastic Load Balancer (ELB). You have noticed that instances launched via the Auto Scaling group are being marked unhealthy due to an ELB health check, but these unhealthy instances are not being terminated. What do you need to do to ensure trial instances marked unhealthy by the ELB will be terminated and replaced?
   1. Change the thresholds set on the Auto Scaling group health check
   2. Add an Elastic Load Balancing health check to your Auto Scaling group
   3. Increase the value for the Health check interval set on the Elastic Load Balancer
   4. Change the health check set on the Elastic Load Balancer to use TCP rather than HTTP checks
5. You are responsible for a web application that consists of an Elastic Load Balancing (ELB) load balancer in front of an Auto Scaling group of Amazon Elastic Compute Cloud (EC2) instances. For a recent deployment of a new version of the application, a new Amazon Machine Image (AMI) was created, and the Auto Scaling group was updated with a new launch configuration that refers to this new AMI. During the deployment, you received complaints from users that the website was responding with errors. All instances passed the ELB health checks. What should you do in order to avoid errors for future deployments? (Choose 2 answers) [PROFESSIONAL]
   1. Add an Elastic Load Balancing health check to the Auto Scaling group. Set a short period for the health checks to operate as soon as possible in order to prevent premature registration of the instance to the load balancer.
   2. Enable EC2 instance CloudWatch alerts to change the launch configuration’s AMI to the previous one. Gradually terminate instances that are using the new AMI.
   3. Set the Elastic Load Balancing health check configuration to target a part of the application that fully tests application health and returns an error if the tests fail.
   4. Create a new launch configuration that refers to the new AMI, and associate it with the group. Double the size of the group, wait for the new instances to become healthy, and reduce back to the original size. If new instances do not become healthy, associate the previous launch configuration.
   5. Increase the Elastic Load Balancing Unhealthy Threshold to a higher value to prevent an unhealthy instance from going into service behind the load balancer.

   Note: For modern deployments, use Instance Refresh with checkpoints and rollback capabilities instead of manually doubling group size. Launch Templates should be used instead of Launch Configurations.

6. What is the order of most-to-least rapidly-scaling (fastest to scale first)? A) EC2 + ELB + Auto Scaling B) Lambda C) RDS
   1. B, A, C (Lambda is designed to scale instantly. EC2 + ELB + Auto Scaling require single-digit minutes to scale out. RDS will take at least 15 minutes, and will apply OS patches or any other updates when applied.)
   2. C, B, A
   3. C, A, B
   4. A, C, B
7. A user has hosted an application on EC2 instances. The EC2 instances are configured with ELB and Auto Scaling. The application server session time out is 2 hours. The user wants to configure connection draining to ensure that all in-flight requests are supported by ELB even though the instance is being deregistered. What time out period should the user specify for connection draining?
   1. 5 minutes
   2. 1 hour (max allowed is 3600 secs that is close to 2 hours to keep the in flight requests alive)
   3. 30 minutes
   4. 2 hours
8. A company runs a web application using an Auto Scaling group behind an Application Load Balancer. They are experiencing slow instance boot times (5+ minutes) and want to reduce latency during scale-out events without over-provisioning. What feature should they use?
   1. Increase the desired capacity of the Auto Scaling group
   2. Use Predictive Scaling to forecast demand
   3. Configure a warm pool with pre-initialized instances
   4. Enable cross-zone load balancing
9. An organization needs to update the AMI for all instances in their Auto Scaling group with minimal disruption. They want to ensure instances are replaced in a rolling fashion. What is the recommended approach?
   1. Manually terminate instances one by one
   2. Create a new Auto Scaling group and swap the ELB attachment
   3. Update the launch template and start an instance refresh
   4. Use the UpdateAutoScalingGroup API to change the AMI directly
10. An e-commerce company experiences predictable traffic spikes every day at 9 AM. They want Auto Scaling to proactively launch instances before the spike arrives. Which scaling approach should they use?
    1. Target tracking scaling policy
    2. Simple scaling policy with CloudWatch alarms
    3. Scheduled scaling actions
    4. Predictive scaling policy (Predictive scaling uses ML to learn patterns and proactively scale before predicted demand, ideal for recurring traffic patterns. While scheduled scaling could work, predictive scaling adapts automatically to changing patterns.)

References

• AWS Auto Scaling with ELB
• Auto Scaling Warm Pools
• Instance Refresh
• Auto Scaling Zonal Shift
• Instance Maintenance Policy
• Migrate to Launch Templates