AWS CDKでS3バケットを作成する際、bucketName を指定するかどうかで挙動が変わります。
特にチーム開発では「自動命名に任せるべきか？」で悩むことが多いため、仕組みと実務判断を整理します。
結論
new s3.Bucket(this, 'HogeBucket')
👉 bucketName を指定しない場合
CloudFormationが一意な名前を自動生成する
全体の流れ
CDKの自動命名は以下の流れで決まります。
CDKコード
↓
Construct ID（開発者が指定）
↓
Logical ID（CloudFormation用）
↓
Physical Name（実際のリソース名）
① Construct ID（開発者が書く）
new s3.Bucket(this, 'HogeBucket')
-
'HogeBucket'は 論理的な名前 - AWS上の実際のバケット名ではない
② Logical ID（CDKが生成）
CDKは構造（パス）からIDを生成します。
例：
Stack
└ Storage
└ HogeBucket
生成される例：
StorageHogeBucketA1B2C3D4
- ハッシュが付く
- CloudFormation内部用
③ Physical Name（実際のバケット名）
最終的にCloudFormationが生成します。
例：
infrastack-storagehogebucketa1b2c3d4-xyz123
構成：
Stack名 + Resource名 + 一意サフィックス
👉 AWS全体で一意になるように自動調整される
なぜ自動命名が推奨されるのか
❌ 固定名を指定する場合
bucketName: 'hoge'
問題：
- S3はグローバルで一意が必要
- 既に存在するとデプロイ失敗
- リソース置換時に衝突する
⭕ 自動命名の場合
bucketName を書かない
メリット：
- 一意性をAWSが保証
- デプロイが安定する
- rollbackしやすい
- 環境複製（dev/stg/prod）が簡単
実務での判断基準
自動命名を使うべきケース
- 内部処理用バケット
- Lambdaやバッチ処理用
- 環境ごとに複製する構成
👉 基本はこちらが推奨
固定名を使うケース
- 外部システムから直接参照される
- DNS的な意味を持つ
- 明示的な命名規則が必要
👉 ただし慎重に設計する
CDKで名前を使う方法
自動命名でも、コードから名前は取得できます。
bucket.bucketName
よくある使い方：
environment: {
BUCKET_NAME: bucket.bucketName
}
👉 Lambdaに渡して利用
よくある勘違い
❌ 「CDKが名前を決めている」
👉 正確には CloudFormationが決めている
❌ 「既存実装に合わせれば正しい」
👉 既存コードが間違っているケースも多い
今回の学び（重要）
- 命名は「横並び」で見るべき
- 既存実装を鵜呑みにしない
- CDKは「書かない方が正しい」ことがある
まとめ
👉 CDKは論理名を定義し、実際のリソース名はCloudFormationが自動生成する
👉 基本は自動命名を使うのが安全で実務的