Terraform Alternatives #

Terraform is certainly popular, but it isn’t the only option in the Infrastructure as Code world. Every IaC tool has its own philosophy, strengths, and trade-offs. AWS has CloudFormation, deeply integrated with its ecosystem. Pulumi and CDK let you write infrastructure in general-purpose programming languages. Ansible takes a different approach with agentless automation. Crossplane brings infrastructure into Kubernetes. And OpenTofu emerged as a response to HashiCorp’s license change.

Choosing the right tool isn’t about which is most popular, but which best fits the context of your team, project, and the architecture you’re building. This article covers each alternative in depth — with real code examples, comparison tables, and guidance for making the decision.

AWS CloudFormation #

CloudFormation is AWS’s native IaC service. First released in 2011, CloudFormation supports nearly all AWS services and integrates directly with the AWS API without needing a separate provider.

How CloudFormation Works #

CloudFormation uses templates in JSON or YAML format to define resources. Each template is uploaded to AWS, and CloudFormation is responsible for creating, modifying, and deleting resources according to the definition.

# cloudformation-template.yml
AWSTemplateFormatVersion: '2010-09-09'
Description: Web server infrastructure

Parameters:
  Environment:
    Type: String
    AllowedValues:
      - staging
      - production
    Default: staging

  InstanceType:
    Type: String
    Default: t3.medium

Resources:
  VPC:
    Type: AWS::EC2::VPC
    Properties:
      CidrBlock: 10.0.0.0/16
      EnableDnsHostnames: true
      Tags:
        - Key: Name
          Value: !Sub ${Environment}-vpc

  PublicSubnet:
    Type: AWS::EC2::Subnet
    Properties:
      VpcId: !Ref VPC
      CidrBlock: 10.0.1.0/24
      AvailabilityZone: ap-southeast-1a
      Tags:
        - Key: Name
          Value: !Sub ${Environment}-public-subnet

  WebServerSG:
    Type: AWS::EC2::SecurityGroup
    Properties:
      GroupDescription: Web server security group
      VpcId: !Ref VPC
      SecurityGroupIngress:
        - IpProtocol: tcp
          FromPort: 443
          ToPort: 443
          CidrIp: 0.0.0.0/0

  WebServer:
    Type: AWS::EC2::Instance
    Properties:
      InstanceType: !Ref InstanceType
      ImageId: ami-0abcdef1234567890
      SubnetId: !Ref PublicSubnet
      SecurityGroupIds:
        - !Ref WebServerSG
      Tags:
        - Key: Name
          Value: !Sub ${Environment}-web-server

Outputs:
  ServerPublicIP:
    Description: Public IP of the web server
    Value: !GetAtt WebServer.PublicIp

CloudFormation’s Strengths #

No additional cost. CloudFormation is free — you only pay for the resources it creates, not the tool itself. This differs from Terraform Cloud, which has paid tiers.

Deep AWS integration. When AWS releases a new service, CloudFormation support is usually available from day one. You don’t have to wait for a provider update like you do with Terraform.

Drift detection. CloudFormation has a drift detection feature that can spot manual changes to resources managed by a stack.

Automatic rollback. If an error occurs while creating or updating a stack, CloudFormation automatically rolls back to the previous state.

CloudFormation’s Weaknesses #

AWS vendor lock-in. CloudFormation templates can only be used for AWS resources. If you have multi-cloud infrastructure, you need a separate tool for each cloud provider.

Verbose syntax. CloudFormation templates tend to be much longer than Terraform’s. A VPC with a few subnets, a route table, and a NAT Gateway can require 200+ lines of YAML in CloudFormation versus 50-70 lines of HCL in Terraform.

Intrinsic functions learning curve. Functions like !Ref, !Sub, !GetAtt, !If, !Select are powerful but confusing for beginners.

