Table of Contents

1. Overview
2. Cloud-Specific Tools
3. Multi-Cloud Tools
4. Configuration Management Tools
5. Tool Comparison Matrix
6. Choosing the Right Tool

Overview

Different IaC tools serve different purposes and excel in different scenarios. This guide helps you understand the landscape and choose the right tool for your needs.

Tool Categories

Cloud-Specific:

• Deep integration with single cloud provider
• Native features and immediate support for new services
• No additional cost (built into cloud platform)
• Examples: CloudFormation (AWS), ARM Templates (Azure), Deployment Manager (GCP)

Multi-Cloud:

• Work across multiple cloud providers
• Consistent syntax and workflow
• Provider-agnostic abstractions
• Examples: Terraform, Pulumi, OpenTofu

Configuration Management:

• Focus on configuring existing infrastructure
• Can also provision infrastructure
• Often imperative or hybrid approach
• Examples: Ansible, Chef, Puppet

Cloud-Specific Tools

AWS CloudFormation

What it is: AWS’s native IaC service for provisioning AWS resources using JSON or YAML templates.

Key features:

• Native AWS integration
• Stack management (create, update, delete as a unit)
• Change sets (preview changes before applying)
• Drift detection
• No additional cost (free service)
• StackSets for multi-account/multi-region deployments

Advantages:

• Deepest AWS feature support
• New AWS features available immediately
• AWS-managed (no servers to maintain)
• Free to use
• Native drift detection
• Excellent AWS console integration

Disadvantages:

• AWS-only (vendor lock-in)
• YAML/JSON can be verbose
• Limited abstraction capabilities
• Steeper learning curve for complex scenarios

Best for:

• AWS-only deployments
• Teams already using AWS
• Need for AWS-specific features
• Organizations wanting AWS-managed solution

Resources:

• AWS CloudFormation Documentation
• CloudFormation Template Reference

Azure Resource Manager (ARM) Templates

What it is: Azure’s declarative template language for deploying Azure resources.

Key features:

• Native Azure integration
• JSON-based templates
• Resource dependencies
• Template validation
• Free (built into Azure)
• Bicep (newer, simpler syntax)

Advantages:

• Deepest Azure integration
• Immediate support for new Azure services
• Azure-managed solution
• Free to use
• Bicep provides cleaner syntax

Disadvantages:

• Azure-only (vendor lock-in)
• JSON can be verbose
• Limited multi-cloud support
• Complex for large deployments

Best for:

• Azure-only deployments
• Microsoft-centric organizations
• Teams already using Azure

Resources:

• ARM Templates Documentation
• Bicep Documentation

Google Cloud Deployment Manager

What it is: Google Cloud’s infrastructure deployment service using YAML, Python, or Jinja2 templates.

Key features:

• Native GCP integration
• Python-based templates (flexibility)
• Preview mode
• Parallel deployment
• Free service

Advantages:

• Deep GCP integration
• Python templates allow complex logic
• Free to use
• Google-managed

Disadvantages:

• GCP-only (vendor lock-in)
• Smaller community than AWS/Azure
• Less mature ecosystem

Best for:

• GCP-only deployments
• Teams using Google Cloud
• Need for Python-based templating

Resources:

• Deployment Manager Documentation

Multi-Cloud Tools

Terraform (HashiCorp)

What it is: Open-source, cloud-agnostic IaC tool using HashiCorp Configuration Language (HCL).

Key features:

• Multi-cloud support (AWS, Azure, GCP, 1000+ providers)
• Strong community and ecosystem
• Module registry for reusable components
• Plan/apply workflow (preview changes)
• State management
• Terraform Cloud for collaboration

Advantages:

• Works across all major clouds
• Largest community and ecosystem
• Extensive provider support
• Declarative and idempotent
• Mature and battle-tested
• Great documentation

Disadvantages:

• State management complexity (requires setup)
• HCL learning curve
• Not always first to support new cloud features
• Terraform Cloud costs for teams

Best for:

