障害で理解した仮想AZと物理AZの違い

結論

サブネット設定などで表示されるap-northeast-1a（仮想AZ）と、実際のデータセンターapne1-az1（物理AZ）は、AWSアカウント単位で対応付けが異なる

アベイラビリティゾーン(AZ)とは？

アベイラビリティゾーン（Availability Zone:AZ）とは、AWSが管理する物理的なデータセンターを指します。
また、1つのAZは1つ以上のデータセンターで構成されています。

アベイラビリティゾーン (AZ) とは、1 つの AWS リージョン内でそれぞれ切り離され、冗長的な電力源、ネットワーク、そして接続機能を備えている 1 つ以上のデータセンターのことです。AZ によって、単一のデータセンターでは実現できない高い可用性、耐障害性、および拡張性を備えた本番用のアプリケーションとデータベースの運用が実現されています。AWS リージョン内のすべての AZ は、AZ 間に高スループットかつ低レイテンシーのネットワーキングを提供する、完全に冗長性を持つ専用メトロファイバー上に構築された、高帯域幅、低レイテンシーのネットワーキングで相互接続されています。AZ 間のすべてのトラフィックは暗号化されます。AZ 間の同期レプリケーションを実行するのに十分なネットワークパフォーマンスを備えています。AZ により、高可用性実現を目的にしたアプリケーションの分割が簡単になります。アプリケーションが AZ 間で分割されている場合、企業は停電、落雷、竜巻、地震などの問題からより安全に隔離され保護されます。各 AZ はそれぞれ他の AZ から物理的に意味のある距離、つまり数キロメートル離れていますが、互いにすべて 100 km (60 マイル) 以内に配置されています。

2025年現在、東京リージョンには4つのAZがあります。
大阪リージョンにも3つのAZがあります。
https://aws.amazon.com/jp/about-aws/global-infrastructure/regions_az/

以下、「本記事ではAWSが管理する1つ以上のデータセンターで構成されるAZ」を物理AZと呼びます。

仮想AZとは？

サブネットを作成する際にこんな感じでAZの数を設定します。

例えば、VPCに2つのサブネットをそれぞれ異なるAZに配置することで、冗長性を確保できます。

本記事では、この時の「ap-northeast-1aなどの名称で割り当てられるAZ」を論理AZと呼びます。

2025/4/15発生の東京リージョンの障害について

以下、Health Dashboardから得た情報です。
障害が発生したのは、apne1-az4でした。

午後 4:40 から午後 5:43 (日本時間) の間、AP-NORTHEAST-1 リージョンの単一のアベイラビリティーゾーン (apne1-az4) において、一部の EC2 インスタンスへの接続の問題が発生しました。これは、影響を受けた EC2 インスタンスへの主電源と二次電源が遮断されたことが原因でした。この間、お客さまは、影響を受けたアベイラビリティゾーンで起動されたインスタンスや、影響を受けた EC2 インスタンスを使用する他の AWS API において、エラー率やレイテンシーの増加の影響を受けた可能性があります。エンジニアは数分以内に自動的に対応し、すぐに緩和策の調査を開始しました。この問題は再発しないことが期待されています。残りの少数のインスタンスは、停電による悪影響を受けたハードウェアでホストされています。影響を受けたすべてのインスタンスとボリュームの復旧に引き続き取り組んでいきますが、即座に復旧を行うためには、可能であれば、影響が残存しているインスタンスまたはボリュームを交換することをお勧めします。事象は解決し、サービスは正常に動作しています。

物理AZ≠論理AZ？

障害が発生したAZはapne1-az4なので、ap-northeast-1d以外には影響ないのでしょうか？
例えば、セキュリティグループをap-northeast-1aとap-northeast-1cに展開していた場合は、影響がなかったといえるのでしょうか？

物理AZと論理AZのマッピングはAWSアカウントごとに異なり、必ずしも同じ論理AZ名だから物理AZも一致するわけではありません。

イメージ的にはこんな感じです。
アカウントによって変わるため、各環境で確認する必要があります。

論理AZと物理AZの対応を確認するには

以下AWS CLIコマンドで確認できます。

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

以下のような出力となります。
ZoneIdが物理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"
        }
    ]
}

Design for Failureの大切さ

今回の障害によりDesign for Failureの大切さを改めて理解しました。
単一AZでの構成ではなく、複数AZでの冗長化の設計思想が大切かと思います。