【AWS本気で運用】シナリオごとのリソース命名規則
はじめに
AWSを使ったことのある方ならば、リソース名について1度は悩んだことがあるのではないでしょうか？
・検証でEC2を作成する際に名前で悩んでしまう
・アカウント内に作成したリソースが増えてきてどのリソースが何に使われているのかわからない
こういった問題を解決するためにAWS環境におけるリソース命名規則を定めてみてはいかがでしょうか。
AWS環境におけるリソース命名規則とは
AWSをご利用の皆様の中で「リソース名をその都度決めている」や「慣習的な命名規則はあるが文書化されていない」に当てはまる方はいらっしゃるのではないでしょうか。
場合によってはそれぞれの命名により様々なリソース名が混在して見通しが悪くなっていることもあるかもしれません。
そこで今回は、運用が楽になるようなリソース命名規則を紹介したいと思います！AWSの活用事例ごとにシナリオとして分割してご紹介しますので、ご自身の環境に近いものを参考にいただければと思います！
なぜリソース命名規則が必要なのか
リソースの命名規則は、そもそもなぜ必要なのでしょうか。最大の理由は、リソースの特定を容易にすることで、業務の効率化を促すためです。
大量のリソースを用いる環境になると、リソースの特定は困難になります。検索機能を使ってリソースを探そうとしても、意図しているリソースにたどり着くために多くの時間を必要としてしまうケースは珍しくありません。
このような問題を少しでも緩和するために大切なのが、命名規則です。命名規則を設けておくことで、規則に基づいた効率的な検索をかけられるようになるだけでなく、並び替えを行いやすくする上でも重要です。
注意したいのが、命名規則の設定はルールとして各担当者に遵守してもらうことがやや難しい点にあります。命名規則にそぐわない命名があったとしても、それを把握するための仕組みが存在しないからです。
そのため、リソース命名規則を作成した際には組織内でしっかりと認識を合わせることが求められます。逆に組織全体で統一化されたリソース命名規則を使用していれば、他部署のAWSアカウントなどを見た際にもすぐに構成が理解できるはずです。
命名規則の設定から得られるその他のメリット
命名規則の設定は、業務効率化に加えヒューマンエラーを減らせるというメリットがあります。命名規則があることで、誤ったリソースを選択してしまったり、どのリソースが本当に必要なものだったかがわからなくなったりする問題を回避できるからです。
命名規則は現場への普及段階が最も厄介ですが、文化として根付いてしまえば高い効率化の効果を得られるでしょう。
リソース名に含めるべき情報
命名規則を設定するにあたり、必要なのがリソース名に含めるべき情報です。何を含めるべきかはケースバイケースですが、一般的には
- システムやプロジェクトの名称
- 環境の名称
- AWSサービスの名称
- ユーザー名
などを含めるのが良いとされています。その名称を見るだけでリソースの概要が把握できるようになっていれば、命名規則を設定する意味を発揮できるでしょう。冗長になりすぎると混乱を招くため、わかりやすく設定するのもポイントです。
リソースの命名規則に役立つケバブケースとは
リソースの命名規則として、活用したいのがケバブケースです。ケバブケースとは、単語と単語の間の区切りの空白を、ハイフン（-）を使って表現する手法です。「cloud-services」のように、ハイフンでそれぞれの単語の可読性を高めます。
AWSにおける命名では、大文字やアンダースコア（_）を使用することができません。ケバブケースによって各単語を表現し、伝わりやすい名称を設定することが大切です。
各シナリオについて
リソース命名規則について考えていきたいのですが、ここでこの記事を読んでいただいている皆様に質問です！
全ての方が利用できる万能的なAWSリソース命名規則は存在するでしょうか？
答えはNoです。なぜならリソース名はリソースを環境で一意に特定するためにありますが、その環境がそれぞれ異なっているからです。
今回は、以下の2要素 × 2パターンの4シナリオで考えていきます。
要素1：シングルリージョン/マルチリージョン
単一リージョンでのサービスなのか、複数リージョンにまたがるサービスなのか
要素2：シングルアカウント/マルチアカウント
運用しているAWSアカウントが単一か、それとも複数のAWSアカウントを運用しているか
リソース命名規則
今回、私が紹介するリソース命名規則はより直感的にリソースを理解できるように作成しました。「用途」と記載がある場所にはそのリソースを何に使いたいのか、という内容を記載ください。
例: OPSサービスのWebサイトを稼働させるEC2インスタンスの場合 ops-web-public-ec2
| サービス | 分類 | 命名ルール |
| EC2 | インスタンス | 〓サービス名〓-〓用途〓-〓(なくてもよい)public/private〓-ec2 |
| AMI | 〓サービス名〓-〓用途(ec2インスタンスと揃える)〓-〓年月日 or Version〓-ami | |
| セキュリティグループ | 〓サービス名〓-〓用途(ポートやプロトコルなど)〓-sg | |
| ALB | 〓サービス名〓-〓用途〓-〓(なくてもよい)public/private〓-alb | |
| NLB | 〓サービス名〓-〓用途〓-〓(なくてもよい)public/private〓-nlb | |
| Lambda | 関数 | 〓サービス名〓-〓用途〓-〓(あれば)VPC名〓-lambda |
| Batch | 〓サービス名〓-〓用途〓- | |
| Elastic Beanstalk | アプリケーション | 〓サービス名〓-eb |
| 環境 | 〓サービス名〓-〓(なくてもよい)用途〓-〓web/worker〓-〓env〓-eb-work | |
| ECR | リポジトリ | 〓サービス名〓-〓用途〓-〓public/private〓-ecr |
| ECS | タスク定義 | 〓サービス名〓-〓用途〓-ecs-task |
| クラスター | 〓サービス名〓-〓用途〓-〓fargate/ec2〓-ecs-cluster | |
| EKS | 〓サービス名〓-〓用途〓- | |
| S3 | バケット | シングルアカウント・シングルリージョン 〓サービス名〓-〓用途〓-s3 シングルアカウント・マルチリージョン 〓サービス名〓-〓用途〓-〓リージョン〓-s3 マルチアカウント・シングルリージョン 〓サービス名〓-〓用途〓-〓アカウントID〓-s3 マルチアカウント・マルチリージョン 〓サービス名〓-〓用途〓-〓リージョン〓-〓アカウントID〓-s3 |
| EFS | ファイルシステム | 〓サービス名〓-〓用途〓-〓VPC名〓-efs |
| Strage Gateway | ゲートウェイ | 〓サービス名〓-〓用途〓-〓file/fsx/volume/tape〓-〓public/private〓-storage-gw |
| AWS Buckup | バックアッププラン | 〓サービス名〓-〓用途〓-backup-plan |
| バックアップルール | 〓サービス名〓-〓用途〓-〓バックアップ頻度〓-backup-rule | |
| リソースの割り当て | 〓サービス名〓-〓all/リソース(ec2)〓-〓(なくてもよい)タグ〓-backup-resource | |
| バックアップボールト | 〓サービス名〓-〓用途〓-backup-vault | |
| RDS | データベース | 〓サービス名〓-〓用途〓-〓aurora/mysql/maria/postgres/oracle/microsoft〓-rds |
| ElasticCache | Redis | 〓サービス名〓-〓用途〓-redis |
| Memcached | 〓サービス名〓-〓用途〓-memcached | |
| DynamoDB | テーブル | 〓サービス名〓-〓用途〓-dynamo |
| VPC | VPC | 〓サービス名〓-〓public/private〓-vpc |
| サブネット | 〓サービス名〓-〓用途〓-〓public/private〓-〓az〓-subnet | |
| ルートテーブル | 〓サービス名〓-〓用途〓-〓vpc/subnet〓-table | |
| NAT Gateway | 〓サービス名〓-〓az〓-nat | |
| インターネットゲートウェイ | 〓サービス名〓-igw | |
| Elastic IP | 〓サービス名〓-〓用途〓-〓xxx.xxx.xxx.xxx〓-eip | |
| セキュリティグループ | 〓サービス名〓-〓用途〓-sg | |
| API Gateway | API | 〓サービス名〓-〓用途〓-〓http/websocket/rest-public/rest-private〓-apigw |
| VPC リンク | 〓サービス名〓-〓用途〓-〓(複数のVPCにリンクする場合)VPC名〓-apigw-vpc-link | |
| Organizations | SCP | マルチアカウント・シングルリージョン、 マルチアカウント・マルチリージョン 〓アタッチするOU名〓-〓(必要なら)用途〓 |
| OU | 〓OUの特性に適した名称〓 | |
| CloudWatch | アラーム | 〓サービス名〓-〓アラーム元リソース 例: ec2〓-〓リソースの用途〓-〓metric(mathなら命名する)〓-cw-alarm |
| ロググループ | 〓サービス名〓-〓ログ出力リソース 例: ec2〓-〓用途〓-loggroup | |
| CloudFormation | スタック | 〓サービス名〓-〓用途〓-cfn |
| マルチアカウント・シングルリージョン 〓サービス名〓-〓用途〓-〓リージョン〓-cfn-stackset マルチアカウント・マルチリージョン 〓サービス名〓-〓用途〓-〓デプロイ先OU/アカウントID〓-cfn-stackset | ||
| Config | レコーダ | config-recorder |
| ルール | 〓サービス名〓-〓用途〓-〓manage/custom〓-rule | |
| CloudTrail | 証跡 | 〓サービス名〓-〓用途〓-trail |
| IAM | IAM ID プロバイダー | 〓サービス名〓-〓用途〓-〓ID プロバイダー〓-〓saml/oidc〓-provider |
| IAM ポリシー | 〓サービス名〓-〓用途〓-policy | |
| IAM ロール | 〓サービス名〓-〓用途〓-role | |
| IAM ユーザー | 〓サービス名〓-〓用途(名前)〓-〓console/accesskey〓-user | |
| RAM | マルチアカウント・シングルリージョン、 マルチアカウント・マルチリージョン 〓サービス名〓-〓共有リソース 例: tgw,ec2〓-〓リージョン〓-ram | |
| IAM Identity Center | グループ | マルチアカウント・シングルリージョン、 マルチアカウント・マルチリージョン 〓チーム名〓-〓権限〓-ssogroup |
| ユーザ | マルチアカウント・シングルリージョン、 マルチアカウント・マルチリージョン 〓名前.性 例: taro.yamada〓 | |
| 許可セット | マルチアカウント・シングルリージョン、 マルチアカウント・マルチリージョン 〓サービス名〓-〓用途〓-ssops | |
| KMS | キー | 〓サービス名〓-〓用途〓-kms-key |
上記の表には記載のないサービスもあるかと思います。またご自身の環境と合わない命名があるかもしれません。
そういった部分も含めてご自身の環境に合わせた命名規則を定めていただければと思います。
全体を通して
今回は、AWSのリソース命名規則について紹介しました。ちょっとしたルールかもしれませんが命名規則を定めておくと意外と便利に感じることが多いです。命名規則の設定は、可読性の向上やヒューマンエラーの解消など、実用性の高いメリットも期待できます。一度文化として命名規則を現場に普及することができれば、後の円滑なプロジェクト遂行に役立ちます。
これを機にAWS環境のリソース命名規則について少しでも考えていただけると嬉しいです。
この記事をシェア
