壊して学ぶ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 好きなAWSサービス AWS Community Builder AWS All Certifications Engineer JAWS-UG 配信部 最近ハマっているもの Kazuki Adachi KiroとCDK @k_adachi_01 コーヒーとトレラン 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 Uploads4F6EB0FD destroy [-] Custom::S3AutoDeleteObjects 16
17. deploy成功 実出力（抜粋） $ cdk deploy S3Stack S3Stack: deploying... [1/1] DELETE_IN_PROGRESS AWS::S3::Bucket DELETE_COMPLETE AWS::S3::Bucket UPDATE_COMPLETE AWS::CloudFormation::Stack ✅ 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が比較するもの 新しい デプロイ済み ローカルの → CloudFormation ↔ Stackの CDKコード template template template同士の差分を見る 28
29. デフォルトは --method=auto $ cdk diff OrderStack default: --method=auto 29
30. cdk diffのmethod method auto change-set template 動作 Change Setを試す 失敗したらtemplate比較 Change Setを使って差分を確認 template同士を比較 https://docs.aws.amazon.com/cdk/v2/guide/ref-cli-cmd-diff.html 30
31. cdk diffで見える変更 実出力 Resources [-] AWS::DynamoDB::Table Table TableCD117FA1 orphan [+] AWS::DynamoDB::Table Orders OrdersA9B65338 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 AWS OrderStack → CloudFormation → DynamoDB Construct Logical ID 物理Table ID: Table 35
36. Construct IDを変えた結果 Construct ID Table Construct ID Orders → → 旧Logical ID 旧DynamoDB → Table 新Logical ID 新DynamoDB → Table CloudFormationには、別のリソースに見える 36
37. TableにはRETAINがある lib/order-stack.ts ts removalPolicy: RemovalPolicy.RETAIN, 37
38. deploy成功 実出力（抜粋） $ cdk deploy OrderStack CREATE_COMPLETE OrdersA9B65338 DELETE_SKIPPED TableCD117FA1 UPDATE_COMPLETE AWS::CloudFormation::Stack OrderStack ✅ 38
39. Tableが2つある Amazon DynamoDB new-orders / old-orders 39
40. データがあるTable、空のTable 旧Table 3件のまま 新Table 0件 40
41. Stackが管理しているTable Amazon DynamoDB list-stack-resources 実出力 Logical ID OrdersA9B65338 Type AWS::DynamoDB::Table Status CREATE_COMPLETE 新Tableだけを管理 旧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 --unstable=refactor --dry-run 実出力 The following resources were moved or renamed: AWS::DynamoDB::Table OrderStack/Table/Resource → OrderStack/Orders/Resource 46
47. cdk refactorを実行できる条件 変えてよいのは、リソースの配置とLogical IDだけ refactorできる Construct IDの変更 階層の組み替え 同じ環境内でStack間を移動 refactorできない リソースのプロパティ変更 リソースの追加 リソースの削除 47
48. 今回の変更をrefactorする Construct ID: Table → Orders Logical ID: 旧 → 新 物理Table: 同じものを引き継ぐ dry-run 実出力 OrderStack/Table/Resource → OrderStack/Orders/Resource 同じ物理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を確認 Stack名を省略 $ cdk drift QueueStack $ cdk drift QueueStackだけ アプリ内の全Stack 58
59. driftがあれば終了コード1 $ cdk drift QueueStack --fail --fail driftが見つかったらexit code 1 すべてのリソースやプロパティが、drift detectionの対象とは限らない 59
60. SQSのdriftを検出 実出力（抜粋） Modified Resources [~] AWS::SQS::Queue Queue └─ [~] /VisibilityTimeout ├─ [-] 30 └─ [+] 60 1 resource has drifted 60
61. 同じ変更に対する結果 cdk diff cdk drift There were no differences 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 Lambda invoke 実出力 $ aws lambda invoke ... { "StatusCode": 200 } { "status": "ok", "object": "sample.txt" } 65
66. kms:Decryptを削除する actions: [ "s3:GetObject", - "kms:Decrypt", ] 66
67. cdk diffには表示される 実出力（抜粋） IAM Statement Changes [-] Action: kms:Decrypt Resources [~] AWS::IAM::Policy AppRoleDefaultPolicy1872B475 67
68. deploy前: 変更内容とズレを確認 cdk diff kms:Decryptの削除を表示 cdk drift IN_SYNC このままdeploy 68
69. deploy成功 実出力（抜粋） $ cdk deploy KmsAppStack UPDATE_IN_PROGRESS AWS::CloudFormation::Stack UPDATE_COMPLETE AWS::IAM::Policy UPDATE_COMPLETE AWS::CloudFormation::Stack ✅ KmsAppStack 69
70. 見えていなかった読み取り経路 アプリ GetObject S3 Object → Decrypt → KMS Key 実は、Objectを読む処理が残っていた 70
71. AccessDenied Lambda invoke 実出力 { "StatusCode": 200, "FunctionError": "Unhandled" } AccessDenied not authorized to perform: kms:Decrypt no identity-based policy allows the action 71
72. 消えていない head-object 実出力 $ aws s3api head-object --bucket <bucket> --key sample.txt ContentLength: 17 describe-key 実出力 $ aws kms describe-key --key-id <key-id> KeyState: Enabled 72
73. IN_SYNCでも、アプリは壊れる 確認 cdk diff cdk drift cdk deploy アプリ 結果 kms:Decrypt削除を表示 IN_SYNC UPDATE_COMPLETE AccessDenied リソースもデータも残っている でも、アプリからは使えない 73
74. 見ているものが違う コマンド cdk diff cdk drift AI 比較しているもの 新しいtemplate ↔ デプロイ済みtemplate デプロイ済みtemplate ↔ 現在のリソース AIに見えるのは、コードとコマンド出力だけ どちらも、アプリが正常に動くことまでは確認していない 74
75. どういう操作をしたときに、 何が消えて、何が残るのか それを理解するために、 一度、自分で壊してみる 壊れる条件が分かると、どこを確認すればいいのかも見えてくる 75
76. そのcdk deployで、 何が消えて、何が残る？ 76
77. ご清聴ありがとうございました。 77