AWS EC2 Auto Scaling now lets you enable Launch Before Terminate as the default replacement behavior across all Auto Scaling groups in your account. When enabled, Auto Scaling launches a replacement instance and waits for it to pass health checks before terminating the instance it replaces, helping your applications maintain full capacity and availability during instance replacement events. This applies to replacement events such as instance refreshes, rebalancing, health checks, and maximum-instance-lifetime replacements. You can enable Launch Before Terminate through AWS EC2 Auto Scaling account settings, which let you configure the behavior once at the account level instead of on each Auto Scaling group individually. You can manage the setting with the new `PutAccountSetting` and `DescribeAccountSettings` APIs, available through the AWS Management Console, AWS CLI, or AWS SDKs. Launch Before Terminate is available in all AWS Regions at no additional cost. To learn more, see Launch Before Terminate in the AWS EC2 Auto Scaling User Guide and AWS EC2 Auto Scaling API Reference Guide.

AWS EC2 Auto Scaling now lets you enable Launch Before Terminate as the default replacement behavior across all Auto Scaling groups in your account. When enabled, Auto Scaling launches a replacement instance and waits for it to pass health checks before terminating the instance it replaces, helping your applications maintain full capacity and availability during instance replacement events. This applies to replacement events such as instance refreshes, rebalancing, health checks, and maximum-instance-lifetime replacements. You can enable Launch Before Terminate through AWS EC2 Auto Scaling account settings, which let you configure the behavior once at the account level instead of on each Auto Scaling group individually. You can manage the setting with the new `PutAccountSetting` and `DescribeAccountSettings` APIs, available through the AWS Management Console, AWS CLI, or AWS SDKs. Launch Before Terminate is available in all AWS Regions at no additional cost. To learn more, see Launch Before Terminate in the https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-account-settings.html and https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_Operations.html.

EC2 Image Builder now supports using existing instances from an Auto Scaling Group (ASG) for building images, enabling faster builds by eliminating the time spent in launching and bootstrapping new instances and reusing already running EC2 instances. With this feature, you can provide an ASG in your Image Builder infrastructure configuration. Instead of launching a new instance at the build time, Image Builder selects an already-running instance from this ASG, applies your build components, and creates the image. The ASG continuously replenishes the pool as instances are used for builds, ensuring instances are always available for subsequent pipeline runs. This feature is fully opt-in and does not affect existing pipelines. Pipelines without an ASG configured continue to use the default launch path with no behavior change. This feature is available in all AWS Regions at no additional cost. To configure ASG integration in your Image Builder pipelines, see the https://docs.aws.amazon.com/imagebuilder/latest/userguide/infra-config-parent-instance.html.

EC2 Image Builder now supports using existing instances from an Auto Scaling Group (ASG) for building images, enabling faster builds by eliminating the time spent in launching and bootstrapping new instances and reusing already running EC2 instances. With this feature, you can provide an ASG in your Image Builder infrastructure configuration. Instead of launching a new instance at the build time, Image Builder selects an already-running instance from this ASG, applies your build components, and creates the image. The ASG continuously replenishes the pool as instances are used for builds, ensuring instances are always available for subsequent pipeline runs. This feature is fully opt-in and does not affect existing pipelines. Pipelines without an ASG configured continue to use the default launch path with no behavior change. This feature is available in all AWS Regions at no additional cost. To configure ASG integration in your Image Builder pipelines, see the EC2 Image Builder documentation.

https://aws.amazon.com/about-aws/whats-new/2026/01/ec2-auto-scaling-new-mechanisms-group-deletion-protection/ https://docs.aws.amazon.com/autoscaling/ec2/userguide/resource-deletion-protection.html https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonec2autoscaling.html#amazonec2autoscaling-policy-keys https://docs.aws.amazon.com/autoscaling/ec2/userguide/control-access-using-iam.html#policy-auto-scaling-condition-keys Eyal Estrin CISSP, CCSP, CISM, CISA, CDPSE, CCSK Blog: https://security-24-7.com | Books: https://amzn.to/42Xai9A | https://amzn.to/3Sggbtv Twitter: @eyalestrin | Bluesky: @eyalestrin.bsky.social

