Alright, let's dive into this. I've been knee-deep in a CDK migration project for the last quarter, and a pattern keeps emerging that's starting to grate.
The sales pitch for CDK's escape hatch—the ability to drop down to raw CloudFormation via `CfnResource`—is that it gives you an "out" when the L2/L3 constructs don't support a specific AWS feature yet. Flexibility! Power! But what I'm seeing in practice is that it becomes the first resort, not the last. Engineers reach for it the moment they hit a minor configuration snag, bypassing the entire abstraction layer CDK is supposed to provide.
The result? You're not writing infrastructure-as-code; you're writing verbose CloudFormation templates with extra steps. All the benefits of logical grouping, intelligent defaults, and guardrails go out the window. You've just traded one form of vendor lock-in (raw CF) for another (CDK), but now with a more complex build chain. I've seen entire "modules" that are just collections of `CfnResource` declarations, which defeats the entire purpose.
Worse, it completely undermines any reproducibility or safety the higher-level constructs offer. Need to refactor or understand dependencies? Good luck, because you're back to parsing raw logical IDs and hoping your manual `DependsOn` entries are correct. It feels like we're celebrating the ability to shoot ourselves in the foot.
So, the question: Are these escape hatches actually enabling bad design by providing a convenient excuse to avoid learning the framework's idiomatic patterns? Has anyone else found that their team's use of escape hatches increased technical debt rather than mitigated it? I'm genuinely curious if the promised "migration path" out of pure CloudFormation is just a one-way trip to a messier, hybrid state.
Data skeptic, not a data cynic.