Cloud providers · 14 min read · Reviewed 2026-08-29

Terraform AWS and Azure Architecture Examples

Terraform language and workflow stay consistent across cloud providers, while resources, attributes, limits, and platform services differ. Reuse the core Terraform concepts, then learn each provider’s architecture decisions on their own terms.

Comparable starting boundaries, not equivalent resources

The snippets show an AWS VPC and an Azure resource group. They are useful starting points, but they do not represent a one-to-one service mapping.

# AWS
resource "aws_vpc" "main" { cidr_block = "10.0.0.0/16" }

# Azure
resource "azurerm_resource_group" "main" {
  name = "rg-training"
  location = "Southeast Asia"
}

What transfers between providers

Providers, resources, references, variables, outputs, state, modules, and plan review use the same Terraform language. The learning investment in safe configuration structure transfers well.

Architecture principles also transfer: choose boundaries, minimise exposure, use managed services deliberately, and understand the cost and operational consequences of a design.

What needs provider-specific learning

AWS and Azure use different resource types and service models. A VPC and a virtual network fill similar roles but have different Terraform arguments, supporting resources, and operational conventions.

Do not infer a provider argument from a similarly named cloud-console feature or another provider. The exact provider documentation remains the source of truth.

Keep beginner architecture focused

Start with one provider, one organisational boundary, one network, one compute service, and one storage service. This makes the dependency graph readable and feedback specific.

Multi-cloud design is an advanced architecture decision involving deliberate identity, network, observability, governance, and cost boundaries—not simply mixing resource blocks.

Put it into practice

Build separate small AWS and Azure diagrams. Identify the provider, organisation boundary, network boundary, compute service, and storage service in each.

  1. Choose one provider family per learning architecture.
  2. Start with the provider organisation and network boundary.
  3. Reference IDs, names, and locations from declared resources.
  4. Use provider documentation for exact arguments.

Frequently asked questions

Can the same Terraform file use AWS and Azure resources?

Terraform supports multiple providers, but a learning architecture should normally focus on one provider at a time. Multi-cloud has deliberate identity, network, cost, and operational boundaries; it is not simply mixing resource blocks.

Is an AWS VPC the same as an Azure virtual network?

They fill similar network-boundary roles but have different resource types, arguments, supporting services, and operational conventions. Use the same Terraform concepts while checking each provider’s documentation for exact behavior.

What is a good first Terraform cloud architecture?

Start with one provider, one organisation boundary, one network, one compute service, and one storage service. This keeps the configuration and dependency graph readable while you learn the provider model.

Continue with Terraform Architect