Snowflake IaC without switching to Terraform
Using CDK Terrain with the official Snowflake Terraform provider
Published: Tuesday, Mar 10, 2026 Last modified: Saturday, Apr 25, 2026
Scenario: you already use CDK, your team is happy, and you use CDKTF for non-AWS resources.
Then HashiCorp (now owned by IBM) sunsets CDKTF, and suddenly it feels like you must run both CDK and plain Terraform/HCL in the same pipelines.
Using CDK Terrain, you can consume the official Snowflake Terraform provider and stay in a CDK workflow.
My proof-of-concept repo:
https://github.com/kaihendry/snowflake-cdktn
Hashicorp drops the Cloud Development Kit
HashiCorp deprecated CDKTF and archived the upstream repository on the same day, on December 10, 2025
- https://github.com/hashicorp/terraform-cdk/commit/a0c56138e2b4c7b6c128bd7ba08a8e317df852af
- https://github.com/hashicorp/terraform-cdk
CDK Terrain is the community continuation. In practice, it preserves the CDKTF workflow and gives a more CDK-consistent way to keep using the Terraform provider ecosystem.
Why I still want CDK over plain Terraform
- Type checking and IDE support: autocomplete, compile-time checks, and first-class language tooling.
- Real refactoring: rename symbols, extract abstractions, and reorganize IaC like normal software.
- Testability: infrastructure can be unit-tested with standard test frameworks.
- Better abstraction for complex systems: CDK constructs are reusable, composable modules instead of repeating verbose config.
- Level 2 constructs: CDK is much more flexible to express Organisational patterns and guard rails that would be very difficult to do with Terraform modules.
For complex infrastructure, CDK gives me the software engineering ergonomics you want, while Terraform providers still do the provisioning.
Thanks to community efforts with CDK Terrain, CDK is still a viable option to deploy non-AWS resources.