Terraform Provider Aliases: 複数アカウント/リージョン運用の実務と試験対策

複数のクラウドアカウントや複数リージョンを同時に扱うとき、TerraformのProviderエイリアスは避けて通れません。公式仕様に沿って、設計・モジュール化・認証切り替えまでをコンパクトにまとめます。

出典はTerraform公式ドキュメント（https://developer.hashicorp.com/terraform/language/providers）に準拠し、バージョン依存の挙動は慎重に扱います。記事後半には試験で問われやすいポイントとサンプル問題も用意しました。

Providerエイリアスの基礎

Terraformでは、同一プロバイダーに対して複数の設定（例: リージョンや認証情報違い）を持たせるためにaliasメタ引数を使います。エイリアスなしの設定はデフォルト構成、alias付きは別名の構成として扱われます。リソースやデータソース側ではproviderメタ引数でどの構成を使うかを明示できます。

モジュール配下では、デフォルトのプロバイダー構成は親から暗黙に利用されますが、エイリアス付き構成を使わせたい場合はmoduleブロックのprovidersマップで明示的に渡します。これが複数アカウント/リージョン運用の基本パターンです。

• aliasはproviderブロック内で定義する（例: provider "aws" { alias = "usw2" ... }）
• リソース/データソース側では provider = aws.usw2 のように選択
• モジュールには providers = { aws = aws.apne1, aws.usw2 = aws.usw2 } のように明示渡し

エイリアスの最小例（AWSを例示）

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

provider "aws" {
  region = "ap-northeast-1" # デフォルト構成
}

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

resource "aws_s3_bucket" "tokyo" {
  bucket = "example-tokyo-bucket-unique"
}

resource "aws_s3_bucket" "oregon" {
  provider = aws.usw2
  bucket   = "example-oregon-bucket-unique"
}

マルチアカウント/リージョン設計パターン

実務では、1) ルートで複数のエイリアスを定義して直接使う、2) モジュール化してprovidersマップで複数構成を注入する、3) スタック（ディレクトリ）を分けて状態も分離する、の3パターンがよく使われます。規模や分離要件（コンプライアンス/ blast radius）に応じて選びます。

複数アカウント（例: dev/prod）、複数リージョン（例: ap-northeast-1 / us-west-2）を横断する場合、アカウント境界はstateも分けるのが安全です。リージョン差は同一stateで扱ってもよいですが、変更衝突や並列実行を考えると業務要件次第で分離検討が必要です。

• アカウントは基本的にstate分離、リージョンは要件に応じて選択
• クロスアカウントはassume_role等のプロバイダー機能で明示切替
• モジュール単位でエイリアスを渡すとテスト・再利用性が上がる

マルチアカウント/リージョンとエイリアスの関係

モジュールへ複数プロバイダーを注入する例

module "multi_region" {
  source = "./modules/multi_region"
  providers = {
    aws        = aws                 # デフォルト（ap-northeast-1）
    aws.usw2   = aws.usw2            # 別リージョン（us-west-2）
  }
}

モジュールとprovidersマップの正しい使い方

子モジュールは親のデフォルト構成を暗黙に使えますが、エイリアス付き構成は暗黙継承されません。子でエイリアスを使う場合、moduleブロックのprovidersマップで、子が参照するプロバイダー名（例: aws、aws.usw2）を、親の具体的なインスタンス（aws、aws.usw2など）にマッピングします。

キーは「子モジュール内で使う名前」、値は「親で定義した実体」を指します。値は式にできるため条件分岐は可能ですが、エイリアスの作成自体は動的には行えません（providerブロックはfor_each等をサポートしません）。

• 子モジュールでエイリアスを参照するなら、親module.providersで必ず対応を渡す
• デフォルト構成のみで足りるなら、providersマップは不要
• provider引数は計算可能でも、エイリアス名自体は静的に定義する必要がある

子モジュールで別リージョンを併用する例

# 親側
module "net" {
  source = "./modules/net"
  providers = {
    aws       = aws        # デフォルト: ap-northeast-1
    aws.usw2  = aws.usw2   # 追加: us-west-2
  }
}

