Auto Scaling

AWS Auto Scaling Policies – Target, Step & Simple

~ Last updated on : ~ jayendrapatil

AWS Auto Scaling Policies

Maintain a Steady Count of Instances

  • Auto Scaling ensures a steady minimum (or desired if specified) count of Instances will always be running.
  • If an instance is found unhealthy, Auto Scaling will terminate the Instance and launch a new one.
  • ASG determines the health state of each instance by periodically checking the results of EC2 instance status checks.
  • ASG can be associated with an Elastic load balancer enabled to use the Elastic Load Balancing health check, Auto Scaling determines the health status of the instances by checking the results of both EC2 instance status and Elastic Load Balancing instance health.
  • Auto Scaling marks an instance unhealthy and launches a replacement if
    • the instance is in a state other than running,
    • the system status is impaired, or
    • Elastic Load Balancing reports the instance state as OutOfService.
  • After an instance has been marked unhealthy as a result of an EC2 or ELB health check, it is almost immediately scheduled for replacement. It never automatically recovers its health.
  • For an unhealthy instance, the instance’s health check can be changed back to healthy manually but you will encounter an error if the instance is already terminating.
  • Because the interval between marking an instance unhealthy and its actual termination is so small, attempting to set an instance’s health status back to healthy is probably useful only for a suspended group.
  • When the instance is terminated, any associated Elastic IP addresses are disassociated and are not automatically associated with the new instance.
  • Elastic IP addresses must be associated with the new instance manually.
  • Similarly, when the instance is terminated, its attached EBS volumes are detached and must be attached to the new instance manually.

Manual Scaling

  • Manual scaling can be performed by
    • Changing the desired capacity limit of the ASG
    • Attaching/Detaching instances to the ASG
  • Attaching/Detaching an EC2 instance can be done only if
    • Instance is in the running state.
    • AMI used to launch the instance must still exist.
    • Instance is not a member of another ASG.
    • Instance is in the same Availability Zone as the ASG.
    • If the ASG is associated with a load balancer, the instance and the load balancer must both be in the same VPC.
  • Auto Scaling increases the desired capacity of the group by the number of instances being attached. But if the number of instances being attached plus the desired capacity exceeds the maximum size, the request fails.
  • When Detaching instances, an option to decrement the desired capacity for the ASG by the number of instances being detached is provided. If chosen not to decrement the capacity, Auto Scaling launches new instances to replace the ones that you detached.
  • If an instance is detached from an ASG that is also registered with a load balancer, the instance is deregistered from the load balancer. If connection draining is enabled for the load balancer, Auto Scaling waits for the in-flight requests to complete.

Synchronous Instance Launch API (New – Dec 2025)

  • EC2 Auto Scaling now offers a LaunchInstances API that allows synchronous launching of instances inside an Auto Scaling group.
  • The API provides immediate feedback on capacity availability, returning instance IDs on success or error details on failure.
  • Allows precise control over where instances are launched by specifying an override for any Availability Zone and/or subnet in the ASG.
  • Unlike the traditional asynchronous scaling approach (where you must monitor scaling activities), this API immediately returns results.
  • Use cases include workloads that need deterministic instance placement or immediate confirmation of capacity provisioning.
  • Refer: Launching instances with synchronous provisioning

Scheduled Scaling

  • Scaling based on a schedule allows you to scale the application in response to predictable load changes for e.g. last day of the month, the last day of a financial year.
  • Scheduled scaling requires the configuration of Scheduled actions, which tells Auto Scaling to perform a scaling action at a certain time in the future, with the start time at which the scaling action should take effect, and the new minimum, maximum, and desired size of group should have.
  • Auto Scaling guarantees the order of execution for scheduled actions within the same group, but not for scheduled actions across groups.
  • Multiple Scheduled Actions can be specified but should have unique time values and they cannot have overlapping times scheduled which will lead to their rejection.
  • Cooldown periods are not supported.

Dynamic Scaling

  • Allows automatic scaling in response to the changing demand for e.g. scale-out in case CPU utilization of the instance goes above 70% and scale in when the CPU utilization goes below 30%
  • ASG uses a combination of alarms & policies to determine when the conditions for scaling are met.
    • An alarm is an object that watches over a single metric over a specified time period. When the value of the metric breaches the defined threshold, for the number of specified time periods the alarm performs one or more actions (such as sending messages to Auto Scaling).
    • A policy is a set of instructions that tells Auto Scaling how to respond to alarm messages.
  • Dynamic scaling process works as below
    1. CloudWatch monitors the specified metrics for all the instances in the Auto Scaling Group.
    2. Changes are reflected in the metrics as the demand grows or shrinks
    3. When the change in the metrics breaches the threshold of the CloudWatch alarm, the CloudWatch alarm performs an action. Depending on the breach, the action is a message sent to either the scale-in policy or the scale-out policy
    4. After the Auto Scaling policy receives the message, Auto Scaling performs the scaling activity for the ASG.
    5. This process continues until you delete either the scaling policies or the ASG.
  • When a scaling policy is executed, if the capacity calculation produces a number outside of the minimum and maximum size range of the group, EC2 Auto Scaling ensures that the new capacity never goes outside of the minimum and maximum size limits.
  • When the desired capacity reaches the maximum size limit, scaling out stops. If demand drops and capacity decreases, Auto Scaling can scale out again.

Dynamic Scaling Policy Types

Target tracking scaling

  • Increase or decrease the current capacity of the group based on a target value for a specific metric.
  • (Updated Nov 2024) Target Tracking policies now feature highly responsive scaling:
    • Self-tuning responsiveness – Target Tracking automatically adapts to the unique usage patterns of individual applications using historical usage data, determining the optimal balance between cost and performance without manual intervention.
    • Sub-minute metric support – Can be configured to monitor high-resolution CloudWatch metrics (as low as 10-second intervals) to make more timely scaling decisions.
    • Ideal for applications with volatile demand patterns such as client-serving APIs, live streaming services, ecommerce websites, or on-demand data processing.

Auto Scaling Target Tracking Scaling

Step scaling

  • Increase or decrease the current capacity of the group based on a set of scaling adjustments, known as step adjustments, that vary based on the size of the alarm breach.

Simple scaling

  • Increase or decrease the current capacity of the group based on a single scaling adjustment.
  • Note: AWS recommends not using simple scaling policies and scaling cooldowns as a best practice. Use target tracking or step scaling instead for more responsive and efficient scaling behavior.

Multiple Policies

  • ASG can have more than one scaling policy attached at any given time.
  • Each ASG would have at least two policies: one to scale the architecture out and another to scale the architecture in.
  • If an ASG has multiple policies, there is always a chance that both policies can instruct the Auto Scaling to Scale Out or Scale In at the same time.
  • When these situations occur, Auto Scaling chooses the policy that has the greatest impact i.e. provides the largest capacity for both scale out and scale in on the ASG for e.g. if two policies are triggered at the same time and Policy 1 instructs to scale out the instance by 1 while Policy 2 instructs to scale out the instances by 2, Auto Scaling will use the Policy 2 and scale out the instances by 2 as it has a greater impact.

Predictive Scaling

  • Predictive scaling can be used to increase the number of EC2 instances in the ASG in advance of daily and weekly patterns in traffic flows.
  • Predictive scaling is well suited for situations where you have:
    • Cyclical traffic, such as high use of resources during regular business hours and low use of resources during evenings and weekends
    • Recurring on-and-off workload patterns, such as batch processing, testing, or periodic data analysis
    • Applications that take a long time to initialize, causing a noticeable latency impact on application performance during scale-out events
  • Predictive scaling provides proactive scaling that can help scale faster by launching capacity in advance of forecasted load, compared to using only dynamic scaling, which is reactive in nature.
  • Predictive scaling uses machine learning to predict capacity requirements based on historical data from CloudWatch. The machine learning algorithm consumes the available historical data and calculates the capacity that best fits the historical load pattern, and then continuously learns based on new data to make future forecasts more accurate.
  • Predictive scaling supports forecast only mode so that you can evaluate the forecast before you allow predictive scaling to actively scale capacity
  • When you are ready to start scaling with predictive scaling, switch the policy from forecast only mode to forecast and scale mode.
  • (Updated Oct 2025) Predictive scaling is now available in additional AWS Regions, expanding its availability to more customers globally.

Warm Pools

  • A warm pool is a pool of pre-initialized EC2 instances that sits alongside the Auto Scaling group, ready to be quickly placed into service when needed.
  • Warm pools help decrease latency for applications that have exceptionally long boot times (e.g., instances that need to write large amounts of data to disk or perform lengthy initialization).
  • Instances in a warm pool can be in one of the following states: Stopped, Running, or Hibernated.
  • When a scale-out event occurs, instances from the warm pool are moved into the ASG, reducing launch latency significantly.
  • Lifecycle hooks can be used with warm pools to perform custom actions while instances transition between states.
  • (Updated Nov 2025) Warm pools now support Auto Scaling groups with mixed instances policies, allowing customers using multiple instance types and purchase options to benefit from pre-initialized instance pools.
  • (Updated Apr 2026) Amazon EKS managed node groups now support EC2 Auto Scaling warm pools, enabling Kubernetes workloads to benefit from faster instance readiness.
  • Refer: Warm pools for Amazon EC2 Auto Scaling

Zonal Shift and Zonal Autoshift

  • (New – Nov 2024) EC2 Auto Scaling now supports Amazon Application Recovery Controller (ARC) zonal shift and zonal autoshift.
  • Zonal shift allows you to rapidly recover from application impairments in a single Availability Zone by shifting traffic and instances away from the affected AZ.
  • Zonal autoshift enables AWS to automatically detect AZ impairments and shift traffic away from the affected zone on your behalf.
  • Can be initiated from the EC2 Auto Scaling console, Application Recovery Controller console, or via the AWS SDK.
  • When a zonal shift is active, Auto Scaling will not launch new instances in the shifted-away AZ and will launch replacement capacity in healthy AZs.
  • Refer: Auto Scaling group zonal shift

ASG Deletion Protection

  • (New – Jan 2026) EC2 Auto Scaling now provides deletion protection at the group level to safeguard against accidental ASG deletions.
  • Multiple protection levels are available:
    • No protection – Default behavior, ASG can be deleted normally.
    • Prevent force deletion – Blocks force-delete operations (ASG cannot be deleted while it still has running instances).
    • Prevent all deletion – Blocks all delete operations on the ASG.
  • A new IAM policy condition key autoscaling:ForceDelete can be used with the DeleteAutoScalingGroup action to control whether the ForceDelete parameter can be used during deletion.
  • Deletion protection can be set when creating or updating an ASG.
  • Combining the condition key with group-level protection provides layered defense against unwanted ASG termination.
  • Available in all AWS Regions and AWS GovCloud (US) Regions.
  • Refer: Configure deletion protection

Instance Lifecycle Policy

  • (New – Nov 2025) EC2 Auto Scaling introduces instance lifecycle policy to control instance retention when termination lifecycle hooks fail or timeout.
  • Customers can configure the ASG to retain instances (instead of terminating them) when lifecycle hook actions are abandoned, providing greater confidence in graceful shutdown processes.
  • Useful for workloads that require guaranteed completion of cleanup tasks before instance termination.
  • Refer: Control instance retention with instance lifecycle policies

Lambda as Lifecycle Hook Target

  • (New – Jul 2025) AWS Lambda functions can now be used as direct notification targets for EC2 Auto Scaling lifecycle hooks.
  • Previously, lifecycle hooks required EventBridge or SNS/SQS intermediaries to invoke Lambda functions.
  • This simplifies the architecture for custom actions when instances enter a wait state (during both launch and termination).
  • Common use cases include downloading logs, running configuration scripts, draining connections, or performing data backups before termination.
  • Refer: Prepare for lifecycle notifications

