Terraform AWS and Azure architecture examples

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.