Terraform depends_on: 明示的依存関係の正しい使い方（Associate向け）

Terraformは式中の参照から依存関係グラフを自動で構築しますが、参照が発生しない関係やプロバイダの整合性遅延を扱うときは、depends_onで明示的に順序を固定するのが安全です。

本稿はAssociateレベルの受験者と現場エンジニアを想定し、depends_onの基本・構文・ユースケース・アンチパターン・検証方法をまとめます。バージョン差異に敏感な箇所は注意書きも添えています。

基本: 暗黙的依存と明示的依存の違い

Terraformはリソース間の属性参照（例: subnet.vpc_id = aws_vpc.main.id）を検出し、暗黙的な依存を自動で張ります。これが最優先の設計原則です。

しかし、参照を伴わない順序づけ（例: 監査ログバケットが先に存在していてほしい、IAM伝播待ちなど）は暗黙依存だけでは表現できないため、depends_onを使って明示的に順序を固定します。depends_onは作成時は依存先→依存元の順、破棄時は逆順で動作します。

• まずは属性参照で暗黙依存を作るのが基本
• 参照がない関係・外部整合性待ちはdepends_onで明示
• 過度なdepends_onはグラフを硬直化させ計画時間を延ばす
• 循環依存（A→B→A）を作るとplanが失敗する

暗黙 vs 明示の依存関係（概念図）

暗黙的依存（属性参照）
[aws_vpc.main] ---> [aws_subnet.app]
     ^                    |
     | (vpc_id参照)       | (subnet_id参照)
     |                    v
[aws_internet_gateway.gw]-->[aws_route_table.rt]

明示的依存（depends_on）
[aws_s3_bucket.audit] --(depends_on)--> [null_resource.bootstrap]
                          (参照なしでも順序を固定)

基本構文（resource・module・data）

resource "aws_s3_bucket" "audit" {
  bucket = "org-audit-logs"
}

resource "aws_s3_bucket" "app" {
  bucket     = "app-bucket"
  depends_on = [aws_s3_bucket.audit]  # 参照しないが順序を固定
}

module "network" {
  source     = "./modules/network"
}

module "eks" {
  source     = "./modules/eks"
  depends_on = [module.network]        # モジュール間の順序固定
}

data "aws_iam_policy" "example" {
  arn        = "arn:aws:iam::aws:policy/ReadOnlyAccess"
  # Terraformのバージョンによってはdepends_onがdataでも使える。必要時のみ慎重に。
  depends_on = [aws_s3_bucket.audit]
}

構文とスコープ: どこに書けるか、何を指定できるか

depends_onはリソースブロック、モジュールブロック（Terraform 0.13以降）で安定利用できます。データソースへの適用はバージョンによって差異があるため、必要時のみ検討し、まずは属性参照で依存を表現するのが原則です。

depends_onに列挙するのは他のリソースやモジュールの参照です。可変な計算式で動的に依存先を切り替えるような使い方は避け、誰が見ても固定の順序が読み取れる形に保ちます。

• resource と module での利用が基本線
• data への適用は必要最小限・バージョン注意
• depends_on は「順序」指定であり、属性値の受け渡しはしない
• destroy時は依存が反転する点を覚える

正と誤の例（読みやすい順序指定）

# 悪い例: 動的に依存先を切り替え（可読性が落ちる）
# resource "aws_s3_bucket" "app" {
#   bucket     = "app-bucket"
#   depends_on = var.use_audit ? [aws_s3_bucket.audit] : []
# }

# 良い例: 監査バケットが必須なら常に固定で明示
resource "aws_s3_bucket" "app" {
  bucket     = "app-bucket"
  depends_on = [aws_s3_bucket.audit]
}

# モジュール間
module "db" {
  source = "./modules/db"
}
module "api" {
  source     = "./modules/api"
  depends_on = [module.db]
}

count/for_each と depends_on の関係

count や for_each を使うリソースにも、ブロックに1度書いた depends_on は全インスタンスに適用されます。インスタンスごとに別のdepends_onを付けることは基本的にできないため、設計段階で順序要件を揃えるか、依存を表す属性参照で分解するのが安全です。

