Terraform Multi-Cloud Design Patterns - Dev.

Adopting a multi-cloud strategy often starts with a business requirement for high availability or vendor leverage, but it quickly becomes an engineering challenge. Managing AWS and Azure simultaneously requires more than just replicating resources; it demands a unified abstraction layer that respects the nuances of each provider.

In this article, we will deconstruct the architectural patterns required to manage hybrid environments using Terraform. We will focus on preventing code duplication, managing state isolation, and establishing a scalable directory structure.

Modularization Strategy for Hybrid Environments

The biggest pitfall in multi-cloud infrastructure is the "lowest common denominator" trap. Attempting to create a single module that creates a VM in both AWS and Azure often leads to complex, unmaintainable conditional logic.

Instead, adopt the composition pattern. Create specific modules for each cloud provider (e.g., aws-compute, azure-compute) and orchestrate them through a higher-level root module or separate environment configurations.

Pro Tip: Do not mix provider resources in the same child module. Keep provider-specific logic isolated to ensure distinct failure domains.

A recommended directory structure for managing multiple clouds looks like this:

.
├── modules
│   ├── aws
│   │   └── networking (VPC, Subnets)
│   └── azure
│       └── networking (VNet, Subnets)
├── environments
│   ├── prod
│   │   ├── main.tf (Calls both AWS/Azure modules)
│   │   └── providers.tf
│   └── stage
└── global
    └── iam (Identity management)

Configuring Multiple Providers

To manage AWS and Azure within a single codebase or even a single execution plan, you must configure multiple provider blocks. Terraform allows this via aliases, which is essential when establishing cross-cloud connectivity (e.g., Site-to-Site VPNs).

Here is a practical configuration for initializing both providers simultaneously:

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

# Default AWS Provider
provider "aws" {
  region = "us-east-1"
}

# Azure Provider
provider "azurerm" {
  features {}
  subscription_id = "xxxx-xxxx-xxxx"
}

# Aliased AWS Provider for DR Region
provider "aws" {
  alias  = "dr_region"
  region = "us-west-2"
}

State Management and Locking

Centralized state management is the backbone of any multi-cloud setup. You should never store state files locally. For a multi-cloud architecture, you have two primary options for remote backends:

1. Terraform Cloud/Enterprise: Agnostic to the underlying cloud, offering easy state locking and history.
2. Cloud-Native Storage: Storing AWS state in S3 (with DynamoDB for locking) and Azure state in Blob Storage.

For teams managing both, using AWS S3 as the single source of truth for both AWS and Azure states is a common pattern to reduce operational complexity, provided that strict IAM policies are in place.

Comparison: Terraform vs. Pulumi

While Terraform is the industry standard, teams often evaluate Pulumi for multi-cloud scenarios because of its general-purpose programming language support. Below is a technical comparison to aid your decision:

Feature	Terraform	Pulumi
Language	HCL (Domain Specific)	TypeScript, Python, Go, etc.
State Management	Strict State File (JSON)	State managed by backend service
Multi-Cloud Logic	Requires `count` / `for_each`	Standard loops / If-statements
Ecosystem	Largest Provider Registry	Growing, wraps Terraform providers

Implementing Disaster Recovery (DR)

A robust multi-cloud strategy enables Disaster Recovery (DR) by distributing workloads. The key to a successful DR setup with Infrastructure as Code (IaC) is minimizing "Configuration Drift."

When designing a DR strategy, do not rely on manual failover. Instead, implement DNS-based traffic routing using Amazon Route53 or Azure Traffic Manager. Your Terraform code should provision the infrastructure in the secondary cloud in a "warm standby" or "pilot light" mode.

Warning: Data gravity is the hardest part of multi-cloud DR. Ensure your Terraform modules for databases include replication configurations (e.g., AWS RDS to Azure SQL via replication tools) before traffic failover is attempted.

Summary and Action Items

Managing AWS and Azure simultaneously with Terraform requires a disciplined approach to modularization and state management. The goal is not to hide the differences between clouds, but to manage them efficiently through a unified workflow.

To succeed, separate your modules by provider, unify your state management backend, and use CI/CD pipelines (like GitHub Actions or GitLab CI) to enforce policy checks across both environments. Start by standardizing your networking modules, as this forms the foundation of cross-cloud connectivity.