Pulumi vs. AWS CDK

Choosing the right infrastructure as code tool is important, and we want you to have as much information as possible to make the choice that best suits your needs. We’ve created this document to help you understand how Pulumi compares with AWS Cloud Development Kit.

What is AWS CDK?

AWS Cloud Development Kit (CDK) is an open-source software development framework for defining AWS cloud resources with general-purpose programming languages. CDK is a transpiler that converts program code into AWS CloudFormation JSON/YAML templates and other assets and then submits them to AWS and the CloudFormation deployment service.

Pulumi vs. CDK: Similarities

Both Pulumi and CDK allow you to build and deploy infrastructure on AWS using familiar programming languages and tools, and both use a declarative infrastructure as code model built on the concept of desired state. In both Pulumi and CDK, desired state is expressed by declaring one or more cloud resources in code that’s evaluated by the deployment engine (though with CDK, that code is rendered CloudFormation text), and the deployment engine determines whether to create, update or destroy the resources of an infrastructure stack by comparing its last known state with the new state expressed by the code. Both have similar concepts for modularity and higher-level abstractions that encapsulate multiple resources. These are known as constructs in CDK and as Component Resources in Pulumi.

Pulumi vs. CDK: Key Differences

First, CDK supports only AWS, whereas Pulumi supports over 60 cloud and SaaS providers, with more being added all the time. Second, while both Pulumi and CDK support languages like TypeScript, Python, Go, C#, and Java, the two tools are fundamentally different in how they interpret these languages and deploy resources. Unlike Pulumi, whose open-source engine understands these languages and communicates directly with cloud providers to deploy infrastructure, CDK is a transpiler (i.e., a source-to-source compiler) that produces AWS Cloud Assembly, an intermediate format consisting of CloudFormation templates and other files that it uploads to the CloudFormation service, which acts as the deployment engine for provisioning resources.

Moreover, because CDK depends on CloudFormation as the deployment engine, it shares many of the same benefits and limitations as CloudFormation (see Pulumi vs. CloudFormation).

Finally, while both CDK and Pulumi support automated testing, the scenarios they’re able to support are quite different. For example, both CDK and Pulumi support unit testing, but Pulumi offers significant advantages as a result of the deep integration between language host and runtime. With Pulumi, you can run fast, in-memory (offline) unit tests that mock external calls to cloud providers, whereas with CDK, you’re only able to run assertions against the rendered CloudFormation template synthesized by the CDK app, and there is no equivalent option for offline testing.

The following table summarizes some additional similarities and differences between Pulumi and CDK, and the sections below the table go into more detail.

Feature Comparisons

FeaturePulumiAWS CDK
Language SupportTypeScript, JavaScript, Python, Go, C#, F#, VB.NET, Java, YAMLPython, TypeScript, JavaScript, Go (developer preview), C#, Java
State ManagementManaged by Pulumi Service or with self-managed optionsManaged by the AWS CloudFormation service
Provider SupportSupports all major cloud providers, including 100% same-day coverage of new resources with AWS NativeAWS only
Cloud Native SupportRichly typed support for the full cloud-native ecosystem and KubernetesAWS only
Dynamic Provider SupportYesLimited
OSS LicenseApache License 2.0Apache License 2.0 (only applies to the CDK framework, and not the deployment engine)
Infrastructure Reuse and ModularityFlexible and extensible: functions, classes, modules, Component Resources, multi-language packages, and moreReuse functions, classes, packages, and CDK constructs
Testing and ValidationUnit, property, and integration testing supported with popular test frameworksOnly supports unit testing that asserts against synthesized YAML/JSON
Modes of ExecutionRun CLI commands or initiate commands programmatically with Automation APIRun CLI commands to execute CloudFormation deployments
Embed within Application CodeYes, via Automation APINo
Third-party CI/CD Tools SupportYesAWS CodePipeline
Policy as CodeYesLimited
Secrets ManagementYes. Secrets are encrypted in transit and in the state fileNo built-in support, available through other services
Audit CapabilitiesYesLimited
Adopt Existing ResourcesYes. Generates code as part of the import processNo
Import code from other IaC ToolsYesNo

Getting started with Pulumi is easy if you already have experience with CDK or a general-purpose programming language. Follow our Adopting Pulumi from AWS CloudFormation or try our CloudFormation conversion tool. To deploy a simple program, follow our Get Started guide:

Get Started with Pulumi

Use Pulumi's open-source SDK to create, deploy, and manage infrastructure on any cloud.

AWS
Azure
Google Cloud
Kubernetes

Language Support

While both Pulumi and CDK support using general-purpose programming languages for infrastructure code, they differ in terms of how your code is used at runtime.

With CDK, the code you write is converted into AWS Cloud Assembly — structured configuration consisting of CloudFormation template code and other assets (to be uploaded later to the CloudFormation service). With Pulumi, however, your code communicates at runtime with the deployment engine, which has deep support for multiple languages and integration with language runtimes. Overall, Pulumi is therefore able to deliver a far richer experience for developers, as its architecture unlocks many advanced capabilities (such as standard unit testing) that may not be possible with CDK.

