Understanding the Difference Between Virtual AZ and Physical AZ Through Failures

Conclusion The ap-northeast-1a (Virtual AZ) displayed in subnet settings and the actual data center apne1-az1 (Physical AZ) correspond differently for each AWS account. What is an Availability Zone (AZ)? An Availability Zone (AZ) refers to a physical data center managed by AWS. One AZ can consist of one or more data centers. An Availability Zone (AZ) is one or more discrete data centers with redundant power, networking, and connectivity in an AWS Region. AZs give customers the ability to operate production applications and databases that are more highly available, fault tolerant, and scalable than would be possible from a single data center. All AZs in an AWS Region are interconnected with high-bandwidth, low-latency networking, over fully redundant, dedicated metro fiber providing high-throughput, low-latency networking between AZs. All traffic between AZs is encrypted. The network performance is sufficient to accomplish synchronous replication between AZs. AZs make partitioning applications for high availability easy. If an application is partitioned across AZs, companies are better isolated and protected from issues such as power outages, lightning strikes, tornadoes, earthquakes, and more. AZs are physically separated by a meaningful distance, many kilometers, from any other AZ, although all are within 100 km (60 miles) of each other. As of 2025, the Tokyo region (ap-northeast-1) has four AZs. The Osaka region (ap-northeast-3) also has three AZs. https://aws.amazon.com/about-aws/global-infrastructure/regions_az/ In this article, we will refer to an AZ composed of one or more data centers managed by AWS as a Physical AZ. What is a Virtual AZ? When creating a subnet, you set the number of AZs like this: For example, by placing two subnets in a VPC in different AZs, you can ensure redundancy. In this article, we will refer to the AZs assigned with names like ap-northeast-1a at this time as Virtual AZ. Incident in the Tokyo Region on April 15, 2025 The following information was obtained from the Health Dashboard. The incident occurred in apne1-az4. Between 4:40 PM and 5:43 PM JST, there was an issue affecting connectivity to some EC2 instances in a single Availability Zone (apne1-az4) in the AP-NORTHEAST-1 Region. This was due to a power outage affecting both the primary and secondary power sources for the affected EC2 instances. During this time, customers may have experienced increased error rates and latency for instances launched in the affected Availability Zone and for other AWS APIs using the affected EC2 instances. Engineers responded automatically within minutes and immediately began investigating mitigation measures. This issue is not expected to recur. A small number of remaining instances are hosted on hardware affected by the power outage. We continue to work on recovering all affected instances and volumes, but we recommend replacing any remaining affected instances or volumes if possible for immediate recovery. The issue has been resolved, and the service is operating normally. https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html Is Physical AZ NOT Virtual AZ? Since the incident occurred in apne1-az4, does it mean that ap-northeast-1d and other AZs were not affected? For example, if security groups were deployed in ap-northeast-1a and ap-northeast-1c, can we say they were not affected? The mapping of Physical AZs to Virtual AZs varies by AWS account, and the same Virtual AZ name does not necessarily correspond to the same Physical AZ. https://docs.aws.amazon.com/ram/latest/userguide/working-with-az-ids.html It looks something like this. Since it varies by account, it needs to be confirmed in each environment. How to Check the Correspondence Between Virtual AZs and Physical AZs You can check using the following AWS CLI command: aws ec2 describe-availability-zones --region us-west-2 The output will look like this. ZoneId represents the Physical AZ. { "AvailabilityZones": [ { "State": "available", "OptInStatus": "opt-in-not-required", "Messages": [], "RegionName": "us-west-2", "ZoneName": "us-west-2a", "ZoneId": "usw2-az2", "GroupName": "us-west-2", "NetworkBorderGroup": "us-west-2", "ZoneType": "availability-zone" }, { "State": "available", "OptInStatus": "opt-in-not-required", "Messages": [], "RegionName": "us-west-2", "ZoneName": "us-west-2b", "ZoneId": "usw2-az1", "GroupName": "us-west-2", "NetworkBorderGroup": "us-west-2", "ZoneType": "availability-zone" }, { "State": "available", "OptInStatus": "opt-in-not-required", "Messages": [], "RegionName": "us-wes

Apr 28, 2025 - 15:20

Understanding the Difference Between Virtual AZ and Physical AZ Through Failures

Conclusion

The ap-northeast-1a (Virtual AZ) displayed in subnet settings and the actual data center apne1-az1 (Physical AZ) correspond differently for each AWS account.

What is an Availability Zone (AZ)?

An Availability Zone (AZ) refers to a physical data center managed by AWS. One AZ can consist of one or more data centers.