flowchart LR
    subgraph CF["CloudFormation"]
        C1["YAML/JSON Template"] --> C2["Upload to AWS"]
        C2 --> C3["CF creates/modifies\nresources"]
        C3 --> C4["Stack formed"]
    end

    subgraph TF["Terraform"]
        T1["HCL Config"] --> T2["terraform plan"]
        T2 --> T3["terraform apply"]
        T3 --> T4["Resources + State"]
    end

    CF --> CF_PRO["✓ Native AWS\n✓ Drift detection\n✓ Automatic rollback"]
    CF --> CF_CON["✗ Vendor lock-in\n✗ Verbose syntax\n✗ Difficult debugging"]

    TF --> TF_PRO["✓ Multi-cloud\n✓ Concise syntax\n✓ Plan/preview"]
    TF --> TF_CON["✗ Provider delay\n✗ Needs install\n✗ State management"]

    style CF_PRO fill:#e8f5e9,stroke:#2e7d32
    style CF_CON fill:#ffebee,stroke:#c62828
    style TF_PRO fill:#e8f5e9,stroke:#2e7d32
    style TF_CON fill:#fff3e0,stroke:#e65100

Pulumi #

Pulumi takes a radical approach: writing IaC in general-purpose programming languages like TypeScript, Python, Go, and C#. This means you can use every programming language feature — loops, conditionals, functions, classes, error handling, testing frameworks — none of which are available in HCL or YAML.

Pulumi Example with TypeScript #

import * as aws from "@pulumi/aws";
import * as pulumi from "@pulumi/pulumi";

// Using plain TypeScript
const config = new pulumi.Config();
const environment = config.require("environment");
const instanceType = config.get("instanceType") || "t3.medium";

// VPC
const vpc = new aws.ec2.Vpc(`${environment}-vpc`, {
    cidrBlock: "10.0.0.0/16",
    enableDnsHostnames: true,
    tags: { Name: `${environment}-vpc` },
});

// Subnets — you can use a loop!
const availabilityZones = ["ap-southeast-1a", "ap-southeast-1b", "ap-southeast-1c"];
const subnets = availabilityZones.map((az, i) => {
    return new aws.ec2.Subnet(`${environment}-subnet-${i}`, {
        vpcId: vpc.id,
        cidrBlock: `10.0.${i + 1}.0/24`,
        availabilityZone: az,
        tags: { Name: `${environment}-subnet-${az}` },
    });
});

// Security Group with conditional rules
const ingressRules: aws.types.input.ec2.SecurityGroupIngress[] = [
    { protocol: "tcp", fromPort: 443, toPort: 443, cidrBlocks: ["0.0.0.0/0"] },
];

if (environment === "staging") {
    // In staging, open SSH for debugging
    ingressRules.push({
        protocol: "tcp", fromPort: 22, toPort: 22,
        cidrBlocks: ["10.0.0.0/8"],
    });
}

const sg = new aws.ec2.SecurityGroup(`${environment}-web-sg`, {
    vpcId: vpc.id,
    description: "Web server security group",
    ingress: ingressRules,
});

// EC2 Instance
const server = new aws.ec2.Instance(`${environment}-web`, {
    ami: "ami-0abcdef1234567890",
    instanceType: instanceType as aws.ec2.InstanceType,
    subnetId: subnets[0].id,
    vpcSecurityGroupIds: [sg.id],
    tags: { Name: `${environment}-web-server` },
});

// Export output
export const serverPublicIp = server.publicIp;
export const vpcId = vpc.id;

Pulumi’s Strengths #

General-purpose programming languages. You can use TypeScript, Python, Go, or C#. No need to learn a new language. Testing can be done with testing frameworks you already know (Jest, pytest, Go testing).

Strong abstractions. With classes, functions, and modules built into the programming language, you can create more flexible abstractions than Terraform modules.

Component resources. Pulumi has a “component resource” concept that lets you create composite resources made up of several resources — with an interface you define yourself.

Pulumi’s Weaknesses #

Complexity leakage. General-purpose languages bring their own complexity. Debugging Pulumi errors can be very confusing because errors can come from the infrastructure or from the program code itself.

Less mature. Pulumi’s provider ecosystem is still narrower than Terraform’s. Some AWS resources may not be available in Pulumi’s native provider.

State management. Pulumi stores state in Pulumi Cloud (paid) or in a self-hosted backend that requires additional setup.