• Multi-cloud environments
• Teams wanting flexibility
• Strong community support needed
• Avoiding vendor lock-in

Example:

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

resource "aws_s3_bucket" "example" {
  bucket = "my-unique-bucket-name"

  tags = {
    Environment = "Production"
  }
}

Resources:

• Terraform Documentation
• Terraform Registry
• HashiCorp Learn

AWS CDK (Cloud Development Kit)

What it is: AWS’s framework for defining cloud infrastructure using familiar programming languages, which synthesizes to CloudFormation templates.

Key features:

• Use TypeScript, Python, Java, C#, or Go
• AWS-focused (deep AWS integration)
• Generates CloudFormation templates
• Rich library of high-level constructs
• Type safety and IDE support
• Built-in best practices

Advantages:

• Use languages you already know
• CloudFormation benefits (drift detection, change sets, rollback)
• Higher-level abstractions than raw CloudFormation
• Excellent AWS integration and support
• Free (generates CloudFormation)
• Great for developers already in AWS

Disadvantages:

• AWS-only (no multi-cloud support)
• Generated CloudFormation can be hard to debug
• Learning curve for construct patterns
• More verbose than raw CloudFormation for simple resources

Best for:

• AWS-focused development teams
• Developers wanting CloudFormation power with code
• Teams already using TypeScript/Python
• Need for higher-level AWS abstractions

Example:

using Amazon.CDK;
using Amazon.CDK.AWS.S3;

namespace MyCdkApp
{
    public class MyStack : Stack
    {
        public MyStack(Construct scope, string id, IStackProps props = null)
            : base(scope, id, props)
        {
            new Bucket(this, "MyBucket", new BucketProps
            {
                WebsiteIndexDocument = "index.html",
                Versioned = true,
                Encryption = BucketEncryption.S3_MANAGED
            });
        }
    }
}

AWS CDK Documentation

Pulumi