for_eachのキーに応じて順序を変える必要がある場合は、上流のデータ構造や生成順序の設計を見直します。無理にdepends_onで辻褄合わせをすると循環や過度な直列化を招きやすく、plan/apply時間が伸びます。

• ブロック1つのdepends_onは全インスタンスに一括適用
• 個別制御が必要なら設計を見直す（依存を属性参照に落とす）
• 循環依存の検出はplan時に起きる（早期に気付ける）

for_each と depends_on の挙動

resource "aws_s3_bucket" "logs" {
  bucket = "shared-logs"
}

# 全アプリバケットはshared-logsの後に作りたい
resource "aws_s3_bucket" "app" {
  for_each   = toset(["a", "b", "c"])
  bucket     = "app-${each.key}"
  depends_on = [aws_s3_bucket.logs]  # 3つ全てに適用
}

# 個別順序を変える設計は避け、必要なら属性参照で関係を作る

実務ユースケースとアンチパターン

ユースケース: 参照が無いが順序を固定したい場面。例として、監査ログ用のS3バケットを最初に作成し、以降のサービスバケットは常にその後に作る、ネットワーク基盤（VPC/サブネット/ルート）を先に構築してからEKS/ECSを作る、といった方針です。

アンチパターン: プロバイダの一時的不整合（例: IAMの伝播遅延）を全てdepends_onで覆うこと。まずはリトライ・タイムアウト等の公式機構や適切な属性参照で解決し、やむを得ない場合だけピンポイントにdepends_onを使います。

• 基盤→アプリの大まかな層順序を固定する
• 監査・セキュリティ関連を前段で成立させる
• 整合性遅延はproviderのリトライ/timeout設定を優先
• null_resourceでの順序制御は最終手段（極力避ける）

IAMの伝播待ちに対する慎重な適用例

resource "aws_iam_role" "app" {
  name = "app-role"
  assume_role_policy = data.aws_iam_policy_document.assume.json
}

resource "aws_iam_role_policy_attachment" "readonly" {
  role       = aws_iam_role.app.name
  policy_arn = "arn:aws:iam::aws:policy/ReadOnlyAccess"
}

# EKSなど後段がIAMに依存するが、まずは属性参照/公式のリトライで様子を見る
module "eks" {
  source     = "./modules/eks"
  depends_on = [aws_iam_role_policy_attachment.readonly]  # 必要なときだけ付ける
}

検証: graph/planで依存を目視し、壊しにくいグラフにする

terraform graphでDOTを出力し、暗黙・明示の依存を俯瞰できます。過度な直列化や循環の予兆を早期に発見し、構造を直します。

狙い撃ちの-targetは便利ですが、依存グラフの整合を壊しやすいため恒常運用には不向きです。試験でも乱用は非推奨の知識として問われがちです。

• terraform planで順序と差分を常に確認
• terraform graph | dot -Tsvg で可視化
• -targetは最小限・緊急時のみ
• 循環依存は設計を分解して解消

graph/planの活用例

# 依存グラフの可視化
$ terraform graph > graph.dot
$ dot -Tpng graph.dot -o graph.png

# 特定モジュールのみ検証（恒常運用は非推奨）
$ terraform plan -target=module.eks

Associate試験で狙われるポイント

暗黙依存が作れるならdepends_onは不要、という原則をまず押さえます。そのうえで、参照が発生しないが順序を固定したいケースでdepends_onを使う設問が典型です。

destroyの順序反転、moduleブロックでのdepends_onサポート、count/for_eachへの一括適用、-target乱用のリスクなどが頻出論点です。

• まず属性参照、次にdepends_on（必要最小限）
• moduleでもdepends_on可（0.13以降）
• destroy時は依存が反転する
• count/for_eachでもブロック1回の指定で全体に効く

誤答と正答のイメージ

# 誤: 参照があるのにdepends_onを多用
resource "aws_subnet" "app" {
  vpc_id     = aws_vpc.main.id  # これで十分に依存が張られる
  cidr_block = "10.0.1.0/24"
  # depends_on = [aws_vpc.main]  # 不要
}

# 正: 参照が無い順序だけ固定
resource "aws_s3_bucket" "audit" { bucket = "audit" }
resource "aws_s3_bucket" "app" {
  bucket     = "app"
  depends_on = [aws_s3_bucket.audit]
}

問題で確認

よくある質問