Not entirely. The abstractions are different between infrastructure deployment.... versus configuration yml of circleci.
The declaration of deployment state is a very BIG and hard problem that has had millions of collective man hours spent over decades. I urge you not to think of it as a simple configuration.
In fact it is so hard that AWS has to build a new language on top of typescript ..versus cloudformation templates that it already had.
The Terraform provider idea is interesting, I'll think about it more carefully. Almost all of our deployment configuration under the hood is done with Kubernetes (which is focused on the declaration of deployment state). We modeled our configuration after Kubernetes for that reason, and we want to go beyond low-level infrastructure configuration by allowing users to configure prediction tracking, model retraining thresholds, and other more ML specific features using the same declarative paradigm and in the same configuration files.
Well, CDK actually produces CloudFormation templates. Sorry, but I always feel the urge to jump in when people claim Terraform should be used instead of CloudFormation because of personal preferences. If you are AWS native and already using CloudFormation, I see no reason to switch. CloudFormation provides a ton of functionality out of the box and Amazon handles it for you. Rollbacks alone are a huge reason one might want to use it over Terraform.
The declaration of deployment state is a very BIG and hard problem that has had millions of collective man hours spent over decades. I urge you not to think of it as a simple configuration.
In fact it is so hard that AWS has to build a new language on top of typescript ..versus cloudformation templates that it already had.
https://docs.aws.amazon.com/cdk/latest/guide/home.html
What you are building makes sense - I would drop cloudformation and surface Terraform right till the top.
So the way to use your tool is to install and use a new Terraform "provider".