【AWS本気で運用】シナリオごとのリソース命名規則
2024.07.04
AWSを使ったことののある方ならば、リソース名について1度は悩んだことがあるのではないでしょうか？
・検証でEC2を作成する際に名前で悩んでしまう
・アカウント内に作成したリソースが増えてきてどのリソースが何に使われているのかわからない
こういった問題を解決するためにAWS環境におけるリソース命名規則を定めてみてはいかがでしょうか。
AWS環境におけるリソース命名規則とは
AWSをご利用の皆様の中で「リソース名をその都度決めている」や「慣習的な命名規則はあるが文書化されていない」に当てはまる方はいらっしゃるのではないでしょうか。
場合によってはそれぞれの命名により様々なリソース名が混在して見通しが悪くなっていることもあるかもしれません。
そこで今回は、運用が楽になるようなリソース命名規則を紹介したいと思います！AWSの活用事例ごとにシナリオとして分割してご紹介しますので、ご自身の環境に近いものを参考にいただければと思います！
なぜリソース命名規則が必要なのか
まず最初に、なぜリソース命名規則が必要かについて考えていきましょう。リソース命名が主に活用されているのは以下です。
・ Webコンソールなどでリソースを確認する際に一意にリソースを特定するため
大量のリソースがある環境にて検索機能を使ったことがある方も多いのではないでしょうか。適切な検索を行う場合や、表示のソートを効率的に行う場合には統制された命名規則が必要となります。またオペミスを減らす効果も期待できますね。
ただし注意点として、リソース名はユーザに対してルールを強要するのが難しく、命名規則に沿わない命名をされたことに気づくことは難しいです。
そのためリソース命名規則を作成した際には組織内でしっかりと認識を合わせることが求められます。逆に組織全体で統一化されたリソース命名規則を使用していれば、他部署の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環境のリソース命名規則について少しでも考えていただけると嬉しいです。
また、JIG-SAWからAWSをご契約いただくとAWSの利用料が割引でご利用いただけます。
利用料の割引だけでなく様々な無料特典もつき、システム構築や監視・運用、セキュリティサポートなど各種オプションサービスもご用意しておりますので、お気軽にご相談ください。
