TerraformでAWS Organizationを完全制圧せよ：クロスアカウント設計の「深淵」と「解」
マルチアカウント環境の構築において、Terraformを「ただのスクリプト実行ツール」として使っているなら、今すぐ考えを改めるべきだ。
大規模なAWS組織において、管理アカウントから個々の子アカウントへリソースをデプロイする際、多くの現場が「権限管理のスパゲッティ」に陥っている。`assume_role`のハードコーディング、循環参照するプロバイダ設定……これらは技術的負債の最上位にランクされる。
本稿では、SREとして数々の環境を構築してきた経験から、「組織全体をコードで支配し、安全に、かつ爆速でデプロイする」ためのアーキテクチャを伝授する。
—
1. 「権限の二重構造」がもたらす地獄
マルチアカウント構成で最も陥りやすい罠は、Terraformの`provider`定義が肥大化し、コンテキストスイッチが困難になることだ。
我々が目指すべきは「プロバイダの抽象化」である。管理アカウントのTerraformが、各子アカウントのロールを動的に引き受ける「動的プロバイダ生成」の設計思想が、スケーラビリティの鍵を握る。
2. 動的AssumeRole設計：モジュールによるカプセル化
Terraformの`alias`を静的に書き連ねるのは素人の仕事だ。子アカウントが増えるたびにコードを修正する？ そんな非効率なことは即刻やめるべきだ。
以下のパターンをモジュール化し、`for_each`で回すのが正解だ。
実践：クロスアカウント管理用のプロバイダ設定例
管理用アカウントのプロバイダ
provider “aws” {
alias = “mgmt”
region = “ap-northeast-1”
}
子アカウントへのアクセスを抽象化するモジュール
module “account_provisioner” {
for_each = var.target_accounts # アカウントIDのリストを渡す
source = “./modules/assume_role_provider”
account_id = each.value
role_name = “TerraformExecutionRole” # 全アカウントで共通化せよ
}
このモジュール内部で`aws_iam_role`を引き受け、プロバイダを動的に作成する設計にすれば、メインロジックは「どのアカウントに何をデプロイするか」という宣言的な記述だけに集中できる。
3. 現場で震えるほど役立つ「プロの生存戦略」
ここからは、チームの生産性を一段階引き上げる「現場の極意」を紹介する。
A. 絶対に入れるべき神プラグイン・ツール
1. `tflint`: AWSの不正なプロパティをCIで弾くための必須ツール。特に`tflint-ruleset-aws`は、リージョンごとの制限を即座に検知する。
2. `terraform-docs`: READMEを自動生成せよ。IaCのドキュメントが古いのは、「動かないコード」と同じだ。
3. `tfswitch`: チーム内でTerraformのバージョンが不一致だと、Stateファイルの破壊という大惨事を招く。`.terraform-version`を共有し、即座に切り替えろ。
B. 開発スピードを劇的に高めるTips
- VS Code ショートカット: `Ctrl + .` (Quick Fix) を使いこなせ。リソース定義の不足や、未定義変数の抽出を一瞬で行う。
- 設定の共有化ルール: `terraform.tfvars`は秘匿情報を含まないこと。環境変数は`direnv`を用いてディレクトリ単位でロードさせる。これにより、誤操作による本番環境破壊を物理的に防ぐ。
C. 設定ファイル（YAML/JSON）のベストプラクティス
Terraformの変数に巨大なリストを直接書くのは愚策だ。「構成データはYAMLに追い出し、Terraformで読み込む」のが鉄則。
environments/prod/config.yaml
accounts:
- id: “123456789012”
name: “production-app”
tags: { Env: “prod”, Owner: “SRE-Team” }
main.tf
locals {
config = yamldecode(file(“${path.module}/config.yaml”))
}
この構成により、インフラの構造を変更せずに、アカウントの増減をYAMLの更新だけで完結させられる。
—
4. 最後に：コードは「対話」である
Terraformは単なる設定ファイルではない。それは「あるべき姿」を表現する宣言だ。
Control Tower配下の組織であれば、`AWSControlTowerExecution`ロールを活用し、信頼境界を厳格に管理せよ。権限を最小限に絞り、かつ必要な自動化を完全にコードに落とし込む。その先にこそ、深夜のトラブルシューティングから解放された、SREとしての真の自由がある。
さあ、コードを書いて組織を支配しろ。あなたの手元のキーボードが、次世代のインフラを作るのだから。