Zenn
📘

【保存版】AWSリソース名の決め方と命名規則

2022/06/12に公開
AWS
EC2
命名規則
aws入門
tech

はじめに

  • AWSのリソース名(主にNameタグ)の決め方がわからない。
  • Nameタグの命名規則がバラバラで分かりづらい。
  • チームで管理する際の命名規則を統一したい。

この記事は、上記の悩みを解決するために書きました。
新規でAWSリソースを作成する際に参考にしていただけると嬉しいです。

【結論】AWSリソースの命名にはケバブケースがオススメ

ケバブケースは、複数の単語をつなげる場合に単語の間にハイフン（-）を入れる命名規則です。
たとえば、「apply-form」「kebab-case」のような書き方です。
※理由：S3のバケット名に大文字またはアンダースコアを含めることができないため

なぜ命名規則を統一するのか

命名規則は、可読性向上および改修コストの削減のため、プロジェクトに統一性を持たせることを目的としている。

具体的には、以下のような状態を避けるためです。

  • 各リソースの役割がわかりにくい
    • オペレーションミスが発生しやすい
    • ソース削除などの判断が難しくなる
  • 単純に見栄えが悪い
    • 設定ミスに気づきにくくなる
    • リソースを見つけるのにムダな時間がかかる
    • チームで管理する際にミスが生じる

事前に命名規則を統一することで、間違えてインスタンス（サーバー）などを「終了」（削除）した。といったミスを防ぐことができます。

リソース名から知りたいこと

対象のリソースによっても異なりますが、共通で知りたいものは以下の2つです。

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

また、これら以外に知りたい情報は、リソースによって異なります。
たとえば、以下のようなことが考えられます。

  • Subnet、RouteTable
    • ネットワークレイヤー（パブリック、プロテクト、プライベート、など）
  • EC2、IAMRole
    • 種別（アプリケーションサーバー、踏み台サーバー、メールサーバー、など）
  • S3
    • 目的（ログ保管用、静的コンテンツ配信用など）
      この情報をわかりやすく表現するために、ケバブケースによりAWSリソースの名前決めを行います。

命名規則と命名規則表

よく使われる命名規則と命名規則表は以下の通りです。

  • 対象システムの名前(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 XXは連番、AZ毎に分ける
IAMRole {sysname}-{env}-{type}-role
SecurityGroup {sysname}-{env}-{type}-sg
RDS {sysname}-{env}-rds
S3 {sysname}-{env}-{use}-{AccountID} S3のリソースは全体で一意にする必要があるためAWSのアカウント番号を付与する

まとめ

最後に、この記事の内容をまとめます。

  • AWSリソースの名前を決める際には、命名規則の統一が大切
  • 命名規則の統一により、各リソースの役割の明確化と見栄えを良くすることができる
  • AWSリソースの命名規則にはケバブケースを使用する
  • EC2の場合の例：sysname-dev-app
  • 特にチームで管理する際に効果を発揮する

チームの認識を合わせ一定のルールを決めることは簡単なことではありませんが、決めて運用して得られるメリットはそれより遥かに大きいです。この記事で書いた命名規則はあくまで一例で、チームの置かれている状況によって最適解は変わると思いますが、この記事の内容がルールを定める上で参考になれば嬉しいです。

あとがき

この記事は、クラスメソッド株式会社の記事を参考にしました。
https://dev.classmethod.jp/articles/aws-name-rule/

Discussion