弊社で使っているAWSリソースの命名規則を紹介します

みなさんこんな画面を見たことありませんか？？

このような状態は避けるべきです。理由は以下の通り。

• 各リソースの役割がわかりにくい
  • オペレーションミスが発生しやすい
  • リソース削除などの判断が難しくなる
• 単純に見栄えが悪い

そこで今回は弊社が環境を構築する際によく使う命名規則を紹介したいと思います。 新規でリソースを作成する際に参考にしていただけると嬉しいです。

※AWSアカウントでシステムや環境を分離していたとしても、命名規則を守ったほうがリソースの見通しがよくなります。

リソース名から何を知りたいのかを考える

みなさんはリソース名（主にNameタグ）から何を知りたいですか？？ 対象のリソースによっても異なりますが、共通で知りたいものは以下になるかと思います。

• 対象システム
• 環境(本番、検証、開発)

また、リソースによってはこれ以外に知りたい情報もあるはずです。

• Subnet、RouteTable
  • ネットワークレイヤー（パブリック、プロテクト、プライベート、など）
• EC2、IAMRole
  • 種別（アプリケーションサーバー、踏み台サーバー、メールサーバー、など）
• S3
  • 目的（ログ保管用、静的コンテンツ配信用など）

などなど、リソースによって様々です。

どう表現するのかを考える

ではこの情報をどのように表現すれば良いでしょうか。

一般的な命名規則としては、キャメルケース、スネークケース、ケバブケースなどがありますが、AWSリソースの命名にはケバブケースがおすすめです。
※S3のバケット名に大文字またはアンダースコアを含めることができないため

WebACLにはハイフンを利用できないなどの一部例外もありますが、基本的にはどのリソースもケバブケースで作成することができます。

命名規則表

ということで私がよく使う命名規則はこちらになります。

• 対象システムの名前(sysname)
  • システムで一意となる識別子(例：xxsystem)
• 環境(env)
  • 本番、検証、開発など(prod/stg/dev)
• ネットワークレイヤー(nlayer)
  • パブリック、プロテクト、プライベートなど(public/protected/private)
• 種別（type）
  • アプリケーションサーバー、踏み台サーバー、メールサーバーなど(app/bastion/mail)
• 目的（use）
  • ログ保管用、静的コンテンツ配信用など(log/contents)

また、採用する文字は「半角英数字とハイフンなどの一部記号のみ」とすべきです。安易に特殊文字を利用するとプログラムで処理する際に苦しむことになります。

AWSリソース	命名規則	備考
VPC	{sysname}-{env}-vpc
Subnet	{sysname}-{env}-{nlayer}-subnetXX	XXは連番、AZ毎に分ける
RouteTable	{sysname}-{env}-{nlayer}-rtb	NatGawatayをAZ毎に分ける場合はprotectedのみ連番を付与
InternetGateway	{sysname}-{env}-igw
ELB	{sysname}-{env}-alb/clb	インターナルなELBを作成する場合、役割毎に分ける場合はその部分も考慮
TargetGroup	{sysname}-{env}-tg	同上
EC2	{sysname}-{env}-{type}XX
IAMRole	{sysname}-{env}-{type}-role
SecurityGroup	{sysname}-{env}-{type}-sg
RDS	{sysname}-{env}-rds
S3	{sysname}-{env}-{use}-{AccountID}	S3のリソースは全体で一意にする必要があるためAWSのアカウント番号を付与

このルールを適用すると。。

かなりスッキリしました。また、このような命名にすることで絞り込みなども容易になります。

おまけ タグの使い方

タグにはNameだけではなく、システム名や環境の情報を登録しておくことをお勧めします。

これにより、EnvやSystemNameを指定した柔軟な絞り込みが可能になります。

最後に

リソースの名前を適当に設定してもシステムは動きます。ただし、適当に設定することで不要な作業をする機会が増えてしまいます。みなさんそんな無駄なことしたくないですよね？？

ということで今一度リソース名を見直してみませんか？？その際に本ブログを参考にしていただければ幸いです。