AWS案件の中で「AZ ID」なるものが出てきたので、なんぞやといろいろ調べてみました。
#1.アベイラビリティーゾーン（AZ）とは
「AZってなんだっけ？」という方以外は、この項目を飛ばしてください！
AWSは以下の構造で構成されています。
※基本的な部分のみ大雑把に記載しています。
リージョン（Regions）
AWSが構築したデータセンタで、各国にあり、物理的に完全に分離されています。
＜リージョン例＞
| コード | 名前 |
|---|---|
| us-east-2 | 米国東部 (オハイオ) |
| ap-northeast-1 | アジアパシフィック (東京) |
| ap-northeast-3 | アジアパシフィック (大阪) |
| AWSリソースを作成する際に、どこで作るかを最初に決めていますよね。 |
アベイラビリティーゾーン（Availability Zones／AZ）
リージョンごとにアベイラビリティーゾーンと呼ばれる複数の物理的に完全に分離した場所があります。
＜アジアパシフィック (東京)のAZ例＞
| AZ名 |
|---|
| ap-northeast-1a |
| ap-northeast-1c |
| ap-northeast-1d |
アジアパシフィック (東京)において「ap-northeast-1b」は存在しない
これらはSubnet作成時に指定しているものですね。
#2.AZ IDとは
では「AZ ID」とはなんなのでしょう。
実はAWSの物理的なデータセンタ群と紐づいたAZのIDです。
AWSでは、各リソースがリージョン内の複数のAZに分散するように、ユーザ側で指定するAZ名と実際のAZ(物理的なDC群)との関連性について、AWSアカウント毎にマッピングする仕様となっています。
AWSアカウント作成時にAZ名とAZ IDがAWSによって自動的にマッピングされるのですね！
AZ IDを直接指定する事は出来ません。
各AZ IDで機能差異はありません。
＜アジアパシフィック (東京)のAZ ID例＞
| AZ ID |
|---|
| apne1-az1 |
| apne1-az2 |
| apne1-az4 |
マッピングイメージはこんな感じです。
#3.AZ ID実装経緯
AWSの大規模な利用が進むにつれ、「複数アカウントを利用しながら可用性を高める目的でマルチAZを進めても、AWS側の物理DC群が同じになってしまっては可用性担保にならない」というユーザの声に応える形で「AZ ID」が実装されたようです。
AWSアカウントごとに同じAZ名でもAZ IDが異なる実体を見える化したと言い換える事も出来そうです。
※AWSの中の人にこっそり聞きました。
#4.AZ IDの使用用途
AWS側の物理的なDC群を明示的に指定する必要がある場合に利用します。
例えばこんな感じでしょうか。
| AWSアカウント | リージョン | AZ ID | AZ名 |
|---|---|---|---|
| アカウントA | ap-northeast-1 | apne1-az1 | ap-northeast-1a |
| アカウントB | ap-northeast-1 | apne1-az1 | ap-northeast-1c |
AZ IDを「apne1-az1」にしたいから、このアカウントでマッピングされている「ap-northeast-1a」を選択するといった考え方になります。
ちなみに、AZ IDの数字が大きいものが新しい設備だそうです。
この事から、AWS側の新しい設備を使用したいという理由でAZ IDを利用する事も可能です。
#5.AZ IDの確認方法
AZ IDはAZ名選択時に画面表示される訳ではありません。
AZ IDとAZ名のマッピング状態を確認する画面が別にあるので、そこでどのAZ名がどのAZ IDに割り当てられているかを確認した上で、AZ名を選択する必要があります。
確認方法はこちらになります。
①AWSコンソールから「Resource Access Manager」を選択する。
②Resource Access Managerコンソール画面の右下の方に以下のような項目がある。
＜リージョンが東京の場合＞
＜リージョンが大阪の場合＞
上記は私の個人所有AWSアカウントの情報ですので、別のアカウントではマッピング結果が異なっていると思います。
#6.最後に
複数アカウントを組み合わせて1つのシステムをAWS構築するなんて案件はそうそうお目にかかった事はないのですが、クラウドといえども根っこはオンプレである事を再認識しました。
クラウドのハード側はクラウド事業者（AWSなど）の責任範囲になっているので普段あまり気にしないのですが、大規模の場合はクラウド側のハード領域まで気にしないといけない場合もあるのだなと、ちょっと目から鱗状態でした。
そして、「そこはAWSの責任範囲だから気にしないで！」と跳ね返す事をせず、逆にユーザ意見を取り込んで機能実装するAWSの心意気をちょっと感じた今日この頃でした。
このAWSの心意気はマネしたいマインドだと思います。