What it is: Multi-cloud IaC tool using familiar programming languages (TypeScript, Python, Go, C#, Java) with its own state management.

Key features:

• Use real programming languages
• Multi-cloud support (AWS, Azure, GCP, Kubernetes, 100+ providers)
• Strong typing and IDE support
• Pulumi Cloud for state management
• Import existing infrastructure
• Native testing with standard test frameworks

Advantages:

• Use languages you already know
• Full programming language features (loops, conditionals, functions)
• Better IDE support (autocomplete, refactoring)
• Easier testing with standard frameworks
• Multi-cloud from day one
• Great for developers

Disadvantages:

• Smaller community than Terraform
• More complex than declarative approaches
• Pulumi Cloud costs for teams (or self-manage state)
• Learning curve for IaC concepts

Best for:

• Developers preferring code over config
• Multi-cloud deployments
• Complex logic in templates
• Teams with strong programming background
• Need for standard testing tools

Example:

import pulumi
import pulumi_aws as aws

bucket = aws.s3.Bucket("my-bucket",
    website=aws.s3.BucketWebsiteArgs(
        index_document="index.html"
    ),
    tags={
        "Environment": "Production"
    }
)

pulumi.export("bucket_name", bucket.id)
pulumi.export("website_url", bucket.website_endpoint)

OpenTofu

What it is: Open-source fork of Terraform, created after HashiCorp’s license change to BSL.

Key features:

• Terraform-compatible
• Community-driven
• Open-source (MPL 2.0 license)
• Backward compatible with Terraform
• Same HCL syntax

Advantages:

• True open-source (no licensing concerns)
• Community governance
• Terraform compatibility (easy migration)
• No vendor lock-in

Disadvantages:

• Newer project (less mature)
• Smaller community than Terraform
• Uncertain long-term trajectory

Best for:

• Teams wanting open-source guarantees
• Avoiding vendor lock-in
• Migration from Terraform
• Organizations with strict open-source requirements

Resources:

• OpenTofu Documentation
• OpenTofu GitHub

Configuration Management Tools

Ansible

What it is: Agentless automation tool for configuration management, application deployment, and orchestration.

Key features:

• Agentless (SSH-based)
• YAML playbooks
• Large module library
• Can provision infrastructure (imperative)
• Easy to learn

Advantages:

• No agents required
• Simple YAML syntax
• Large ecosystem
• Good for both infrastructure and configuration
• Easy to get started

Disadvantages:

• Slower than agent-based tools
• Less declarative than Terraform/CloudFormation
• State management not as robust
• Can become complex at scale

Best for:

• Configuration management
• Hybrid IaC/config approach
• Teams already using Ansible
• Need for agentless solution

Example:

---
- name: Provision AWS EC2 instance
  hosts: localhost
  tasks:
    - name: Create EC2 instance
      amazon.aws.ec2_instance:
        name: "web-server"
        instance_type: "t2.micro"
        image_id: "ami-0c55b159cbfafe1f0"
        region: "us-east-1"
        tags:
          Environment: "Production"

Resources:

• Ansible Documentation

Chef & Puppet

Chef and Puppet are configuration management tools for defining infrastructure state using code.

Key features:

• Mature ecosystems
• Agent-based architecture
• Domain-specific languages (Ruby-based)
• Strong enterprise support
• Compliance automation

Advantages:

• Mature and battle-tested
• Strong enterprise features
• Compliance and security focus
• Large module libraries

Disadvantages:

• Agent-based (more complexity)
• Steeper learning curve
• Less popular for new projects
• Primarily configuration, not provisioning

Best for:

• Large enterprises
• Existing Chef/Puppet investments
• Compliance-heavy environments
• Configuration management over provisioning

Tool Comparison Matrix

Choosing the Right Tool

Decision Framework

Question 1: Single cloud or multi-cloud?

• Single cloud (AWS) → Consider CloudFormation
• Single cloud (Azure) → Consider ARM/Bicep
• Single cloud (GCP) → Consider Deployment Manager
• Multi-cloud or future flexibility → Terraform or Pulumi

Question 2: Team background?

• Ops/Infrastructure background → Terraform or CloudFormation
• Developer background (AWS-focused) → AWS CDK
• Developer background (multi-cloud) → Pulumi
• Prefer simplicity → Ansible or CloudFormation

Question 3: Primary use case?

• Infrastructure provisioning → Terraform, CloudFormation, Pulumi
• Configuration management → Ansible, Chef, Puppet
• Both → Terraform + Ansible, or Pulumi

Question 4: Organizational constraints?

• Must be open-source → OpenTofu, Ansible
• Need vendor support → Terraform (with HCP), Pulumi Cloud
• No additional costs → CloudFormation, ARM, Deployment Manager

Common Scenarios

Scenario: AWS-only startup

• Recommendation: CloudFormation
• Why: Free, native, deep AWS integration, no vendor lock-in risk for AWS-only

Scenario: Multi-cloud enterprise

• Recommendation: Terraform
• Why: Largest ecosystem, mature, works everywhere

Scenario: Developer-heavy team (AWS-focused)

• Recommendation: AWS CDK
• Why: Use familiar languages, CloudFormation benefits, AWS best practices built-in

Scenario: Developer-heavy team (multi-cloud)

• Recommendation: Pulumi
• Why: Use familiar languages, better IDE support, easier testing, multi-cloud from day one

Scenario: Hybrid infrastructure + configuration

• Recommendation: Terraform + Ansible
• Why: Terraform for provisioning, Ansible for configuration

Scenario: Open-source requirement

• Recommendation: OpenTofu
• Why: True open-source, Terraform-compatible

Migration Considerations

From manual to IaC:

1. Start with cloud-native tool (CloudFormation/ARM)
2. Import existing resources
3. Build new resources as code
4. Gradually convert legacy infrastructure

From one IaC tool to another:

• Terraform → OpenTofu: Easy (compatible)
• CloudFormation → AWS CDK: Easy (CDK can import CloudFormation)
• CloudFormation → Terraform: Moderate (import existing)
• Any → Pulumi: Easy (Pulumi can import from others)