ANTI-PATTERN vs CORRECT (Pulumi):

ANTI-PATTERN:
  ✗ Using too many complex abstractions
    (5-level-deep class inheritance — hard for the team to understand)
  ✗ Writing IaC like writing a regular application
    (too much unpredictable dynamic behavior)
  ✗ Ignoring the type safety TypeScript offers

CORRECT:
  ✓ Use simple abstractions everyone can understand
  ✓ Leverage type safety to prevent errors at the code level
  ✓ Keep resource definitions clear and readable
  ✓ Use unit tests to validate infrastructure

AWS CDK #

The AWS Cloud Development Kit (CDK) is a framework that lets you define CloudFormation resources using general-purpose programming languages. CDK is essentially a “wrapper” around CloudFormation — the code you write gets compiled into a CloudFormation template.

CDK Example with TypeScript #

import * as cdk from 'aws-cdk-lib';
import * as ec2 from 'aws-cdk-lib/aws-ec2';
import * as rds from 'aws-cdk-lib/aws-rds';
import { Construct } from 'constructs';

export class WebAppStack extends cdk.Stack {
    constructor(scope: Construct, id: string, props?: cdk.StackProps) {
        super(scope, id, props);

        // VPC with 2 Availability Zones
        const vpc = new ec2.Vpc(this, 'WebAppVPC', {
            maxAzs: 2,
            natGateways: 1,
            subnetConfiguration: [
                {
                    cidrMask: 24,
                    name: 'Public',
                    subnetType: ec2.SubnetType.PUBLIC,
                },
                {
                    cidrMask: 24,
                    name: 'Private',
                    subnetType: ec2.SubnetType.PRIVATE_WITH_EGRESS,
                },
                {
                    cidrMask: 28,
                    name: 'Database',
                    subnetType: ec2.SubnetType.PRIVATE_ISOLATED,
                },
            ],
        });

        // Security Group
        const webSg = new ec2.SecurityGroup(this, 'WebSG', {
            vpc,
            description: 'Security group for web servers',
            allowAllOutbound: true,
        });
        webSg.addIngressRule(ec2.Peer.anyIpv4(), ec2.Port.tcp(443));

        // EC2 Instance
        const webServer = new ec2.Instance(this, 'WebServer', {
            vpc,
            instanceType: ec2.InstanceType.of(
                ec2.InstanceClass.T3, ec2.InstanceSize.MEDIUM
            ),
            machineImage: ec2.MachineImage.latestAmazonLinux2(),
            vpcSubnets: { subnetType: ec2.SubnetType.PRIVATE_WITH_EGRESS },
            securityGroup: webSg,
        });

        // RDS Database
        const database = new rds.DatabaseInstance(this, 'AppDB', {
            engine: rds.DatabaseInstanceEngine.postgres({
                version: rds.PostgresEngineVersion.VER_15_4,
            }),
            vpc,
            vpcSubnets: { subnetType: ec2.SubnetType.PRIVATE_ISOLATED },
            instanceType: ec2.InstanceType.of(
                ec2.InstanceClass.T3, ec2.InstanceSize.MEDIUM
            ),
            multiAz: true,
            allocatedStorage: 20,
        });

        database.connections.allowFrom(webSg, ec2.Port.tcp(5432));
    }
}

CDK vs Pulumi #

CDK and Pulumi are often compared because both use general-purpose programming languages. The main differences:

CDK’s Weaknesses #

AWS only. CDK can only create AWS resources through CloudFormation. For multi-cloud, you need another tool.

CloudFormation bottleneck. Because it compiles to CloudFormation, CDK inherits all of CloudFormation’s weaknesses — including the 500-resource-per-stack limit and unclear error messages.

Construct complexity. L1 (Cfn), L2 (high-level), and L3 (pattern) constructs can be confusing — especially when an L2 construct doesn’t support the feature you need and you have to “drop down” to L1.

Crossplane #

Crossplane takes a unique approach: bringing cloud infrastructure into Kubernetes. With Crossplane, you define cloud resources (like RDS, S3, EC2) as Kubernetes custom resources, and Crossplane translates them to cloud provider APIs.

