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

みなさんこんな画面を見たことありませんか？？ このような状態は避けるべきです。理由は以下の通り。 各リソースの役割がわかりにくい オペレーションミスが発生しやすい リソース削除などの判断が難しくなる 単純に見栄えが悪い そこで今回は弊社が環境を構築する際によく使う命名規則を紹介したいと思います。 新規でリソースを作成する際に参考にしていただけると嬉しいです。 ※AWSアカウントでシステムや環境を分離していたとしても、命名規則を守ったほうがリソースの見通しがよくなります。 リソース名から何を知りたいのかを考える みなさんはリソース名（主にNameタグ）から何を知りたいですか？？ 対象のリソースによっても異なりますが、共通で知りたいものは以下になるかと思います。 対象システム 環境(本番、検証、開発) また、リソースによってはこれ以外に知りたい情報もあるはずです。 Subnet、RouteTa

[everybodyelse]

自分は名前でソートしたときに、上下に隣り合ってて取り違えたらクリティカルにならないような名前順でいつもつけてる。なので、まずはdev、stg、prodから始める感じ。

[masatomo-m]

AWSは何やろうとしてもIAMの権限で引っかかるので、環境別にAWSアカウントごと切り離す方が結局面倒がないのではという結論に至りつつある。PowerUserAccessでもIAMRole参照ができなくてEC2インスタンス立ち上げられないとかね

[bonlife]

サービスによって使える文字が違うのでいつも悩むけど、それなりに基準持っておきたいところ。

[tettekete37564]

いっつもセキュリティーグループの命名に悩む

[den8]

本文まったく関係ないくそbして申し訳無いんだけど、IAMの命名規則を見ているとAWS自体のサービスすら命名規則を統一できていない(snake_caseやspinal-case,camelCaseが入り乱れる)のでまずAWSさんから襟を正してほしい

[pinkumohikan]

👀

[efcl]

AWSのリソース命名規則。 S3はグローバル

[hdkINO33]

システム名を先頭に付けるのは複数のシステムを運用するから一見してすぐわからないといけない。アカウント別に環境を分けるとしてもそれらを運用するPCが分かれているわけではない。運用者のことを常に意識すること

[surume000]

サービス単位＆環境単位でアカウント分けるのを推奨してなかったっけ？https://dev.classmethod.jp/cloud/aws/account-and-vpc-dividing-pattern/

[shinjukukumin]

キャメル/スネーク/ケバブ

[bYMQ]

トップブコメにあるけどenvが先頭の規則の方がよい。パッとみてprefixに{対象システム}全部ついてるならいらなくね？と思った

[shiopon01]

以外と困る部分なのでありがたい。これを標準としたい

[michiomochi]

指標を作ってくれてありがたい。。 今後はこれに従いましょうといえばよくなった。

[yutaro1985]

大体自分も似たような感じのものをイメージすることが多い気がしてるんですが、もしかしたら元ネタがあるのかも。

[miho-satoh-satomi]

AWS リソース 命名規則

[Kil]

ケバブケース……なるほど、ハイフン区切りでつなぐ部分が「串」っぽいから？　プログラム言語だとハイフンでつなぐのメジャーじゃないから、馴染みなかった。CSSとか書いてると良く使ってそう。

[t14kw]

“ケバブケース”

[sashiharajp]

命名規則ちゃんとあると良い。

[tolkine9999h]

一つの参考例にしていただければ。

[ngyuki]

だいたい同じようにつけてたけど -vpc のようなリソースの種類示すものつけたりつけなかったりしてた。つけるように統一したほうがわかりやすそう

[rAdio]

「ペットから家畜へ」という意味では、命名に頼ると負けなのかも、とは思ってる。でもずっと負け続けている…。

[mayumayu_nimolove]

最近みんなが右倣えで規則がするのに疑問を感じてる

[daishi_n]

だいたい最後にリソースタイプ付けるんだよね。ハンガリアン記法の1種ではあるけどしゃーないか

[civitaspo]

参考になる

[YusukeOno]

覚えておきたい

[yuu-sss]

このやり方はわかりやすい。