# 子モジュール側（./modules/net/main.tf）
terraform {
  required_providers {
    aws = { source = "hashicorp/aws" }
  }
}

resource "aws_vpc" "primary" {
  cidr_block = "10.0.0.0/16"           # デフォルト構成（ap-northeast-1）
}

resource "aws_subnet" "west" {
  provider   = aws.usw2                # エイリアス構成（us-west-2）
  cidr_block = "10.1.0.0/24"
  vpc_id     = "vpc-xxxxxxxx"
}

認証と権限分離（AWS例だが一般化可能）

エイリアスごとに認証情報や権限を切り替えます。AWSではprofile、assume_role、環境変数など複数の経路があり、特定の優先順位で評価されます。各プロバイダーの公式ドキュメントに沿って、意図した方法のみを構成に記述するのが安全です。

アカウント単位の強い分離が必要な場合は、エイリアスだけでなくstateも環境/アカウントごとに分け、CIから実行ロールも分離します。リージョンは変数で切り替えられますが、エイリアス名は静的に保つのが移行しやすいです。

• 各エイリアスに個別の認証設定（例: profileやassume_role）を与える
• 環境変数とプロバイダー設定の重複は避け、明示性を優先
• アカウント跨ぎの操作は最小権限で。stateも分離すると安全

エイリアス別に資格情報を分ける例（AWS）

provider "aws" {
  alias   = "dev"
  region  = var.dev_region
  profile = "dev"
}

provider "aws" {
  alias  = "prod"
  region = var.prod_region
  assume_role {
    role_arn     = var.prod_role_arn
    session_name = "tf-prod"
  }
}

resource "aws_kms_key" "dev" {
  provider = aws.dev
  description = "dev key"
}

resource "aws_kms_key" "prod" {
  provider = aws.prod
  description = "prod key"
}

状態管理・Plan/Apply・Import時のエイリアス指定

stateは各リソースがどのプロバイダー構成で管理されるかの参照を保持します。エイリアス名自体の変更は慎重に。名称だけを変えると、同一API先であっても予期しない差分検出の温床になります。エイリアス名は長期的に安定した命名にしてください。

import（Terraform 1.5+のimportブロック）や移行でも、どのエイリアス構成を使うかを明示できます。plan/applyは、各リソースが参照するproviderメタ引数に基づいて適切な構成を使用します。

• エイリアス名は原則リネームしない（必要なら計画的に段階移行）
• import時はproviderを明示して誤リージョン/誤アカウントを防止
• plan差分が広がるのを避けるため、state分離と命名規約を併用

importブロックでエイリアスを指定（1.5+）

import {
  to       = aws_s3_bucket.oregon
  id       = "example-oregon-bucket-unique"
  provider = aws.usw2
}

試験対策の要点と落とし穴

Associate/Professionalともに、エイリアスの定義場所、リソース/モジュールでの指定方法、暗黙の継承の範囲が頻出です。とくにモジュールに対してエイリアスを渡し忘れると、子がデフォルト構成を使ってしまい意図しないリージョン/アカウントに作用するケースを問われがちです。

provider引数は式を取れますが、エイリアス自体を動的生成することはできません。大量リージョン展開はディレクトリ分割やテンプレート化で補いましょう。

• aliasはproviderブロックのメタ引数。required_providersではない
• 子モジュールがaws.usw2を使うなら、親module.providersでaws.usw2キーを必ず埋める
• データソースもproviderメタ引数でエイリアスを選べる
• providerブロックはcount/for_each非対応。ループで量産は不可
• ワークスペースは変数値切替には有用だが、権限/アカウント分離の代替ではない

誤りやすい例と正しい指定

# 誤り（子でaws.usw2を使うのに親が渡していない）
module "m" {
  source = "./m"
  # providersマップが無い -> 子はデフォルトawsのみ
}

# 正
module "m" {
  source = "./m"
  providers = {
    aws.usw2 = aws.usw2
  }
}

問題で確認

よくある質問