How Crossplane Works #

# crossplane-rds.yaml — Defining RDS in Kubernetes
apiVersion: rds.aws.crossplane.io/v1alpha1
kind: DBInstance
metadata:
  name: app-database
spec:
  forProvider:
    engine: postgres
    engineVersion: "15.4"
    dbInstanceClass: db.t3.medium
    masterUsername: admin
    allocatedStorage: 20
    storageType: gp3
    multiAZ: true
    vpcSecurityGroupIds:
      - sg-0123456789
    dbSubnetGroupNameRef:
      name: app-subnet-group
  providerConfigRef:
    name: aws-provider
  writeConnectionSecretToRef:
    name: app-database-conn
    namespace: crossplane-system

Crossplane’s Strengths #

GitOps native. Crossplane works very well with ArgoCD and FluxCD. You can manage infrastructure using the same workflow as Kubernetes application deployments.

Composition. Crossplane has a “composition” concept that lets you create high-level abstractions (like a “WebApp” made up of EC2, RDS, and S3) as a single Kubernetes resource.

Self-service. Developers can request infrastructure through Kubernetes manifests without needing to know cloud provider details.

Crossplane’s Weaknesses #

Only for teams already using Kubernetes. Crossplane requires a running Kubernetes cluster — if you’re not on Kubernetes yet, this adds complexity.

Difficult debugging. When an error occurs, you have to check Crossplane provider logs, Kubernetes events, and the cloud provider API — three different layers.

Less mature. The Crossplane ecosystem is still evolving. Not all cloud resources are available in Crossplane providers.

flowchart TD
    A["Developer\nkubectl apply -f resource.yaml"] --> B["Kubernetes API Server"]
    B --> C["Crossplane Controller"]
    C --> D{"Resource\nType?"}
    D -->|"AWS"| E["AWS Provider"]
    D -->|"GCP"| F["GCP Provider"]
    D -->|"Azure"| G["Azure Provider"]
    E --> H["AWS API"]
    F --> I["GCP API"]
    G --> J["Azure API"]
    H --> K["Resource Created"]
    I --> K
    J --> K

    style A fill:#e3f2fd,stroke:#1565c0
    style K fill:#e8f5e9,stroke:#2e7d32

OpenTofu #

OpenTofu is a fork of Terraform born as a response to HashiCorp’s license change from MPL 2.0 to BSL (Business Source License) in August 2023. OpenTofu is maintained by the Linux Foundation and is committed to staying open-source.

Differences Between OpenTofu and Terraform #

OpenTofu is currently very similar to Terraform — it uses the same HCL syntax, supports the same providers, and most workflows are identical. However, there are some exclusive features OpenTofu has added:

State encryption. OpenTofu supports state file encryption on all backends, not just Terraform Cloud.

# opentofu-backend.tf — State encryption
terraform {
  backend "s3" {
    bucket         = "my-terraform-state"
    key            = "prod/terraform.tfstate"
    region         = "ap-southeast-1"
    encrypt        = true
    # OpenTofu: client-side encryption
    # (Terraform only supports S3 server-side encryption)
  }
}

Client-side state encryption. Encryption happens on the client side before state is sent to the backend — giving you full control over encryption keys.

When to Choose OpenTofu #

OpenTofu is worth considering if:

• HashiCorp’s BSL license is a problem for your use case
• You need state encryption on all backends
• You want to contribute to an open-source project
• You want fork protection from future license changes

ANTI-PATTERN vs CORRECT (OpenTofu):

ANTI-PATTERN:
  ✗ Choosing OpenTofu just because you're "anti-HashiCorp"
    without evaluating features and team needs
  ✗ Assuming OpenTofu is 100% compatible with Terraform
    (each has exclusive new features)

CORRECT:
  ✓ Evaluate the features you need (state encryption?)
  ✓ Check the compatibility of the providers you use
  ✓ Consider the ecosystem and community support
  ✓ Migrating from Terraform to OpenTofu is relatively easy
    (swap the binary, almost all configurations keep working)

Decision Framework #

