AWSリソース命名規則_カオスなインフラを救う命名戦略

Kuroda

AWSリソース命名規則_カオスなインフラを救う命名戦略

どうも、クラ本の黒田です。大変ご無沙汰しております。

先日、とあるお客様の環境を引き継いだら、EC2がtest-server、test-server2、test-server-new、test-server-finalと並んでいて、どれが本番か誰もわからない状態だった。CloudTrailを遡って調査するハメになり、丸一日溶かした。

この手の話、珍しくない。

AWSパートナーとして500以上の環境を見てきたけど、命名規則がまともに運用されているのは体感2割くらい。残り8割は、作った本人すら覚えていないカオス状態になっている。

というわけで今回は、うちのチームで実際に使っている命名規則について記録する。
file

命名規則、正直めんどくさい

最初に本音を言うと、命名規則を決めるのはめんどくさい。チーム内で合意を取るのも、既存リソースとの整合性を考えるのも。

でも、やらないともっとめんどくさいことになる。

過去に見た事故：

  • 本番と検証の区別がつかず、新人が本番DBをDROP（その後退職）
  • 命名バラバラでコスト按分できず、毎月Excelで手集計
  • 障害対応で「どのEC2再起動すればいい？」がわからず、全台再起動

全部、命名規則があれば防げた。

基本原則

まずファイルやフォルダの基本から。AWS以前の話だけど、ここがブレると全部ブレる。

原則 内容
小文字統一 Windows/Mac/Linux間の互換性確保。大文字小文字の区別トラブルを避ける。
英数字とハイフン 日本語・特殊文字（&@#_等）・スペース禁止。区切りはハイフン-推奨。
日付先頭 ドキュメント類はYYYYMMDD_で開始。ソートした時に時系列になる。

ドキュメント系はこのフォーマット：

YYYYMMDD_type_desc_vX.X.ext

例：
20250108_proposal_bedrock-implementation_v1.0.docx
20250108_estimate_redshift-serverless_v2.1.xlsx
20250108_meeting-notes_aws-kawashima_v1.0.md

typeは用途で使い分ける：

type 用途
proposal 提案書
estimate 見積書
design 設計書
spec 仕様書
meeting-notes 議事録
report レポート

バージョンは_draftで作成中、_v1.0で初版確定。軽微な修正は_v1.1、大幅変更で_v2.0。

AWSリソースの命名規則（基本構造）

本題。AWSリソースは基本このフォーマットで統一している。人間がパッと見て「何者か」を識別するための名前だ。

{project}-{env}-{resource}-{role}-{identifier}
要素 内容 例 備考
project プロジェクト/システム名 ragchat, billing 広すぎず狭すぎない範囲で。
env 環境 prd, stg, dev 3〜4文字の略称で統一。
resource リソース種別略称 ec2, rds, alb 組織内で略称リストを定義する。
role 役割/機能 web, api, batch そのリソースが何をしているか。
identifier 識別子（任意） 1a01, primary AZ名や連番、主副など。

環境識別子は3文字で揃えると見た目がいい。prod派とprd派がいるけど、自分は短い方が好み。

prd = Production（本番）
stg = Staging（ステージング）
dev = Development（開発）
sbx = Sandbox（検証用、devとは別に持っておくと便利）

サービス別の命名規則

全部書くとキリがないので、よく使うやつだけ。

EC2まわり

インスタンス

{project}-{env}-{role}-{az}{number}

ragchat-prd-web-1a01
ragchat-prd-web-1c01
ragchat-prd-batch-1a01

AZ（アベイラビリティゾーン）を入れるかは好みが分かれるが、自分は入れる派。障害時に「1a側が全滅か」とか一目でわかるので便利。

セキュリティグループ

{project}-{env}-sg-{role}

ragchat-prd-sg-web
ragchat-prd-sg-rds
ragchat-prd-sg-alb

SGは数が増えがち。「このSG何用だっけ」と言い出したら末期。アタッチする対象の役割を名前に含める。

AMI

{project}-{role}-ami-{yyyymmdd}

ragchat-web-ami-20250108

日付を入れておくと、古いAMIの棚卸し（コスト削減）が楽になる。

ネットワーク系

ragchat-prd-vpc
ragchat-prd-subnet-public-1a
ragchat-prd-subnet-private-1a
ragchat-prd-natgw-1a
ragchat-prd-alb-web
ragchat-prd-tg-web-443

サブネットはpublic/privateを明記する。NATゲートウェイの設定ミスやルートテーブルの割り当てミスを防げる。

ターゲットグループ（tg）はポート番号も入れておくと、後から見たとき「443で受けてるやつね」とわかる。

S3

S3はバケット名がグローバルで一意じゃないといけない。なので会社名や組織名を頭につけるのが定石。

{company}-{project}-{env}-{purpose}-{region}

kyoei-ragchat-prd-assets-apne1
kyoei-ragchat-prd-logs-apne1

リージョン略称は公式に合わせる。ap-northeast-1はapne1。tokyoとか書く人がいるけど、他リージョン（大阪など）と整合性取れなくなるのでやめたほうがいい。

RDS・Aurora