Instance Maintenance Policy

  • (Introduced Nov 2023) Instance maintenance policy allows you to control how Amazon EC2 Auto Scaling handles instance replacement during events such as instance refresh, health check replacements, and AZ rebalancing.
  • Available options:
    • Launch before terminating – A new instance must be provisioned first before an existing instance can be terminated (ensures availability but temporarily increases capacity).
    • Terminate and launch – An existing instance is terminated first, then a new instance is launched (reduces cost but temporarily decreases capacity).
    • Custom – Set min/max healthy percentage to control the capacity range during replacement.
  • Helps maintain application availability and performance during routine maintenance operations.
  • Refer: Instance maintenance 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 user has created a web application with Auto Scaling. The user is regularly monitoring the application and he observed that the traffic is highest on Thursday and Friday between 8 AM to 6 PM. What is the best solution to handle scaling in this case?
    1. Add a new instance manually by 8 AM Thursday and terminate the same by 6 PM Friday
    2. Schedule Auto Scaling to scale up by 8 AM Thursday and scale down after 6 PM on Friday
    3. Schedule a policy which may scale up every day at 8 AM and scales down by 6 PM
    4. Configure a batch process to add a instance by 8 AM and remove it by Friday 6 PM
  2. A customer has a website which shows all the deals available across the market. The site experiences a load of 5 large EC2 instances generally. However, a week before Thanksgiving vacation they encounter a load of almost 20 large instances. The load during that period varies over the day based on the office timings. Which of the below mentioned solutions is cost effective as well as help the website achieve better performance?
    1. Keep only 10 instances running and manually launch 10 instances every day during office hours.
    2. Setup to run 10 instances during the pre-vacation period and only scale up during the office time by launching 10 more instances using the AutoScaling schedule.
    3. During the pre-vacation period setup a scenario where the organization has 15 instances running and 5 instances to scale up and down using Auto Scaling based on the network I/O policy.
    4. During the pre-vacation period setup 20 instances to run continuously.
  3. A user has setup Auto Scaling with ELB on the EC2 instances. The user wants to configure that whenever the CPU utilization is below 10%, Auto Scaling should remove one instance. How can the user configure this?
    1. The user can get an email using SNS when the CPU utilization is less than 10%. The user can use the desired capacity of Auto Scaling to remove the instance
    2. Use CloudWatch to monitor the data and Auto Scaling to remove the instances using scheduled actions
    3. Configure CloudWatch to send a notification to Auto Scaling Launch configuration when the CPU utilization is less than 10% and configure the Auto Scaling policy to remove the instance
    4. Configure CloudWatch to send a notification to the Auto Scaling group when the CPU Utilization is less than 10% and configure the Auto Scaling policy to remove the instance
  4. A company has an application with unpredictable traffic that spikes rapidly. They are using target tracking scaling with a 60-second CloudWatch metric period. Despite scaling policies, users experience latency during sudden traffic bursts. What should they do to improve scaling responsiveness?
    1. Switch to simple scaling with a lower cooldown period
    2. Add more instances to the minimum capacity of the ASG
    3. Configure the target tracking policy to use high-resolution CloudWatch metrics with sub-minute (10-second) evaluation periods
    4. Replace target tracking with step scaling policies
  5. A company wants to protect their production Auto Scaling group from accidental deletion. The ASG runs critical workloads and must remain available at all times. What combination of features provides the strongest protection? (Select TWO)
    1. Enable instance scale-in protection on all instances
    2. Enable ASG deletion protection with “Prevent all deletion” level
    3. Set the minimum capacity to match the desired capacity
    4. Use the autoscaling:ForceDelete IAM condition key to restrict force-delete permissions
    5. Enable termination protection on individual EC2 instances
  6. An application running on an Auto Scaling group takes 10 minutes to fully initialize. The application experiences predictable daily traffic spikes at 9 AM. Which approach would minimize user-facing latency during the morning traffic increase?
    1. Use dynamic target tracking scaling with aggressive scale-out settings
    2. Use scheduled scaling to add instances at 8:50 AM daily
    3. Use predictive scaling combined with a warm pool of pre-initialized instances
    4. Increase the minimum capacity of the ASG to handle peak load
  7. A company detects degraded performance in one Availability Zone affecting their Auto Scaling group. They need to quickly shift traffic and instances away from the impaired AZ without manual intervention in the future. What should they configure?
    1. Remove the affected subnet from the ASG configuration
    2. Use a scheduled action to reduce capacity in the affected AZ
    3. Enable cross-zone load balancing on the load balancer
    4. Enable zonal autoshift with Amazon Application Recovery Controller for the ASG

📖 Related: AWS Auto Scaling with ELB – Integration Guide

References

AWS Auto Scaling Lifecycle – Hooks & Warm Pools

~ Last updated on : ~ jayendrapatil

Auto Scaling Lifecycle

  • Instances launched through the Auto Scaling group have a different lifecycle than that of other EC2 instances
  • Auto Scaling lifecycle starts when the Auto Scaling group launches an instance and puts it into service.
  • Auto Scaling lifecycle ends when the instance is terminated either by the user, or the Auto Scaling group takes it out of service and terminates it
  • AWS charges for the instances as soon as they are launched, including the time it is not in InService

Auto Scaling Lifecycle Transition

Auto Scaling Group Lifecycle

Auto Scaling Lifecycle Hooks

  • Auto Scaling Lifecycle hooks enable performing custom actions by pausing instances as an Auto Scaling group launches or terminates them
  • Each Auto Scaling group can have multiple lifecycle hooks. However, there is a limit on the number of hooks per Auto Scaling group
  • Auto Scaling scale out event flow
    • Instances start in the Pending state
    • If an autoscaling:EC2_INSTANCE_LAUNCHING lifecycle hook is added, the state is moved to Pending:Wait
    • After the lifecycle action is completed, instances enter to Pending:Proceed
    • When the instances are fully configured, they are attached to the Auto Scaling group and moved to the InService state
  • Auto Scaling scale in event flow
    • Instances are detached from the Auto Scaling group and enter the Terminating state.
    • If an autoscaling:EC2_INSTANCE_TERMINATING lifecycle hook is added, the state is moved to Terminating:Wait
    • After the lifecycle action is completed, the instances enter the Terminating:Proceed state.
    • When the instances are fully terminated, they enter the Terminated state.
  • During the scale out and scale in events, instances are put into a wait state (Pending:Wait or Terminating:Wait) and are paused until either a continue action happens or the timeout period ends.
  • By default, the instance remains in a wait state for one hour, which can be extended by restarting the timeout period by recording a heartbeat.
  • If the task finishes before the timeout period ends, the lifecycle action can be marked completed and it continues the launch or termination process.
  • After the wait period, the Auto Scaling group continues the launch or terminate process (Pending:Proceed or Terminating:Proceed)
  • Custom actions can be implemented using the following notification targets:
    • Amazon EventBridge (Recommended) – Configure an EventBridge rule to invoke a Lambda function or other targets when an instance enters a wait state. EventBridge provides more options for which services you can target and makes it easier to handle events using serverless architecture.
    • AWS Lambda (Direct notification target) – Lambda functions can be specified directly as notification targets for lifecycle hooks, enabling custom actions when an instance enters a wait state without requiring EventBridge as an intermediary.
    • Amazon SNS – Publish notifications to an SNS topic that subscribers can receive and act on.
    • Amazon SQS – Send messages to an SQS queue (standard queues only; FIFO queues are not compatible with lifecycle hooks).
    • Create a script that runs on the instance as the instance starts. The script can control the lifecycle action using the ID of the instance on which it runs.

Auto Scaling Lifecycle Hooks Considerations

  • Keeping Instances in a Wait State
    • Instances remain in a wait state for a finite period of time.
    • Default is 1 hour (3600 seconds) with the max being 48 hours or 100 times the heartbeat timeout, whichever is smaller.
    • Time can be adjusted using
      • complete-lifecycle-action (CompleteLifecycleAction) command to continue to the next state if finishes before the timeout period end
      • put-lifecycle-hook command, the –heartbeat-timeout parameter to set the heartbeat timeout for the lifecycle hook during its creation
      • Restart the timeout period by recording a heartbeat, using the record-lifecycle-action-heartbeat (RecordLifecycleActionHeartbeat) command
  • Cooldowns and Custom Actions
    • Cooldown period helps ensure that the Auto Scaling group does not launch or terminate more instances than needed
    • Cooldown period starts when the instance enters the InService state. Any suspended scaling actions resume after cooldown period expires
  • Health Check Grace Period
    • Health check grace period does not start until the lifecycle hook completes and the instance enters the InService state
  • Lifecycle Action Result
    • Result of the lifecycle hook is either ABANDON or CONTINUE
    • If the instance is launching,
      • CONTINUE indicates a successful action, and the instance can be put into service.
      • ABANDON indicates the custom actions were unsuccessful, and that the instance can be terminated.
    • If the instance is terminating,
      • ABANDON and CONTINUE allow the instance to terminate.
      • However, ABANDON stops any remaining actions from other lifecycle hooks, while CONTINUE allows them to complete
  • Spot Instances
    • Lifecycle hooks can be used with Spot Instances. However, a lifecycle hook does not prevent an instance from terminating due to a change in the Spot Price, which can happen at any time

Instance Lifecycle Policy (Nov 2025)

  • Instance lifecycle policies allow configuring instance retention when termination lifecycle hooks fail or timeout, providing greater confidence in managing instances for graceful shutdown.
  • Instance lifecycle policies work in combination with termination lifecycle hooks, not as a replacement.
  • When configured, instances move to a Terminating:Retained state if the termination lifecycle action completes with an ABANDON result, instead of being terminated immediately.
  • Use instance lifecycle policies when:
    • Graceful shutdown is mandatory and failed shutdowns require manual intervention
    • Stateful applications must complete data persistence before termination
    • Applications require extended draining periods that may exceed the maximum lifecycle hook timeout of 48 hours
    • Workloads handling sensitive data where failed cleanup could result in data loss
  • How it works:
    • Termination lifecycle hooks are invoked and instance enters Terminating:Wait state
    • Graceful shutdown attempt begins
    • If the termination lifecycle action completes with ABANDON, the instance lifecycle policy evaluates and moves the instance to a retained state
    • Retained instances await manual action – they do NOT count toward the Auto Scaling group’s desired capacity
    • Auto Scaling launches replacement instances to maintain desired capacity
    • Standard EC2 charges apply for retained instances until manually terminated
    • Use TerminateInstanceInAutoScalingGroup API to terminate retained instances after completing necessary actions

Enter and Exit Standby

  • Instance in an InService state can be moved to Standby state.
  • Standby state enables you to remove the instance from service, troubleshoot or make changes to it, and then put it back into service.
  • Instances in a Standby state continue to be managed by the Auto Scaling group. However, they are not an active part of the application until they are put back into service.

