All of CDK does things in cloudformation, which made the whole thing stillborn as far as I’m concerned.
The CDK team goes to some lengths to make it better, but it’s all lambda based kludges.
This is one hyper annoying area.
It is possible to get around it, but it's ugly, drop to L1 and override logical id:
let vpc = new ec2.Vpc(this, 'vpc', { natGateways: 1 })
let cfnVpc = vpc.node.defaultChild as ec2.CfnVPC
cfnVpc.overrideLogicalId('MainVpc')
For us, we run 2 stacks. One that basically cannot/should-not be deleted/refactored. VPC, RDS, critical S3 buckets - i.e. critical data.
The 2nd stack runs the software and all those resources can be destroyed, moved whatever w/o any data loss.
in my experience you'd need to read the CDK source code to find the offending node and call `overrideLogicalId`
there is a library to do it in nicer way: https://github.com/mbonig/cdk-logical-id-mapper
however it does not work in every case
Why, dear god, you put VPC and RDS in one stack? They are much better off as separate CFN stacks.
But circular dependencies can also lead to issues here where CDK will prevent you from deleting a resource used or referenced by a different stack.
So dumb. Trying to move to SST for only that reason
but if you add cdk to the path, you can still deploy, its just that your cicd and deployment scripts are not all using bun anymore
You have to do a few adjustments which you can see here https://github.com/codetalkio/bun-issue-cdk-repro?tab=readme...
- Change app/cdk.json to use bun instead of ts-node
- Remove package-lock.json + existing node_modules and run bun install
- You can now use bun run cdk as normal
The problem with upserting is that if the resource already exists, its existing attributes and behavior might be incompatible with the state you're declaring. And it's impossible to devise a general solution that safely transitions an arbitrary resource from state A to state A' in a way that is sure to honor your intent.
If you don't mind sharing, suppose (because it's what I was doing) I was trying to create personal dev, staging, and prod environments. I want the usual suspects: templated entries in route53, a load balancer, a database, some Fargate, etc.
What are you meant to do here? Thank you.
Just write CloudFormation directly. Once you get the hang of the declarative style and become aware of the small gotchas, it's pretty comfy.
Exactly this. And don't make huge templates, split stuff logically to several stacks and pass vars via export/importvalue.