ragchat-prd-rds-mysql-primary
ragchat-prd-rds-mysql-replica
ragchat-prd-aurora-mysql-01  # Writer
ragchat-prd-aurora-mysql-02  # Reader

エンジン名を入れるかは議論あるけど、自分は入れる派。同じプロジェクトでMySQLとPostgreSQL併用とか普通にあるし。

パラメータグループ

バージョンも入れること。絶対。

ragchat-prd-mysql80-params

MySQL 5.7から8.0に上げるとき、パラメータグループも新しく作ることになる。バージョン入ってないと、どっちが新しい適用対象なのかわからず地獄を見る。経験済み。

Lambda

{project}-{env}-{trigger}-{action}

ragchat-prd-api-create-chat
ragchat-prd-s3-process-image
ragchat-prd-schedule-daily-backup

トリガー（何がきっかけで動くか）を入れておくと、後から見たときに「API Gateway経由」「S3イベント」「EventBridgeスケジューラー」とわかる。Lambdaは油断すると数が爆発するので、命名規則がないと本当にカオスになる。

IAM

ロール

「誰が/何が」使うか明確にする。

ragchat-prd-role-ec2-web     # EC2が使う
ragchat-prd-role-lambda-api  # Lambdaが使う
ragchat-prd-role-ecs-task    # ECSタスクが使う

ポリシー

ragchat-prd-policy-s3-read
ragchat-prd-policy-dynamodb-full

IAMは「誰が何のために作ったかわからないカスタムポリシー」が残りがち。AWS管理ポリシーで済むところを、わざわざカスタム作って放置、みたいなのをよく見る。

Secrets Manager / Parameter Store

スラッシュ区切りにして階層化しておくと、IAMポリシーでパスベースのワイルドカード指定ができて便利。

/ragchat/prd/rds/credentials
/ragchat/prd/api/stripe-key

CloudWatch

ロググループ

スラッシュ始まりにしておくと、Logs Insightsでグループ化検索しやすい。

/ragchat/prd/ecs/web
/ragchat/prd/lambda/api-create-chat

アラーム

ragchat-prd-alarm-ec2-cpu-high
ragchat-prd-alarm-rds-connections
ragchat-prd-alarm-alb-5xx

アラーム名は長くなりがちだけど、PagerDutyやSlackに飛んできたときに「何のアラームか」一目でわかるようにしたい。深夜に叩き起こされて通知を見たらalarm-1とか書いてあったら泣く。

タグも一緒にやる

「名前」は人間用。「タグ」は機械（自動化、集計）用。
命名規則だけだと限界がある。タグと組み合わせて初めて威力を発揮する。

最低限これだけは必須：

タグキー 用途
Name リソース名（上記の命名規則を適用）
Project プロジェクト名（フィルタリング用）
Environment 環境（誤操作防止、フィルタリング用）
Owner 責任者・チーム（誰に聞けばいいか）
CostCenter コスト按分用（経理用）
ManagedBy 管理ツール（terraform, cdk, manual など）

Terraformならdefault_tagsでプロバイダレベルで一括設定できるので楽。

provider "aws" {
  region = "ap-northeast-1"
  default_tags {
    tags = {
      Project     = "ragchat"
      Environment = "prd"
      ManagedBy   = "terraform"
    }
  }
}

導入は新規リソースから（事後修正は慎重に）

「よし、明日から全リソースリネームするぞ！」は現実的じゃない。

S3バケットはリネームできないし、RDSもインスタンス名変更は再起動が必要。本番でいきなりやると事故る。

現実的なアプローチ：

  1. まず新規リソースから適用する。
  2. IaC（Terraform/CloudFormation）に命名規則を組み込む（手動を減らす）。
  3. 既存リソースは、リプレースのタイミングや、大規模メンテナンスのついでに徐々に移行する。

完璧を目指すと永遠に始まらないので、まずは新規から適用していくのがコツ。

やっちゃダメなやつ（アンチパターン）

最後に禁止事項。これやると後で絶対困る。

❌ やめて ✅ こうして 理由
提案書_AWS移行.docx 20250108_proposal_aws-migration_v1.0.docx 日本語ファイル名は環境によって化ける。日付がないとどれが最新かわからない。
test_FINAL_v2 (1).xlsx 20250108_estimate_bedrock_v2.0.xlsx FINALは絶対にFINALじゃない。バージョン管理せよ。
MyWebServer ragchat-prd-web-1a01 個人所有物ではない。プロジェクトと環境を明記せよ。
(タグが一切ない) (必須タグをつける) コスト配分が不可能になり、ゾンビインスタンス化する。

おわりに

命名規則の整備は地味だし、やっても誰も褒めてくれない。

でも半年後の自分は感謝するはずだ。深夜の障害対応で、眠い目をこすりながら「このリソース何だっけ…」と調べる時間が減るだけで、精神的にだいぶ楽になる。

紹介したのはあくまでうちのチームのやり方なので、これをベースに自チームの状況に合わせてカスタマイズしてほしい。大事なのは「決めて、守る」こと。

完璧な命名規則より、80点でも運用されている命名規則のほうが100倍マシだ。

質問や「うちはこうしてる」があればコメントで教えてほしい。

Last modified: 2026-02-01

Author