Amazon EC2 Auto Scaling now supports batch instance termination in a single API call. You can now pass up to 100 instance IDs to the TerminateInstanceInAutoScalingGroup API to terminate them as a batch, reducing the number of API calls needed to scale down your Auto Scaling groups. Batch termination is designed for workloads that need to rapidly scale down, such as AI/ML training jobs, container orchestrators, or event-driven architectures that spin up large fleets temporarily. All instances in a batch are validated atomically before termination begins, and existing Auto Scaling behaviors such as lifecycle hooks and load balancer connection draining are preserved for each instance in the batch. This feature is available in all AWS Regions at no additional cost. To learn more, visit https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-scaling-manually.html and https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_TerminateInstanceInAutoScalingGroup.html.

Amazon EC2 Auto Scaling now supports Instance Refresh as a new AWS CloudFormation update policy. When you configure the new AutoScalingInstanceRefresh update policy and update properties that require instance replacement, CloudFormation automatically triggers an Instance Refresh. With this integration, you can now access Instance Refresh capabilities including replace root volume for in-place updates, launch-before-terminate, alarm-based monitoring, and checkpoints with bake time for controlled rollouts. Auto Scaling features such as scaling policies and health checks remain active throughout the update, so your service health is not at risk during deployments. Rollback is handled through CloudFormation stack rollback. This feature is available in all AWS Regions at no additional cost. To learn more, see https://docs.aws.amazon.com/AWSCloudFormation/latest/TemplateReference/aws-attribute-updatepolicy.html#cfn-attributes-updatepolicy-instancerefresh in the AWS CloudFormation Template Reference.

Amazon EC2 Auto Scaling now offers reservations-then-balanced, a new Availability Zone (AZ) distribution strategy that prioritizes launching instances into your capacity reservations before distributing remaining capacity evenly across Availability Zones. This enables you to maximize utilization of pre-purchased capacity such as On-Demand Capacity Reservations (ODCRs), Capacity Blocks, and Interruptible Capacity Reservations, while retaining the operational simplicity and resilience of Auto Scaling. Starting today, you can configure reservations-then-balanced by setting the capacity distribution strategy in the AvailabilityZoneDistribution configuration of your Auto Scaling group and targeting reservations by Capacity Reservation Group ARN or by individual Capacity Reservation IDs. There is no additional charge to use reservations-then-balanced; you continue to pay standard EC2 pricing for your reservations and any On-Demand or Spot instances launched by the group. Reservations-then-balanced is available today in all AWS commercial Regions. To learn more, visit the https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-availability-zone-balanced.html.

EC2 Auto Scaling is introducing a new policy condition key https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonec2autoscaling.html#amazonec2autoscaling-policy-keys. This condition key is used with the DeleteAutoScalingGroup action to control whether the ForceDelete parameter can be used during deletion, which determines if an Auto Scaling group (ASG) can be deleted while it still contains running instances. You can use this condition key in IAM policies to restrict deletion permissions. This provides a safety measure to prevent accidental deletion of ASGs that still have running instances. Furthermore, EC2 Auto Scaling now offers deletion protection at the group level. The new deletion-protection configuration can be set either when you create your ASGs or update them. This new feature lets you set enhanced controls based on your workload's criticality, with multiple protection levels available to safeguard against accidental deletions and help maintain application availability. Combining the autoscaling:ForceDelete condition key with deletion protection at the group level provides a layered defense against unwanted ASG termination by allowing you to both restrict IAM permissions for force-delete operations and set enhanced protection controls directly on critical ASGs. The features now available in all https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/ and AWS GovCloud (US) Regions. To get started, visit the EC2 Auto Scaling console or refer to our https://docs.aws.amazon.com/autoscaling/ec2/userguide/resource-deletion-protection.html and https://docs.aws.amazon.com/autoscaling/ec2/userguide/control-access-using-iam.html#policy-auto-scaling-condition-keys for Amazon EC2 Auto Scaling.

Today, EC2 Auto Scaling is launching a new API, LaunchInstances, which gives customers more control and flexibility over how EC2 Auto Scaling provisions instances while providing instant feedback on capacity availability. Customers use EC2 Auto Scaling for automated fleet management. With scaling policies, EC2 Auto Scaling can automatically add instances when demand spikes and remove them when traffic drops, ensuring customers' applications always have the right amount of compute. EC2 Auto Scaling also offers the ability to monitor and replace unhealthy instances. In certain use cases, customers may want to specify exactly where EC2 Auto Scaling should launch additional instances and need immediate feedback on capacity availability. The new LaunchInstances API allows customers to precisely control where instances are launched by specifying an override for any Availability Zone and/or subnet in an Auto Scaling group, while providing immediate feedback on capacity availability. This synchronous operation gives customers real-time insight into scaling operations, enabling them to quickly implement alternative strategies if needed. For additional flexibility, the API includes optional asynchronous retries to help reach the desired capacity. This feature is now available in all https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/ and AWS GovCloud (US) Regions, at no additional cost beyond standard EC2 and EBS usage. To get started, visit the https://aws.amazon.com/cli/ and the https://aws.amazon.com/tools/. To learn more about this feature, visit the https://docs.aws.amazon.com/autoscaling/ec2/userguide/launch-instances-synchronously. 