To learn more about languages and language runtimes in Pulumi, see How Pulumi Works.

State Management

CDK depends on AWS CloudFormation for this capability. See Pulumi vs. CloudFormation to learn more.

Provider Support

CDK depends on AWS CloudFormation for this capability. See Pulumi vs. CloudFormation to learn more.

Cloud Native Support

CDK depends on AWS CloudFormation for this capability. See Pulumi vs. CloudFormation to learn more.

Dynamic Provider Support

CDK depends on AWS CloudFormation for this capability. See Pulumi vs. CloudFormation to learn more.

OSS License

Both CDK and Pulumi are licensed under Apache License 2.0, however CDK’s deployment engine (AWS CloudFormation) is a proprietary AWS service. The Pulumi CLI (which contains the deployment engine) is also fully open source, and all Pulumi providers are open source as well.

Infrastructure Reuse and Modularity

Both CDK and Pulumi support reusability through the built-in capabilities of the languages they support, such as functions, classes, modules, and packages. Both support the concept of higher-level abstractions as well — CDK through constructs and Pulumi through Component Resources — and both are supported by public registries that index these abstractions.

The main advantage Pulumi has over CDK in this regard is its ability to create multi-language, reusable packages encapsulating higher-level abstractions and architectural patterns. With Pulumi, you can write a package in your language of choice and then generate equivalent packages in any language Pulumi supports. To learn more, see Pulumi Packages.

Testing and Validation

Unit tests in CDK assert on the synthesized CloudFormation template content rather than the CDK code itself, meaning that in order to write a unit test with CDK, you must first understand the translation of CDK to CloudFormation. This makes testing challenging since you face a contextual gap between the intent specified in CDK code and the synthesized CloudFormation template. However, with Pulumi, unit tests can assert using the same object model as the Pulumi program, which gives you direct debugging and faster productivity. You can run fast in-memory tests that mock external calls, and also validate how data flows across resource dependencies in a way that mimics what would happen in production. In contrast, CDK doesn’t allow you to perform the same level of assertion on dependencies since it converts resource references into values that CloudFormation understands via its Ref intrinsic function.

Pulumi also supports property tests (Policy as Code), which run resource-level assertions while infrastructure is being deployed, and integration tests, which deploy ephemeral infrastructure and run external tests against it.

To learn more about how Pulumi enables testing and test-driven development tools and methodologies, see Testing.

Modes of Execution

The CDK CLI synthesizes CDK apps into CloudFormation templates and initiates deployments through the AWS CloudFormation service. You can also deploy CDK apps through a CI/CD service like AWS CodePipeline.

Pulumi’s approach is fundamentally different in that deployments are performed within the CLI itself by the Pulumi engine. This results in a much tighter development loop, easier debugging, and simpler integration into CI/CD workflows because of the CLI’s ability to block until deployment is complete and return with a standard exit code indicating whether the deployment was successful. Moreover, with Automation API, Pulumi can be embedded into application code and driven programmatically, enabling higher-order orchestration workflows and dynamically managed infrastructure.

To learn more about how Pulumi deploys infrastructure, see How Pulumi Works. To learn more about how to run Pulumi within the context of another program, see Automation API.

Embed within Application Code

With Automation API, you can import Pulumi into another application and drive stack operations programmatically. Automation API gives you a strongly typed and safe way to use Pulumi in many different kinds of embedded contexts — e.g., command-line tools, web applications, self-service portals, or desktop applications — without having to shell out to a CLI, enabling creation of custom experiences tailored to your use-case, team, or domain. CDK does not have this capability. To learn more about using Pulumi programmatically, see Automation API.

Third-Party CI/CD Support

CDK depends on AWS CloudFormation for this capability. See Pulumi vs. CloudFormation to learn more.

Policy as Code

CDK depends on AWS CloudFormation for this capability. See Pulumi vs. CloudFormation to learn more.

Secrets Management

CDK depends on AWS CloudFormation for this capability. See Pulumi vs. CloudFormation to learn more.

Audit Capabilities

CDK depends on AWS CloudFormation for this capability. See Pulumi vs. CloudFormation to learn more.

Adopt Existing Resources

CDK does not support this capability officially. It’s possible to import existing resources from an AWS CloudFormation template, but doing so requires adding a CDK API wrapper around the CloudFormation resources and referencing it within your CDK code.

Importing is simpler and more streamlined in Pulumi, and can be done in one of two ways: either with the Pulumi CLI, using pulumi import, which adds the resource to your stack state and generates the code to manage resource going forward; or in code, in a resource declaration using the import resource option.

To learn more about importing and managing imported cloud resources with Pulumi, see Importing Infrastructure in our Adopting Pulumi user guide.

Convert Code from Other IaC Tools

Pulumi offers a number of useful tools to help you convert code written for other infrastructure-as-code tools (including CloudFormation) into deployable Pulumi programs written in your language of choice. The conversion process automatically generates a new, fully-functional Pulumi program that matches the source IaC program or template. CloudFormation has no comparable support for this feature.

To learn more, see Conversion in our Adopting Pulumi user guide.