こんにちは。クラウドインフラの深淵を覗き、日々IaCのコードと格闘しているエンジニアです。
今日は、AWS環境を管理する多くのエンジニアが「一度は絶望する」、しかし「避けては通れない」最重要トピック——AWS Organizations / Control Tower 環境におけるTerraformのクロスアカウント設計についてお話しします。
「手動でアカウントを切り替えて設定する」時代はもう終わりです。今日は、Terraformの力を最大限に引き出し、一つの管理アカウントから組織全体を制御下に置く「インフラの自動化」の神髄に触れていきましょう。
—
1. なぜ「権限管理」が最初の壁になるのか？
複数アカウント環境でTerraformを使う際、最も苦しむのは「どこで誰として実行するか」という認証の問題です。
管理アカウント（Management Account）のTerraformから、メンバーアカウント（子アカウント）のリソースを操作する場合、「AssumeRole（ロールの引き受け）」という仕組みを使います。これを使わずにAccess Keyを直書きしたり、手動でスイッチロールしてCLIを実行するのは、セキュリティ的にも運用コスト的にも「悪夢」の始まりです。
我々が目指すべきは、「Terraformが自動的に、必要な時だけ、必要なアカウントの権限を拝借する」という設計です。
—
2. 高度なモジュール設計：Providerの動的切り替え
Terraformには `alias` という強力な武器があります。これを使うと、一つのコードベースの中で「どのプロバイダー設定を使ってリソースを作るか」を自在に制御できます。
実践的な構成例
まずは、Terraformのメイン設定で、メンバーアカウントへのAssumeRole設定を定義しましょう。
1. メンバーアカウント用のプロバイダー設定
provider “aws” {
alias = “member_account”
region = “ap-northeast-1”
# ここが魔法の鍵。管理アカウントからメンバーのロールへ一時的に昇格する
assume_role {
role_arn = “arn:aws:iam::123456789012:role/TerraformExecutionRole”
session_name = “Terraform-CrossAccount-Session”
}
}
2. リソース定義でプロバイダーを指定
resource “aws_s3_bucket” “member_bucket” {
provider = aws.member_account # ここで明示的に指定
bucket = “my-company-prod-data”
}
この設計の肝は、`role_arn` をモジュール化して変数化することです。これにより、アカウントが増えても、Terraform側は設定をコピペすることなく、新しいアカウントIDを渡すだけで済むようになります。
—
3. ガバナンスを担保する「HelloWorld」：最小構成の構築
まずは、Control Towerで作成されたアカウントに対して、TerraformからS3バケットを1つ作るという最小の成功体験（HelloWorld）を積みましょう。
ステップ1：信頼関係の設定
まず、メンバーアカウント側のIAMロール（`TerraformExecutionRole`）に、管理アカウントからのアクセスを許可する信頼ポリシーを記述します。
{
“Version”: “2012-10-17”,
“Statement”: [
{
“Effect”: “Allow”,
“Principal”: { “AWS”: “arn:aws:iam::管理アカウントID:root” },
“Action”: “sts:AssumeRole”
}
]
}
ステップ2：Terraformの初期化と実行
ターミナルを開き、以下のコマンドで環境を立ち上げます。
準備：設定ファイルの初期化
terraform init
計画の確認：どのアカウントに何を作るか、差分を確認する（重要！）
terraform plan
適用：一気にプロビジョニング
terraform apply -auto-approve
—
伝説のエンジニアからのアドバイス：運用を劇的に楽にするために
この設計をマスターした後に、さらなる高みを目指すなら、以下のポイントを意識してください。
1. Stateファイルの分離: アカウントごとにStateファイルを分けるか、`terragrunt`のようなツールを使って「アカウントごとの独立性」を担保してください。一つの巨大なStateファイルは、いつか必ず爆発します。
2. IAMの最小権限: `TerraformExecutionRole` に `AdministratorAccess` をつけるのは楽ですが、本番環境では必要な権限（IAMやS3など）だけに絞るのがプロの流儀です。
3. ガードレールの自動適用: Control Towerを使っているなら、Terraformで作成したリソースがガードレールに抵触しないかを `terraform plan` の段階でチェックするパイプラインを組むと、現場の信頼度が桁違いに上がります。
—
最後に
インフラの自動化は、単なるコード書きではありません。「人間が手作業で行うリスクを、コードの論理性で置換する」という、エンジニアリングの芸術です。
最初は少し難しく感じるかもしれませんが、一度この「クロスアカウントAssumeRole」のパターンを理解すれば、AWSのアカウントが10個あろうと100個あろうと、あなたの手元で制御できるようになります。
毎日の作業から「手動の恐怖」を取り除き、もっとクリエイティブな設計に時間を使えるようになりましょう。素晴らしいIaCライフを！