Instance Refresh and Lifecycle Hooks

  • Instance refresh is used to update instances within an Auto Scaling group when configuration changes require instance replacement.
  • Lifecycle hooks execute during instance refresh operations (both launching new and terminating old instances).
  • Forced Cancellation (Sep 2025) – Instance refreshes can now be force-cancelled immediately without waiting for in-progress instance launches or terminations to complete.
    • Set WaitForTransitioningInstances to false when calling the CancelInstanceRefresh API
    • This bypasses the wait for pending instance activities such as lifecycle hooks
    • Useful during emergency situations when needing to rapidly roll forward to a new deployment
  • Rollback – Instance refresh can be rolled back using RollbackInstanceRefresh API while still in progress, which replaces instances that were already replaced during the refresh.

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. Your application is running on EC2 in an Auto Scaling group. Bootstrapping is taking 20 minutes to complete. You find out that instances are shown as InService although the bootstrapping has not completed. How can you make sure that new instances are not added until the bootstrapping has finished. Choose the correct answer:
    1. Create a CloudWatch alarm with an SNS topic to send alarms to your DevOps engineer.
    2. Create a lifecycle hook to keep the instance in pending:wait state until the bootstrapping has finished and then put the instance in pending:proceed state.
    3. Increase the number of instances in your Auto Scaling group.
    4. Create a lifecycle hook to keep the instance in standby state until the bootstrapping has finished and then put the instance in pending:proceed state.
  2. When a scale out event occurs, the Auto Scaling group launches the required number of EC2 instances using its assigned launch configuration. What instance state do these instances start in? Choose the correct answer:
    1. pending:wait
    2. InService
    3. Pending
    4. Terminating
  3. With AWS Auto Scaling, once we apply a hook and the action is complete or the default wait state timeout runs out, the state changes to what, depending on which hook we have applied and what the instance is doing? Select two. Choose the 2 correct answers:
    1. pending:proceed
    2. pending:wait
    3. terminating:wait
    4. terminating:proceed
  4. For AWS Auto Scaling, what is the first transition state an existing instance enters after leaving steady state in Standby mode?
    1. Detaching
    2. Terminating:Wait
    3. Pending (You can put any instance that is in an InService state into a Standby state. This enables you to remove the instance from service, troubleshoot or make changes to it, and then put it back into service. Instances in a Standby state continue to be managed by the Auto Scaling group. However, they are not an active part of your application until you put them back into service. Refer link)
    4. EnteringStandby
  5. For AWS Auto Scaling, what is the first transition state an instance enters after leaving steady state when scaling in due to health check failure or decreased load?
    1. Terminating (When Auto Scaling responds to a scale in event, it terminates one or more instances. These instances are detached from the Auto Scaling group and enter the Terminating state. Refer link)
    2. Detaching
    3. Terminating:Wait
    4. EnteringStandby
  6. A company runs a stateful application on an Auto Scaling group. The application requires that all in-progress transactions are completed before an instance is terminated. If a termination lifecycle hook fails or times out, the instance should NOT be terminated to avoid data loss. Which solution meets these requirements?
    1. Configure the lifecycle hook default result to ABANDON and use a CloudWatch alarm to notify the operations team.
    2. Set the lifecycle hook heartbeat timeout to 48 hours to provide maximum time for completion.
    3. Configure an instance lifecycle policy to retain instances when the termination lifecycle action is abandoned.
    4. Use a custom Lambda function to continuously record heartbeats and prevent timeout.
  7. An organization wants to execute a custom action when an Auto Scaling instance enters a wait state during launch. Which notification target is recommended as a best practice?
    1. Amazon SNS topic with email subscription
    2. Amazon SQS FIFO queue
    3. Amazon EventBridge rule invoking a Lambda function
    4. Amazon SQS standard queue with a polling consumer

📖 Related: AWS Auto Scaling with ELB – Integration Guide

References

 

AWS Compute Services Cheat Sheet – EC2, Lambda, ECS

~ Last updated on : ~ jayendrapatil ~ 22 Comments

AWS Compute Services Cheat Sheet

AWS Compute Services

Elastic Cloud Compute – EC2

  • provides scalable computing capacity
  • Features
    • Virtual computing environments, known as EC2 instances
    • Preconfigured templates for EC2 instances, known as Amazon Machine Images (AMIs), that package the bits needed for the server (including the operating system and additional software)
    • Various configurations of CPU, memory, storage, and networking capacity for your instances, known as Instance types
    • Secure login information for your instances using key pairs (public-private keys where private is kept by user)
    • Storage volumes for temporary data that’s deleted when you stop or terminate your instance, known as Instance store volumes
    • Persistent storage volumes for data using Elastic Block Store (EBS)
    • Multiple physical locations for your resources, such as instances and EBS volumes, known as Regions and Availability Zones
    • A firewall to specify the protocols, ports, and source IP ranges that can reach your instances using Security Groups
    • Static IP addresses, known as Elastic IP addresses
    • Metadata, known as tags, can be created and assigned to EC2 resources
    • Virtual networks that are logically isolated from the rest of the AWS cloud, and can optionally connect to on-premises network, known as Virtual private clouds (VPCs)

Amazon Machine Image – AMI

    • template from which EC2 instances can be launched quickly
    • does NOT span across regions, and needs to be copied
    • can be shared with other specific AWS accounts or made public

Instance Types

  • T for applications needing general usage
    • T2 instances are Burstable Performance Instances that provide a baseline level of CPU performance with the ability to burst above the baseline.
    • T2 instances accumulate CPU Credits when they are idle, and consume CPU Credits when they are active.
    • T2 Unlimited Instances can sustain high CPU performance for as long as a workload needs it at an additional cost.
    • T4g instances are powered by AWS Graviton2 processors and provide the next generation low cost burstable general purpose instance type.
  • R for applications needing more RAM or Memory
    • R8g instances powered by Graviton4 processors deliver up to 30% better performance over Graviton3-based instances for memory-intensive workloads.
  • C for applications needing more Compute
    • C8g instances powered by Graviton4 and C8i instances powered by Intel Xeon 6 processors represent the latest generation (2024-2025).
  • M for applications needing more Medium or Moderate performance on both Memory and CPU
    • M8g instances powered by Graviton4 and M8i instances powered by Intel Xeon 6 processors are the latest generation (2024-2025).
  • I for applications needing more IOPS
  • G for applications needing more GPU
  • P for applications needing GPU-accelerated computing for ML/AI
    • P5 and P5e instances for high-performance ML training and inference workloads.
  • Graviton-based instances (suffix “g”, e.g., C8g, M8g, R8g) are powered by AWS-designed Arm processors and provide the best price performance for most workloads.

Instance Purchasing Option

  • On-Demand Instances
    • pay for instances and compute capacity that you use by the hour or second
    • no long-term commitments or up-front payments
  • Reserved Instances
    • provides lower hourly running costs by providing a billing discount (up to 72%)
    • capacity reservation is applied to instances
    • suited if consistent, heavy, predictable usage
    • provides benefits with Consolidate Billing
    • can be modified to switch Availability Zones or the instance size within the same instance type, given the instance size footprint (Normalization factor) remains the same
    • pay for the entire term regardless of the usage
    • is not a physical instance that is launched, but rather a billing discount applied to the use of On-Demand Instances
    • available in Standard and Convertible options
  • Savings Plans
    • flexible pricing model offering savings up to 72% on compute usage in exchange for a commitment to a consistent amount of usage (measured in $/hour) for a 1 or 3 year term
    • Compute Savings Plans apply to EC2, Fargate, and Lambda usage regardless of instance family, size, AZ, region, OS, or tenancy
    • EC2 Instance Savings Plans apply to a specific instance family within a region
    • recommended over Reserved Instances for new workloads due to greater flexibility
  • Scheduled Reserved Instances
    • ⚠️ Scheduled Reserved Instances are no longer available for purchase. AWS does not have capacity available and has no plans to make it available in the future. Use On-Demand Capacity Reservations instead.
  • On-Demand Capacity Reservations
    • reserve compute capacity for instances in a specific AZ for any duration
    • can be created to start immediately or scheduled for a future date
    • ensures access to EC2 capacity when needed, independent of billing discounts
    • can be combined with Savings Plans or Reserved Instances for cost savings
  • Capacity Blocks for ML
    • reserve GPU instances (P4d, P5, P5e, Trn1) for ML workloads up to 8 weeks in advance
    • durations of up to 6 months in cluster sizes of 1 to 64 instances
    • supports instant start times and extensions
    • instances are placed in EC2 UltraClusters for low-latency networking
  • Spot Instances
    • cost-effective choice (up to 90% discount) but does NOT guarantee availability
    • applications flexible in the timing when they can run and also able to handle interruption by storing the state externally
    • provides a two-minute warning if the instance is to be terminated to save any unsaved work
    • Spot blocks can also be launched with a required duration, which are not interrupted due to changes in the Spot price Spot Blocks (Defined Duration) are no longer available for new customers.
    • Spot Fleet is a collection, or fleet, of Spot Instances, and optionally On-Demand Instances, which attempts to launch the number of Spot and On-Demand Instances to meet the specified target capacity
  • Dedicated Instances
    • is a tenancy option that enables instances to run in VPC on hardware that’s isolated, dedicated to a single customer
  • Dedicated Host
    • is a physical server with EC2 instance capacity fully dedicated to your use
    • helps meet compliance requirements and reduce costs by allowing use of existing server-bound software licenses
  • Light, Medium, and Heavy Utilization Reserved Instances are no longer available for purchase and were part of the Previous Generation AWS EC2 purchasing model

Enhanced Networking

  • results in higher bandwidth, higher packet per second (PPS) performance, lower latency, consistency, scalability, and lower jitter
  • supported using Single Root – I/O Virtualization (SR-IOV) only on supported instance types
  • is supported only with a VPC and HVM virtualization type
  • available by default on Amazon AMI but can be installed on other AMIs as well
  • no additional charge for using enhanced networking
  • Note: EC2-Classic has been fully retired (August 2023). All instances now run in VPC only.

Placement Group

  • Cluster Placement Group
    • provide low latency, High-Performance Computing via 10Gbps network
    • is a logical grouping on instances within a Single AZ
    • don’t span availability zones, can span multiple subnets but subnets must be in the same AZ
    • can span across peered VPCs for the same Availability Zones
    • An existing instance can be moved to a placement group, or moved from one placement group to another, or removed from a placement group, given it is in the stopped state.
    • for capacity errors, stop and start the instances in the placement group
    • use homogenous instance types which support enhanced networking and launch all the instances at once
  • Spread Placement Groups
    • is a group of instances that are each placed on distinct underlying hardware i.e. each instance on a distinct rack across AZ
    • recommended for applications that have a small number of critical instances that should be kept separate from each other.
    • reduces the risk of simultaneous failures that might occur when instances share the same underlying hardware.
  • Partition Placement Groups
    • is a group of instances spread across partitions i.e. group of instances spread across racks across AZs
    • reduces the likelihood of correlated hardware failures for the application.
    • can be used to spread deployment of large distributed and replicated workloads, such as HDFS, HBase, and Cassandra, across distinct hardware

EC2 Monitoring

  • CloudWatch provides monitoring for EC2 instances
  • Status monitoring helps quickly determine whether EC2 has detected any problems that might prevent instances from running applications.
  • Status monitoring includes
    • System Status checks – indicate issues with the underlying hardware
    • Instance Status checks – indicate issues with the underlying instance.

