個人的AWSリソースの命名規則（暫定版）
基本的にはこれで良いと思っていますが、ちょっと好みからずれるところの補足。
環境
同一のAWSアカウント上にProduction, Staging, Developmentの3環境があり、なおかつシステム自体も複数あるものとします。（おそらくCDKなどで3アカウントに構築する場合も同様）
今回は Example という公開サイトと Example Manager という管理サイトがそれぞれ3環境あるとしましょう。
命名規則
実際にいっぱいリソースが並んでいたほうが実感が湧きやすいのでEC2だけを例にあげます。
命名規則： {env}-{system}-{app type}-{az}{number}
- prd-example-web-a1
- prd-example-web-c1
- prd-manager-web-a1
- prd-manager-web-c1
- stg-example-web-a1
- stg-example-web-c1
- stg-manager-web-a1
- stg-manager-web-c1
- dev-example-web-a1
- dev-example-web-c1
- dev-manager-web-a1
- dev-manager-web-c1
まず、envを頭に書きます。
一覧でソートした際に環境ごとにまとまっていた方が見通しが良いのと、どの環境に対して作業しているのかというのはインフラを触る上で最も重要な情報なので先頭に書きたいという気持ちが強いです。
あと dev.example.com みたいなURLと同じ順番になるのも嬉しいですね。
クラスメソッドさんがsystem名を先頭に置いているのは、会社の性質上、複数のシステムを触ることが多く、envよりもsystemの方が優先度が高い情報だからという理由な気がします。
このあたりの優先順序は触るサービスの数に依りそうですね。
systemはそのままですね。
example-managerとせず単にmanagerとするのはソートしたときにこういう順になってキモくならないようにするための配慮です。
- prd-example-api
- prd-example-manager-api
- prd-example-manager-web
- prd-example-web
あとの部分はAZ名を入れています。
個人的には冗長化している感が強くなって好きなのですが、デフォルトで3リージョンで冗長化するとかの運用であれば、どこのリージョンにそのインスタンスが存在しているかはかなり透過的な情報になってくるので、わざわざ名前に入れずリージョンカラムを見るだけで十分かもしれません。
ハンガリアン的サフィックスについて
こんな感じのやつ
VPC {sysname}-{env}-vpc
CDKやCLIで管理する場合はコード上で操作対象が明示的になるメリットがあると思うのでお好みで。
Discussion