Today, Amazon EC2 Auto Scaling announced a new strategy, ReplaceRootVolume, within instance refresh. This feature allows customers to update the root volume of an EC2 instance without stopping or terminating the instance, while preserving other associated instance resources. The capability reduces operational complexity, simplifies software patching, and streamlines recovery from corrupted root volumes. Customers use instance refresh to update the instances in their Auto Scaling groups (ASGs). This feature can be useful when customers want to migrate their instances to new instance types to take advantage of the latest improvements and optimizations. Traditionally, this process involved terminating older instances and launching new ones in a controlled manner. The new ReplaceRootVolume strategy transforms how customers manage instance lifecycles and software updates in their ASGs by enabling EC2 Auto Scaling service to replace the root Amazon EBS volume for running instances without stopping them. Organizations can now implement OS-level updates and security patches more efficiently without worrying about capacity management. This is especially valuable for workloads that use specialized instance types like Mac or GPU instances. Customers with stateful applications can now refresh their fleets with more confidence that their instances data, metadata, and attachments (such as network interfaces and elastic IPs) will be preserved with the new ReplaceRootVolume strategy. This feature is now available in US East (N. Virginia), US West (Oregon), Europe (Ireland), and Asia Pacific (Singapore), at no additional cost beyond standard EC2 and EBS usage. To get started, refer to our https://docs.aws.amazon.com/autoscaling/ec2/userguide/replace-root-volume.html.

Today, EC2 Auto Scaling announces a new feature called instance lifecycle policy. Customers can now configure a way to retain their instances when their termination lifecycle hooks fail or timeout, providing greater confidence in managing instances for graceful shutdown. You can add https://docs.aws.amazon.com/autoscaling/ec2/userguide/lifecycle-hooks.html to an Auto Scaling group (ASG) to perform custom actions when an instance enters a wait state. You can choose a target service (e.g., Amazon EventBridge or AWS Lambda) to perform these actions depending on your preferred development approach. Customers use ASG lifecycle hooks to save application state, properly close database connections, back up important data from local storage, delete sensitive data/credentials, or deregister from service discovery before instance termination. Previously, both default results—continue and abandon—led to ASG terminating instances when the lifecycle hook timeout elapsed or if an unexpected failure occurred. With the new instance lifecycle policy, you can now configure retention-triggers to keep your instances in a retained state for manual intervention until you're ready to terminate them again. This policy provides greater confidence in graceful instance termination and is especially helpful for stateful applications running on ASG. This feature is now available in US East (N. Virginia), US West (Oregon), Europe (Ireland), and Asia Pacific (Singapore). To get started, visit the EC2 Auto Scaling console or refer to our https://docs.aws.amazon.com/autoscaling/ec2/userguide/instance-lifecycle-policy.html.

Today, EC2 Auto Scaling is launching a new API, LaunchInstances, which gives customers more control and flexibility over how EC2 Auto Scaling provisions instances while providing instant feedback on capacity availability. Customers use EC2 Auto Scaling for automated fleet management. With scaling policies, EC2 Auto Scaling can automatically add instances when demand spikes and remove them when traffic drops, ensuring customers' applications always have the right amount of compute. EC2 Auto Scaling also offers the ability to monitor and replace unhealthy instances. In certain use cases, customers may want to specify exactly where EC2 Auto Scaling should launch additional instances and need immediate feedback on capacity availability. The new LaunchInstances API allows customers to precisely control where instances are launched by specifying an override for any Availability Zone and/or subnet in an Auto Scaling group, while providing immediate feedback on capacity availability. This synchronous operation gives customers real-time insight into scaling operations, enabling them to quickly implement alternative strategies if needed. For additional flexibility, the API includes optional asynchronous retries to help reach the desired capacity. This feature is now available in US East (N. Virginia), US West (Oregon), Europe (Ireland), and Asia Pacific (Singapore), at no additional cost beyond standard EC2 and EBS usage. To get started, visit the https://aws.amazon.com/cli/ and the https://aws.amazon.com/tools/. To learn more about this feature, visit the https://docs.aws.amazon.com/autoscaling/ec2/userguide/launch-instances-synchronously. 