Elastic Load Balancer

  • Managed load balancing service and scales automatically
  • distributes incoming application traffic across multiple EC2 instances
  • is distributed system that is fault tolerant and actively monitored by AWS scales it as per the demand
  • are engineered to not be a single point of failure
  • supports Load Balancer Capacity Unit (LCU) Reservation to proactively set a minimum capacity for ALB and NLB, complementing auto-scaling for planned traffic events (launched Nov 2024)
  • supports routing traffic to instances in multiple AZs in the same region
  • performs Health Checks to route traffic only to the healthy instances
  • support Listeners with HTTP, HTTPS, SSL, TCP protocols
  • has an associated IPv4 and dual stack DNS name
  • can offload the work of encryption and decryption (SSL termination) so that the EC2 instances can focus on their main work
  • supports Cross Zone load balancing to help route traffic evenly across all EC2 instances regardless of the AZs they reside in
  • to help identify the IP address of a client
    • supports Proxy Protocol header for TCP/SSL connections
    • supports X-Forward headers for HTTP/HTTPS connections
  • supports Stick Sessions (session affinity) to bind a user’s session to a specific application instance,
    • it is not fault tolerant, if an instance is lost the information is lost
    • requires HTTP/HTTPS listener and does not work with TCP
    • requires SSL termination on ELB as it users the headers
  • supports Connection draining to help complete the in-flight requests in case an instance is deregistered
  • For High Availability, it is recommended to attach one subnet per AZ for at least two AZs, even if the instances are in a single subnet.
  • supports Static/Elastic IP (NLB only)
  • IPv4 & IPv6 support. VPC supports IPv6.
  • HTTPS listener does not support Client Side Certificate
  • For SSL termination at backend instances or support for Client Side Certificate use TCP for connections from the client to the ELB, use the SSL protocol for connections from the ELB to the back-end application, and deploy certificates on the back-end instances handling requests
  • Uses Server Name Indication to supports multiple SSL certificates
  • Supports four types: Application Load Balancer (ALB), Network Load Balancer (NLB), Gateway Load Balancer (GWLB), and Classic Load Balancer (CLB – previous generation)

Application Load Balancer

  • supports HTTP and HTTPS (Secure HTTP) protocols
  • supports HTTP/2, which is enabled natively. Clients that support HTTP/2 can connect over TLS
  • supports WebSockets and Secure WebSockets natively
  • supports Request tracing, by default.
    • request tracing can be used to track HTTP requests from clients to targets or other services.
    • Load balancer upon receiving a request from a client, adds or updates the X-Amzn-Trace-Id header before sending the request to the target
  • supports containerized applications. Using Dynamic port mapping, ECS can select an unused port when scheduling a task and register the task with a target group using this port.
  • supports Sticky Sessions (Session Affinity) using load balancer generated cookies, to route requests from the same client to the same target
  • supports SSL termination, to decrypt the request on ALB before sending it to the underlying targets.
  • supports layer 7 specific features like X-Forwarded-For headers to help determine the actual client IP, port and protocol
  • automatically scales its request handling capacity in response to incoming application traffic.
  • supports hybrid load balancing, to route traffic to instances in VPC and an on-premises location
  • provides High Availability, by allowing more than one AZ to be specified
  • integrates with ACM to provision and bind a SSL/TLS certificate to the load balancer thereby making the entire SSL offload process very easy
  • supports multiple certificates for the same domain to a secure listener
  • supports IPv6 addressing, for an Internet facing load balancer
  • supports dual-stack without public IPv4, enabling clients to connect using only IPv6 addresses without needing public IPv4 addresses (launched May 2024)
  • supports Cross-zone load balancing, and cannot be disabled.
  • supports Security Groups to control the traffic allowed to and from the load balancer.
  • provides Access Logs, to record all requests sent the load balancer, and store the logs in S3 for later analysis in compressed format
  • provides Delete Protection, to prevent the ALB from accidental deletion
  • supports Connection Idle Timeout – ALB maintains two connections for each request one with the Client (front end) and one with the target instance (back end). If no data has been sent or received by the time that the idle timeout period elapses, ALB closes the front-end connection
  • integrates with CloudWatch to provide metrics such as request counts, error counts, error types, and request latency
  • integrates with AWS WAF, a web application firewall that helps protect web applications from attacks by allowing rules configuration based on IP addresses, HTTP headers, and custom URI strings
  • integrates with CloudTrail to receive a history of ALB API calls made on the AWS account
  • back-end server authentication is NOT supported
  • does not provide Static, Elastic IP addresses

Network Load Balancer

  • handles volatile workloads and scale to millions of requests per second, without the need of pre-warming
  • offers extremely low latencies for latency-sensitive applications.
  • provides static IP/Elastic IP addresses for the load balancer
  • allows registering targets by IP address, including targets outside the VPC (on-premises) for the load balancer.
  • supports containerized applications. Using Dynamic port mapping, ECS can select an unused port when scheduling a task and register the task with a target group using this port.
  • monitors the health of its registered targets and routes the traffic only to healthy targets
  • enable cross-zone loading balancing only after creating the NLB
  • preserves client side source IP allowing the back-end to see client IP address. Target groups can be created with target type as instance ID or IP address. If targets registered by instance ID, the source IP addresses of the clients are preserved and provided to the applications. If register targets registered by IP address, the source IP addresses are the private IP addresses of the load balancer nodes.
  • supports both network and application target health checks.
  • supports long-lived TCP connections ideal for WebSocket type of applications
  • supports Zonal Isolation, which is designed for application architectures in a single zone and can be enabled in a single AZ to support architectures that require zonal isolation
  • supports sticky sessions using source IP affinity at the target group level to route traffic from the same client to the same target
  • supports removing Availability Zones after creation, enabling subnet reconfiguration without recreating the NLB (launched Feb 2025)
  • supports weighted target groups for blue/green and canary deployments without multiple load balancers (launched 2025)
  • supports QUIC protocol in passthrough mode, enabling low-latency forwarding of QUIC traffic while preserving session stickiness through QUIC Connection ID (launched Nov 2025)
  • supports UDP over IPv6 for dualstack load balancers (launched Nov 2024)

Gateway Load Balancer

  • enables deployment, scaling, and management of third-party virtual appliances such as firewalls, intrusion detection/prevention systems, and deep packet inspection systems
  • provides one gateway for distributing traffic across multiple virtual appliances while scaling them up or down based on demand
  • operates at Layer 3 (Network layer) and listens for all IP packets across all ports
  • uses the GENEVE protocol on port 6081 to encapsulate traffic
  • supports flow stickiness using 2-tuple, 3-tuple, or 5-tuple hash
  • configurable TCP idle timeout from 60 to 6000 seconds
  • decreases potential points of failure in network and increases availability
  • use cases include centralized network security inspection, traffic mirroring, and compliance monitoring

Auto Scaling

  • ensures correct number of EC2 instances are always running to handle the load by scaling up or down automatically as demand changes
  • cannot span multiple regions.
  • attempts to distribute instances evenly between the AZs that are enabled for the Auto Scaling group
  • performs checks either using EC2 status checks or can use ELB health checks to determine the health of an instance and terminates the instance if unhealthy, to launch a new instance
  • can be scaled using manual scaling, scheduled scaling, dynamic scaling (target tracking, step, simple) or predictive scaling
  • Predictive Scaling uses machine learning to predict future traffic based on historical patterns and proactively launches instances ahead of demand, ideal for applications with recurring traffic spikes
  • Target Tracking scaling now features highly responsive scaling policies that adapt to unique application usage patterns and support high-resolution CloudWatch metrics (enhanced Nov 2024)
  • cooldown period helps ensure instances are not launched or terminated before the previous scaling activity takes effect to allow the newly launched instances to start handling traffic and reduce load

AWS Auto Scaling & ELB

  • Auto Scaling & ELB can be used for High Availability and Redundancy by spanning Auto Scaling groups across multiple AZs within a region and then setting up ELB to distribute incoming traffic across those AZs
  • With Auto Scaling, use ELB health check with the instances to ensure that traffic is routed only to the healthy instances

Lambda

  • offers Serverless computing that allows applications and services to be built and run without thinking about servers.
  • helps run code without provisioning or managing servers, where you pay only for the compute time when the code is running.
  • is priced on a pay-per-use basis and there are no charges when the code is not running.
  • performs all the operational and administrative activities on your behalf, including capacity provisioning, monitoring fleet health, applying security patches to the underlying compute resources, deploying code, running a web service front end, and monitoring and logging the code.
  • does not provide access to the underlying compute infrastructure.
  • handles scalability and availability as it
    • provides easy scaling and high availability to the code without additional effort on your part.
    • is designed to process events within milliseconds.
    • is designed to run many instances of the functions in parallel.
    • is designed to use replication and redundancy to provide high availability for both the service and the functions it operates.
    • has no maintenance windows or scheduled downtimes for either.
    • has a default safety throttle for the number of concurrent executions per account per region.
    • has a higher latency immediately after a function is created, or updated, or if it has not been used recently.
    • for any function updates, there is a brief window of time, less than a minute, when requests would be served by both versions
  • Security
    • stores code in S3 and encrypts it at rest and performs additional integrity checks while the code is in use.
    • each function runs in its own isolated environment, with its own resources and file system view
    • supports Code Signing using AWS Signer, which offers trust and integrity controls that enable you to verify that only unaltered code from approved developers is deployed in the functions.
  • Functions must complete execution within 900 seconds (15 minutes). The default timeout is 3 seconds. The timeout can be set to any value between 1 and 900 seconds.
  • Supports up to 10,240 MB (10 GB) of memory per function.
  • AWS Step Functions can help coordinate a series of Lambda functions in a specific order. Multiple functions can be invoked sequentially, passing the output of one to the other, and/or in parallel, while the state is being maintained by Step Functions.
  • AWS X-Ray helps to trace functions, which provides insights such as service overhead, function init time, and function execution time.
  • Lambda Provisioned Concurrency provides greater control over the performance of serverless applications.
  • Lambda@Edge allows you to run code across AWS locations globally without provisioning or managing servers, responding to end-users at the lowest network latency.
  • Lambda Extensions allow integration of Lambda with other third-party tools for monitoring, observability, security, and governance.
  • Compute Savings Plan can help save money for Lambda executions.
  • CodePipeline and CodeDeploy can be used to automate the serverless application release process.
  • RDS Proxy provides a highly available database proxy that manages thousands of concurrent connections to relational databases.
  • Supports Elastic File Store, to provide a shared, external, persistent, scalable volume using a fully managed elastic NFS file system without the need for provisioning or capacity management.
  • Supports Function URLs, a built-in HTTPS endpoint that can be invoked using the browser, curl, and any HTTP client.
  • Lambda SnapStart reduces cold start latency from several seconds to sub-second for Java, Python, and .NET functions by taking a snapshot of the initialized execution environment (GA for Python & .NET in Nov 2024).
  • Lambda Durable Functions enable building resilient multi-step applications and AI workflows that can execute for up to one year, automatically checkpoint progress, suspend execution during long-running tasks, and recover from failures without custom state management code (launched Dec 2025).
  • Lambda Managed Instances enables running Lambda functions on EC2 instances (including Graviton4, GPU, network-optimized) while maintaining Lambda’s operational simplicity, with access to EC2 commitment-based pricing (Savings Plans, Reserved Instances) for up to 72% cost savings (launched Nov 2025).
  • Supports runtimes including Node.js 24, Python 3.12+, Java 25, .NET 8, and more.

AWS Compute – Additional Services

  • Amazon ECS (Elastic Container Service) – fully managed container orchestration service
    • Supports Fargate (serverless) and EC2 launch types
    • ECS Express Mode (launched Nov 2025) – streamlines deployment of containerized workloads by automatically setting up load balancing, auto scaling, networking, and monitoring with simplified APIs
    • ECS Managed Instances (launched Sep 2025) – fully managed compute option for broader EC2 instance access without infrastructure overhead
    • Supports predictive scaling (launched Nov 2024)
  • Amazon EKS (Elastic Kubernetes Service) – managed Kubernetes service for running containers at scale
  • AWS Fargate – serverless compute engine for containers that works with both ECS and EKS, removing the need to manage underlying infrastructure
  • AWS Batch – fully managed batch computing service for running batch jobs at any scale
  • AWS App Runner – ⚠️ No longer accepting new customers as of April 30, 2026. Existing services continue to operate. AWS recommends migrating to Amazon ECS Express Mode. No new features planned.