An Availability Zone (AZ) is one or more discrete data centers with redundant power, networking, and connectivity in an AWS Region. AZs give customers the ability to operate production applications and databases that are more highly available, fault tolerant, and scalable than would be possible from a single data center. All AZs in an AWS Region are interconnected with high-bandwidth, low-latency networking, over fully redundant, dedicated metro fiber providing high-throughput, low-latency networking between AZs. All traffic between AZs is encrypted. The network performance is sufficient to accomplish synchronous replication between AZs. AZs make partitioning applications for high availability easy. If an application is partitioned across AZs, companies are better isolated and protected from issues such as power outages, lightning strikes, tornadoes, earthquakes, and more. AZs are physically separated by a meaningful distance, many kilometers, from any other AZ, although all are within 100 km (60 miles) of each other.

As of 2025, the Tokyo region (ap-northeast-1) has four AZs. The Osaka region (ap-northeast-3) also has three AZs.
https://aws.amazon.com/about-aws/global-infrastructure/regions_az/

In this article, we will refer to an AZ composed of one or more data centers managed by AWS as a Physical AZ.

What is a Virtual AZ?

When creating a subnet, you set the number of AZs like this:

For example, by placing two subnets in a VPC in different AZs, you can ensure redundancy.

In this article, we will refer to the AZs assigned with names like ap-northeast-1a at this time as Virtual AZ.

Incident in the Tokyo Region on April 15, 2025

The following information was obtained from the Health Dashboard. The incident occurred in apne1-az4.

Between 4:40 PM and 5:43 PM JST, there was an issue affecting connectivity to some EC2 instances in a single Availability Zone (apne1-az4) in the AP-NORTHEAST-1 Region. This was due to a power outage affecting both the primary and secondary power sources for the affected EC2 instances. During this time, customers may have experienced increased error rates and latency for instances launched in the affected Availability Zone and for other AWS APIs using the affected EC2 instances. Engineers responded automatically within minutes and immediately began investigating mitigation measures. This issue is not expected to recur. A small number of remaining instances are hosted on hardware affected by the power outage. We continue to work on recovering all affected instances and volumes, but we recommend replacing any remaining affected instances or volumes if possible for immediate recovery. The issue has been resolved, and the service is operating normally.

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html

Is Physical AZ NOT Virtual AZ?

Since the incident occurred in apne1-az4, does it mean that ap-northeast-1d and other AZs were not affected?
For example, if security groups were deployed in ap-northeast-1a and ap-northeast-1c, can we say they were not affected?

The mapping of Physical AZs to Virtual AZs varies by AWS account, and the same Virtual AZ name does not necessarily correspond to the same Physical AZ.

https://docs.aws.amazon.com/ram/latest/userguide/working-with-az-ids.html

It looks something like this. Since it varies by account, it needs to be confirmed in each environment.

How to Check the Correspondence Between Virtual AZs and Physical AZs

You can check using the following AWS CLI command:

aws ec2 describe-availability-zones --region us-west-2

The output will look like this. ZoneId represents the Physical AZ.

{
    "AvailabilityZones": [
        {
            "State": "available",
            "OptInStatus": "opt-in-not-required",
            "Messages": [],
            "RegionName": "us-west-2",
            "ZoneName": "us-west-2a",
            "ZoneId": "usw2-az2",
            "GroupName": "us-west-2",
            "NetworkBorderGroup": "us-west-2",
            "ZoneType": "availability-zone"
        },
        {
            "State": "available",
            "OptInStatus": "opt-in-not-required",
            "Messages": [],
            "RegionName": "us-west-2",
            "ZoneName": "us-west-2b",
            "ZoneId": "usw2-az1",
            "GroupName": "us-west-2",
            "NetworkBorderGroup": "us-west-2",
            "ZoneType": "availability-zone"
        },
        {
            "State": "available",
            "OptInStatus": "opt-in-not-required",
            "Messages": [],
            "RegionName": "us-west-2",
            "ZoneName": "us-west-2c",
            "ZoneId": "usw2-az3",
            "GroupName": "us-west-2",
            "NetworkBorderGroup": "us-west-2",
            "ZoneType": "availability-zone"
        },
        {
            "State": "available",
            "OptInStatus": "opt-in-not-required",
            "Messages": [],
            "RegionName": "us-west-2",
            "ZoneName": "us-west-2d",
            "ZoneId": "usw2-az4",
            "GroupName": "us-west-2",
            "NetworkBorderGroup": "us-west-2",
            "ZoneType": "availability-zone"
        }
    ]
}

Importance of Design for Failure

This incident has reinforced the importance of Design for Failure.
It is crucial to design for redundancy across multiple AZs rather than relying on a single AZ configuration.