How to Keep AI from Breaking Your Environment with AWS CDK
How to Keep AI from Breaking Your Environment with AWS CDK
More and more people are letting AI write their AWS CDK code. At the same time, some may feel uneasy about AI breaking their environment on its own.
For those people, this article introduces a way to safely stop the process only when a change to your CDK code contains a dangerous diff that could break your environment.
Destructive Changes
So what kind of dangerous diff can break an environment?
It is a destructive change, where a resource is deleted or replaced (recreated).
Simply adding a resource or changing a property is usually recoverable. But deleting or replacing a resource can affect your system, causing unexpected downtime or data loss.
Especially these days, some people let AI not only write CDK code but also deploy the resources. You absolutely want to avoid handing CDK development over to AI, running iteration after iteration, and then finding that an important resource has been deleted.
Of course, even if you don't let AI handle the deployment, you probably deploy through CI/CD, especially for production, and the same thing applies to automated deployments in a pipeline.
The Difficulty of Judging Destructive Changes
Some of you may already have been showing diffs to AI and having it judge whether an operation is dangerous. When you leave the judgment to AI, however, it inevitably becomes non-deterministic, which makes it hard to meet a requirement like reliably detecting and preventing destructive changes every single time.
The reason is this: just by looking at the diff of the CloudFormation template that CDK generates, you can tell whether a resource itself will be deleted.
But some AWS resources are replaced, that is, recreated, when a specific property is changed.
So even if the template diff shows no resource deletion, you cannot determine whether the change is destructive unless you can also judge changes to the properties that trigger replacement.
Mechanical Detection of Destructive Changes
The approach introduced here is now possible as a feature of AWS CDK itself: you can detect destructive changes mechanically and deterministically. Compared with having AI judge the diff, this gives you certainty.
In other words, you can now let AI drive development autonomously while reliably blocking only destructive changes for a human to judge, achieving both autonomy and safety.
This enables a workflow where a human decides whether the destructive change is expected, and approves it only in that case so the CI pipeline can move forward.
How to Do This in AWS CDK
AWS CDK CLI v2.1145.0 made the following available on the cdk diff and cdk deploy commands. These are the measures for detecting and preventing destructive changes.
- cdk diff --fail-on destructive
- cdk deploy --require-approval destructive
cdk diff --fail-on destructive
The --fail-on option makes the command fail when a diff occurs and matches the condition you specify.
This option itself did not exist before; it was added in this release. Until now, there was only --fail, which fails the command whenever a diff occurs.
You can pass the following four values to --fail-on. These values are in fact the same ones you can pass to cdk deploy --require-approval, which is described next.
- broadening: fails when there are changes that broaden permissions from a security standpoint, such as adding IAM statements or security group rules
- any-change: fails whenever a diff occurs, no matter what the change is (= --fail)
- never: never fails, no matter what the change is
- destructive: fails when there is a destructive change
Running cdk diff with destructive passed to --fail-on makes it exit with an error only when there are destructive changes such as resource deletions or replacements.
$ npx cdk diff --fail-on destructive
...(omitted)
...
Resources
[~] AWS::Lambda::Function ChatBackend/HistoryFn ChatBackendHistoryFnCCDE0D46 replace
└─ [+] FunctionName (requires replacement)
└─ changed-name
...
✨ Number of stacks with differences: 1
❌ Found 5 destructive change(s) (--fail-on=destructive):
MyStack: AWS::Lambda::Function ChatBackend/HistoryFn ChatBackendHistoryFnCCDE0D46 will be replaced
...
cdk deploy --require-approval destructive
--require-approval is an option that prompts the user for confirmation when a diff at deploy time matches the condition you specify.
As with cdk diff above, specifying destructive now lets you detect destructive changes and prompt for confirmation.
$ npx cdk deploy --require-approval destructive
...(omitted)
...
Destructive changes:
MyStack: AWS::Lambda::Function ChatBackend/HistoryFn ChatBackendHistoryFnCCDE0D46 will be replaced
...
Stack includes destructive updates and "--require-approval" is set to 'destructive'.
Do you wish to deploy these changes? (y/n)
Putting It into Practice
Whether you let AI drive development autonomously or not — in CI/CD, for example — it is a good idea to run cdk diff --fail-on destructive before you deploy.
With AI, have the command run automatically from within a skill or a hook; with CI/CD, insert a stage right before the deploy. The basic idea is to keep the process running, and when a destructive change does appear, approve it and move on if the change is what you intended.
!A development flow that fails only on destructive changes and goes back to implementation when they are unexpected
With this in place, the process stops only on destructive changes inside an autonomous, automated loop, which gives you a workflow that ensures safety at a low cost.
Contributing to the AWS CDK CLI
This feature actually started as an idea I had and wanted for myself. So I implemented it in the upstream repository, opened PRs, and had them merged. It ended up as the following three PRs, making it a fairly large feature addition.
- feat(cli): add --fail-on to cdk diff
- feat(cli): add destructive to cdk diff --fail-on
- feat(cli): add destructive to cdk deploy --require-approval
Shipped First in cdkd
This feature was in fact shipped first in an OSS CLI tool called cdkd that I develop on my own, and was added to the CDK CLI afterwards. (Only a few days apart, though.)
cdkd is a from-scratch reimplementation of the CDK CLI. It lets you deploy CDK up to 15 times faster without changing a single line of your CDK code. If you are interested, I would be happy if you took a look.
GitHub: go-to-k/cdkd
P.S. A Follow-up PR (Added on 2026/10/21)
The destructive check described above flags a deletion or replacement of any resource.
However, some services replace resources on every code change or deployment, such as API Gateway deployments, Lambda aliases (versions), and Lambda Web Functions revisions. In those cases, the check fires every time, which makes this approach hard to adopt.
So I later submitted another PR that adds an option to exclude specific resources from the check:
feat(cli): add --ignore-destructive to exclude resources from the destructive check
Once this is merged, you will be able to apply the approach introduced here even to resource configurations where routine replacements are the normal use case.
Final Thoughts
As AI becomes widespread, the way we develop with AWS CDK keeps changing. Still, building infrastructure comes with side effects, so fully automating it remains a little unnerving.
I think the approach introduced here is a well-balanced hybrid that leaves as much as possible to AI while having humans cover only the genuinely dangerous and important parts.
Mentions
cdk refactor で論理 ID を付け替えるときにハマったポイント はじめに AWS CDK で、construct ID（CloudFormation の論理 ID の元になる名前）をまとめてリネームしました。 Firehose や S3 バケットが後から増えて、名前だけでは区別がつきにくくなったためです。たとえば、Lambda のログを S3 に転送する Firehose が 1 本だけのころは LogFirehose で十分でしたが、API Gateway のアクセスログ転送用が加わると、どちらが何のログを転送するものか分からなくなりました。そこで LambdaLogFirehose / ApiGwAccessLogFirehose のように付け直しました。 データを残したまま付け替えたかったので cdk refactor を使いましたが、「リネーム以外の変更が含まれている」と言われて、なかなか通りませんでした。ハマったのは次の 4 つです。 ロールの名前を変えると、CDK が自動で作るポリシーの中身も変わる 日本語の説明文が、デプロイ済みのテンプレートでは ??? に化けている node.addDependency() で付けた依存関係の並び順がずれる（しかも、外してもデプロイに反映されない） Glue テーブルは付け替えられない（dry-run では分からない） 検証時の CDK CLI のバージョンは v2.1135.1（2026 年 8 月時点）です。cdk refactor はプレビュー機能なので、今後動作が変わる可能性があります1。cdk refactor の仕組みは、次の節で説明します。 前提: なぜ cdk refactor を使うか CloudFormation の論理 ID は、CDK が construct ID をもとに生成します。そのため construct ID を変えると論理 ID も変わり、CloudFormation からは「旧リソースを削除して、新リソースを作成する」ように見えます1:1。 S3 バケットやロググループのように物理名を固定しているリソースでは、新旧が同じ名前になるので衝突します。旧リソースをいったんスタックから外して削除すれば作り直せますが、重要なデータを持つ S3 バケットを消すわけにはいきません。 そこで使うのが cdk refactor です。実リソースを残したまま、論理 ID だけを付け替えてくれます。プレビュー機能なので --unstable=refactor が必要です2。 cdk refactor MyStack --unstable=refactor --dry-run 覚えておくべき制約があります。cdk refactor は、デプロイ済みのリソースとコード上のリソースを、プロパティと依存関係で比べます。参照（Ref など）の書き方の違いを除いて、完全に一致したものだけを「名前の変更や移動」と判断します。一致しないリソースが 1 つでもあると、付け替え全体が拒否されます1:2。ハマりどころ 1〜3 は、どれもこの制約が原因です。 cdk refactor の比べ方 cdk refactor は、リソースごとに次の 3 つから 1 つのハッシュ値を作り、デプロイ済みとコード上で突き合わせます34。 リソースの種類（AWS::IAM::Policy など） プロパティ。ただし Ref や Fn::GetAtt で書かれた参照は伏せてから計算するので、参照先の論理 ID が変わっても影響しません 依存先のハッシュ値。依存関係の並び順のままつなげます そのため、次のどれかに当てはまると一致しません。 プロパティに、論理 ID が Ref などの参照ではなく、ただの文字列として入っている（ハマりどころ 1） デプロイ済み側のプロパティが文字化けている（ハマりどころ 2） 依存先が 1 つでも一致しない（依存元にも不一致が連鎖する） 依存関係の並び順が変わった（ハマりどころ 3） 今回の進め方 今回は、リネームと同じ PR に別の修正も入っていました。このコードのままでは、cdk deploy でも cdk refactor でも通りません（下の図の点線）。cdk deploy では物理名が衝突し、cdk refactor では別の修正が「リネーム以外の変更」と判定されるためです。 そこで、論理 ID だけを旧名に戻した一時ブランチを、踏み台として先にデプロイしました（図の①）。こうすると、デプロイ済みの状態とリネーム後のコードの違いが名前だけになり、cdk refactor で付け替えられるはずです（図の②）。 ②は、まず cdk refactor --dry-run で確かめてから本実行する予定でした。ところが、dry-run で次のエラーになりました。 ❌ Refactor failed: A refactor operation cannot add, remove or update resources. Only resource moves and renames are allowed. The following resources are present only in the AWS environment: [-] MyStack/LogFirehoseRole/DefaultPolicy/Resource [-] MyStack/LogFirehose ... The following resources are present only in your CDK application: [+] MyStack/LambdaLogFirehoseRole/DefaultPolicy/Resource [+] MyStack/LambdaLogFirehose ... The following resources are different in your CDK application and the AWS environment: [~] MyStack/MyFunctionLogGroupToFirehose ... 中身は何も変えていないのに、数十件のリソースが「削除と追加」や「変更」と判定されました。ここから先が、その原因と対処です。 ハマりどころ 1: ロールの名前を変えると、自動で作られるポリシーも変わる 症状: ロールと、そのロールに付いているポリシー、さらにそれを使う Firehose などが、まとめて「削除と追加」と判定されました。 原因: CDK の grant 系のメソッドなどでロールに権限を付けると、CDK はそのロール専用のポリシー（DefaultPolicy）を自動で作ります。このポリシーの名前には、ロールの論理 ID から作った文字列がそのまま入ります。 "LogFirehoseRoleDefaultPolicyXXXXXXXX": { "Type": "AWS::IAM::Policy", "Properties": { "PolicyName": "LogFirehoseRoleDefaultPolicyXXXXXXXX", "Roles": [{ "Ref": "LogFirehoseRoleYYYYYYYY" }] } } ロールの名前を変えるとポリシー名も変わるので、cdk refactor からは「中身が変わった」ように見えます。さらに、このポリシーに依存するリソースにも不一致が連鎖します。 対処: リソースを「論理 ID を変えると物理名も変わるか」で 2 つに分けました。 区分 例 付け替え方 物理名が論理 ID から自動生成される IAM ロール・DefaultPolicy・SubscriptionFilter 新旧が別の名前になり衝突しないので、普通の cdk deploy で付け替える 物理名が固定 S3 バケット・Glue テーブル・Firehose・ロググループ cdk refactor で付け替える 前者を先に cdk deploy しておけば、ポリシー名はデプロイ済みとコード上で一致します。cdk refactor に渡すのは、純粋に名前だけが変わる後者だけになります。 ハマりどころ 2: 日本語の説明文が ??? に化けている 症状: 説明文（Description）に日本語を書いたリソースも「変更」と判定されました。cdk diff で見ると、デプロイ済み側の日本語が ? になっています。 [~] AWS::Lambda::Function MyStack/MyFunction ├─ [~] Description │ ├─ [-] ????????? │ └─ [+] 日本語の説明文です 原因: デプロイ済みのテンプレートを AWS CLI で取得すると、その時点で日本語が ? に置き換わっていました。1 文字が ? 1 つになります。 aws cloudformation get-template --stack-name MyStack \ --template-stage Original --query TemplateBody --output json "Description": "?????????" リソースそのものは正常で、コンソールでは日本語で表示されます。化けるのはテンプレートを読み出したときだけです。cdk refactor はこの読み出したテンプレートと比べるので、日本語を含む文字列はどうやっても一致しません。 対処: 一時ブランチで説明文を英数字に置き換えてデプロイし、デプロイ済み側も英数字にそろえました。付け替えが終わったら、日本語に戻して問題ありません（cdk refactor を使うときだけ一致していればよいため）。 ハマりどころ 3: 依存関係の並び順がずれる 症状: 1 と 2 を片付けた後も、Firehose と、それに依存するリソースが不一致のまま残りました。 原因: Firehose には node.addDependency() で「ロール・ポリシー・ロググループの後に作る」という依存関係を付けていました。テンプレートでは、依存先の論理 ID が名前順に並びます。 デプロイ済み: [ LambdaLogFirehoseRoleDefaultPolicy..., LambdaLogFirehoseRole..., LogFirehoseLogGroup... ] コード上: [ LambdaLogFirehoseLogGroup..., LambdaLogFirehoseRoleDefaultPolicy..., LambdaLogFirehoseRole... ] ハマりどころ 1 の対処で、ロールとポリシーは先に新しい名前にしました。一方、ロググループは物理名が固定なので旧名のままです。名前が変わったことで、ロググループの位置が末尾から先頭に移っています。cdk refactor は依存先を並び順のまま比べるので、中身が同じでも不一致になります（2026-10 時点の最新の CLI でも同じです5）。 対処: node.addDependency() を一時的に外してデプロイし、デプロイ済み側とコード上の両方から依存関係を消すことにしました。比べる対象から消えれば、並び順は関係なくなります。 外したのに、デプロイに反映されない ここでもう 1 つハマりました。node.addDependency() を外してデプロイすると、ログは成功で終わるのに (no changes) と表示され、テンプレートが更新されませんでした。 DependsOn（node.addDependency() がテンプレートに書き出す項目）だけを変えたデプロイは、CloudFormation が「変更なし」と扱います。公式ドキュメントに明記はありませんが、実際にデプロイして確認した挙動です6。 そこで、作り直しが起きない別の変更を 1 つ混ぜてデプロイしました。今回は、付け替えの対象ではないリソースの説明文を変えました。ほかに変更があればデプロイは反映されるので、依存関係の削除も一緒に反映されます。 混ぜた変更は、「今回の進め方」の図の①の一時ブランチと、②のリネーム後のコードの両方に入れておきます。片側だけに入っていると、それ自体が「変更」と判定されます。 ハマりどころ 4: Glue テーブルは付け替えられない 症状: dry-run は Glue テーブルを含めて「付け替え可能」と表示し、成功しました。ところが本実行で失敗しました。 ❌ Refactor failed: Refactor creation: [CREATE_FAILED] arn:aws:cloudformation:...:stack/MyStack/...: Stack Refactor does not support AWS::Glue::Table. 原因: CloudFormation 側が Glue テーブルの付け替えに対応していません。しかも、本実行するまで分かりませんでした。 公式ドキュメントの「付け替えに対応していないリソース」の一覧に、AWS::Glue::Table は載っていません（2026-11-02 時点）7 dry-run は CDK CLI の中で比べるだけで、CloudFormation が対応しているかまでは確認しません 対処: Glue テーブルだけを cdk refactor から外し、仮の名前を経由して作り直しました。 Glue テーブルの論理 ID だけを旧名に戻したコードで cdk refactor を本実行する（Glue テーブル以外の付け替えが完了） Glue テーブルを新しい論理 ID ＋仮の物理名にしてデプロイする。新しいテーブルが仮の名前で作られ、旧テーブルは消えるので衝突しない 物理名を正式な名前に戻してデプロイする Glue テーブルはデータの置き場所を記録しているだけなので、作り直しても S3 上のデータは消えません。今回のテーブルはパーティション射影を使っていたので、パーティションを登録し直す必要もありませんでした。 まとめ cdk refactor を使う前に、次のことを確認しておくと楽になります。 リネームだけの変更になっているか リネームは、ほかの修正と別の PR に分けておく。今回はリネームと別の修正が同じ PR に入っていたため、一時ブランチを踏み台にする必要がありました（「今回の進め方」の図の①） 一致しなくなる原因が無いか（ハマりどころ 1〜3） どれも、cdk refactor が「プロパティと依存関係が完全に一致したものだけを付け替える」ことから来ています。 付け替えるリソースの物理名は、自動生成か固定か（自動生成なら cdk deploy で済む） テンプレートに日本語などの非 ASCII 文字が入っていないか node.addDependency() で依存関係を付けたリソースについて、依存先の一部だけを先に付け替えることにならないか CloudFormation が付け替えに対応しているか（ハマりどころ 4） Glue テーブルを使っていないか（ドキュメントの一覧に載っていなくても、付け替えに対応していないリソースがあります） 別の選択肢: 論理 ID を変えない そもそも論理 ID を変えない方法もあります。overrideLogicalId() で論理 ID を旧名に固定すれば、コード上の construct ID だけを付け直せます。CloudFormation から見ると何も変わらないので、cdk deploy も cdk refactor も要りません。 ただし、CloudFormation のリソース一覧や cdk diff の出力には、旧名の論理 ID が残ります。「名前で区別しやすくする」という目的は半分しか達成できません。今回は使いませんでしたが、次にリネームするときはまずこちらを検討すると思います。 脚注 Preserve deployed resources when refactoring CDK code - AWS CDK v2 Developer Guide ↩︎ ↩︎ ↩︎ cdk refactor - AWS CDK v2 Developer Guide ↩︎ aws-cdk-cli v2.1135.1: packages/@aws-cdk/toolkit-lib/lib/api/refactoring/digest.ts L61-L63 ↩︎ aws-cdk-cli v2.1135.1: packages/@aws-cdk/toolkit-lib/lib/api/refactoring/context.ts L195-L255 ↩︎ aws-cdk-cli（2026-10 時点の main）: packages/@aws-cdk/toolkit-lib/lib/api/refactoring/digest.ts L78-L84 ↩︎ 参考: 変更セットが「どの項目の変更か」を表す値は Properties | Metadata | CreationPolicy | UpdatePolicy | DeletionPolicy | UpdateReplacePolicy | Tags の 7 つで、DependsOn が含まれていません。ResourceTargetDefinition - AWS CloudFormation API Reference ↩︎ Stack refactoring - AWS CloudFormation User Guide（Resource limitations） ↩︎
これも出してて、ぜひマージされてほしいところ。 cdk diff --fail-on destructive で除外対象リソースを指定できるようにするやつ。 aws-cdk-cli#2069
昨日はリグレッション解決コントリビュートしました。さすがにマージは早かった。 aws-cdk-cli#2071
cdk evaluate コマンドが生えそう。 aws-cdk-cli#2066
こんな機能追加も提案。 aws-cdk-cli#2065
How to Keep AI from Breaking Your Environment with AWS CDK How to Keep AI from Breaking Your Environment with AWS CDK More and more people are letting AI write their AWS CDK code. At the same time, some may feel uneasy about AI breaking their environment on its own. For those people, this article introduces a way to safely stop the process only when a change to your CDK code contains a dangerous diff that could break your environment. Destructive Changes So what kind of dangerous diff can break an environment? It is a destructive change, where a resource is deleted or replaced (recreated). Simply adding a resource or changing a property is usually recoverable. But deleting or replacing a resource can affect your system, causing unexpected downtime or data loss. Especially these days, some people let AI not only write CDK code but also deploy the resources. You absolutely want to avoid handing CDK development over to AI, running iteration after iteration, and then finding that an important resource has been deleted. Of course, even if you don't let AI handle the deployment, you probably deploy through CI/CD, especially for production, and the same thing applies to automated deployments in a pipeline. The Difficulty of Judging Destructive Changes Some of you may already have been showing diffs to AI and having it judge whether an operation is dangerous. When you leave the judgment to AI, however, it inevitably becomes non-deterministic, which makes it hard to meet a requirement like reliably detecting and preventing destructive changes every single time. The reason is this: just by looking at the diff of the CloudFormation template that CDK generates, you can tell whether a resource itself will be deleted. But some AWS resources are replaced, that is, recreated, when a specific property is changed. So even if the template diff shows no resource deletion, you cannot determine whether the change is destructive unless you can also judge changes to the properties that trigger replacement. Mechanical Detection of Destructive Changes The approach introduced here is now possible as a feature of AWS CDK itself: you can detect destructive changes mechanically and deterministically. Compared with having AI judge the diff, this gives you certainty. In other words, you can now let AI drive development autonomously while reliably blocking only destructive changes for a human to judge, achieving both autonomy and safety. This enables a workflow where a human decides whether the destructive change is expected, and approves it only in that case so the CI pipeline can move forward. How to Do This in AWS CDK AWS CDK CLI v2.1145.0 made the following available on the cdk diff and cdk deploy commands. These are the measures for detecting and preventing destructive changes. - cdk diff --fail-on destructive - cdk deploy --require-approval destructive cdk diff --fail-on destructive The --fail-on option makes the command fail when a diff occurs and matches the condition you specify. This option itself did not exist before; it was added in this release. Until now, there was only --fail, which fails the command whenever a diff occurs. You can pass the following four values to --fail-on. These values are in fact the same ones you can pass to cdk deploy --require-approval, which is described next. - broadening: fails when there are changes that broaden permissions from a security standpoint, such as adding IAM statements or security group rules - any-change: fails whenever a diff occurs, no matter what the change is (= --fail) - never: never fails, no matter what the change is - destructive: fails when there is a destructive change Running cdk diff with destructive passed to --fail-on makes it exit with an error only when there are destructive changes such as resource deletions or replacements. $ npx cdk diff --fail-on destructive ...(omitted) ... Resources [~] AWS::Lambda::Function ChatBackend/HistoryFn ChatBackendHistoryFnCCDE0D46 replace └─ [+] FunctionName (requires replacement) └─ changed-name ... ✨ Number of stacks with differences: 1 ❌ Found 5 destructive change(s) (--fail-on=destructive): MyStack: AWS::Lambda::Function ChatBackend/HistoryFn ChatBackendHistoryFnCCDE0D46 will be replaced ... cdk deploy --require-approval destructive --require-approval is an option that prompts the user for confirmation when a diff at deploy time matches the condition you specify. As with cdk diff above, specifying destructive now lets you detect destructive changes and prompt for confirmation. $ npx cdk deploy --require-approval destructive ...(omitted) ... Destructive changes: MyStack: AWS::Lambda::Function ChatBackend/HistoryFn ChatBackendHistoryFnCCDE0D46 will be replaced ... Stack includes destructive updates and "--require-approval" is set to 'destructive'. Do you wish to deploy these changes? (y/n) Putting It into Practice Whether you let AI drive development autonomously or not — in CI/CD, for example — it is a good idea to run cdk diff --fail-on destructive before you deploy. With AI, have the command run automatically from within a skill or a hook; with CI/CD, insert a stage right before the deploy. The basic idea is to keep the process running, and when a destructive change does appear, approve it and move on if the change is what you intended. !A development flow that fails only on destructive changes and goes back to implementation when they are unexpected With this in place, the process stops only on destructive changes inside an autonomous, automated loop, which gives you a workflow that ensures safety at a low cost. Contributing to the AWS CDK CLI This feature actually started as an idea I had and wanted for myself. So I implemented it in the upstream repository, opened PRs, and had them merged. It ended up as the following three PRs, making it a fairly large feature addition. - feat(cli): add --fail-on to cdk diff - feat(cli): add destructive to cdk diff --fail-on - feat(cli): add destructive to cdk deploy --require-approval Shipped First in cdkd This feature was in fact shipped first in an OSS CLI tool called cdkd that I develop on my own, and was added to the CDK CLI afterwards. (Only a few days apart, though.) cdkd is a from-scratch reimplementation of the CDK CLI. It lets you deploy CDK up to 15 times faster without changing a single line of your CDK code. If you are interested, I would be happy if you took a look. GitHub: go-to-k/cdkd P.S. A Follow-up PR (Added on 2026/10/21) The destructive check described above flags a deletion or replacement of any resource. However, some services replace resources on every code change or deployment, such as API Gateway deployments, Lambda aliases (versions), and Lambda Web Functions revisions. In those cases, the check fires every time, which makes this approach hard to adopt. So I later submitted another PR that adds an option to exclude specific resources from the check: feat(cli): add --ignore-destructive to exclude resources from the destructive check Once this is merged, you will be able to apply the approach introduced here even to resource configurations where routine replacements are the normal use case. Final Thoughts As AI becomes widespread, the way we develop with AWS CDK keeps changing. Still, building infrastructure comes with side effects, so fully automating it remains a little unnerving. I think the approach introduced here is a well-balanced hybrid that leaves as much as possible to AI while having humans cover only the genuinely dangerous and important parts.
AWS CDK CLI (aws-cdk) v2.1145.0で、cdk diffとcdk deployで、差分に破壊的変更があるときのみ止められるようになりました！ - cdk diff --fail-on destructive - cdk deploy --require-approval destructive AIに任せるときやCIでは、cdk diffを挟んでおくのがおすすめ！ github.com/aws/aws-cdk-cli/releases/tag/aws-cdk%4…