Pulumi vs. AWS CloudFormation
Pulumi and AWS CloudFormation are both declarative infrastructure as code tools for AWS. Pulumi lets you define infrastructure in general-purpose languages (Python, TypeScript, JavaScript, Go, C#, Java, or YAML) and supports any cloud or SaaS provider through the Pulumi Registry; AWS CloudFormation uses JSON or YAML templates and provisions only AWS resources.
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 CloudFormation.
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, C#, and Java — as well as YAML. The Pulumi Registry covers all major clouds, including first-party native providers for Kubernetes and Azure Native 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 CloudFormation, 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 and offers same-day coverage of new AWS resources. The Pulumi Registry also covers Azure, Google Cloud, Kubernetes, and SaaS platforms like Datadog, Auth0, GitHub, and Cloudflare.
What is AWS CloudFormation?
AWS CloudFormation is an AWS-managed service for provisioning AWS resources from templates written in JSON or YAML. Templates are uploaded to the CloudFormation service, which evaluates them and creates, updates, or deletes the corresponding AWS resources. CloudFormation is AWS-only; third-party resources are supported through CloudFormation Registry extensions published by AWS partners and the community. CloudFormation is a closed-source AWS service with no usage cost beyond the cost of the resources it manages, and no separately licensed commercial tier.
Detailed comparison
| Feature | Pulumi | AWS CloudFormation |
|---|---|---|
| Language support | Python, TypeScript, JavaScript, Go, C#, Java, and YAML — general-purpose languages with familiar syntax for loops, conditionals, and abstractions | JSON or YAML templates, with intrinsic functions (Fn::Join, Fn::If, Fn::ForEach, etc.) for limited dynamic logic |
| Cloud and service support | Pulumi 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 provider | AWS services 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 language | No — templates are interpreted by the CloudFormation service |
| State management | Managed by Pulumi Cloud by default; self-managed backends include Amazon S3, Azure Blob Storage, Google Cloud Storage, local files, and others | Managed by the CloudFormation service inside the AWS account; no user-accessible state file |
| Secrets management | Encrypted 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 model | Local CLI, programmatic via Automation API, or remote runs in Pulumi Deployments | Centralized AWS-managed service driven through the AWS Console, AWS CLI, AWS SDKs, or change sets |
| Rollback on failed operation | Failed 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 | Automatic stack rollback on failed create or update; configurable rollback triggers and DisableRollback for debugging |
| Programmatic API for tools and platforms | Automation 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 CLI | No embeddable SDK; orchestration goes through the AWS CLI, AWS SDKs, or the CloudFormation API |
| Modularity and reuse | Component 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 packages | Nested stacks, CloudFormation modules registered through the CloudFormation Registry, and Cross-stack references via exported outputs |
| Import existing resources | pulumi import and the import resource option, both of which generate code in your language | Import existing resources through a change set, with a hand-authored template fragment describing the resources to adopt |
| Policy as code | Pulumi 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 SOC 2 | CloudFormation Hooks (authored in Java, Python, or TypeScript and registered with the CloudFormation Registry) and CloudFormation Guard for policy-as-code rules |
| Open source | Yes — Apache License 2.0 | No — CloudFormation is a closed-source AWS service |
| Commercial option | Pulumi Cloud | None — CloudFormation is part of AWS and has no separate commercial tier |
Key differences
Language support and the authoring experience
CloudFormation templates are written in JSON or YAML. Dynamic behavior comes from a fixed set of intrinsic functions such as Fn::If, Fn::Join, and Fn::ForEach, which keep templates declarative but become harder to read as logic grows. Pulumi programs are written in general-purpose languages, so 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. Pulumi also supports YAML for users who prefer a markup format closer to CloudFormation.
Cloud and service coverage
CloudFormation manages AWS resources, with third-party support added through CloudFormation Registry extensions and custom resources backed by AWS Lambda. 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, which is generated from the AWS Cloud Control API and offers 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
CloudFormation runs deployments inside an AWS-managed service. The CloudFormation service evaluates a template, executes changes, and on failure rolls the stack back to its last stable state by default; rollback behavior is configurable through rollback triggers and DisableRollback. 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) 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. CloudFormation has no built-in secrets primitive; sensitive values are typically passed in through NoEcho parameters (which masks values in the AWS Console but stores them in the template processing path) 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, SOC 2, HITRUST, NIST), so teams don’t have to author and maintain those rules themselves. CloudFormation’s first-party options are 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. CloudFormation offers nested stacks, CloudFormation modules registered through the CloudFormation Registry, and cross-stack references via exported outputs.
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. CloudFormation is invoked through the AWS Console, AWS CLI, AWS SDKs, or the CloudFormation API directly, and does not provide an equivalent embeddable SDK.
When to choose Pulumi vs. AWS CloudFormation
Choose Pulumi when you:
- Manage infrastructure across multiple clouds or SaaS providers (Azure, Google Cloud, Kubernetes, Datadog, Cloudflare, etc.) and want one tool for all of it.
- Want to write infrastructure in a general-purpose language with the testing frameworks, package managers, and IDE tooling that already exist in that ecosystem.
- 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.
- Want built-in secrets encryption, pluggable KMS providers, and per-stack encryption keys without bolting on a separate service.
Choose AWS CloudFormation when you:
- Provision only AWS resources and want a service fully managed inside your AWS account with no external dependencies.
- Depend on CloudFormation-specific features such as automatic stack rollback on failure, Service Catalog, or StackSets for multi-account deployments.
- Have an existing investment in CloudFormation templates, 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 CloudFormation, and they can be combined:
- Use CloudFormation alongside Pulumi. A Pulumi program can reference an existing CloudFormation stack and read its outputs through
aws.cloudformation.getStack, which lets you keep some infrastructure in CloudFormation while incrementally adopting Pulumi for new work. Pulumi can also manage CloudFormation stacks themselves throughaws.cloudformation.Stackwhen you need a CloudFormation-specific feature. - Convert templates with
pulumi convert.pulumi convert --from cloudformationtranslates a CloudFormation JSON or YAML template into a Pulumi program in the language of your choice, preserving names and structure where possible. - Import existing resources.
pulumi importand theimportresource option bring already-provisioned AWS resources under Pulumi management and generate the corresponding code in your chosen language.
For a complete walkthrough including coexistence patterns and conversion, see Migrating from AWS CloudFormation to Pulumi.
Frequently asked questions
Can Pulumi manage existing AWS CloudFormation stacks?
Yes. A Pulumi program can read outputs from an existing CloudFormation stack via aws.cloudformation.getStack, and can create and manage CloudFormation stacks themselves with aws.cloudformation.Stack. This lets you keep some infrastructure in CloudFormation while incrementally adopting Pulumi.
How do I migrate from CloudFormation to Pulumi?
You have three options that can be combined: convert templates with pulumi convert --from cloudformation, bring already-provisioned resources under Pulumi management with pulumi import, or run both tools side by side until you’re ready to cut over. See the migration guide for a full walkthrough.
Does Pulumi cover the same AWS resources as CloudFormation?
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 CloudFormation?
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. CloudFormation itself has no usage cost beyond the resources it manages.
How does Pulumi handle rollback if there is no automatic stack rollback?
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 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.
Can I use Pulumi for non-AWS resources alongside CloudFormation for AWS?
Yes — and this is one of the more common adoption patterns. Teams keep AWS infrastructure in CloudFormation while using Pulumi for Kubernetes, Azure, Google Cloud, Datadog, Cloudflare, or other SaaS platforms, then optionally migrate AWS later.
Next steps
Thank you for your feedback!
If you have a question about how to use Pulumi, reach out in Community Slack.
Open an issue on GitHub to report a problem or suggest an improvement.