Related Posts

AWS Auto Scaling with ELB – Scaling & Health

~ Last updated on : ~ jayendrapatil ~ 30 Comments

Auto Scaling & ELB

📌 2025/2026 Updates

  • Launch Configurations Deprecated: As of October 1, 2024, new AWS accounts cannot create launch configurations. All users must use Launch Templates instead.
  • Zonal Shift & Autoshift: EC2 Auto Scaling now supports Amazon Application Recovery Controller (ARC) zonal shift to rapidly recover from AZ impairments (Nov 2024).
  • Instance Refresh – ReplaceRootVolume: New strategy to update root volumes without terminating instances (Nov 2025).
  • Predictive Scaling: Expanded to additional regions, uses ML to proactively scale ahead of demand (Oct 2025).
  • Instance Maintenance Policy: Control replacement behavior with launch-before-terminate or terminate-and-launch strategies.
  • ELB Target Groups: Modern load balancers (ALB, NLB, GWLB) use target groups instead of direct instance registration.
  • 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.

AWS Auto Scaling & ELB

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 – EC2, ECS & DynamoDB Scaling

~ Last updated on : ~ jayendrapatil ~ 59 Comments

Auto Scaling Overview

  • Auto Scaling provides the ability to ensure a correct number of EC2 instances are always running to handle the load of the application
  • Auto Scaling helps
    • to achieve better fault tolerance, better availability and cost management.
    • helps specify scaling policies that can be used to launch and terminate EC2 instances to handle any increase or decrease in demand.
  • Auto Scaling attempts to distribute instances evenly between the AZs that are enabled for the Auto Scaling group.
  • Auto Scaling does this by attempting to launch new instances in the AZ with the fewest instances. If the attempt fails, it attempts to launch the instances in another AZ until it succeeds.

Auto Scaling Components

AWS Auto Scaling

Auto Scaling Groups – ASG

  • Auto Scaling groups are the core of Auto Scaling and contain a collection of EC2 instances that share similar characteristics and are treated as a logical grouping for the purposes of automatic scaling and management.
  • ASG requires
    • Launch Template (recommended) OR Launch Configuration (deprecated)
      • determine the EC2 template to use for launching the instance
    • Minimum & Maximum capacity
      • determine the number of instances when an autoscaling policy is applied.
      • Number of instances cannot grow beyond these boundaries
    • Desired capacity
      • to determine the number of instances the ASG must maintain at all times. If missing, it equals the minimum size.
      • Desired capacity is different from minimum capacity.
      • An Auto Scaling group’s desired capacity is the default number of instances that should be running. A group’s minimum capacity is the fewest number of instances the group can have running
    • Availability Zones or Subnets in which the instances will be launched.
    • Metrics & Health Checks
      • metrics to determine when it should launch or terminate instances and health checks to determine if the instance is healthy or not
  • ASG starts by launching a desired capacity of instances and maintains this number by performing periodic health checks.
  • If an instance becomes unhealthy, the ASG terminates and launches a new instance.
  • ASG can also use scaling policies to increase or decrease the number of instances automatically to meet changing demands
  • An ASG can contain EC2 instances in one or more AZs within the same region.
  • ASGs cannot span multiple regions.
  • ASG can launch On-Demand Instances, Spot Instances, or both when configured to use a launch template.
  • To merge separate single-zone ASGs into a single ASG spanning multiple AZs, rezone one of the single-zone groups into a multi-zone group, and then delete the other groups. This process works for groups with or without a load balancer, as long as the new multi-zone group is in one of the same AZs as the original single-zone groups.
  • ASG can be associated with a single launch configuration or template
  • As the Launch Configuration can’t be modified once created, the only way to update the Launch Configuration for an ASG is to create a new one and associate it with the ASG.
  • When the launch configuration for the ASG is changed, any new instances launched, use the new configuration parameters, but the existing instances are not affected.
  • ASG can be deleted from CLI, if it has no running instances else need to set the minimum and desired capacity to 0. This is handled automatically when deleting an ASG from the AWS management console.
  • Deletion Protection (Jan 2026) – ASGs now support deletion protection with multiple protection levels to prevent accidental deletions. A new IAM policy condition key autoscaling:ForceDelete controls the use of the ForceDelete parameter.

Launch Configuration

⚠️ LAUNCH CONFIGURATION – DEPRECATED

Launch Configurations are being phased out in favor of Launch Templates.

  • As of January 1, 2023 – No new EC2 instance types are supported in launch configurations.
  • As of June 1, 2023 – New accounts cannot create launch configurations via the console.
  • As of October 1, 2024 – New accounts cannot create launch configurations using any method (console, API, CLI, or CloudFormation).
  • Existing accounts can still use existing launch configurations but should migrate to Launch Templates.

Migration: Use Migrate to Launch Templates guide to transition.

  • Launch configuration is an instance configuration template that an ASG uses to launch EC2 instances.
  • Launch configuration is similar to EC2 configuration and involves the selection of the Amazon Machine Image (AMI), block devices, key pair, instance type, security groups, user data, EC2 instance monitoring, instance profile, kernel, ramdisk, the instance tenancy, whether the instance has a public IP address, and is EBS-optimized.
  • Launch configuration can be associated with multiple ASGs
  • Launch configuration can’t be modified after creation and needs to be created new if any modification is required.
  • Basic or detailed monitoring for the instances in the ASG can be enabled when a launch configuration is created.
  • By default, basic monitoring is enabled when you create the launch configuration using the AWS Management Console, and detailed monitoring is enabled when you create the launch configuration using the AWS CLI or an API
  • AWS recommends using Launch Template instead. Launch Configurations are deprecated for new accounts.

Launch Template

  • A Launch Template is similar to a launch configuration, with additional features, and is the recommended and only supported option for new AWS accounts (since Oct 2024).
  • Launch Template allows multiple versions of a template to be defined.
  • With versioning, a subset of the full set of parameters can be created and then reused to create other templates or template versions for e.g, a default template that defines common configuration parameters can be created and allow the other parameters to be specified as part of another version of the same template.
  • Launch Template allows the selection of both Spot and On-Demand Instances or multiple instance types.
  • Launch templates support EC2 Dedicated Hosts. Dedicated Hosts are physical servers with EC2 instance capacity that are dedicated to your use.
  • Launch templates provide the following features
    • Support for multiple instance types and purchase options in a single ASG.
    • Launching Spot Instances with the capacity-optimized allocation strategy.
    • Support for launching instances into existing Capacity Reservations through an ASG.
    • Support for unlimited mode for burstable performance instances.
    • Support for Dedicated Hosts.
    • Combining CPU architectures such as Intel, AMD, and ARM (Graviton2/Graviton3/Graviton4)
    • Improved governance through IAM controls and versioning.
    • Automating instance deployment with Instance Refresh.
    • Support for all new EC2 instance types (required since Jan 2023 as launch configs no longer support new types).

Auto Scaling Launch Configuration vs Launch Template

Auto Scaling Launch Template vs Launch Configuration

Auto Scaling Policies

Refer blog post @ Auto Scaling Policies

Predictive Scaling

  • Predictive Scaling uses machine learning to predict future traffic patterns and proactively scales capacity in advance of predicted changes.
  • It analyzes historical load data to detect daily and weekly patterns and automatically adjusts forecasts.
  • Predictive Scaling provisions EC2 instances ahead of anticipated demand, improving availability and reducing the need for over-provisioning.
  • It works alongside dynamic scaling policies – predictive scaling handles anticipated load changes while dynamic scaling handles unexpected spikes.
  • Predictive Scaling supports:
    • Forecast-only mode for evaluation before activating scaling
    • Forecast and scale mode for automatic capacity adjustment
    • Custom metrics in addition to predefined CPU, network, and ALB request metrics
  • Best suited for workloads with recurring, predictable traffic patterns (e.g., business-hour traffic, weekly patterns).

Auto Scaling Cooldown Period

  • Auto Scaling Cooldown period is a configurable setting for the ASG that helps to ensure that Auto Scaling doesn’t launch or terminate additional instances before the previous scaling activity takes effect and allows the newly launched instances to start handling traffic and reduce load
  • When ASG dynamically scales using a simple scaling policy and launches an instance, Auto Scaling suspends the scaling activities for the cooldown period (default 300 seconds) to complete before resuming scaling activities
  • Example Use Case
    • You configure a scale out alarm to increase the capacity, if the CPU utilization increases more than 80%
    • A CPU spike occurs and causes the alarm to be triggered, Auto Scaling launches a new instance
    • However, it would take time for the newly launched instance to be configured, instantiated, and started, let’s say 5 mins
    • Without a cooldown period, if another CPU spike occurs Auto Scaling would launch a new instance again and this would continue for 5 mins till the previously launched instance is up and running and started handling traffic
    • With a cooldown period, Auto Scaling would suspend the activity for the specified time period enabling the newly launched instance to start handling traffic and reduce the load.
    • After the cooldown period, Auto Scaling resumes acting on the alarms
  • When manually scaling the ASG, the default is not to wait for the cooldown period but can be overridden to honour the cooldown period.
  • Note that if an instance becomes unhealthy, Auto Scaling does not wait for the cooldown period to complete before replacing the unhealthy instance.
  • Cooldown periods are automatically applied to dynamic scaling activities for simple scaling policies and are not supported for step scaling or target tracking policies.
  • Default Instance Warmup – a recommended alternative to cooldown periods. It specifies how long after an instance reaches InService state before it contributes to aggregated CloudWatch metrics. This prevents premature scaling decisions based on incomplete data from newly launched instances.

Auto Scaling Termination Policy

  • Termination policy helps Auto Scaling decide which instances it should terminate first when Auto Scaling automatically scales in.
  • Auto Scaling specifies a default termination policy and also provides the ability to create a customized one.

Default Termination Policy

Default termination policy helps ensure that the network architecture spans AZs evenly and instances are selected for termination as follows:-

  1. Selection of Availability Zone
    • selects the AZ, in multiple AZs environments, with the most instances and at least one instance that is not protected from scale in.
    • selects the AZ with instances that use the oldest launch template or configuration, if there is more than one AZ with the same number of instances
  2. Selection of an Instance within the Availability Zone
    • terminates the unprotected instance using the oldest launch template or configuration if one exists.
    • terminates unprotected instances closest to the next billing hour, If multiple instances with the oldest launch configuration. This helps in maximizing the use of the EC2 instances that have an hourly charge while minimizing the number of hours billed for EC2 usage.
    • terminates instances at random, if more than one unprotected instance is closest to the next billing hour.

Customized Termination Policy

  1. Auto Scaling first assesses the AZs for any imbalance. If an AZ has more instances than the other AZs that are used by the group, then it applies the specified termination policy on the instances from the imbalanced AZ
  2. If the Availability Zones used by the group are balanced, then Auto Scaling applies the specified termination policy.
  3. Following Customized Termination policies are supported:
    1. OldestInstance – terminates the oldest instance in the group and can be useful to upgrade to new instance types
    2. NewestInstance – terminates the newest instance in the group and can be useful when testing a new launch configuration
    3. OldestLaunchConfiguration – terminates instances that have the oldest launch configuration
    4. OldestLaunchTemplate – terminates instances that have the oldest launch template
    5. ClosestToNextInstanceHour – terminates instances that are closest to the next billing hour and helps to maximize the use of your instances and manage costs.
    6. AllocationStrategy – terminates instances to align remaining instances to the allocation strategy for the instance type (Spot or On-Demand).
    7. Default – terminates as per the default termination policy