Choosing an IaC tool isn’t a decision you can make in 5 minutes. Here’s a framework that can help:

flowchart TD
    A["Start: Choose IaC Tool"] --> B{"Multi-cloud?"}
    B -->|"Yes"| C{"Team knows a\nprogramming language\nwell?"}
    B -->|"No, AWS only"| D{"Already on\nKubernetes?"}
    B -->|"No, GCP only"| E["Cloud Deployment\nManager / Terraform"]
    B -->|"No, Azure only"| F["Bicep / Terraform"]

    C -->|"Yes, TypeScript/Python"| G["Pulumi"]
    C -->|"No, prefer DSL"| H["Terraform / OpenTofu"]

    D -->|"Yes"| I{"All resources\nin K8s?"}
    D -->|"No"| J{"Need tight\nAWS integration?"}

    I -->|"Yes"| K["Crossplane"]
    I -->|"No"| L["Terraform + K8s mix"]

    J -->|"Yes"| M["CloudFormation / CDK"]
    J -->|"No"| N["Terraform / OpenTofu"]

    style G fill:#e8f5e9,stroke:#2e7d32
    style H fill:#e8f5e9,stroke:#2e7d32
    style K fill:#e3f2fd,stroke:#1565c0
    style L fill:#e3f2fd,stroke:#1565c0
    style M fill:#fff3e0,stroke:#e65100
    style N fill:#e8f5e9,stroke:#2e7d32
    style E fill:#fff3e0,stroke:#e65100
    style F fill:#fff3e0,stroke:#e65100

Considerations by Team Size #

Considerations by Multi-Cloud Needs #

Single cloud (AWS only): CloudFormation or CDK is most optimal due to native integration. Terraform is still good if you want workflow consistency and multi-cloud options in the future.

Multi-cloud (AWS + GCP + Azure): Terraform or Pulumi. CloudFormation and CDK are out because they’re AWS-only. Crossplane can be an option if you’re already on Kubernetes.

Hybrid (cloud + on-premise): Terraform or Ansible. Terraform has providers for VMware, bare metal, and various cloud providers. Ansible can handle server configuration anywhere.

flowchart LR
    subgraph Single["Single Cloud"]
        S1["AWS → CloudFormation/CDK"]
        S2["GCP → Deployment Manager"]
        S3["Azure → Bicep/ARM"]
        S4["Or → Terraform (more flexible)"]
    end

    subgraph Multi["Multi-Cloud"]
        M1["Terraform ✓"]
        M2["Pulumi ✓"]
        M3["OpenTofu ✓"]
    end

    subgraph Hybrid["Hybrid"]
        H1["Terraform + Ansible"]
        H2["Terraform + Chef/Puppet"]
    end

    style S1 fill:#fff3e0,stroke:#e65100
    style S4 fill:#e3f2fd,stroke:#1565c0
    style M1 fill:#e8f5e9,stroke:#2e7d32
    style M2 fill:#e8f5e9,stroke:#2e7d32
    style M3 fill:#e8f5e9,stroke:#2e7d32

Comprehensive Comparison #

The following table compares all tools across important aspects:

Summary #

• CloudFormation is best for AWS-only teams that need native integration — free, drift detection, and automatic rollback, but verbose and vendor lock-in.
• Pulumi fits teams that want to use general-purpose programming languages (TypeScript, Python, Go) for IaC — powerful for complex abstractions but has complexity leakage.
• CDK suits AWS teams comfortable with TypeScript — a powerful CloudFormation wrapper but still bound by CloudFormation limitations.
• Crossplane is ideal for Kubernetes teams that want to manage infrastructure through GitOps — native K8s experience but requires Kubernetes expertise.
• OpenTofu is an open-source Terraform alternative with state encryption — good for teams prioritizing open-source and needing client-side encryption.
• Decision framework: Single cloud → CDK/CloudFormation, Multi-cloud → Terraform/Pulumi, Hybrid → Terraform + Ansible, Kubernetes-native → Crossplane.
• No tool is perfect — choose based on your team’s context, project scale, and multi-cloud needs.

← Previous: Imperative Tools   Next: When to Use Terraform? →