Starting today, you can add warm pools to Auto Scaling groups (ASGs) that have https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-mixed-instances-groups.html. With warm pools, customers can improve the elasticity of their applications by creating a pool of pre-initialized EC2 instances that are ready to quickly serve application traffic. By combining warm pools with instance type flexibility, an ASG can rapidly scale out to its maximum size at any time, deploying applications across multiple instance types to enhance availability. Warm pools are particularly beneficial for applications with lengthy initialization processes, such as writing large amounts of data to disk, running complex custom scripts, or other time-consuming setup procedures that can take several minutes or longer to serve traffic. With this new release, the warm pool feature now works seamlessly with ASGs configured for multiple On-Demand instance types, whether specified through manual instance type lists or attribute-based instance type selection. The combination of instance type flexibility and warm pools provides a powerful solution that helps customers scale out efficiently while maximizing availability. The warm pool feature is available through the https://console.aws.amazon.com/console/home, the https://aws.amazon.com/tools/, and the https://aws.amazon.com/cli/. It is available in all https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/ and https://aws.amazon.com/govcloud-us/ Regions. To learn more about warm pools, visit this https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-warm-pools.html.

Customers can now enable predictive scaling for their Auto Scaling groups (ASGs) in six more regions: Asia Pacific (Hyderabad), Asia Pacific (Melbourne), Israel (Tel Aviv), Canada West (Calgary), Europe (Spain), and Europe (Zurich). Predictive Scaling can proactively scale out your ASGs to be ready for upcoming demand. This allows you to avoid the need to over-provision capacity, resulting in lower EC2 cost, while ensuring your application’s responsiveness. To see the list of all supported AWS public regions and AWS GovCloud (US) regions, https://docs.aws.amazon.com/autoscaling/ec2/userguide/predictive-scaling-policy-overview.html#predictive-scaling-regions. Predictive Scaling is appropriate for applications that experience recurring patterns of steep demand changes, such as early morning spikes when business resumes. It learns from the past patterns and launches instances in advance of predicted demand, giving instances time to warm up. Predictive scaling enhances existing Auto Scaling policies, such as Target Tracking or Simple Scaling, so that your applications scale based on both real-time metrics and historic patterns. You can preview how Predictive Scaling works with your ASG by using the “Forecast Only” mode. Predictive Scaling is available as a scaling policy type through AWS Command Line Interface (CLI), EC2 Auto Scaling Management Console, AWS CloudFormation and AWS SDKs. To learn more, visit the Predictive Scaling page in the https://docs.aws.amazon.com/autoscaling/ec2/userguide/predictive-scaling-policy-overview.html#predictive-scaling-regions.

Amazon EC2 Auto Scaling (ASG) now supports Internet Protocol Version 6 (IPv6), enabling dual-stack configuration (IPv4 and IPv6) connectivity for your Auto Scaling groups. https://aws.amazon.com/vpc/ipv6/ enables an expanded address space, enabling you to scale your application on AWS beyond the typical constraints of the number of IPv4 addresses in your VPC. With IPv6, you can assign easy to manage contiguous IP ranges to micro-services and can get virtually unlimited scale for your applications. Moreover, with support for both IPv4 and IPv6, you can gradually transition applications from IPv4 to IPv6, enabling safer migration. IPv6 support is available in all https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/ (except New Zealand) and GovCloud regions where ASG is available. To learn more about configuring your network to use IPv6 endpoints, see the https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-instance-addressing.html#ipv6-addressing.

Starting today, Amazon EC2 Auto Scaling (ASG) supports Federal Information Processing Standard (FIPS) 140-3 validated VPC endpoints. With this launch, you can use AWS PrivateLink with ASG for regulated workloads that require secure connections using FIPS 140-3 validated cryptographic modules. FIPS-compliant endpoints help organizations contracting with the U.S. federal government meet FIPS security requirements for encrypting sensitive data in supported regions. To create a VPC endpoint that connects to an ASG endpoint, see https://docs.aws.amazon.com/autoscaling/ec2/userguide/asg-in-vpc.html. This capability is available in the following regions: US East (N. Virginia), US East (Ohio), US West (N. California), US West (Oregon), Canada (Central), and Canada West (Calgary). For more information about FIPS 140-3 at AWS, visit https://aws.amazon.com/compliance/fips/. To learn more about Amazon EC2 Auto Scaling, visit the ASG https://aws.amazon.com/ec2/autoscaling/.

