This was my first thought too. We already have terraform for repeatable, source controlled service provisioning and we have the relatively straightforward aws cli for ad hoc management. I don’t know that I really need another layer, and it feels quite risky.

Terraform CDK is just a layer on top of terraform to avoid writing HCL/JSON.

It's also deprecated by Hashicorp now.

CDK on AWS itself uses CFN, which is a dog's breakfast and has no visibility on what's happening under the covers.

Just write HCL (or JSON, JSONNET etc) in the first place.

Not sure what's a dog breakfast, but why care about what's happening under the cover? You can't know what's happening anyway in AWS.

I thought that was deprecated?

cdktf is, not AWS CDK. The former allows you to use Terraform without HCL, the latter is a generator for CloudFormation.

Am I the only person that despises CDK? Why would I use a cloud specific language instead of something like opentofu?

CDK's twin problems are that it compiles down to CloudFormation and that AWS did a terrible job at supporting languages other than TypeScript. The latter is theoretically fixable with a native FFI library that is called from each language, but the former is too leaky of an abstraction.

I've only ever used it with ts and thought the experience was pretty good (especially compared to terraform)

Considering all the downvotes I got I guess you're not the only one. I'm surprised because I really like cdk. It makes creating an AWS stack really easy, and for having dealt with terraform configurations that were trying to deal with multiple cloud platforms I'd rather have a per-platform eDSL

The read-only hesitation seems overcautious. If you’re genuinely using it read-only, what’s the failure mode? The tool crashes or returns bad data - same risks as the AWS CLI or console.

The “middleware layer” concern doesn’t hold up. This is just a better interface for exploring AWS resources, same as k9s is for Kubernetes. If you trust k9s (which clearly works, given how widely it’s used), the same logic applies here.

If you’re enforcing infrastructure changes through IaC, having a visual way to explore your AWS resources makes sense. The AWS console is clunky for this.

> what’s the failure mode?

The tool misrepresents what is in AWS, and you make a decision based on the bad info.

FWIW I agree with you it doesn’t seem that bad, but this is what came to mind when I read GPs comment

Fair. Best use might be to double check on the proper UI before making any big decisions, and just use it as a general monitor

I mean sure… but to me that is as likely as the official ui misrepresenting the info.

I guess it's the kind of thing where you want an almost Terraform like "plan" that it prints out before it does anything, and then a very literal execution engine that is incapable of doing anything that isn't in the plan.

All the use cases that popped into my head when I saw this were around how nice it would be to be able to quickly see what was really happening without trying to flop between logs and the AWS console. That's really how I use k9s and wouldn't be able to stand k8s without it. I almost never make any changes from inside k9s. But yeah... I could see using this with a role that only has Read permissions on everything.

The AWS APIs are quite stable and usually do exactly one thing. It’s hard to really see much risk. The worst case seems to be that the API returns a new enum value and the code misinterprets it rather than showing an error message.

With properly scoped roles I would not be concerned