Hand waving away a more than 10x increase in issues won't make them go away. That's a pretty clear indication things are wrong. CDK/cloudformation is objectivel

Hand waving away a more than 10x increase in issues won't make them go away. That's a pretty clear indication things are wrong. CDK/cloudformation is objectively buggy compared to boto3/the standard API. Terraform is unusable for all but the most basic tasks, with issues like not being able to get private IPs for certain resources, and seemingly no plans to support the many inherently procedural operations that one may need to perform on AWS. > Candidly, to describe CDK/Terraform as "essentially API wrappers" betrays the fact that you didn't really try to use them seriously. Yes, they call AWS APIs under the hood; but if you're only using them as a drop-in replacement for boto3 calls, you are missing out on a lot of the power they provide. Well I actually reviewed the code as part of my evaluation, and even made the initial version with terraform that I contributed a patch for, so it's an accurate description. CDK is a wrapper for cloudformation... > Either way, I feel extremely confident claiming that a bug in CDK code is significantly less likely than making a mistake when attempting to reimplement-in-boto3 all the wiring and dependencies of a complex stack. If you were to actually compare CDK and boto3 examples, you would find they are very close in practice with the major difference being that you _may_ need to diff existing resources before performing updates with boto3. Not hard to do in practice and gives you the opportunity to choose exactly how to handle different scenarios, which I see as a plus. You still need to learn AWS concepts and have a strategy for error handling. I'm glad CDK it works for your use case! I'm provisioning entire build and runtime environments as a service, and chose the API wrapper that is clearly given first priority at AWS.