はじめに
背景
本ドキュメントは、AWSのZone IDに関する調査結果を分かりやすくまとめたものです。可用性ゾーン（Availability Zone）はリージョン内の分散された物理的な場所を示しますが、同じ場所でもアカウントごとに見える名前が異なることがあります。Zone IDはその違いを解消するための固有識別子です。
このドキュメントの目的
Zone IDの定義、特徴、確認方法、そしてマルチアカウント環境での活用法を丁寧に説明します。運用時に起きがちな混乱を減らし、設計やトラブルシューティングを助けることを目的としています。
簡単な例
たとえば、アカウントAでは「ap-northeast-1a」、アカウントBでは「ap-northeast-1c」と表示される可用性ゾーンが、実際には同じ物理設備に属していることがあります。Zone IDで見ると両者は同じIDになり、同一性を正しく把握できます。
対象読者
クラウド運用者、アーキテクト、開発者向けです。専門的な用語は必要最小限に抑え、具体例で補足します。
本ドキュメントの構成
全5章で構成します。本章は導入、続く章で基本概念、必要性、確認方法、マルチアカウントでの一貫性確保を順に解説します。
AWS Zone IDの基本概念
概要
AWSのインフラは複数のリージョンと可用性ゾーン（AZ）で成り立っています。Zone IDは、物理的な場所をアカウント間で一意に表す識別子です。これにより、同じ物理ゾーンを複数アカウントで確実に指定できます。
Zone IDの形式
Zone IDは次のような形式になります。リージョンコードの先頭3文字＋リージョン末尾の数字＋”-az”＋番号。例：
– euw1-az1
– use1-az1
この形式は読みやすく、どのリージョンのどのゾーンかがわかります。
従来のAZ名との違い
従来のAvailability Zone名（例：us-east-1a）は、アカウントごとに物理ゾーンへの割り当てが異なります。同じ名前でも物理的には別の場所を指すことがあり、意図せず同一ゾーンにリソースが集まる可能性があります。Zone IDはその問題を解消し、物理的な一貫性を提供します。
利点と利用シーン
- マルチアカウントでの配置を正確に制御できます。
- DR（災害対策）や可用性設計で役立ちます。
- 自動化スクリプトやテンプレートで予測可能な挙動を得られます。
注意点
すべてのAWSサービスで同じ方法で扱われるとは限りません。Zone IDを使う前に対象サービスのドキュメントで対応状況を確認してください。
Zone IDが必要な理由
背景
単一のAWSアカウント内では、Availability Zone（AZ）の名前に頼ってリソースを配置しても問題になりません。複数アカウントでリソースを共有すると、AZ名はアカウントごとに異なる場合があり、同じ名前が必ずしも同じ物理的ゾーンを指すとは限りません。
共有で生じる課題
アカウントAがサブネットやインスタンスをアカウントBと共有すると、B側で同じAZ名を指定しても物理的に別の場所を参照する可能性があります。これにより通信遅延や障害時の冗長化が期待通りに機能しません。
具体例
例えば、アカウントAのZone IDが「use1-az2」のサブネットを共有した場合、相手も同じZone IDで参照できます。したがって、低遅延通信やリソース配置の最適化が可能になります。
主な利点
- 一貫した参照：全アカウントで同じ物理ゾーンを指せます。
- 性能の最適化：遅延を抑えた配置が実現します。
- 運用の明確化：障害対応やネットワーク設計が分かりやすくなります。
注意点
Zone IDは参照用の識別子です。共有前に権限やネットワーク設計を確認し、期待する配置になるか実際に検証してください。
Zone IDの確認方法と表示形式
方法1: EC2ダッシュボード（Service Health Panel）
EC2コンソールのService Health Panelでは、利用可能なAZとそのZone IDを一覧で確認できます。コンソール画面でリージョンを選び、Availability ZonesまたはService Healthの項目を開くと表示されます。GUIなので迷わず確認できます。
方法2: AWS CLI
CLIでまとめて確認する場合は次のコマンドが便利です。
aws ec2 describe-availability-zones --query "AvailabilityZones[*].{Name:ZoneName,ID:ZoneId}" --output table
出力例（US East (Ohio)）:
----------------------------
| DescribeAvailabilityZones|
+-----------+--------------+
| ID | Name |
+-----------+--------------+
| use2-az1 | us-east-2a |
| use2-az2 | us-east-2b |
| use2-az3 | us-east-2c |
+-----------+--------------+
この方法はスクリプトから自動取得したい時に便利です。
方法3: インスタンスメタデータ（IMDS）
EC2インスタンス内部から確認する場合、インスタンスメタデータを参照します。IMDSv2を使う場合の例：
TOKEN=$(curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")
curl -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/placement/availability-zone-id
この結果は、そのインスタンスが属するZone IDを返します。
表示形式の読み方
Zone IDは通常、リージョンコード（例：use）＋リージョン番号（例：2）+”-az”+番号で構成されます。例えば「use2-az1」は、us-east-2リージョンの1番目のAZを指します。人間に分かりやすい名前（us-east-2a）と、リージョン横断で一意なZone IDの両方を使い分けてください。
マルチアカウント環境での一貫性確保
概要
複数アカウントで同じ物理的な可用性ゾーン（AZ）にリソースを置きたいとき、Zone IDを使うと一貫性が保てます。Zone名（例：us-east-1a）はアカウントごとに割り当てが異なるため、Zone IDで揃えると物理的位置が一致します。
手順（実務で使える簡単な流れ）
- 使用するZone IDを決めてリスト化します。例：zone-1, zone-2, zone-3のように、対象リージョンで使用するIDを固定します。
- 各アカウントでZone IDとAZ名のマッピングを確認します。CLIやSDKで“DescribeAvailabilityZones”を実行し、ZoneIdとZoneNameの対応を取得します。
- CloudFormationテンプレートではAvailabilityZoneではなくZoneIdを指定してサブネットやENIを作成します。テンプレートのパラメータ化でアカウントごとのAZ名を気にせずに済みます。
検証と運用
テンプレート適用後に、各アカウントでリソースが同じZoneIdに作成されているかを確認します。簡単なチェックとしては、EC2やサブネットのZoneId属性を照合する方法があります。
自動化のヒント
- 最初にZoneIdのマスターリストを管理用リポジトリに保存します。
- Bootstrapスクリプトで各アカウントからマッピングを取得し、CloudFormationパラメータを自動生成します。
- 変更時はCIで検証を入れて、誤ったAZ配置を防ぎます。
注意点
- リージョン間ではZoneIdは異なります。リージョンをまたぐ設計では個別管理が必要です。
- 一部サービスでZoneId指定が使えないことがあるため、事前に対応可否を確認してください。
