AWS の Availability Zone ID はなぜアカウントごとに異なるのか - AZ マッピングの設計意図
us-east-1a がアカウントごとに異なる物理 AZ を指す仕組み、AZ ID (use1-az1) が導入された背景、キャパシティの均等分散という設計意図、クロスアカウントでの AZ 指定の注意点を解説します。
us-east-1a は全員同じ場所ではない
AWS の Availability Zone 名 (us-east-1a、us-east-1b など) は、アカウントごとに異なる物理的な AZ にマッピングされています。アカウント A の us-east-1a と、アカウント B の us-east-1a は、異なる物理データセンター群を指している可能性があります。この事実は、AWS を長年使っていても知らない人が多い雑学です。AWS がこの設計を採用した理由は、キャパシティの均等分散です。もし us-east-1a がすべてのアカウントで同じ物理 AZ を指していたら、多くのユーザーが「とりあえず a を使おう」と考えるため、us-east-1a に負荷が集中します。マッピングをランダム化することで、各物理 AZ の負荷が自然に分散されます。このマッピングはアカウント作成時に決定され、その後変更されることはありません。同じアカウント内では、us-east-1a は常に同じ物理 AZ を指します。
AZ ID の導入 - 物理 AZ を一意に識別する
AZ 名のマッピングがアカウントごとに異なるため、クロスアカウントで「同じ物理 AZ」を指定する方法が必要になりました。たとえば、RAM (Resource Access Manager) でサブネットを別のアカウントと共有する場合、共有元と共有先が同じ物理 AZ にリソースを配置したいケースがあります。この課題を解決するために導入されたのが AZ ID です。AZ ID は use1-az1、use1-az2 のような形式で、すべてのアカウントで同じ物理 AZ を指します。アカウント A の us-east-1a が use1-az1 にマッピングされ、アカウント B の us-east-1c が同じ use1-az1 にマッピングされている場合、両者は同じ物理 AZ を使用しています。AZ ID は EC2 コンソールの「AZ ID」列、または describe-availability-zones API の ZoneId フィールドで確認できます。クロスアカウントのアーキテクチャ設計では、AZ 名ではなく AZ ID で物理 AZ を指定してください。
マッピングの実装 - どのように決まるのか
AZ 名と物理 AZ のマッピングは、アカウント作成時にランダムに割り当てられます。AWS はマッピングのアルゴリズムを公開していませんが、実測からいくつかの特性が判明しています。第 1 に、マッピングは完全にランダムではなく、物理 AZ 間の負荷バランスを考慮した重み付けが行われている可能性があります。新しい物理 AZ が追加された場合、その AZ に多くのアカウントがマッピングされるよう調整されると推測されます。第 2 に、リージョン内の AZ 数とマッピングの関係です。us-east-1 には 6 つの AZ がありますが、新規アカウントにはデフォルトで 4〜5 つの AZ しか表示されません。残りの AZ はオプトインが必要です。これは、古い AZ のキャパシティが限られている場合に、新規アカウントの負荷を新しい AZ に誘導するための仕組みです。第 3 に、同じ組織 (AWS Organizations) 内のアカウントでも、マッピングは異なります。組織内で統一されたマッピングが必要な場合は、AZ ID を使用してください。
AZ マッピングが問題になるケース
AZ マッピングの違いが実際に問題になるケースがあります。最も多いのは、クロスアカウントのデータ転送コストです。アカウント A の us-east-1a (物理: use1-az1) からアカウント B の us-east-1a (物理: use1-az2) にデータを転送すると、AZ 名は同じですが物理 AZ が異なるため、AZ 間のデータ転送料金 (0.01 USD/GB) が発生します。同じ物理 AZ 内のデータ転送は無料であるため、AZ ID を確認して同じ物理 AZ にリソースを配置することで、転送コストを削減できます。もう一つのケースは、レイテンシの最適化です。同じ物理 AZ 内の通信レイテンシは 0.1ms 未満ですが、AZ 間の通信レイテンシは 1〜2ms です。マイクロサービス間の通信が頻繁な場合、同じ物理 AZ に配置することでレイテンシを削減できます。ただし、可用性の観点からは、サービスを複数の AZ に分散させることが推奨されます。レイテンシと可用性のトレードオフを考慮して設計してください。
Local Zones と Wavelength Zones - AZ の拡張概念
AZ の概念を拡張したものとして、Local Zones と Wavelength Zones があります。Local Zones は、AWS リージョンの外に配置された小規模なインフラで、特定の都市に近い場所でコンピューティングリソースを提供します。東京リージョンの Local Zone はありませんが、大阪に Local Zone が存在します。Local Zones は、エンドユーザーに近い場所で低レイテンシのサービスを提供するために使用されます。Wavelength Zones は、通信事業者の 5G ネットワーク内に配置された AWS インフラです。5G デバイスからのリクエストが通信事業者のネットワーク内で処理されるため、インターネットを経由するよりも低レイテンシです。Local Zones と Wavelength Zones は、通常の AZ とは異なるオプトイン方式で有効化します。デフォルトでは無効であり、EC2 コンソールの「AZ」設定から有効化する必要があります。これらの拡張 AZ にも AZ ID が割り当てられており、クロスアカウントでの識別に使用できます。AZ の設計思想を体系的に学ぶには、専門書籍 (Amazon)が参考になります。