Terraformマルチリージョン戦略の深淵：Provider `alias` の罠を壊し、カオスを制御せよ
Terraformで「マルチリージョン構成」や「複数アカウント管理」に踏み込んだ瞬間、多くのエンジニアが一度は遭遇する悪夢がある。
`provider “aws” {}` を乱立させ、モジュール間でプロバイダをバケツリレーのように渡し、最終的に「予期せぬリージョンにリソースが飛んでいく」「プランと適用結果が食い違う」という惨状だ。
今日は、プロフェッショナルとして現場を生き抜くための、「Providerの依存関係を完全に制御し、二度と予期せぬリソース生成を許さない」ための極意を伝授する。
—
1. 「デフォルトプロバイダ」の幻想を捨てろ
Terraformにおいて、最も危険なのは「明示的に指定しないプロバイダ」だ。
❌ 絶対にやるな：暗黙の依存関係
provider “aws” { region = “ap-northeast-1” }
module “ec2” {
source = “./modules/ec2”
# プロバイダを渡さないと、このモジュール内のリソースは
# 常にデフォルト（東京）に生成される。
}
この書き方では、`alias` を使ったマルチリージョン運用は崩壊する。原則として、ルートモジュールで定義したプロバイダを、モジュールへ「依存注入（Dependency Injection）」する設計を徹底する。
極意：Providerの明示的注入
モジュール側では `required_providers` を定義し、呼び出し側で `providers` 引数を使って紐付ける。
ルートモジュールの呼び出し
module “oregon_vpc” {
source = “./modules/vpc”
providers = {
aws = aws.us_west_2 # aliasで指定したプロバイダを注入
}
}
—
2. マルチリージョン管理の黄金律：`alias` 構成
大規模なインフラでは、単なるリージョン違いだけでなく「セキュリティアカウント」や「ログ専用アカウント」を跨ぐことが常態化する。この時、`alias` を使ったプロバイダ構成は以下のように整理するのがベストプラクティスだ。
provider.tf
provider “aws” {
alias = “tokyo”
region = “ap-northeast-1”
}
provider “aws” {
alias = “oregon”
region = “us-west-2”
}
モジュール側での受け取り定義 (modules/vpc/versions.tf)
terraform {
required_providers {
aws = {
source = “hashicorp/aws”
configuration_aliases = [ aws ] # ここが重要！
}
}
}
`configuration_aliases` を明示することで、「このモジュールはプロバイダの受け渡しを前提としている」という制約を静的解析レベルで強制できる。これにより、意図しないプロバイダが使われるリスクをゼロにする。
—
3. 実務で生産性を爆上げする「隠れた」テクニック
① VS Code最強の神プラグインと設定
Terraform開発において、`HashiCorp Terraform` 拡張機能は必須だが、さらに以下の設定を `settings.json` に追記せよ。
{
“terraform.languageServer”: {
“enabled”: true,
“args”: [“serve”]
},
“editor.formatOnSave”: true,
“terraform.validation”: true
}
保存するたびに `terraform fmt` が走り、インデントのズレによるレビューの無駄時間を撲滅できる。
② チーム開発を加速する `tfrc` とプラグインキャッシュ
CI/CDやチーム開発で一番の敵は「依存関係のダウンロードによる待ち時間」だ。ホームディレクトリに `.terraformrc` を配置し、キャッシュディレクトリを設定せよ。
~/.terraformrc
plugin_cache_dir = “$HOME/.terraform.d/plugin-cache”
これで、プロバイダーのバージョンアップやプロジェクトの切り替えが爆速になる。
③ 実用的な設定ファイル構成（YAMLを活用せよ）
変数（`variable`）が増えすぎると管理が破綻する。設定情報は `locals` でYAMLを読み込み、構造化するのがプロの作法だ。
locals.tf
locals {
# config.yamlをロードして動的にプロバイダ設定を生成する
config = yamldecode(file(“${path.module}/config.yaml”))
}
config.yaml
regions:
primary: “ap-northeast-1”
dr: “us-west-2”
—
4. プロの教訓：なぜ「バグ」が起きるのか
多くのエンジニアがハマる「Providerの仕様変更」や「予期せぬリソース生成」の根源は、Terraformの状態（State）に対する過信にある。
- Rule 1: `terraform plan` は必ず `-out=tfplan` で保存し、適用時にはそのファイルを指定する。
- Rule 2: リソースの削除や移動（`moved` ブロック）は、必ず実行前に `plan` を精査し、Stateの整合性を確認する。
- Rule 3: プロバイダのバージョンを `~> 4.0` のように固定し、`terraform.lock.hcl` を必ずコミットせよ。
結びに代えて
Terraformは単なる「設定ツール」ではない。君たちのインフラをコードとして定義する「言語」だ。
`alias` を恐れるな。暗黙的な依存を排除し、モジュールにプロバイダを明示的に注入する。この設計思想を貫くだけで、君たちのIaCは「壊れやすいもの」から「堅牢な資産」へと進化する。
今日から `provider` 定義を整理し、チームの生産性を一段上のステージへと引き上げてほしい。インフラの自動化は、コードの美しさから始まるのだから。