Amazon EC2 Auto Scaling now enables customers to force cancel instance refreshes immediately, without waiting for in-progress instance launches or terminations to complete. This enhancement provides greater control over Auto Scaling group (ASG) updates, especially during emergency situations such as when needing to rapidly roll forward to a new application deployment when the current deployment is causing service disruptions. Customers can now quickly abort ongoing deployments and immediately start new instance refreshes when needed. Instance refreshes are used to update instances within an ASG, typically when configuration changes require instance replacement. To use this feature, set the WaitForTransitioningInstances to false when calling the CancelInstanceRefresh API. This enables faster cancellation of the instance refresh, bypassing the wait for any pending instance activities such as instance lifecycle hooks. This feature is available in all AWS regions, including AWS GovCloud (US) Regions. To get started, please visit https://docs.aws.amazon.com/autoscaling/ec2/userguide/cancel-instance-refresh.html#cancel-instance-refresh-cli.

AWS Compute Optimizer now detects idle EC2 Auto Scaling groups using G and P instance types, enabling you to identify additional savings opportunities in your AWS spend. As AI development accelerates, organizations are creating more Auto Scaling groups with G and P instance types for training and inference workloads. Once you https://alpha.www.docs.aws.a2z.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Agent-NVIDIA-GPU.html Compute Optimizer analyzes utilization data and identifies groups that have completed jobs and remained idle during your specified lookback period, making it easier to identify and prevent waste on these high-cost instance types. This new feature is available in all https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/ where AWS Compute Optimizer is available except for the AWS GovCloud (US) and the China Regions. The new recommendations will also be available in https://aws.amazon.com/aws-cost-management/cost-optimization-hub/. For more information about Compute Optimizer, visit our https://aws.amazon.com/compute-optimizer/ and https://docs.aws.amazon.com/compute-optimizer/latest/ug/view-ec2-recommendations.html. You can start using AWS Compute Optimizer through the AWS Management Console, AWS Services CLI, or AWS SDK.  

Cost Optimization Hub now supports idle EC2 Auto Scaling group recommendations and rightsizing recommendations for EC2 Auto Scaling groups with scaling policies and multiple instance types. It also allows you to easily filter and aggregate EC2 Auto Scaling group cost optimization opportunities separately from standalone EC2 instances, making it easier to identify EC2 Auto Scaling groups with the highest cost-saving opportunities. With this launch, you can view, consolidate, and prioritize cost optimization opportunities for EC2 Auto Scaling groups across your organization’s member accounts and AWS Regions through a single dashboard. Cost Optimization Hub helps you quantify estimated savings from these recommendations, taking into account your specific discounts, such as Reserved Instances and Savings Plans, enabling you to easily compare and prioritize recommendations. The new EC2 Auto Scaling group experience and recommendations are available in https://aws.amazon.com/aws-cost-management/cost-optimization-hub/ across all https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/ where Cost Optimization Hub and AWS Organizations are supported.  

Today, we are launching two new capabilities to EC2 Auto Scaling (ASG) that improve the responsiveness of Target Tracking scaling policies. Target Tracking now automatically adapts to the unique usage patterns of your individual applications, and can be configured to monitor high-resolution CloudWatch metrics to make more timely scaling decisions. With this release, you can enhance your application performance, and also maintain high utilization for your EC2 resources to save costs. Scaling based on sub-minute CloudWatch metrics enables customers, with applications that have volatile demand patterns, like client-serving APIs, live streaming services, ecommerce websites, or on-demand data processing, reduce the time to detect and respond to changing demand. In addition, Target Tracking policies now self-tune their responsiveness, using historical usage data to determine the optimal balance between cost and performance for each application that saves customers’ time and effort. Both these new features are available in select https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-scaling-target-tracking.html, and Target Tracking policies will begin self-tuning once they have completed analyzing your application’s usage patterns. You can use Amazon Management Console, CLI, SDKs, and CloudFormation to update your Target Tracking configurations. Refer https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-scaling-target-tracking.html.

