AWS CloudFormation Alternatives in 2026

AWS CloudFormation deploys AWS resources from JSON or YAML templates as stacks, with change sets to preview updates, automatic rollback on failure and drift detection. It needs no state file, because AWS keeps the state. The friction shows up as templates grow: thousands of lines of YAML with intrinsic functions, a 500 resource limit per stack that forces nested stacks, slow rollbacks that can leave a stack in UPDATE_ROLLBACK_FAILED, and nothing outside AWS.

This guide compares the alternatives on what changes in daily work: the language you write, where state lives, which providers are covered, and how much infrastructure code remains.

CloudFormation alternatives at a glance

1. Encore

Encore combines an open source infrastructure SDK with a platform that provisions and deploys into your own AWS or GCP account. It takes the infrastructure from code approach: instead of describing resources in a template, the application declares the databases, buckets, queues and cron jobs it uses, and the Encore platform provisions them on deploy.

A CloudFormation template for one queue with a dead-letter queue, subscribed to a topic, looks like this before any permissions or compute:

Resources:
  EmailsTopic:
    Type: AWS::SNS::Topic
  SendEmailDLQ:
    Type: AWS::SQS::Queue
  SendEmailQueue:
    Type: AWS::SQS::Queue
    Properties:
      RedrivePolicy:
        deadLetterTargetArn: !GetAtt SendEmailDLQ.Arn
        maxReceiveCount: 5
  SendEmailSubscription:
    Type: AWS::SNS::Subscription
    Properties:
      TopicArn: !Ref EmailsTopic
      Protocol: sqs
      Endpoint: !GetAtt SendEmailQueue.Arn
      RawMessageDelivery: true
  # plus an AWS::SQS::QueuePolicy, IAM policies for publisher and consumer,
  # and the ECS service that polls the queue

In Encore the same queue, a database, a bucket and a schedule are declarations in the TypeScript service that uses them:

import { CronJob } from "encore.dev/cron";
import { api } from "encore.dev/api";
import { Subscription, Topic } from "encore.dev/pubsub";
import { SQLDatabase } from "encore.dev/storage/sqldb";
import { Bucket } from "encore.dev/storage/objects";

export const db = new SQLDatabase("app", { migrations: "./migrations" });
export const uploads = new Bucket("uploads", { versioned: false });

interface EmailJob {
  userId: string;
  template: string;
}
export const emails = new Topic<EmailJob>("emails", { deliveryGuarantee: "at-least-once" });

const _ = new Subscription(emails, "send-email", {
  handler: async (job) => {
    // send the email
  },
  retryPolicy: { maxRetries: 5 },
});

export const cleanup = api({}, async (): Promise<void> => {
  await db.exec`DELETE FROM sessions WHERE expires_at < now()`;
});

const nightly = new CronJob("cleanup", { title: "Delete expired sessions", schedule: "0 3 * * *", endpoint: cleanup });

On AWS, Encore provisions RDS for PostgreSQL, the S3 bucket, an SNS topic and SQS queue with a dead-letter queue for the subscription, Fargate or EKS for compute, and the VPC and load balancer around them, as listed in the AWS infrastructure docs. It provisions an IAM role for the service. Cron jobs are run by the Encore platform and need no extra AWS resources. encore run starts the same database, queue and bucket locally, which a template never gives you. The infrastructure overview lists the GCP equivalents.

Encore provisions what the application declares, not arbitrary AWS resources, so a team still managing an organization-wide VPC, IAM Identity Center or a data warehouse keeps a separate IaC tool for those. Existing resources such as an RDS instance can be imported instead of recreated.

Best fit: product teams whose CloudFormation is mostly the application's own database, queues, buckets and services, and who want that infrastructure to follow the code. See infrastructure from code for the approach in more depth.

2. Terraform

Terraform

Terraform describes resources in HCL and keeps a state file, usually in S3 with locking. Its provider ecosystem covers AWS, every other major cloud and hundreds of SaaS APIs, and terraform plan shows a diff before apply, which is easier to read than a change set. The costs are the state file, which has to be stored, locked and occasionally repaired, and HCL, which has loops and modules but is not a general-purpose language. HashiCorp moved Terraform to the Business Source License in 2023, which matters to some vendors and platform builders.

Best fit: teams that manage AWS alongside other providers and want one declarative workflow with a large module ecosystem.

3. OpenTofu

OpenTofu

OpenTofu is the open source fork of Terraform created after the license change and maintained under the Linux Foundation. It reads the same HCL and works with the same providers, so moving between the two is usually a binary swap. It has added features of its own, such as client-side state encryption. The workflow, and the state file management, are the same as Terraform's.

Best fit: teams that want the Terraform workflow under an open source license.

4. AWS CDK

AWS CDK

The AWS Cloud Development Kit lets you define stacks in TypeScript, Python, Java, C# or Go, with higher-level constructs that set sensible defaults, such as a Fargate service with a load balancer in a few lines. cdk synth turns the code into a CloudFormation template and cdk deploy hands it to CloudFormation. That makes CDK the smallest move away from writing templates, and also means stack limits, rollback behavior and AWS-only coverage stay as they are.

Best fit: AWS-only teams that want to stop writing YAML and keep CloudFormation's managed state and rollback.

5. Pulumi

Pulumi

Pulumi uses general-purpose languages like CDK does, but talks to cloud APIs directly instead of generating CloudFormation, and covers AWS, GCP, Azure, Kubernetes and many SaaS providers. State lives in Pulumi Cloud or a self-managed backend such as S3. Code in a real language allows loops, functions and unit tests, and it also means infrastructure code can grow the abstractions and indirection of application code.

Best fit: teams that want TypeScript, Python or Go for infrastructure across several clouds.

How to choose

The right choice depends on what the templates contain: if most of the CloudFormation describes the application's own database, queues, buckets and compute, Encore removes that code by provisioning it from the application. If the templates describe shared platform resources across AWS and other providers, pick Terraform, or OpenTofu for the open source license. If you want to stay on CloudFormation and write TypeScript or Python instead of YAML, pick CDK, and pick Pulumi for general-purpose languages across clouds. Many setups combine two: a Terraform or CDK codebase for the shared platform, and Encore for the application infrastructure.

Related guides

• What is AWS CloudFormation?
• Terraform vs CloudFormation
• AWS CDK vs CloudFormation
• AWS CDK vs Terraform
• AWS SAM alternatives