論理IDと物理リソース名は別物だが漏れる
論理ID / URN / binding名はstate/IR内部の識別子であり、AWS上の物理リソース名(S3 bucket名、IAM Role名等)とは別物である。ただし完全に独立しているわけではなく、リソース名を省略したときに内部識別子が物理名へ漏れる。
- リソース名を明示指定すれば(CDKの
bucketName、Carinaのname属性等)、物理名は完全に制御でき、論理ID / URNとは独立する - リソース名を省略すると、CFNは
<stack>-<logicalId>-<random>形式(例:mystack-mybucketf68f3ff0-abc123xyz)で自動生成する。論理IDが物理名にサフィックスとして埋め込まれる
CDKとPulumiのデフォルト命名を比べると差がはっきりする。
| 観点 | CDK | Pulumi (デフォルト) |
|---|---|---|
| 形式 | <stack>-<logicalId>-<random> | <logicalName>-<7hex> (terraform-bridgeベース) |
例(new ... ("mybucket")) | mystack-mybucketf68f3ff0-abc123xyz | mybucket-d7c2fa0 |
| stack名を含む | はい | いいえ |
| 論理IDのhashを含む | はい(MyBucketF68F3FF0) | いいえ(logical nameそのまま) |
Pulumiの方がCDKよりユーザフレンドリーである。
長さ制限による切り詰め(CDK特有)
AWSリソース名には長さ制限がある — S3が63文字、IAM Roleが64文字、Lambda Functionが64文字、そしてALB Target Groupは32文字。MyAppProductionStack-MyServiceTargetGroupF68F3FF0は51文字で、ALB TGの32文字制限にかかるとMyAppProductionStaMyServ-XXXXXXXXのように真ん中が削られる。元の意味のある部分が削られて識別がより困難になる。
運用面の弊害
- 認知負荷:一覧で何のbucketか分からない
- コミュニケーション摩擦:ハッシュ付き名前を口頭やIssueで共有しにくい
- ドキュメント乖離:設計時の名前と運用時の名前のズレ
- クロスサービス連携の不便: IAMポリシーで正確な名前が必要になる
- URL/ドメインの見栄え: S3 website / CloudFront originではURLに直接出る
なおCarinaではname属性とstate identifierは独立しており、CDK / Pulumiの自動名生成とは異なる設計になっている。