If I really need to migrate off of AWS at some point I'll throw an LLM at it.
Besides, actual full-scale Cloud migrations are exceedingly rare.
In my experience claude/codex to wrangle CDK constructs be complicated, it frequently hallucinates constructs that simply do not exist, options that are not supported etc.
While they can generate IaaC component mostly okay and these problems can be managed, Iterations can take a lot of time, each checkpoint, goes the deploy/ rollback cycles in CF. CloudFormation is also not particularly fast, other IaaC frameworks are not that different.
Running an agent to iterate until it gets it right is just more difficult with IaaC refactor projects. Hallucinations, stuck loops and other issues, can quickly run the infra bill up not to mention security.
I am very detailed about all of the security group requirements, tell it that I don’t need Internet access and tell it which VPC endpoints. I don’t do “agentic coding”.
I got a nice and comprehensive infrastructure requirement document out of this.
Now I am using it to create Terraform repo , deploying it via OpenTofu and comparing it to my existing AWS cloud formation . This part is still a WIP .
Not picking on you personally but having had this conversation many times over many years with many clients I find it confounding. Oftentimes TF itself was heavily promoted as a way of "avoiding lock in".
Well guess what? Now you're locked-in to IBM, whose motivations may not be perfectly aligned to you goals of simply and efficiently using your cloud provider of choice to deliver your business outcomes.
What we refer to as lock-in is simply an expression of risk, with one axis being the cost of getting off $solution and the other being the likelihood of needing to do so. Having stepped through this exercise a few times, the cost of rewriting your e.g. AWS API Gateway + Lambda + SQS + RDS + CloudWatch etc architecture invariably vastly dwarfed the cost of changing the IaC language it is expressed in.
Anytime you feel the urge to overbuild on a cloud provider's services, stop, and do a really rigorous cost/benefit analysis. If you truly have unique drivers the data should tell the story.
- More accurate types/type safety than the CDK (for static feedback on required parameters, etc)
- No CLI required - just plain Rust (provider definitions can be published as normal rust packages so you don't have to generate them yourselves, and I've published a bunch of common ones - docker, aws, etc)
- Simpler: Terraform CDK had this crazy flow where it (go code) generated typescript code then used some transpiler to generate target language code. The output wasn't pretty, and there were bugs. Your project directory would get filled with boilerplate generated files.
It generates tf json files and has a fairly safe way for handling variable interpolation and escapes - I haven't hit any weird bugs with it.
It's a bit of an "Caveman solve problem with rock" approach, but for very regular projects it's great. A new cluster is some group vars, larger changes to the structures can be easily reviewed - and if you really really have to, you can also just modify the generated code by hand to fix something your generation code can't deal with right now.
Downsides are doing infrastructure in a programming language was always problematic unless developer was skilled at Ops which most who used TFCDK were not.
The real value of cdktf was more dynamic infrastructure provisioning while still having the plan / apply pattern.
When writing stacks you need normal language features: loops, yes, but also if statements, reuse (functions), being able to do stuff like complex string parsing and re-formatting, etc etc.
HCL supports loops, modules can be kind-of used as functions with lots of footguns, there are awful hacks for some other things, and some stuff just couldn't be done.
Terraform is ugly but it works well enough for me and seems ingrained enough to be durable to this kind of thing (i.e. I bet for sure the community would pick it up (I wish I could say that I'm part of that community but I can't say I use it quite that often))
This is clearly a business decision rather than technical.
Pulumi is meant to be semi-automated (in generating the bridges) so perhaps is slightly better off in maintenance.