Custom Termination Policy with Lambda

  • Auto Scaling supports using an AWS Lambda function as a custom termination policy for advanced termination logic.
  • The Lambda function receives a JSON payload with candidate instances and returns which instances should be terminated.
  • This provides fine-grained control over termination decisions, e.g., avoiding instances running critical workloads.
  • Requires granting EC2 Auto Scaling permission via a Lambda resource-based policy.

Instance Refresh

  • Instance refresh can be used to update the instances in the ASG instead of manually replacing instances a few at a time.
  • An instance refresh can be helpful when you have a new AMI or a new user data script.
  • Instance refresh also helps configure the minimum healthy percentage, instance warmup, and checkpoints.
  • Instance refresh supports two strategies:
    • Rolling strategy (default) – Terminates instances and launches new ones in batches while maintaining desired capacity and availability.
    • Replace Root Volume strategy (Nov 2025) – Updates instances by replacing only the root EBS volume without terminating the instance. Preserves network interfaces, non-root EBS volumes, and instance store data.
  • To use an instance refresh:
    • Create a new launch template that specifies the new AMI or user data script.
    • Start an instance refresh to begin updating the instances in the group immediately.
    • EC2 Auto Scaling starts performing a rolling replacement of the instances.
  • Skip Matching – When enabled, Auto Scaling compares each instance’s current configuration against the desired configuration and only replaces instances that don’t match, skipping already-updated instances.

Warm Pools

  • A warm pool is a pool of pre-initialized EC2 instances that sits alongside the Auto Scaling group for faster scale-out.
  • When the application needs to scale out, the ASG draws from the warm pool instead of launching cold instances, significantly reducing startup latency.
  • Instances in a warm pool can be in one of three states: Stopped, Running, or Hibernated.
  • Warm pools are ideal for applications with long boot times (e.g., instances that need to load large datasets or perform complex initialization).
  • Warm pool supports lifecycle hooks to perform custom actions when instances transition between states.
  • Supports ASGs with mixed instances policies (Nov 2025) – warm pools can now be used with groups that have multiple instance types and purchase options.
  • Creating a warm pool when not required can lead to unnecessary costs for the stopped/running instances.

Instance Maintenance Policy

  • Instance Maintenance Policy (Nov 2023) defines whether new instances are launched before or after existing instances are terminated during replacement operations.
  • Controls replacement behavior for instance refresh, health checks, and AZ rebalancing.
  • Three preset options:
    • Launch before terminating – Provisions new instance first, then terminates old one. Favors availability over cost.
    • Terminate and launch – Terminates and launches simultaneously. Favors cost savings over availability.
    • Custom policy – Set custom min/max range for available capacity during replacement.
  • Can be set at the ASG level and overridden for individual instance refresh operations.

Instance Protection

  • Instance protection controls whether Auto Scaling can terminate a particular instance or not.
  • Instance protection can be enabled on an ASG or an individual instance as well, at any time
  • Instances launched within an ASG with Instance protection enabled would inherit the property.
  • Instance protection starts as soon as the instance is InService and if the Instance is detached, it loses its Instance protection
  • If all instances in an ASG are protected from termination during scale in and a scale-in event occurs, it can’t terminate any instance and will decrement the desired capacity.
  • Instance protection does not protect for the below cases
    • Manual termination through the EC2 console, the terminate-instances command, or the TerminateInstances API.
    • If it fails health checks and must be replaced
    • Spot instances in an ASG from interruption

Standby State

Auto Scaling allows putting the InService instances in the Standby state during which the instance is still a part of the ASG but does not serve any requests. This can be used to either troubleshoot an instance or update an instance and return the instance back to service.

  • An instance can be put into Standby state and it will continue to remain in the Standby state unless exited.
  • Auto Scaling, by default, decrements the desired capacity for the group and prevents it from launching a new instance. If no decrement is selected, it would launch a new instance
  • When the instance is in the standby state, the instance can be updated or used for troubleshooting.
  • If a load balancer is associated with Auto Scaling, the instance is automatically deregistered when the instance is in Standby state and registered again when the instance exits the Standby state

Suspension

  • Auto Scaling processes can be suspended and then resumed. This can be very useful to investigate a configuration problem or debug an issue with the application, without triggering the Auto Scaling process.
  • Auto Scaling also performs Administrative Suspension where it would suspend processes for ASGs if the ASG has been trying to launch instances for over 24 hours but has not succeeded in launching any instances.
  • Auto Scaling processes include
    • Launch – Adds a new EC2 instance to the group, increasing its capacity.
    • Terminate – Removes an EC2 instance from the group, decreasing its capacity.
    • HealthCheck – Checks the health of the instances.
    • ReplaceUnhealthy – Terminates instances that are marked as unhealthy and subsequently creates new instances to replace them.
    • AlarmNotification – Accepts notifications from CloudWatch alarms that are associated with the group. If suspended, Auto Scaling does not automatically execute policies that would be triggered by an alarm
    • ScheduledActions – Performs scheduled actions that you create.
    • AddToLoadBalancer – Adds instances to the load balancer when they are launched.
    • InstanceRefresh – Terminates and replaces instances using the instance refresh feature.
    • AZRebalance – Balances the number of EC2 instances in the group across the Availability Zones in the region.
      • If an AZ either is removed from the ASG or becomes unhealthy or unavailable, Auto Scaling launches new instances in an unaffected AZ before terminating the unhealthy or unavailable instances
      • When the unhealthy AZ returns to a healthy state, Auto Scaling automatically redistributes the instances evenly across the Availability Zones for the group.
      • Note that if you suspend AZRebalance and a scale out or scale in event occurs, Auto Scaling still tries to balance the Availability Zones for e.g. during scale out, it launches the instance in the Availability Zone with the fewest instances.
      • If you suspend Launch, AZRebalance neither launches new instances nor terminates existing instances. This is because AZRebalance terminates instances only after launching the replacement instances.
      • If you suspend Terminate, the ASG can grow up to 10% larger than its maximum size, because Auto Scaling allows this temporarily during rebalancing activities. If it cannot terminate instances, your ASG could remain above its maximum size until the Terminate process is resumed

Zonal Shift Integration

  • Zonal Shift (Nov 2024) integrates with Amazon Application Recovery Controller (ARC) to rapidly recover from AZ impairments.
  • When a zonal shift is activated, Auto Scaling stops dynamic scale-in to preserve capacity and launches new instances in healthy AZs only.
  • Zonal Autoshift can automatically shift traffic away from an impaired AZ on a periodic basis to test resilience.
  • Health checks can be configured to either remain enabled or be disabled in the impaired AZ during a zonal shift.
  • Can be initiated from the EC2 Auto Scaling console, ARC console, or programmatically via AWS SDK.

Strict Availability Zone Balance

  • Strict AZ Balance (Nov 2024) provides a new provisioning control to strictly balance workloads across Availability Zones.
  • Unlike the default best-effort balancing, strict mode ensures exact equal distribution across configured AZs.
  • Provides greater control over instance placement for compliance or performance requirements.

Auto Scaling Lifecycle

Refer to blog post @ Auto Scaling Lifecycle

Autoscaling & ELB

