壊して学ぶAWS CDK: そのcdk deployで消えるもの、残るもの

AWS CDKの変更で「何が消え、何が残るのか」を、実際に壊しながら確かめます。RemovalPolicy、Construct ID変更、CDK Refactor、cdk diffとcdk driftの違いを具体例で整理。デプロイ成功だけでは分からない、リソース・データ・アプリへの影響を安全に見極める方法を紹介します。

登壇資料 @CDK Conference 2026
https://jawsug-cdk.connpass.com/event/393595/

Transcript

1. { } 壊して学ぶAWS CDK そのcdk deployで消えるもの、残るもの AWS CDK Conference Japan 2026 / 2026-07-18 Kazuki-Adachi
2. 自己紹介 SPEAKER Kazuki Adachi @k_adachi_01 AWS Community Builder AWS All Certifications Engineer JAWS-UG 配信部 好きなAWSサービス KiroとCDK 最近ハマっているもの コーヒーとトレラン 2
3. QUESTION 皆さんは、技術を どうやって学びますか？ 3
4. 読む、聞く、触る 読む 本・ドキュメント 聞く 人・勉強会 触る 自分で試す 4
5. MY APPROACH 自分で触って、 失敗させてみる 5
6. 失敗させて分かること ・ 設定を変えたら、どこが変わるか ・ どんな場合にエラーになるか 技術以外にも わざと、まずくしてみる 6
7. “To invent you have to experiment, and if you know in advance that it’s going to work, it’s not an experiment.” 「発明するには実験しなければならない。 あらかじめ成功すると分かっているなら、 それは実験ではない」 Jeff Bezos Amazon 2015 Letter to Shareholders https://ir.aboutamazon.com/files/doc_financials/annual/2015-Letter-to-Shareholders.PDF 7
8. 今日話すこと cdk deployで何が壊れるのかを見る ・ 小さなコード変更で起きる更新・置換・削除 ・ cdk diffとcdk driftは何を見ているのか ・ 何が消えて、何が残るのかを見分ける 8
9. 何が起きたら「壊れた」のか？ 消える 入れ替わる 使えなくなる 9
10. 今回は、壊していいSandboxで 試します みなさんは本番環境で真似しないでください 10
11. まずは、分かりやすく壊したい 11
12. 削除前のS3 Bucket Amazon S3 削除前: Object 3件 12
13. lib/s3-stack.ts ts const bucket = new s3.Bucket(this, "Uploads" removalPolicy: RemovalPolicy.DESTROY, autoDeleteObjects: true, }); データとか知らん、消えてしまえ 13
14. lib/s3-stack.ts ts removalPolicy: RemovalPolicy.DESTROY, Stackから削除すると、Bucketも削除される 14
15. lib/s3-stack.ts ts autoDeleteObjects: true, 中身を先に空にしてから、Bucketを削除する 15
16. CDKコードからBucketを削除 - const bucket = new s3.Bucket( - this, "Uploads", { - removalPolicy: - RemovalPolicy.DESTROY, - autoDeleteObjects: true, - }); サンプル出力 Resources [-] AWS::S3::Bucket 　Uploads... 16
17. deploy成功 サンプル出力 $ cdk deploy S3Stack S3Stack: deploying... S3Stack: destroying... ✅ S3Stack 17
18. Bucketもデータも消えた Amazon S3 削除後: Bucketは存在しない 18
19. RemovalPolicy.RETAIN lib/s3-stack.ts ts const bucket = new s3.Bucket(this, "Uploads" removalPolicy: RemovalPolicy.RETAIN, }); 19
20. RemovalPolicy.RETAIN lib/s3-stack.ts ts removalPolicy: RemovalPolicy.RETAIN, Stackから削除しても、Bucketは残る 20
21. Stackの管理外に残る AWS CloudFormation Stack管理外 Amazon S3 BucketとObjectは残る 21
22. RETAINは、移行でも バックアップでもない 残るだけ。新しいリソースへデータは移らない。 22
23. 次は、気づきにくく壊したい 23
24. OrderStack export class OrderStack extends Stack { constructor( scope: Construct, id: string, props?: StackProps, ) { super(scope, id, props); const table = new Table(this, "Table", { partitionKey: { name: "id", type: AttributeType.STRING, }, removalPolicy: RemovalPolicy.RETAIN, }); } } DynamoDB 変更前: 3件 24
25. Construct IDを変更する - const table = new Table(this, "Table", { + const table = new Table(this, "Orders", { 25
26. これをdeployすると、 何が起きると思いますか？ - "Table"　→　+ "Orders" 26
27. deploy前に cdk diffで確認する 27
28. cdk diffが比較するもの ローカルの CDKコード → 新しい CloudFormation template ↔ デプロイ済み Stackの template template同士の差分を見る 28
29. デフォルトは --method=auto $ cdk diff OrderStack default: --method=auto 29
30. cdk diffのmethod method 動作 auto Change Setを試す 失敗したらtemplate比較 change-set Change Setを使って差分を確認 template template同士を比較 https://docs.aws.amazon.com/cdk/v2/guide/ref-cli-cmd-diff.html 30
31. cdk diffで見える変更 サンプル出力 Resources [-] AWS::DynamoDB::Table Table... [+] AWS::DynamoDB::Table Orders... 31
32. 更新ではない [-] AWS::DynamoDB::Table Table... [+] AWS::DynamoDB::Table Orders... 削除 ＋ 追加 32
33. なぜ名前を変えただけで、 削除と追加になる？ 33
34. これはConstruct ID const table = new Table( this, "Orders", { /* ... */ }, ); これは変数名ではない　Construct ID 34
35. CDKからAWSリソースまで CDK OrderStack Construct ID: Table → CloudFormation Logical ID → AWS DynamoDB 物理Table 35
36. Construct IDを変えた結果 Construct ID Table → 旧Logical ID → 旧DynamoDB Table Construct ID Orders → 新Logical ID → 新DynamoDB Table CloudFormationには、別のリソースに見える 36
37. TableにはRETAINがある lib/order-stack.ts ts removalPolicy: RemovalPolicy.RETAIN, 37
38. deploy成功 サンプル出力 $ cdk deploy OrderStack OrderStack: deploying... UPDATE_COMPLETE ✅ OrderStack 38
39. Tableが2つある Amazon DynamoDB new-orders / old-orders 39
40. データがあるTable、空のTable 旧Table 3件のまま 新Table 0件 40
41. Stackが管理しているTable Resources表示例 Logical ID　Orders... Type　　　　AWS::DynamoDB::Table 新Tableだけを管理 Amazon DynamoDB 旧Tableと新Tableが存在 41
42. データは消えていない でも、アプリからは消えた 42
43. Construct IDと物理名 new Table(this, "Orders", { tableName: "customer-orders", }); "Orders" Construct ID "customer-orders" 物理名 43
44. CDK Refactor Construct IDを変えても、 同じ物理リソースを引き継ぐ Preview: 2025-09-10 https://aws.amazon.com/about-aws/whats-new/2025/09/aws-cdk-refactor-preview/ 44
45. Logical IDを付け替える 旧Logical ID 新Logical ID → 同じ物理 DynamoDB Table Logical IDは変わる　物理リソースは変えない 45
46. まず --dry-run $ cdk refactor --dry-run 対応付け例 AWS::DynamoDB::Table Table...　→　Orders... 同じ物理Tableを引き継ぐ 46
47. cdk refactorを実行できる条件 変えてよいのは、リソースの配置とLogical IDだけ refactorできる refactorできない Construct IDの変更 リソースのプロパティ変更 階層の組み替え リソースの追加 同じ環境内でStack間を移動 リソースの削除 47
48. 今回の変更をrefactorする Construct ID:　Table → Orders Logical ID:　旧 → 新 物理Table:　同じものを引き継ぐ 対応付け例 Table...　→　Orders... 物理Tableは変更しない 48
49. refactor後の結果 Logical ID 変更された 物理Table 同じ 注文データ 3件のまま Amazon DynamoDB refactor後も3件のまま 49
50. コードを読みやすくする 普通のリファクタリングに見える でも、仕組みを知らずにdeployすると Tableが入れ替わる 普通の変更に見えるから、芸術点が高い 50
51. AWS Consoleから 手動で変更する 壊し方としては、ちょっと奥の手 51
52. SQSを手動変更する 設定例 Visibility Timeout 30秒 → 60秒 52
53. cdk diffの結果 $ cdk diff QueueStack サンプル出力 There were no differences 53
54. なぜdiffに出ないのか ローカルの template 30秒 ↔ デプロイ済み template 30秒 ⋯ AWS上のSQS 60秒 cdk diffは左のtemplate同士を比較する 54
55. 実リソースとのズレを見るなら cdk drift 55
56. cdk driftが比較するもの デプロイ済みtemplate に記録された構成 ↔ AWS上の現 在の リソース構 成 56
57. cdk diffとcdk driftの違い CDKコード 新しい template デプロイ済み template 現在の リソース cdk diff cdk drift 57
58. Stack名で確認範囲が変わる 1つのStackを確認 $ cdk drift QueueStack QueueStackだけ Stack名を省略 $ cdk drift アプリ内の全Stack 58
59. driftがあれば終了コード1 $ cdk drift QueueStack --fail --fail　driftが見つかったらexit code 1 すべてのリソースやプロパティが、drift detectionの対象とは限らない 59
60. SQSのdriftを検出 サンプル出力 Queue　MODIFIED Property　VisibilityTimeout Expected　30 Actual　　60 60
61. 同じ変更に対する結果 cdk diff There were no differences cdk drift 1 resource drifted 61
62. IN_SYNCは何を意味するか Stackのdrift status 意味 IN_SYNC 対応リソースの現在の構成がtemplateと一致 DRIFTED 1つ以上のリソースに差分がある NOT_CHECKED driftをまだ確認していない UNKNOWN driftの確認に失敗した IN_SYNCでも、アプリが正常に動くとは限らない リソース単位ではMODIFIED / DELETEDなどのstatusも表示される 62
63. cdk diffとcdk driftを 両方確認すれば安全？ 63
64. KMSで暗号化したS3 Object アプリ GetObject → S3 Object 暗号化 → KMS Key アプリ → kms:Decrypt → KMS Key 64
65. 変更前は読める GetObject: 成功 kms:Decrypt: Allow アプリ出力例 $ node read-object.js { 　"status": "ok", 　"object": "sample.txt" } 65
66. kms:Decryptを削除する actions: [ "s3:GetObject", - "kms:Decrypt", ] 66
67. cdk diffには表示される サンプル出力 IAM Statement Changes [-] Action: kms:Decrypt Resource: KmsKey... 67
68. deploy前: 変更内容とズレを確認 cdk diff　kms:Decryptの削除を表示 cdk drift　IN_SYNC このままdeploy 68
69. deploy成功 サンプル出力 $ cdk deploy KmsAppStack KmsAppStack: deploying... UPDATE_COMPLETE ✅ KmsAppStack 69
70. 見えていなかった読み取り経路 アプリ GetObject → S3 Object Decrypt → KMS Key 実は、Objectを読む処理が残っていた 70
71. AccessDenied エラー出力例 $ node read-object.js AccessDenied not authorized to perform: kms:Decrypt 71
72. 消えていない 確認例 $ aws s3api head-object 　--bucket <bucket> 　--key sample.txt ContentLength: 128 確認例 $ aws kms describe-key 　--key-id <key-id> KeyState: Enabled 72
73. IN_SYNCでも、アプリは壊れる 確認 結果 cdk diff kms:Decrypt削除を表示 cdk drift IN_SYNC cdk deploy UPDATE_COMPLETE アプリ AccessDenied リソースもデータも残っている でも、アプリからは使えない 73
74. 見ているものが違う コマンド 比較しているもの cdk diff 新しいtemplate ↔ デプロイ済みtemplate cdk drift デプロイ済みtemplate ↔ 現在のリソース AI どちらも、アプリが正常に動くことまでは確認していない AIに見えるのは、コードとコマンド出力だけ 74
75. どういう操作をしたときに、 何が消えて、何が残るのか それを理解するために、 一度、自分で壊してみる 壊れる条件が分かると、どこを確認すればいいのかも見えてくる 75
76. そのcdk deployで、 何が消えて、何が残る？ 76
77. ご清聴ありがとうございました。 77