この記事はAWS（Amazon Web Services）Advent Calendar 2023 シリーズ2の17日目の記事として書かれました。
はじめに
リージョン名をリソースに含める命名規則にしたとき、どのようにリージョン名を含めるか悩みませんか？
結論
空港コードを使いましょう。
エッジロケーションも全て含めたコード一覧
※公式ではなく有志の善意で成り立っているリポジトリのためリンク切れの場合はご了承ください。
WorkSpacesに対応しているリージョンのコード一覧
drp-nrtでページ内検索すると出てきます。
日本語ページの情報更新が追いついていないことがあるので、英語ページを参照することをおすすめします。
詳細
命名においてリージョン名をどのように一意にするか
AWSのリージョン名はxx-yyyy-zという規則になっています。(y部の文字数は可変)
この規則に対してある程度のわかりやすさをもって機械的にユニークにしようとすると、どうしても5文字以上が必要になります。例えば、ap-south-1とap-southeast-1をどう区別する？といった問題に気がつくでしょう。
しかし5文字だと幅を取るだけでなく、us-east-1等を略するときに気持ち悪さが出てきます。usea1でしょうか？ 名称の長さにもクォータがあるので、リージョンによって文字数が異なることを許容するのはおすすめできません。
先行研究
そんなとき素晴らしい先行研究に触れ、リージョンを表す文字列を3文字の空港コードで統一することに心から共感しました。
さらに当該記事でも触れられているとおり、空港コードは一部サービスでリージョンを表すエンドポイントとして利用されています。
よって、AWSが考える命名規則からもそんなに大外ししていないと考えることができるでしょう。
新規性
しかし、東京の次(または次の次)くらいには日本国内で利用の需要がある大阪リージョンはどのように表せばいいのでしょうか？ ITMでしょうか、KIXでしょうか？
残念ながら、先行研究でもAmazon WorkSpacesの記事でも大阪リージョンを表すコードがどちらかは書いていませんでした。
十中八九、国際線の多い関空の方だろう。もちろんそんな予測は立ちますが、それは本当にそうなのだろうか？
そんなクッソ細かいことが気になり、調べた結果よいリポジトリがあったため本記事を書きました。
補足
AWSはCloudFrontのx-edge-locationの説明で、以下のように記載しています。
リクエストを処理したエッジロケーション。各エッジロケーションは、3 文字コードと、割り当てられた任意の数字で識別されます (例: DFW3)。通常、この 3 文字コードは、エッジロケーションの地理的場所の近くにある空港の、国際航空運送協会 (IATA) の空港コードに対応します。(これらの略語は今後変更される可能性があります)。
つまり、空港コードを使った識別子は公式が確約している仕様ではなく、今後変更の可能性を含んでいることには注意が必要です。
しかし、以下は個人的な見解ですが、リージョンやローカルゾーンに割り当てた3文字のコードが変更される可能性は低いのではないかと考えています。
理由は、AWSがこれら3文字のコードを変更したくなったら、①AWS利用者の利便性・②命名規則の統一 のどちらかを犠牲にする必要があるからです。
たとえば、x-edge-locationについて、エッジロケーションが東京リージョンのときはNRTではなくHNDを使おうと考えたとします。
まず、①の利用者の利便性です。利用者への影響は、Amazon WorkSpaceがわかりやすいでしょう。
NRTをHNDに変えるという規則で考えると、ヘルスチェックサーバの drp-nrt.amazonworkspaces.com というエンドポイントも drp-hnd.amazonworkspaces.com に変えたくなります。
利用者は、このドメインが変わることに対して影響がないか調査する必要が出てくるでしょう。
ではWorkSpaceはdrp-nrtのままにしておいて、CloudFrontのヘッダのみNRTをHNDにすると考えましょう。
すると、東京リージョンを表すコードが、WorkSpacesではNRT、CloudFrontではHNDといういびつな状況が発生します。これが②のパターンで、命名規則の統一を犠牲にしているという状態です。
変えるほうが色々面倒なので、ちょっとやそっとの理由では変えないでしょう。
おわりに
命名規則にリージョンを含もうと思ったら、CloudFormationの${AWS::Region}に則る形にするのも一つの解です。でも、長いんです。ap-northeast-1だけで14文字も取られるんです。
IAMのロール名64文字、S3のバケット名63文字等の制限を考えると、リージョンにこれだけの文字数を割くのはちょっと嫌だなと思いませんか？ 僕は思います。
あとリージョンによって長さが異なるのでリソース名称の長さの統一を基本的に諦める必要があり(以下、愚痴略
参考
-
AWS リージョンの短いエイリアスとしての空港コード
素晴らしい先行研究です。7年以上も前に同じことを考えて情報を残してくれた先達がいたことに感動しました。 -
aws-edge-locations
素晴らしいリポジトリです。リージョンだけでなくエッジロケーションにも対応しているところが素晴らしいです。