Refer to blog post @ Autoscaling & ELB

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 user is trying to setup a scheduled scaling activity using Auto Scaling. The user wants to setup the recurring schedule. Which of the below mentioned parameters is not required in this case?
    1. Maximum size
    2. Auto Scaling group name
    3. End time
    4. Recurrence value
  2. A user has configured Auto Scaling with 3 instances. The user had created a new AMI after updating one of the instances. If the user wants to terminate two specific instances to ensure that Auto Scaling launches an instances with the new launch configuration, which command should he run?
    1. as-delete-instance-in-auto-scaling-group <Instance ID> –no-decrement-desired-capacity
    2. as-terminate-instance-in-auto-scaling-group <Instance ID> –update-desired-capacity
    3. as-terminate-instance-in-auto-scaling-group <Instance ID> –decrement-desired-capacity
    4. as-terminate-instance-in-auto-scaling-group <Instance ID> –no-decrement-desired-capacity
  3. A user is planning to scale up an application by 8 AM and scale down by 7 PM daily using Auto Scaling. What should the user do in this case?
    1. Setup the scaling policy to scale up and down based on the CloudWatch alarms
    2. User should increase the desired capacity at 8 AM and decrease it by 7 PM manually
    3. User should setup a batch process which launches the EC2 instance at a specific time
    4. Setup scheduled actions to scale up or down at a specific time
  4. An organization has setup Auto Scaling with ELB. Due to some manual error, one of the instances got rebooted. Thus, it failed the Auto Scaling health check. Auto Scaling has marked it for replacement. How can the system admin ensure that the instance does not get terminated?
    1. Update the Auto Scaling group to ignore the instance reboot event
    2. It is not possible to change the status once it is marked for replacement
    3. Manually add that instance to the Auto Scaling group after reboot to avoid replacement
    4. Change the health of the instance to healthy using the Auto Scaling commands
  5. A user has configured Auto Scaling with the minimum capacity as 2 and the desired capacity as 2. The user is trying to terminate one of the existing instance with the command: as-terminate-instance-in-auto-scaling-group<Instance ID> –decrement-desired-capacity. What will Auto Scaling do in this scenario?
    1. Terminates the instance and does not launch a new instance
    2. Terminates the instance and updates the desired capacity to 1
    3. Terminates the instance and updates the desired capacity & minimum size to 1
    4. Throws an error
  6. An organization has configured Auto Scaling for hosting their application. The system admin wants to understand the Auto Scaling health check process. If the instance is unhealthy, Auto Scaling launches an instance and terminates the unhealthy instance. What is the order execution?
    1. Auto Scaling launches a new instance first and then terminates the unhealthy instance
    2. Auto Scaling performs the launch and terminate processes in a random order
    3. Auto Scaling launches and terminates the instances simultaneously
    4. Auto Scaling terminates the instance first and then launches a new instance
  7. A user has configured ELB with Auto Scaling. The user suspended the Auto Scaling terminate process only for a while. What will happen to the availability zone rebalancing process (AZRebalance) during this period?
    1. Auto Scaling will not launch or terminate any instances
    2. Auto Scaling will allow the instances to grow more than the maximum size
    3. Auto Scaling will keep launching instances till the maximum instance size
    4. It is not possible to suspend the terminate process while keeping the launch active
  8. An organization has configured Auto Scaling with ELB. There is a memory issue in the application which is causing CPU utilization to go above 90%. The higher CPU usage triggers an event for Auto Scaling as per the scaling policy. If the user wants to find the root cause inside the application without triggering a scaling activity, how can he achieve this?
    1. Stop the scaling process until research is completed
    2. It is not possible to find the root cause from that instance without triggering scaling
    3. Delete Auto Scaling until research is completed
    4. Suspend the scaling process until research is completed
  9. A user has configured ELB with Auto Scaling. The user suspended the Auto Scaling Alarm Notification (which notifies Auto Scaling for CloudWatch alarms) process for a while. What will Auto Scaling do during this period?
    1. AWS will not receive the alarms from CloudWatch
    2. AWS will receive the alarms but will not execute the Auto Scaling policy
    3. Auto Scaling will execute the policy but it will not launch the instances until the process is resumed
    4. It is not possible to suspend the AlarmNotification process
  10. An organization has configured two single availability zones. The Auto Scaling groups are configured in separate zones. The user wants to merge the groups such that one group spans across multiple zones. How can the user configure this?
    1. Run the command as-join-auto-scaling-group to join the two groups
    2. Run the command as-update-auto-scaling-group to configure one group to span across zones and delete the other group
    3. Run the command as-copy-auto-scaling-group to join the two groups
    4. Run the command as-merge-auto-scaling-group to merge the groups
  11. An organization has configured Auto Scaling with ELB. One of the instance health check returns the status as Impaired to Auto Scaling. What will Auto Scaling do in this scenario?
    1. Perform a health check until cool down before declaring that the instance has failed
    2. Terminate the instance and launch a new instance
    3. Notify the user using SNS for the failed state
    4. Notify ELB to stop sending traffic to the impaired instance
  12. A user has setup an Auto Scaling group. The group has failed to launch a single instance for more than 24 hours. What will happen to Auto Scaling in this condition
    1. Auto Scaling will keep trying to launch the instance for 72 hours
    2. Auto Scaling will suspend the scaling process
    3. Auto Scaling will start an instance in a separate region
    4. The Auto Scaling group will be terminated automatically
  13. A user is planning to setup infrastructure on AWS for the Christmas sales. The user is planning to use Auto Scaling based on the schedule for proactive scaling. What advise would you give to the user?
    1. It is good to schedule now because if the user forgets later on it will not scale up
    2. The scaling should be setup only one week before Christmas
    3. Wait till end of November before scheduling the activity
    4. It is not advisable to use scheduled based scaling
  14. A user is trying to setup a recurring Auto Scaling process. The user has setup one process to scale up every day at 8 am and scale down at 7 PM. The user is trying to setup another recurring process which scales up on the 1st of every month at 8 AM and scales down the same day at 7 PM. What will Auto Scaling do in this scenario
    1. Auto Scaling will execute both processes but will add just one instance on the 1st
    2. Auto Scaling will add two instances on the 1st of the month
    3. Auto Scaling will schedule both the processes but execute only one process randomly
    4. Auto Scaling will throw an error since there is a conflict in the schedule of two separate Auto Scaling Processes
  15. A sys admin is trying to understand the Auto Scaling activities. Which of the below mentioned processes is not performed by Auto Scaling?
    1. Reboot Instance
    2. Schedule Actions
    3. Replace Unhealthy
    4. Availability Zone Re-Balancing
  16. You have started a new job and are reviewing your company’s infrastructure on AWS. You notice one web application where they have an Elastic Load Balancer in front of web instances in an Auto Scaling Group. When you check the metrics for the ELB in CloudWatch you see four healthy instances in Availability Zone (AZ) A and zero in AZ B. There are zero unhealthy instances. What do you need to fix to balance the instances across AZs?
    1. Set the ELB to only be attached to another AZ
    2. Make sure Auto Scaling is configured to launch in both AZs
    3. Make sure your AMI is available in both AZs
    4. Make sure the maximum size of the Auto Scaling Group is greater than 4
  17. You have been asked to leverage Amazon VPC EC2 and SQS to implement an application that submits and receives millions of messages per second to a message queue. You want to ensure your application has sufficient bandwidth between your EC2 instances and SQS. Which option will provide the most scalable solution for communicating between the application and SQS?
    1. Ensure the application instances are properly configured with an Elastic Load Balancer
    2. Ensure the application instances are launched in private subnets with the EBS-optimized option enabled
    3. Ensure the application instances are launched in public subnets with the associate-public-IP-address=trueoption enabled
    4. Launch application instances in private subnets with an Auto Scaling group and Auto Scaling triggers configured to watch the SQS queue size
  18. You have decided to change the Instance type for instances running in your application tier that are using Auto Scaling. In which area below would you change the instance type definition?
    1. Auto Scaling launch configuration or launch template
    2. Auto Scaling group
    3. Auto Scaling policy
    4. Auto Scaling tags
  19. A user is trying to delete an Auto Scaling group from CLI. Which of the below mentioned steps are to be performed by the user?
    1. Terminate the instances with the ec2-terminate-instance command
    2. Terminate the Auto Scaling instances with the as-terminate-instance command
    3. Set the minimum size and desired capacity to 0
    4. There is no need to change the capacity. Run the as-delete-group command and it will reset all values to 0
  20. A user has created a web application with Auto Scaling. The user is regularly monitoring the application and he observed that the traffic is highest on Thursday and Friday between 8 AM to 6 PM. What is the best solution to handle scaling in this case?
    1. Add a new instance manually by 8 AM Thursday and terminate the same by 6 PM Friday
    2. Schedule Auto Scaling to scale up by 8 AM Thursday and scale down after 6 PM on Friday
    3. Schedule a policy which may scale up every day at 8 AM and scales down by 6 PM
    4. Configure a batch process to add a instance by 8 AM and remove it by Friday 6 PM
  21. A user has configured the Auto Scaling group with the minimum capacity as 3 and the maximum capacity as 5. When the user configures the AS group, how many instances will Auto Scaling launch?
    1. 3
    2. 0
    3. 5
    4. 2
  22. A sys admin is maintaining an application on AWS. The application is installed on EC2 and user has configured ELB and Auto Scaling. Considering future load increase, the user is planning to launch new servers proactively so that they get registered with ELB. How can the user add these instances with Auto Scaling?
    1. Increase the desired capacity of the Auto Scaling group
    2. Increase the maximum limit of the Auto Scaling group
    3. Launch an instance manually and register it with ELB on the fly
    4. Decrease the minimum limit of the Auto Scaling group
  23. In reviewing the auto scaling events for your application you notice that your application is scaling up and down multiple times in the same hour. What design choice could you make to optimize for the cost while preserving elasticity? Choose 2 answers.
    1. Modify the Amazon CloudWatch alarm period that triggers your auto scaling scale down policy.
    2. Modify the Auto scaling group termination policy to terminate the oldest instance first.
    3. Modify the Auto scaling policy to use scheduled scaling actions.
    4. Modify the Auto scaling group cool down timers.
    5. Modify the Auto scaling group termination policy to terminate newest instance first.
  24. You have a business critical two tier web app currently deployed in two availability zones in a single region, using Elastic Load Balancing and Auto Scaling. The app depends on synchronous replication (very low latency connectivity) at the database layer. The application needs to remain fully available even if one application Availability Zone goes off-line, and Auto scaling cannot launch new instances in the remaining Availability Zones. How can the current architecture be enhanced to ensure this? [PROFESSIONAL]
    1. Deploy in two regions using Weighted Round Robin (WRR), with Auto Scaling minimums set for 100% peak load per region.
    2. Deploy in three AZs, with Auto Scaling minimum set to handle 50% peak load per zone.
    3. Deploy in three AZs, with Auto Scaling minimum set to handle 33% peak load per zone. (Loss of one AZ will handle only 66% if the autoscaling also fails)
    4. Deploy in two regions using Weighted Round Robin (WRR), with Auto Scaling minimums set for 50% peak load per region.
  25. A user has created a launch configuration for Auto Scaling where CloudWatch detailed monitoring is disabled. The user wants to now enable detailed monitoring. How can the user achieve this?
    1. Update the Launch config with CLI to set InstanceMonitoringDisabled = false
    2. The user should change the Auto Scaling group from the AWS console to enable detailed monitoring
    3. Update the Launch config with CLI to set InstanceMonitoring.Enabled = true
    4. Create a new Launch Config with detail monitoring enabled and update the Auto Scaling group (Note: For new accounts, create a new Launch Template version instead)
  26. A user has created an Auto Scaling group with default configurations from CLI. The user wants to setup the CloudWatch alarm on the EC2 instances, which are launched by the Auto Scaling group. The user has setup an alarm to monitor the CPU utilization every minute. Which of the below mentioned statements is true?
    1. It will fetch the data at every minute but the four data points [corresponding to 4 minutes] will not have value since the EC2 basic monitoring metrics are collected every five minutes
    2. It will fetch the data at every minute as detailed monitoring on EC2 will be enabled by the default launch configuration of Auto Scaling
    3. The alarm creation will fail since the user has not enabled detailed monitoring on the EC2 instances
    4. The user has to first enable detailed monitoring on the EC2 instances to support alarm monitoring at every minute
  27. A customer has a website which shows all the deals available across the market. The site experiences a load of 5 large EC2 instances generally. However, a week before Thanksgiving vacation they encounter a load of almost 20 large instances. The load during that period varies over the day based on the office timings. Which of the below mentioned solutions is cost effective as well as help the website achieve better performance?
    1. Keep only 10 instances running and manually launch 10 instances every day during office hours.
    2. Setup to run 10 instances during the pre-vacation period and only scale up during the office time by launching 10 more instances using the AutoScaling schedule.
    3. During the pre-vacation period setup a scenario where the organization has 15 instances running and 5 instances to scale up and down using Auto Scaling based on the network I/O policy.
    4. During the pre-vacation period setup 20 instances to run continuously.
  28. When Auto Scaling is launching a new instance based on condition, which of the below mentioned policies will it follow?
    1. Based on the criteria defined with cross zone Load balancing
    2. Launch an instance which has the highest load distribution
    3. Launch an instance in the AZ with the fewest instances
    4. Launch an instance in the AZ which has the highest instances
  29. The user has created multiple AutoScaling groups. The user is trying to create a new AS group but it fails. How can the user know that he has reached the AS group limit specified by AutoScaling in that region?
    1. Run the command: as-describe-account-limits
    2. Run the command: as-describe-group-limits
    3. Run the command: as-max-account-limits
    4. Run the command: as-list-account-limits
  30. A user is trying to save some cost on the AWS services. Which of the below mentioned options will not help him save cost?
    1. Delete the unutilized EBS volumes once the instance is terminated
    2. Delete the Auto Scaling launch configuration after the instances are terminated (Auto Scaling Launch config does not cost anything)
    3. Release the elastic IP if not required once the instance is terminated
    4. Delete the AWS ELB after the instances are terminated
  31. To scale up the AWS resources using manual Auto Scaling, which of the below mentioned parameters should the user change?
    1. Maximum capacity
    2. Desired capacity
    3. Preferred capacity
    4. Current capacity
  32. For AWS Auto Scaling, what is the first transition state an existing instance enters after leaving steady state in Standby mode?
    1. Detaching
    2. Terminating:Wait
    3. Pending (You can put any instance that is in an InService state into a Standby state. This enables you to remove the instance from service, troubleshoot or make changes to it, and then put it back into service. Instances in a Standby state continue to be managed by the Auto Scaling group. However, they are not an active part of your application until you put them back into service. Refer link)
    4. EnteringStandby
  33. For AWS Auto Scaling, what is the first transition state an instance enters after leaving steady state when scaling in due to health check failure or decreased load?
    1. Terminating (When Auto Scaling responds to a scale in event, it terminates one or more instances. These instances are detached from the Auto Scaling group and enter the Terminating state. Refer link)
    2. Detaching
    3. Terminating:Wait
    4. EnteringStandby
  34. A user has setup Auto Scaling with ELB on the EC2 instances. The user wants to configure that whenever the CPU utilization is below 10%, Auto Scaling should remove one instance. How can the user configure this?
    1. The user can get an email using SNS when the CPU utilization is less than 10%. The user can use the desired capacity of Auto Scaling to remove the instance
    2. Use CloudWatch to monitor the data and Auto Scaling to remove the instances using scheduled actions
    3. Configure CloudWatch to send a notification to Auto Scaling Launch configuration when the CPU utilization is less than 10% and configure the Auto Scaling policy to remove the instance
    4. Configure CloudWatch to send a notification to the Auto Scaling group when the CPU Utilization is less than 10% and configure the Auto Scaling policy to remove the instance
  35. A user has enabled detailed CloudWatch metric monitoring on an Auto Scaling group. Which of the below mentioned metrics will help the user identify the total number of instances in an Auto Scaling group including pending, terminating and running instances?
    1. GroupTotalInstances (Refer link)
    2. GroupSumInstances
    3. It is not possible to get a count of all the three metrics together. The user has to find the individual number of running, terminating and pending instances and sum it
    4. GroupInstancesCount
  36. Your startup wants to implement an order fulfillment process for selling a personalized gadget that needs an average of 3-4 days to produce with some orders taking up to 6 months you expect 10 orders per day on your first day. 1000 orders per day after 6 months and 10,000 orders after 12 months. Orders coming in are checked for consistency then dispatched to your manufacturing plant for production quality control packaging shipment and payment processing. If the product does not meet the quality standards at any stage of the process employees may force the process to repeat a step. Customers are notified via email about order status and any critical issues with their orders such as payment failure. Your case architecture includes AWS Elastic Beanstalk for your website with an RDS MySQL instance for customer data and orders. How can you implement the order fulfillment process while making sure that the emails are delivered reliably? [PROFESSIONAL]
    1. Add a business process management application to your Elastic Beanstalk app servers and re-use the ROS database for tracking order status use one of the Elastic Beanstalk instances to send emails to customers.
    2. Use SWF with an Auto Scaling group of activity workers and a decider instance in another Auto Scaling group with min/max=1 Use the decider instance to send emails to customers.
    3. Use SWF with an Auto Scaling group of activity workers and a decider instance in another Auto Scaling group with min/max=1 use SES to send emails to customers.
    4. Use an SQS queue to manage all process tasks Use an Auto Scaling group of EC2 Instances that poll the tasks and execute them. Use SES to send emails to customers.
  37. An organization wants to reduce latency for their Auto Scaling group during scale-out events. Their application takes 5 minutes to boot and initialize. Which Auto Scaling feature should they use?
    1. Increase the desired capacity permanently
    2. Use Predictive Scaling to pre-provision
    3. Configure a Warm Pool with pre-initialized instances
    4. Set a longer cooldown period
  38. A company has an application with predictable traffic patterns that peaks every weekday at 9 AM and reduces at 6 PM. They want Auto Scaling to proactively provision capacity before the peak. Which scaling approach is most appropriate?
    1. Target tracking scaling policy with CPU metric
    2. Step scaling policy with CloudWatch alarms
    3. Scheduled scaling actions
    4. Predictive Scaling policy
  39. A company needs to update the AMI across all instances in their Auto Scaling group without terminating instances, preserving their network interfaces and non-root EBS volumes. Which approach should they use?
    1. Create new launch template version and wait for scale-in/scale-out to replace instances
    2. Use instance refresh with the rolling strategy
    3. Use instance refresh with the replace root volume strategy
    4. Manually stop and update each instance
  40. An application team wants to control the order in which instances are replaced during Auto Scaling health check replacements. They want new instances launched BEFORE unhealthy ones are terminated to maintain capacity. Which feature should they configure?
    1. Instance protection
    2. Lifecycle hooks
    3. Instance maintenance policy with “Launch before terminating”
    4. Custom termination policy
  41. An Auto Scaling group experiences an Availability Zone impairment. The team wants to quickly shift traffic away from the impaired AZ while preventing Auto Scaling from terminating instances in that zone. Which feature integrates with Auto Scaling to handle this? [PROFESSIONAL]
    1. Suspend the AZRebalance process
    2. Remove the AZ from the ASG configuration
    3. Use Amazon ARC Zonal Shift with the Auto Scaling group
    4. Enable cross-zone load balancing on the ELB

