【実務・中級編】TerraformでAWS IAMポリシーの「JSON記述地獄」から脱出する：jsonencode関数とaws_iam_policy_documentデータソースの使い分け – インフラ構成管理（IaC）活用バイブル

IAMポリシーの「JSON地獄」を浄化せよ：Terraformで構築する型安全なIaCの極意

TerraformでIAMポリシーを管理しているとき、ヒアドキュメント（`<1. 生のJSON文字列（ヒアドキュメント）が招く「負債の正体」

`aws_iam_policy` リソースの中でJSONを直書きするのは、現代のインフラ管理において「技術的負債の先払い」でしかない。

静的解析の無力化: `terraform validate` や `tflint` が文法エラーを検知できない。
Diffの崩壊: 1行でも改行が入ると、PR上のDiffが壊滅的に読みづらくなる。
再利用性の欠如: 似たような権限セットを別リソースで使いたいとき、コピペ以外に道がない。

これらを解決するための「二つの武器」を紹介する。

—

2. aws_iam_policy_document：型安全という名の救済

Terraformの `data “aws_iam_policy_document”` は、JSONの構造を「Terraformのコード」として抽象化するデータソースだ。

実践：ベストプラクティス構成

IAMポリシーを論理的に分割し、データソースとして管理するのがSREの流儀である。

data/iam_policies.tf
data “aws_iam_policy_document” “s3_read_only” {
statement {
sid = “AllowS3Read”
effect = “Allow”

actions = [
“s3:Get”,
“s3:List”,
]

resources = [
“arn:aws:s3:::my-secure-bucket”,
“arn:aws:s3:::my-secure-bucket/”,
]
}
}

resource “aws_iam_policy” “s3_reader” {
name = “S3ReadOnlyPolicy”
# jsonencodeを噛ませる必要すらなくなる
policy = data.aws_iam_policy_document.s3_read_only.json
}

なぜこれが神なのか？
1. シンタックスハイライト: エディタが正しく構文を認識する。
2. 型チェック: `actions` に存在しないアクションを記述すると、Terraformがエラーを吐く（AWSプロバイダとの連携による）。
3. Diffの透明性: `sid` を振ることで、ポリシーのどのブロックが変更されたのかがTerraformのPlan上で明確になる。

—

3. jsonencodeと動的生成：複雑な条件分岐の突破口

「環境ごとにポリシーを微妙に変えたい」という要件に直面したとき、`data` ソースだけでは力不足になることがある。ここで `jsonencode()` の出番だ。

テクニック：環境別動的ポリシー生成

変数をMapで定義し、条件に応じて動的にStatementを構築する。

locals {
is_prod = terraform.workspace == “prod”

# 動的なステートメント構築
dynamic_statements = [
{
Effect = “Allow”
Action = [“kms:Decrypt”]
Resource = [var.kms_key_arn]
},
# 本番環境のみ追加の権限を付与
local.is_prod ? {
Effect = “Deny”
Action = [“s3:DeleteBucket”]
Resource = [“”]
} : null
]
}

resource “aws_iam_policy” “dynamic_policy” {
name = “DynamicPolicy”
policy = jsonencode({
Version = “2012-10-17”
Statement = compact(local.dynamic_statements) # nullを除外して生成
})
}

この手法を使えば、無理やり `concat()` や `flatten()` を使わずに、クリーンなロジックでポリシーを制御できる。

—

4. プロの現場で生産性を爆上げする環境設定

どれほど優れたコードも、タイピングが遅ければ意味がない。

推奨ツール・設定

VS Code + Terraform Extension (HashiCorp公式): 必須。`Format on Save` を有効にし、保存時に自動整形させる。
tflint: AWSルールセットを必ず入れる。これだけで、未定義のIAMアクションをCIで弾けるようになる。
Terraform Doc (terraform-docs): モジュール化している場合、READMEへの自動出力は基本。
神ショートカット: `Ctrl + Space` (補完) はもちろん、`Ctrl + Alt + L` (JetBrains系) や `Shift + Alt + F` (VSCode) でのフォーマットの癖を体に叩き込む。

チーム開発のルール（マニフェスト）

1. ポリシーは必ず `data` ソース化する: ベタ書きJSONはPRレビューを通さない。
2. `sid` を強制する: 誰が見ても何の権限かわかるように記述する。
3. ポリシーの分割: 1つのJSONに全て詰め込まず、機能単位（S3用、KMS用など）でデータソースを分ける。

—

最後に：コードは「読み手」のために書く

IAMポリシーは、クラウドインフラにおける「憲法」だ。これを可読性の低いヒアドキュメントで放置することは、将来の自分とチームに対する冒涜に等しい。

`aws_iam_policy_document` を使い、型安全に、そして論理的にポリシーを記述する。この小さな積み重ねが、障害発生時の切り分け速度を劇的に高め、あなたのチームを「運用に追われるチーム」から「設計を楽しむチーム」へと変貌させる。

今日から、JSON地獄を卒業しよう。あなたのインフラは、もっと美しくなれるはずだ。