Multiple Regions and Accounts

Production AWS estates span regions for latency and disaster recovery, and accounts for isolation and blast-radius control. Terraform reaches both through the tools from the previous topic: aliased providers for regions, and assume_role providers for accounts.

The mechanics are the easy part. The decision that actually matters is how much of that multi-account topology belongs in a single state versus separate states. Cramming a dozen accounts into one apply maximizes blast radius — the exact thing multiple accounts were created to reduce. An elegant single state that can destroy your whole estate in one wrong plan is not elegant.

Multi-Region With Aliases

Multi-region within one account is the simplest case: one provider per region, each resource targeting the region it belongs in. The pattern below puts a primary bucket in us-east-1 and a replica in us-west-2 for disaster recovery, with replication wiring referencing both. Because both regions share one account, the credential chain is identical — only the region differs.

provider "aws" {
  region = "us-east-1"
}

provider "aws" {
  alias  = "dr"
  region = "us-west-2"
}

resource "aws_s3_bucket" "primary" {
  bucket = "app-data-primary"
}

resource "aws_s3_bucket" "replica" {
  provider = aws.dr
  bucket   = "app-data-replica"
}

Cross-Account With assume_role

Crossing accounts adds role assumption. A provider configured with assume_role assumes an IAM role in the target account and manages resources there, so a single run can baseline a brand-new workload account from your tooling account. The role assumption fails with an opaque AccessDenied unless the target role's trust policy permits the principal doing the assuming — the most common cross-account stumbling block, and one that lives in the target account's IAM, not in your Terraform.

provider "aws" {
  alias  = "sandbox"
  region = "us-east-1"

  assume_role {
    role_arn     = "arn:aws:iam::555566667777:role/OrgTerraform"
    session_name = "tf-sandbox-baseline"
  }
}

resource "aws_iam_account_password_policy" "strict" {
  provider        = aws.sandbox
  minimum_password_length = 14
}

State Topology

The structural choice is whether many accounts and regions share one state or each gets an isolated state. One state makes cross-references trivial — every resource can read every other's attributes directly. It also means every plan refreshes the entire estate, every apply can touch any account, and one lock blocks everyone. Isolated state per account contains failures and keeps plans fast, at the cost of wiring cross-account values through data sources or a parameter store rather than direct references.

Account Factory Patterns

At scale, the accounts themselves become infrastructure. AWS Organizations and Control Tower provision and baseline new accounts — a guardrail set, a logging configuration, a standard IAM role — and Terraform drives that factory. A new team gets an account created, baselined, and handed over through the same plan-and-apply workflow as any other resource, instead of a manual click-through that drifts from the standard within a week.

Blast Radius

The recurring lesson is that blast radius is an operational property, not an aesthetic one. A single state spanning every account looks clean in a repo and is a liability in an incident: one wrong destroy, one bad plan applied in a hurry, one corrupted state, and the failure is org-wide instead of contained to one account. Split production into its own state and pipeline, separate from non-prod, so the worst a mistake can do is bounded by the account it happened in.