Amazon EC2 introduces a new capability that makes it easy for customers to target instance launches on their https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/capacity-reservation-overview.html. On-Demand Capacity Reservations help you reserve compute capacity for your workloads in a specific Availability Zone for any duration. This new feature allows you to better utilize your On-Demand Capacity Reservations by ensuring that launches from the RunInstances EC2 API and EC2 Auto Scaling groups will only be fulfilled by your targeted or open Capacity Reservations. To get started, customers simply specify they if want to only launch on ODCR capacity on either their RunInstances EC2 API, Launch Templates, or Auto-Scaling Groups (ASGs). This capability is now available in all AWS Regions, except China regions. To get started, please refer to the documentation for use with https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/capacity-reservations-launch.html and https://docs.aws.amazon.com/autoscaling/ec2/userguide/use-ec2-capacity-reservations.html.  

Starting today, EC2 Auto Scaling and EC2 Fleet customers can express their EC2 instances’ CPU-performance requirements as part of the Attribute-Based Instance Type Selection (ABIS) configuration. With ABIS, customers can already choose a list of instances types by defining a set of desired resource requirements, such as the number of vCPU cores and memory per instance. Now, in addition to the quantitative resource requirements, customers can also identify an instance family that ABIS will use as a baseline to automatically select instance types that offer similar or better CPU performance, enabling customers to further optimize their instance-type selection. ABIS is a powerful tool for customers looking to leverage instance type diversification to meet their capacity requirements. For example, customers who use Spot Instances to launch into limited EC2 spare capacity for a discounted price, access multiple instance types to successfully fulfill their larger capacity needs and experience fewer interruptions. With this release, for example, customers can use ABIS in a launch request for instances that can be in the C, M, and R instance classes, with a minimum of 4 vCPUs, and provide CPU performance in line with the C6i instance family, or better. The feature is available in all AWS commercial and the AWS GovCloud (US) Regions. You can use Amazon Management Console, CLI, SDKs, and CloudFormation to update your instance requirements. To get started, refer the user guide for https://docs.aws.amazon.com/autoscaling/ec2/userguide/create-mixed-instances-group-attribute-based-instance-type-selection.html and https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-fleet-attribute-based-instance-type-selection.html.

EC2 Auto Scaling now supports Amazon Application Recovery Controller (ARC) zonal shift and zonal autoshift to help you quickly recover an impaired application from failures in an Availability Zone (AZ). Starting today, you can shift the launches of EC2 instances in an Auto Scaling Group (ASG) away from an impaired AZ to quickly recover your unhealthy application in another AZ, reducing the duration and severity of impact due to events such as power outages and hardware, or software failures. This new integration also brings support for ARC zonal autoshift, which automatically starts a zonal shift for enabled ASGs when AWS identifies a potential failure affecting an AZ. You can initiate a zonal shift for an ASG from the Amazon EC2 Auto Scaling or Application Recovery Controller console. You can also use the AWS SDK to start a zonal shift and programmatically shift the instances in your ASG away from an AZ, and shift it back once the affected AZ is healthy. There is no additional charge for using zonal shift. Zonal shift is now available in all AWS Regions. To get started, read the https://aws.amazon.com/blogs/compute/using-zonal-shift-with-amazon-ec2-auto-scaling/, or refer to the https://docs.aws.amazon.com/r53recovery/latest/dg/arc-zonal-shift.html.  

Amazon Application Recovery Controller (ARC) zonal shift and zonal autoshift have expanded their capabilities and now support EC2 Auto Scaling. ARC zonal shift helps you quickly recover an unhealthy application in an Availability Zone (AZ), and reduce the duration and severity of impact to the application due to events such as power outages and hardware or software failures. ARC zonal autoshift safely and automatically shifts your application’s traffic away from an AZ when AWS identifies a potential failure affecting that AZ. EC2 Auto Scaling customers can now shift traffic away from an AZ in the event of a failure. Zonal shift works with EC2 Auto Scaling by stopping dynamic scale-in, so that capacity is not unnecessarily removed and launching new EC2 instances in the healthy AZs only. In addition, you can set health checks to enabled in the impaired AZ or disable health checks in the impaired AZ. When disabled, it will pause unhealthy instance replacement in the AZ that has an active zonal shift. Enable your EC2 Auto Scaling Groups for zonal shift using the EC2 Auto Scaling console or API, and then trigger a zonal shift or enable autoshift via ARC zonal shift console or API. To learn more review the https://docs.aws.amazon.com/r53recovery/latest/dg/arc-zonal-shift.resource-types.ec2-auto-scaling-groups.html and read this https://aws.amazon.com/blogs/compute/using-zonal-shift-with-amazon-ec2-auto-scaling/. There is no additional charge for using zonal shift or zonal autoshift. See the https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/ for the most up-to-date availability information.