# Ensure Auto Scaling group uses multiple Availability Zones - Source: https://support.icompaas.com/support/solutions/articles/a_1793292232460712-ensure-auto-scaling-group-uses-multiple-availability-zones - Section: [Solutions](https://support.icompaas.com/support/solutions) › [AWS_Checks_v5.39.1](https://support.icompaas.com/support/solutions/c_1793285913477877) › [AWS Checks](https://support.icompaas.com/support/solutions/folders/f_1793287194371224) - Last updated: 2026-10-29 - Publisher: iCompaas, Inc. (https://www.icompaas.com) **Description** Ensure that every Amazon EC2 Auto Scaling group is configured to launch instances in more than one Availability Zone within its region. Spreading instances across zones keeps the workload running if one zone has a failure or capacity shortage. **Rationale** A group limited to a single Availability Zone depends entirely on that zone. A zonal outage or lack of capacity can stop the group from replacing or adding instances, causing downtime and dropped traffic, and recovery is slower because the workload cannot move to healthy zones. Distributing each group across at least two Availability Zones, with a load balancer spreading traffic, applies fault isolation and keeps the service available during zonal problems. **Impact** - Improves availability and fault tolerance against the failure of one Availability Zone - Auto Scaling rebalances instances across the zones, which can terminate and launch instances after the change - Cross-zone data transfer charges may apply, and the application must not depend on resources available in only one zone - Each added subnet must have the required routes, security and access to dependent resources **Default Value** There is no default. The Availability Zones are set by the subnets chosen when the group is created, and a group created with only one subnet uses a single zone. **Pre-Requisites** - IAM permissions: autoscaling:DescribeAutoScalingGroups, autoscaling:UpdateAutoScalingGroup and ec2:DescribeSubnets - At least one additional subnet in a different Availability Zone of the same VPC, with the same routing and network access as the existing subnet - If the group is behind a load balancer, the load balancer must also be enabled in the new Availability Zone **Remediation** **Test Plan** **Console:** 1. Sign in to the AWS Management Console at [https://console.aws.amazon.com](https://console.aws.amazon.com/). 2. Open the Amazon EC2 console and select **Auto Scaling Groups** under **Auto Scaling**. 3. Select a group and open the **Details** tab. 4. In the **Network** section, check the **Availability Zones** and subnets used by the group. 5. Repeat for each group in each region in use. 6. If the group uses only one Availability Zone, follow the implementation steps. **CLI:** Show the Availability Zones and subnets of each group: aws autoscaling describe-auto-scaling-groups --region --query "AutoScalingGroups\[\].{Name:AutoScalingGroupName,AvailabilityZones:AvailabilityZones,Subnets:VPCZoneIdentifier}" --output json A group fails if AvailabilityZones lists only one zone. **Implementation Steps** **Console:** 1. Sign in to the AWS Management Console at [https://console.aws.amazon.com](https://console.aws.amazon.com/). 2. Open the Amazon EC2 console and select **Auto Scaling Groups** under **Auto Scaling**. 3. Select the group and open the **Details** tab. 4. In the **Network** section, choose **Edit**. 5. Under **Subnets**, add at least one subnet from a different Availability Zone. 6. Choose **Update**. 7. Repeat for each affected group in each region in use. **CLI:** Set the subnets of the group to subnets in at least two Availability Zones (include the existing subnet): aws autoscaling update-auto-scaling-group --region --auto-scaling-group-name --vpc-zone-identifier "," **Backout Plan** Before making changes, save the group's current settings: aws autoscaling describe-auto-scaling-groups --region --auto-scaling-group-names > -backup.json To roll back: 1. Sign in to the AWS Management Console at [https://console.aws.amazon.com](https://console.aws.amazon.com/). 2. Open the Amazon EC2 console and select **Auto Scaling Groups** under **Auto Scaling**. 3. Select the group, open the **Details** tab and choose **Edit** in the **Network** section. 4. Remove the added subnets so that only the original subnets from the backup remain, then choose **Update**. **CLI:** aws autoscaling update-auto-scaling-group --region --auto-scaling-group-name --vpc-zone-identifier "" Note: rolling back makes the group depend on a single Availability Zone again, and instances in the removed zones are terminated and replaced. **Reference** - [https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-add-az-console.html](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-add-az-console.html) - [https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-availability-zone-balanced.html](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-availability-zone-balanced.html) - [https://docs.aws.amazon.com/autoscaling/ec2/userguide/disaster-recovery-resiliency.html](https://docs.aws.amazon.com/autoscaling/ec2/userguide/disaster-recovery-resiliency.html) - [https://docs.aws.amazon.com/cli/latest/reference/autoscaling/update-auto-scaling-group.html](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/update-auto-scaling-group.html) ## Related compliance guidance - [SOC 2 compliance: a practical implementation guide for cloud-native SaaS teams](https://support.icompaas.com/compliance/soc-2-trust-services-criteria): Configuration checks like this one are the technical half of a SOC 2 / ISO 27001 programme — the guide shows where they fit, what else an auditor expects, and how to evidence them. - [ISO/IEC 27001:2022 compliance: a practical implementation guide](https://support.icompaas.com/compliance/iso-27001-2022): ISO 27001 Annex A.8 (technological controls) is where cloud hardening evidence lands; the guide shows how to run the ISMS around it.