Skip to main content
  1. Docs
  2. Infrastructure as Code
  3. Comparisons
  4. AWS CDK

Pulumi vs. AWS CDK

    Pulumi and AWS Cloud Development Kit (CDK) are both infrastructure as code tools that let you author cloud resources in general-purpose programming languages. They differ in how programs are turned into provisioned infrastructure: Pulumi runs programs directly through its own deployment engine and supports any cloud or SaaS platform through the Pulumi Registry, while AWS CDK transpiles programs into AWS CloudFormation templates that the AWS CloudFormation service deploys, and supports AWS only.

    This page covers what each tool is, a feature-by-feature comparison, the most important differences in detail, and the available paths for adopting Pulumi alongside or instead of AWS CDK.

    What is Pulumi?

    Pulumi is an infrastructure as code platform for provisioning and managing resources across any cloud or SaaS platform. Pulumi programs are written in general-purpose programming languages — Python, TypeScript, JavaScript, Go, .NET, and Java — as well as YAML. The Pulumi Registry covers all major clouds, including first-party native providers that are generated from upstream API schemas for same-day coverage of new platform features. The Pulumi CLI and SDKs are open source under the Apache 2.0 license. Pulumi Cloud is the commercial product that adds managed state, secrets, RBAC, audit logs, policy management, and other features for running Pulumi at organizational scale.

    For users coming from AWS CDK, the most relevant Pulumi providers are the AWS Classic provider (built on the AWS Terraform provider) and the AWS Cloud Control provider, which is generated from the AWS Cloud Control API — the same API CloudFormation uses — and offers same-day coverage of new AWS resources.

    What is AWS CDK?

    AWS Cloud Development Kit (CDK) is an AWS-maintained framework, released in 2018, for defining AWS infrastructure in TypeScript, Python, Go, C#, and Java. CDK is a transpiler (a.k.a. source-to-source compiler): running cdk synth produces an AWS Cloud Assembly — CloudFormation JSON or YAML templates plus other deployment assets — which is uploaded to Amazon S3/ECR and deployed by the AWS CloudFormation service. CDK is AWS-only. The CDK framework is open source under the Apache 2.0 license; the CloudFormation deployment engine it depends on is a closed-source AWS service.

    Detailed comparison

    FeaturePulumiAWS CDK
    Language supportPython, TypeScript, JavaScript, Go, C#, Java, and YAML — general-purpose languages with familiar syntax for loops, conditionals, and abstractionsTypeScript, JavaScript, Python, Go, C#, and Java
    Cloud and service supportPulumi Registry of packages, including bridged, native, parameterized, and dynamic providers; first-party native providers for Kubernetes and Azure Native generated from upstream API schemas; any Terraform provider can be adapted into a Pulumi providerAWS only; third-party resources are supported through CloudFormation Registry extensions and custom resources backed by AWS Lambda
    Transpiled to another format?No — programs run directly in their host languageYes — programs are synthesized into CloudFormation templates and an AWS Cloud Assembly
    State managementManaged by Pulumi Cloud by default; self-managed backends include Amazon S3, Azure Blob Storage, Google Cloud Storage, local files, and othersManaged by the CloudFormation service inside the AWS account; no user-accessible state file
    Secrets managementEncrypted in transit and at rest in the state file by default, with per-stack encryption keys; pluggable KMS providers (AWS KMS, Azure Key Vault, Google Cloud KMS, HashiCorp Vault)No built-in secrets primitive; sensitive values are typically passed via NoEcho parameters or dynamic references to AWS Secrets Manager or SSM Parameter Store
    Execution modelLocal CLI, programmatic via Automation API, or remote runs in Pulumi Deploymentscdk deploy invokes the AWS CloudFormation service; can also run through AWS CodePipeline or any CI/CD tool that wraps the CDK CLI
    Rollback on failed operationFailed updates leave the stack in a partially-updated state; subsequent pulumi up runs reconcile toward the desired state, and you can roll forward by reverting program codeAutomatic stack rollback on failed create or update; configurable rollback triggers and DisableRollback for debugging
    Programmatic API for tools and platformsAutomation API — a programmatic SDK for building custom CLIs, internal developer platforms, and services that drive up, preview, and destroy without shelling out to the Pulumi CLINo embeddable SDK; orchestration goes through the CDK CLI, the AWS CLI, AWS SDKs, or the CloudFormation API
    Modularity and reuseComponent Resources authored in any supported language; Pulumi Packages let a component written in one language be consumed from any Pulumi language; language-native package managers (npm, PyPI, NuGet, Maven, Go modules); and the Pulumi Registry for publicly available packagesConstructs — reusable abstractions built on the constructs library and published to language-specific package managers; the Construct Hub indexes public constructs
    Import existing resourcespulumi import and the import resource option, both of which generate code in your languageResource import through a CloudFormation change set, with a hand-authored CDK wrapper around the imported resources
    Policy as codePulumi Policies — open source, with rules written in Python, TypeScript, or Open Policy Agent Rego; Pulumi Cloud commercial plans add centralized policy management plus Pulumi-maintained policy packs for compliance frameworks like CIS, PCI DSS, and NISTCloudFormation Hooks (authored in Java, Python, or TypeScript and registered with the CloudFormation Registry) and CloudFormation Guard for policy-as-code rules
    Open sourceYes — Apache License 2.0The CDK framework is Apache License 2.0; the CloudFormation deployment engine it depends on is a closed-source AWS service
    Commercial optionPulumi CloudNone — CDK is part of AWS and has no separate commercial tier

    Key differences

    Language support and the authoring experience

    Pulumi programs are written in general-purpose languages and run directly through Pulumi’s deployment engine. Authors get loops, conditionals, classes, package management, IDE features (autocomplete, type checking, refactoring, go-to-definition), and the testing frameworks that already exist in those ecosystems. AWS CDK programs are also written in general-purpose languages, but every program is synthesized into CloudFormation templates before deployment, so CDK testing centers on assertions against the synthesized template rather than the program’s own object graph. Pulumi additionally supports YAML for users who prefer a markup format.

    Cloud and service coverage

    AWS CDK manages AWS resources only. Third-party support is added through CloudFormation Registry extensions and custom resources backed by AWS Lambda. CDK organizes its abstractions into three levels — L1 (auto-generated CloudFormation bindings), L2 (curated higher-level constructs), and L3 (multi-resource patterns) — but all three levels target AWS.

    Pulumi targets any cloud or SaaS platform through the Pulumi Registry, which includes bridged, native, parameterized, and dynamic providers. For AWS specifically, Pulumi offers the AWS Classic provider (built on the AWS Terraform provider) and the AWS Cloud Control provider, generated from the AWS Cloud Control API for same-day coverage of new AWS resources. Pulumi also maintains native providers for Kubernetes and Azure Native generated directly from each platform’s API schema. When a resource is not available in a Pulumi provider, Pulumi can adapt any Terraform provider for use from a Pulumi program.

    Execution and rollbacks

    AWS CDK runs deployments through the AWS CloudFormation service. CDK inherits CloudFormation’s properties, including its 500-resource-per-template limit, automatic stack rollback on failed create or update operations, and the minutes-scale feedback loop of CloudFormation change sets. The synthesis step adds an additional template-generation phase between code and deployment.

    Pulumi runs deployments through the local CLI, programmatically through the Automation API, or remotely through Pulumi Deployments. Failed Pulumi updates leave the stack in a partially-updated state; subsequent pulumi up runs reconcile toward the desired state, and you can roll forward by reverting program code. The two models trade off differently between automated cleanup on failure (CloudFormation/CDK) and direct, scriptable control over the deployment loop (Pulumi).

    Secrets handling

    Pulumi treats secrets as a first-class primitive. Values marked as secrets are encrypted in transit and at rest in the state file, anything derived from a secret is also encrypted, and each stack has its own encryption key. The default encryption provider can be replaced with AWS KMS, Azure Key Vault, Google Cloud KMS, or HashiCorp Vault. AWS CDK has no built-in secrets primitive; sensitive values are typically passed in through NoEcho parameters or through dynamic references that resolve to values in AWS Secrets Manager or SSM Parameter Store at deploy time.

    Policy as code

    Pulumi Policies is open source and free. Policies can be written in Python, TypeScript, or Open Policy Agent Rego, and Pulumi Cloud adds centralized management, policy groups, and enforcement across stacks. Pulumi Cloud commercial plans also include Pulumi-maintained policy packs for common compliance frameworks (CIS, PCI DSS, HITRUST, NIST), so teams don’t have to author and maintain those rules themselves. CDK inherits CloudFormation’s policy options: CloudFormation Hooks, which run pre-provisioning checks authored in Java, Python, or TypeScript and registered with the CloudFormation Registry, and CloudFormation Guard, an open-source CLI for evaluating templates against rules.

    Modularity and reuse

    Pulumi’s Component Resources are runtime objects with explicit parent/child relationships, so a component and the resources inside it form a coherent unit in plan output, deletion, and state. Components can be authored in one language and consumed from any other supported language by publishing them as a Pulumi Package. AWS CDK offers Constructs built on the constructs library and published as language-specific packages; public constructs are indexed by the Construct Hub. Cross-language consumption of a single construct requires that the construct be authored with jsii and published to multiple package managers.

    Automation API

    The Automation API lets a host application drive Pulumi without shelling out to the CLI. Practical uses include embedding stack creation in a SaaS product, building an internal developer platform that provisions environments per team or per branch, generating ephemeral preview environments from CI, and orchestrating cross-cloud deployments where each step runs as part of a larger workflow. AWS CDK is invoked through the cdk CLI and does not provide an equivalent embeddable SDK.

    When to choose Pulumi vs. AWS CDK

    Choose Pulumi when you:

    1. Manage infrastructure across multiple clouds or SaaS providers (Azure, Google Cloud, Kubernetes, Datadog, Cloudflare, etc.) and want one tool for all of it.
    2. Want to run programs directly without a CloudFormation synthesis step, including the ability to test the program’s own object graph rather than the synthesized template.
    3. Need an embeddable SDK (Automation API) to drive deployments from a host application — internal developer platforms, SaaS products, or ephemeral preview environments per pull request.
    4. Want built-in secrets encryption, pluggable KMS providers, and per-stack encryption keys without bolting on a separate service.
    5. Want a free, open-source policy-as-code engine with rules in Python, TypeScript, or Rego.

    Choose AWS CDK when you:

    1. Provision only AWS resources and want to stay within AWS-managed tooling (CloudFormation, AWS CLI, AWS SDKs, AWS CodePipeline) end to end.
    2. Depend on CloudFormation-specific features such as automatic stack rollback on failure, Service Catalog integration, or StackSets for multi-account deployments.
    3. Have an existing investment in CDK constructs, custom resources, and team expertise that you don’t want to migrate.

    The two can also coexist — see Adoption below.

    Adoption: coexistence, conversion, and import

    There are several common paths for adopting Pulumi alongside or in place of AWS CDK, and they can be combined:

    1. Use AWS CDK alongside Pulumi. The Pulumi CDK Adapter embeds CDK constructs directly inside Pulumi programs, so existing CDK constructs continue to work while the surrounding program is managed by Pulumi. Outputs flow in both directions between CDK constructs and other Pulumi resources. See Using Pulumi with AWS CDK and the Pulumi CDK guide.
    2. Import existing resources. pulumi import and the import resource option bring already-provisioned AWS resources under Pulumi management and generate the corresponding code in your chosen language.
    3. Automated migration with Pulumi Neo (recommended). Pulumi Neo automates the conversion of an existing CDK application — converting code, importing existing CloudFormation resources, and running pulumi preview to verify zero changes — without downtime. See Migrating existing AWS CDK applications to Pulumi.

    For a complete walkthrough, see Migrating from AWS CDK to Pulumi.

    Frequently asked questions

    Can Pulumi run AWS CDK constructs?

    Yes. The Pulumi CDK Adapter embeds CDK constructs directly inside Pulumi programs, so existing CDK constructs and stacks can be referenced from a Pulumi program. Outputs from CDK constructs can feed other Pulumi resources, and outputs from Pulumi resources can feed CDK constructs. See the Pulumi CDK guide for details.

    How do I migrate from AWS CDK to Pulumi?

    You have three options that can be combined: use Pulumi Neo for automated conversion and import; bring existing resources under Pulumi management with pulumi import; or run both tools side by side using the Pulumi CDK Adapter until you’re ready to cut over. The migration guide has the full walkthrough.

    Does Pulumi cover the same AWS resources as AWS CDK?

    Yes. The AWS Cloud Control provider is generated from the AWS Cloud Control API — the same API CloudFormation uses — so it offers same-day coverage of new AWS resources. The AWS Classic provider, built on the AWS Terraform provider, offers long-standing, comprehensive coverage and is appropriate for the majority of production use cases.

    Is Pulumi free like AWS CDK?

    The Pulumi CLI and SDKs are open source under Apache 2.0 and free to use. Pulumi Cloud has a free Individual tier and paid plans that add managed state, RBAC, audit logs, policy management, and other features for running Pulumi at organizational scale. AWS CDK is open source; the AWS CloudFormation deployment engine it depends on has no usage cost beyond the resources it manages, but is itself a closed-source AWS service.

    Does Pulumi have automatic rollback like CloudFormation/CDK?

    No. On a failed update, Pulumi leaves the stack in a partially-updated state and reports exactly which resources changed. You roll forward by fixing the program and running pulumi up again, or revert the program to a previous commit and re-deploy. This gives direct, scriptable control over the deployment loop at the cost of CloudFormation’s automated cleanup behavior.

    Can I use Pulumi for non-AWS resources alongside AWS CDK for AWS?

    Yes — and this is one of the more common adoption patterns. Teams keep AWS infrastructure in CDK while using Pulumi for Kubernetes, Azure, Google Cloud, Datadog, Cloudflare, or other SaaS platforms, then optionally migrate AWS later. The Pulumi CDK Adapter also supports the reverse pattern, where a Pulumi program embeds existing CDK constructs.

    How does the CloudFormation 500-resource-per-stack limit compare to Pulumi?

    AWS CDK inherits CloudFormation’s 500-resource-per-template limit; teams working around it typically split deployments across nested stacks or multiple top-level stacks. Pulumi imposes no equivalent hard limit on resources per stack, so very large deployments do not require artificial decomposition.

    Can Pulumi detect drift like CloudFormation?

    Yes. pulumi refresh compares the state file to the actual state in the cloud and reports differences, and pulumi preview --diff shows what would change on the next update. Pulumi Cloud commercial plans add scheduled drift detection and remediation.

    Next steps