The Real Power of Code-Based IaC
The most transformative capability of CDK and Pulumi isn't that you can use Python instead of HCL. It's that you can build reusable abstractions that encode your organization's standards, and distribute them like any other software library.
Consider this scenario: your platform team has defined standards for every microservice deployment — it must have a health check endpoint, structured logging to CloudWatch, an alarm if error rate exceeds 1%, and a specific IAM permission boundary. In HCL, you'd write a Terraform module and hope teams use it correctly. In CDK, you write a class: a StandardFunction construct that wraps a Lambda function, and inside its constructor — not as optional configuration, but as code that always runs — creates the log group with the company's retention policy, enables tracing, and attaches the error-rate alarm. Any team instantiating a StandardFunction gets logging, tracing, and alerting automatically. They can't forget — it's in the constructor, not a checklist.
Publishing and Versioning
This StandardFunction class can be published to your company's internal npm registry (or PyPI for Python CDK), and teams install it like any other versioned dependency. When the platform team updates the standard (say, changing log retention from 90 to 180 days), they publish a new version. Teams opt into the update on their own schedule. This is infrastructure as a versioned API — a fundamentally more mature model than copying and pasting Terraform modules.
Key Point: Custom constructs are the mechanism by which platform teams scale their standards across an organization without becoming a bottleneck. The construct library becomes the "golden path" — the easiest way to do the right thing is to use the standard construct.