コードに触れず"雰囲気価格"で判断してしまうと、リリース直前に驚くほどの差異が出ます。Terraformの計画出力を単一の真実源として扱い、Infracostで差分まで自動評価するのが安全な型です。
本稿は、Terraformの安定した公式動作(plan/showのワークフロー)に立脚し、Infracostを実務・試験の双方で迷わず使えるように整理しました。
コスト見積もりは、HCLの静的読解ではなく、変数・モジュール・データソースが具体値に解決された計画結果を基点に行うと精度が上がります。Terraformでは terraform plan で計画を生成し、terraform show -json で機械可読なJSONに変換できます。このJSONをInfracostに渡すのが実務での定番です。
計画を真実源にする利点は、条件分岐(count/for_each)やデフォルト値、プロバイダの解決結果が反映される点です。apply前に差分を把握し、PRでレビューできるため、コストの逸脱を早期に検知できます。
| 観点 | terraform plan | terraform apply | Infracost |
|---|---|---|---|
| 入力 | HCL + 変数 + 状態(参照のみ) | 計画 + 外部API実行 | plan.json またはHCL/状態 |
| 目的 | 変更案の算出 | 実変更の適用 | コストの算出/比較 |
| 出力 | plan.out / plan.json | リソースの実変更とstate更新 | コスト明細・差分(JSON/表/PRコメント) |
| 試験要点 | 未知値はplanで具体化される | コストはapply不要で見積可 | plan.jsonを渡すと精度向上 |
PlanからInfracostまでのデータフロー
Dev
|
v
terraform plan ----> plan.out -- terraform show -json --> plan.json
|
v
Infracost breakdown
|
v
コスト明細/PRコメント最小手順(ローカル)
terraform init
terraform plan -out plan.out
terraform show -json plan.out > plan.json
INFRACOST_API_KEY=xxxxxxxx infracost breakdown --path plan.jsonInfracostはCLIで、クラウド各社の公開価格表を参照して見積もりを計算します。Terraformプロジェクト直下のHCLを直接読むことも可能ですが、精度と再現性の観点ではplan.json経由を推奨します。
組み込みは単純です。APIキーを環境変数に設定し、plan.jsonを指定して breakdown を実行します。CIでは既存のplanアーティファクトを再利用し、PRにコメントする運用が一般的です。
導入スニペット
# APIキー設定(例)
export INFRACOST_API_KEY=xxxxxxxxxxxxxxxx
# 計画の作成とJSON化
terraform plan -out plan.out
terraform show -json plan.out > plan.json
# 見積もり
infracost breakdown --path plan.json --format table
# 複数パスをまとめる infracost.yml(任意)
# version: 0.1
# projects:
# - path: ./app
# - path: ./infra/network使用量ベースの料金(ストレージGB月、リクエスト数、データ転送など)はHCLだけでは確定しません。Infracostは usage ファイルで現実的な利用量を与えると精度が大幅に向上します。
変数は var-file で本番相当を渡し、plan時点でサイズや台数が確定するようにします。count/for_eachの条件やデフォルト値が曖昧だと未知のまま推定がぶれます。
usageファイルとvar-fileの例
# infracost-usage.yml(例)
version: 0.1
resource_usage:
aws_s3_bucket.my_logs:
monthly_tier_1_requests: 2000000
storage_gb: 500
aws_lb.app:
new_connections: 10000000
active_connections: 2000
# terraform.tfvars(本番)
instance_type = "t3.large"
volume_size = 200
replicas = 3PRでコスト差分を可視化し、しきい値を超える変更をゲートするのが実運用の定石です。ベースブランチの見積もり結果を保存し、変更ブランチと比較します。
公式アクション(GitHub)や汎用シェルで構成できます。失敗条件は組織ポリシーに合わせ、金額や増加率で判定します。
GitHub Actions例(要点のみ)
name: Cost Diff
on: pull_request
jobs:
infracost:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Terraform Plan
run: |
terraform init
terraform plan -out plan.out
terraform show -json plan.out > plan.json
- name: Setup Infracost
uses: infracost/actions/setup@v2
- name: Generate Base (main)
if: github.event.pull_request.base.ref == 'main'
run: |
infracost breakdown --path plan.json --format json --out-file .infracost-base.json
- name: Cost Diff
env:
INFRACOST_API_KEY: ${{ secrets.INFRACOST_API_KEY }}
run: |
infracost breakdown --path plan.json --format json --out-file current.json
infracost diff --path current.json --compare-to .infracost-base.json --format table
# 例: しきい値チェック(単純化)
infracost diff --path current.json --compare-to .infracost-base.json --format json --out-file diff.json
python .github/scripts/fail_on_threshold.py diff.json 20 100 # 20%または100通貨単位超で失敗Terraformの試験では、コスト見積もりそのものよりも、見積もりの前提となる計画の正確性と再現性が問われます。planを真実源とし、未知値を減らし、変数・条件分岐を明示化できるかが鍵です。
count/for_each、lifecycle、変数の優先順位、plan出力の解釈(create/replace/destroyの区別)といった基礎が、コスト差分の読み取り精度に直結します。
plan.jsonを出すコマンド(確認)
terraform plan -out plan.out
terraform show -json plan.out > plan.json
# これをInfracostに渡す
infracost breakdown --path plan.json複数ワークスペースや環境ごとに変数が変わる場合、意図しないデフォルトでplanしてしまうと見積もりがずれます。CIでも本番相当のvar-fileを必ず指定します。
プロバイダエイリアスやモジュールパスの解決誤りは、計画自体の失敗や未知値の増加を招きます。providersブロックやrequired_providersの整合を確認し、graph/consoleで依存関係を点検します。
診断のためのコマンド
terraform providers
terraform graph | dot -Tsvg > graph.svg
terraform console
# planの検証
terraform plan -out plan.out && terraform show -json plan.out | jq '.planned_values.root_module.resources[] | .type, .name'同一モジュールでdev/prodのサイズが異なる典型例です。両環境のplan.jsonを作り、Infracostで差分を出すと増減の根拠をPRで共有できます。
単一のHCLに対してvar-fileを切り替えるだけで再現できるため、レビューの標準手順として定着させやすい運用です。
サンプル構成と比較実行
# main.tf(抜粋)
variable "instance_type" {}
variable "replicas" { type = number }
resource "aws_instance" "app" {
count = var.replicas
ami = data.aws_ami.ubuntu.id
instance_type = var.instance_type
}
data "aws_ami" "ubuntu" {
most_recent = true
owners = ["099720109477"]
filter { name = "name" values = ["ubuntu/images/hvm-ssd/ubuntu-focal-20.04-amd64-server-*"] }
}
# dev.tfvars
instance_type = "t3.micro"
replicas = 1
# prod.tfvars
instance_type = "t3.large"
replicas = 3
# 実行
terraform init
terraform plan -var-file=dev.tfvars -out dev.out && terraform show -json dev.out > dev.json
terraform plan -var-file=prod.tfvars -out prod.out && terraform show -json prod.out > prod.json
# 見積作成
infracost breakdown --path dev.json --format json --out-file dev.cost.json
infracost breakdown --path prod.json --format json --out-file prod.cost.json
# 差分
infracost diff --path prod.cost.json --compare-to dev.cost.json --format tablePro
問題 1
チームはPR時点で正確なコスト見積もりと差分をレビューしたい。モジュールや変数の解決結果を反映した見積もりを得る、最も再現性の高い手順はどれか。
正解: A
計画をJSON化したplan.jsonを真実源にすると、モジュール展開や変数の具体値が反映され、apply不要で正確かつ再現性のある見積もりが可能。usageファイルで使用量を補足すればさらに精度が上がる。state単独やapply前提は要件に合致しない。
HCLディレクトリを直接Infracostに渡すのと、plan.jsonを渡すのは何が違いますか?
HCL直読みは静的解析のため、条件分岐やデータソース解決の結果が反映されにくく、未知値が増えがちです。plan.jsonはTerraformが解決した結果を含むため、見積もりの再現性と精度が上がります。
使用量に依存する料金はどう指定すればよいですか?
infracost-usage.yml などのusageファイルで、ストレージ容量やリクエスト数など現実的な値を与えます。これにより"使用量次第"の項目が具体化され、過小・過大見積もりを避けられます。
applyしなくても正確な見積もりは可能ですか?
はい。terraform plan と terraform show -json で得たplan.jsonを基にInfracostで見積もれば、apply不要で差分まで確認できます。applyはコスト見積もりの前提ではありません。
NicheeLab編集部
データエンジニアリング・クラウド資格の専門家。Databricks・Snowflake等の認定資格を保有し、実務経験に基づいた問題作成・解説を行っています。NicheeLab運営。
Terraform HCL 構文の基礎:Block / Attribute / Expression を正しく使い分ける
Terraform Associate で頻出の HCL 構文を、ブロック・属性・式の3視点で整理。実務で迷いがちな書き...
Terraform Authoring & Ops Pro: 上位資格の範囲と対策
上位レベルを想定したTerraformの設計・運用ドメインを整理し、実務で通用する対策を提示。モジュール設計、ステート運...
Terraform Providers の基本: プラグイン型アーキテクチャを正しく使いこなす
Associate レベルで押さえるべき Provider の基礎、インストール、バージョニング、認証、エイリアス運用を...
Terraform Resourceブロック徹底ガイド: 最小単位のリソース定義
Associateレベルで押さえるべきResourceブロックの構造、依存関係、メタ引数、ライフサイクル制御を実務目線で...
Terraform Data Source徹底理解:既存リソースの参照で壊さず足す
Terraform Associate向けに、Data Sourceを用いた既存リソース参照の基本、選択基準、評価順序、...