References

AWS Auto Scaling User Guide

 

AWS Autoscaling Troubleshooting

~ Last updated on : ~ jayendrapatil ~ 2 Comments

AWS EC2 Auto Scaling Troubleshooting

⚠️ Important: Launch Configurations Deprecated

AWS has deprecated Launch Configurations. As of October 1, 2024, new AWS accounts cannot create launch configurations using any method (Console, API, CLI, or CloudFormation). Existing accounts can still use them but should migrate to Launch Templates, which support all new EC2 features.

This post has been updated to reflect Launch Templates as the current standard. References to launch configurations are maintained for existing deployments.

Exam Question Scenario

EC2 instances fail to launch with Auto Scaling configuration

Auto Scaling Configuration Overview

  • Auto Scaling configuration requires the following:
    • Launch Template (recommended) or Launch Configuration (deprecated) which allows you to specify:
      • AMI
      • Instance type (or multiple instance types with mixed instances policy)
      • IAM role (optional)
      • Security group(s)
      • Key pair (optional)
      • Network interfaces and subnet settings
      • EBS volume configuration
      • User data scripts
    • Auto Scaling Group (ASG) configuration specifies:
      • VPC and Subnets (Availability Zones) for instance placement
      • Desired, minimum, and maximum capacity
      • Health check type and grace period
      • Scaling policies (target tracking, step, simple, predictive)
      • Instance maintenance policy
      • Load balancer / target group attachments

EC2 Instance Launch Failure Troubleshooting

  • AMI Issues
    • AMI ID does not exist or has been deregistered
    • AMI is still in a pending state and cannot be used to launch instances
    • AMI is in a different region than the Auto Scaling group
    • AMI permissions do not allow the account to launch from it (private/shared AMI)
  • Security Group Issues
    • Security group specified in the launch template does not exist or has been deleted
    • Security group belongs to a different VPC than the one specified in the ASG subnets
  • Key Pair Issues
    • Key pair associated with the launch template does not exist or has been deleted
  • Auto Scaling Group Configuration Issues
    • Auto Scaling group not found or is incorrectly configured
    • Subnet specified in the ASG does not exist or is invalid
    • AZ configured with the Auto Scaling group is no longer supported or unavailable
  • EBS Volume Issues
    • Invalid EBS block device mappings
    • EBS snapshot specified does not exist
    • EBS volume type not supported in the AZ
    • Encrypted EBS volumes require proper KMS key permissions for the service-linked role
  • Instance Type & Capacity Issues
    • Instance type is not supported in the specified AZ
    • InsufficientInstanceCapacity – AWS does not have enough capacity for the requested instance type in the AZ
    • Account-level service limits (vCPU limits) for instance types reached in the region
    • Spot Instance capacity unavailable or Spot price exceeds the maximum price specified
  • Launch Template Issues
    • Launch template version specified does not exist
    • Launch template contains invalid parameters (e.g., unsupported instance type for a region)
    • IAM instance profile specified does not exist or the ASG service role lacks iam:PassRole permission
  • Networking Issues
    • VPC/Subnet has no available IP addresses
    • Placement group constraints cannot be satisfied
    • Network interface configuration conflicts with subnet settings
  • Permission Issues
    • Auto Scaling service-linked role (AWSServiceRoleForAutoScaling) lacks required EC2 permissions
    • Custom service-linked role does not have permissions for encrypted volumes, specific VPCs, or EC2 actions
    • SCP (Service Control Policy) blocking required ec2:RunInstances action

Health Check Failure Troubleshooting

  • Auto Scaling supports multiple health check sources:
    • EC2 Status Checks – Default; checks instance system and instance status
    • ELB Health Checks – Target group health checks when integrated with ALB/NLB
    • VPC Lattice Health Checks – Health checks from VPC Lattice target groups
    • Amazon EBS Health Checks – Monitors attached EBS volume status
    • Custom Health Checks – User-defined via set-instance-health API
  • Common Health Check Issues:
    • Instances marked unhealthy immediately after launch – health check grace period may be too short
    • Application not ready before grace period expires – increase the grace period or fix slow startup
    • ELB health check failing – verify security group allows health check traffic from LB
    • Instances stuck in a launch/terminate loop – check application health and startup scripts
    • Instances failing system status checks – may indicate underlying hardware issues

Scaling Policy Troubleshooting

  • Scaling Not Triggering:
    • CloudWatch alarm not in ALARM state – verify metric and threshold
    • Scaling processes suspended (AlarmNotification, Launch, or Terminate processes)
    • Cooldown period active – scaling actions wait until cooldown expires
    • ASG already at maximum (scale-out) or minimum (scale-in) capacity
  • Predictive Scaling Issues:
    • Insufficient historical data (requires at least 24 hours of load data)
    • Metrics not available in CloudWatch for the prediction
    • Policy in forecast-only mode will not actually scale
  • Target Tracking Issues:
    • Metric math expression errors in custom metrics
    • Scale-in disabled unintentionally
    • Conflicting scaling policies (scale-out and scale-in triggering simultaneously – scale-out takes precedence)

Instance Refresh Troubleshooting

  • Instance refresh allows rolling updates to replace instances with new launch template versions
  • Common Issues:
    • Refresh stuck or slow – minimum healthy percentage too high, leaving no room for replacement
    • New instances failing health checks – launch template changes may have introduced issues
    • Checkpoint failure – application not ready within checkpoint delay period
    • Rollback triggered – instances launched with new configuration failing health checks
    • Cannot start refresh – another refresh or operation already in progress

Warm Pool Troubleshooting

  • Warm pools maintain pre-initialized instances for faster scale-out
  • Common Issues:
    • Instances not entering warm pool – lifecycle hook actions completing with ABANDON result
    • Warm pool instances not transitioning to InService – health check failures during transition
    • Warm pool size not maintained – check MaxGroupPreparedCapacity and min pool size settings
    • Hibernated instances failing to resume – instance type or AMI may not support hibernation

Capacity Rebalancing (Spot) Troubleshooting

  • Capacity Rebalancing proactively replaces Spot Instances at risk of interruption
  • Common Issues:
    • Frequent instance replacements – diversify instance types (recommend 10+ types) across multiple AZs
    • Replacement instances also getting rebalance recommendations – enable attribute-based instance type selection (ABS) for broader diversification
    • Capacity not maintained during rebalancing – ASG temporarily exceeds desired capacity (by design) to launch replacements before terminating at-risk instances

Zonal Shift Troubleshooting

  • Zonal shift (Amazon ARC) allows shifting traffic away from an impaired AZ
  • Common Issues:
    • Zonal shift not available – ensure ASG has zonal shift enabled (AvailabilityZoneImpairmentPolicy)
    • Instances still terminating in shifted zone – check health check behavior setting (IgnoreUnhealthy vs ReplaceUnhealthy)
    • Insufficient capacity after shift – remaining AZs must have capacity to handle full load; consider cross-AZ pre-provisioning

Troubleshooting Commands

  • Use describe-scaling-activities to retrieve error messages:
  • Scaling activities log is retained for 6 weeks
  • Check the StatusCode (Successful, Failed, Cancelled) and StatusMessage fields for details
  • Use --include-deleted-groups to view activities for deleted ASGs

Best Practices to Avoid Launch Failures

  • Use Launch Templates (not launch configurations) for access to all new features
  • Specify multiple instance types (10+) using mixed instances policy or attribute-based instance type selection
  • Configure instances across multiple Availability Zones
  • Use attribute-based instance type selection (ABS) to automatically select instance types matching compute requirements
  • Enable Capacity Rebalancing for Spot Instance workloads
  • Set appropriate health check grace period based on application startup time
  • Monitor ASG activities via CloudWatch metrics and scaling activity history
  • Use instance maintenance policy to control replacement behavior (launch-before-terminate vs terminate-before-launch)

Certification Exam Tips

  • Know the difference between launch templates and launch configurations and that launch configurations are deprecated
  • Understand InsufficientInstanceCapacity errors and the recommendation to use multiple instance types
  • Know health check types (EC2, ELB, VPC Lattice, EBS, Custom) and grace period behavior
  • Understand that scaling activities can be viewed with describe-scaling-activities API
  • Know that conflicting scaling policies resolve in favor of scale-out for availability
  • Understand instance refresh rollback behavior and checkpoint mechanisms

References