Terraform、AWS CDK、CloudFormation、AWS SAM、Pulumi——5つのツールはそれぞれ異なる設計思想を持つ。「どれが最強か」という問いは意味をなさない。チームの技術スタック、組織の成熟度、ワークロードの特性によって最適解は変わる。本稿ではアーキテクト視点で、ユースケース別の判断基準を整理する。
目次
1. 5ツールの概要と設計思想
まず各ツールが「何を解決しようとしているか」を理解することが選定の出発点となる。
Terraform（HashiCorp / OpenTofu）
記述スタイル: HCL（独自DSL）
マルチクラウド対応の宣言型IaC。Provider エコシステムが強力で、AWS以外も同一ワークフローで管理できる。State管理が核心であり、Remote State・Workspaceによる環境分離が成熟している。業界最大のコミュニティと再利用可能なモジュール群を持つ、事実上の業界標準。
AWS CDK（AWS / オープンソース）
記述スタイル: TypeScript / Python / Java / Go（汎用言語）
汎用プログラミング言語でインフラを記述し、CloudFormationにコンパイルする。抽象化レイヤー（Construct）が強力で、L1（CFn Raw）・L2（ベストプラクティス込み）・L3（高レベルパターン）の3段階がある。CDK Pipelines との統合でCI/CDも完結できる。
CloudFormation（AWS ネイティブ）
記述スタイル: YAML / JSON
AWS唯一のネイティブIaC。新サービスのゼロデイサポート、ドリフト検出、StackSetsによるマルチアカウント展開がAWSコンソールと密結合している。State はAWSが管理するため運用負荷が低い。
AWS SAM（サーバーレス特化）
記述スタイル: YAML（CloudFormationの拡張）
Lambda・API Gateway・DynamoDBをシンプルに記述するためのCloudFormation拡張。sam local invoke / sam local start-api によるローカルデバッグが最大の強み。CloudFormationと完全互換のため、既存のCFnスタックと共存できる。
Pulumi（Pulumi Corp）
記述スタイル: TypeScript / Python / Go / C#（汎用言語）
CDKに近い思想だがAWS非依存。Terraform Providerをそのまま利用可能で、既存TFコードからの移行パスもある。汎用言語で記述しつつマルチクラウドに対応できるのが最大の差別化ポイント。
2. 比較マトリクス
| 観点 | Terraform | AWS CDK | CloudFormation | AWS SAM | Pulumi |
|---|---|---|---|---|---|
| 記述スタイル | 宣言型 (HCL) | 命令型 (汎用言語) | 宣言型 (YAML) | 宣言型 (YAML) | 命令型 (汎用言語) |
| マルチクラウド | ★★★ | ★☆☆ | ☆☆☆ | ☆☆☆ | ★★★ |
| AWS新サービス対応 | 数日〜数週のラグ | L1は即日、L2は遅延あり | ゼロデイ | CloudFormation依存 | Provider経由でラグあり |
| 学習コスト | 中（HCL） | 高（CDK + AWS知識） | 低（YAML） | 低（SAM + YAML） | 高（言語 + 概念） |
| テスト容易性 | 中（terratest） | 高（jest, pytest） | 低 | 高（sam local） | 高（言語ネイティブ） |
| State管理 | 自前（S3+DynamoDB等） | CloudFormationに委譲 | AWS管理 | AWS管理 | 自前 or Pulumi Cloud |
3. ユースケース別の最適解
シナリオ A: マルチクラウド・大規模プラットフォーム基盤
→ Terraform
AWS + GCP + Azure を単一ワークフローで管理。モジュール化による再利用性、Remote State、Workspaceによる環境分離が完成されている。Platform Engineeringチームが中央集権的に提供するゴールデンモジュールに最適。
シナリオ B: AWS専用・複雑な構成ロジックが必要な基盤
→ AWS CDK
条件分岐、ループ、型安全なインターフェースが必要な場合。L2/L3 Constructで高レベル抽象化を提供し、アプリチームに「安全なレール」を提供できる。CDK Pipelinesとの統合でCI/CDも完結。
シナリオ C: 厳格なコンプライアンス・監査要件
→ CloudFormation
AWS Configとの深い統合、ドリフト検出、StackSetsによるマルチアカウント展開が監査証跡として機能。ChangeSet承認フローを組み込んだ変更管理プロセスに適合しやすい。
シナリオ D: サーバーレスアプリケーション開発
→ AWS SAM
sam local invoke / sam local start-api によるローカルデバッグが他ツールにない強み。Lambda + API Gateway + DynamoDB 構成を最小コードで記述でき、開発速度が最速。
シナリオ E: 既存Terraformからの移行・ソフトウェア志向チーム
→ Pulumi
Terraform Providerをそのまま利用しつつ、汎用言語で記述したい場合に有効。CDKと異なりAWSに依存しない設計で、SREチームが既存言語スキルをフル活用できる。
シナリオ F: ハイブリッド構成（SAM + Terraform 併用）
→ SAM + Terraform の分割統治
ネットワーク・セキュリティ基盤はTerraform、アプリ層（Lambda/API）はSAMで管理する分割統治。terraform_remote_state でVPC IDを参照し、SAM側で利用するパターンが実用的。
4. デシジョンツリー
5. 各ツールのPros / Cons（アーキテクト視点）
Terraform
Pros
- 業界最大のコミュニティとモジュール群
- マルチクラウド対応の実績
- Plan/Apply サイクルが直感的
- OpenTofu でベンダーロックイン回避可能
Cons
- HCLの表現力に限界あり（動的ロジック）
- State 管理・ロック設計が必要
- BSL ライセンス問題（v1.6+）
AWS CDK
Pros
- 汎用言語の全機能（型、テスト、IDE補完）
- L2/L3 Constructによる高い抽象化
- CDK Pipelines との統合
cdk diffでCloudFormationレベルの差分確認
Cons
- 生成されるCFnテンプレートがブラックボックス化
- CDKのバージョンアップへの追従コストあり
- AWS以外での利用不可
CloudFormation
Pros
- 新サービスのゼロデイサポート
- AWS管理のStateで運用負荷が低い
- Service Control Policy との統合
Cons
- YAMLの冗長性・可読性の低さ
- エラーメッセージが不親切
- Rollback 挙動がトリッキーなケースあり
AWS SAM
Pros
sam localでのローカルデバッグが強力- サーバーレス構成の記述が簡潔
- CloudFormationと完全互換
Cons
- サーバーレス以外のユースケースに不向き
- 大規模ネットワーク構成には限界
Pulumi
Pros
- 汎用言語 + マルチクラウドの両立
- Terraform Provider との互換性
- テスト文化が強いチームに合う
Cons
- コミュニティ・採用事例がまだ少ない
- Pulumi Cloud への依存度が高い
- トラブルシューティング情報が薄い
6. まとめ：選定の原則
| 状況 | 推奨ツール |
|---|---|
| マルチクラウドが現実的な要件 | Terraform |
| AWS専用でロジックの複雑さを制御したい | AWS CDK |
| コンプライアンス・監査が最優先 | CloudFormation |
| サーバーレスの開発速度を最大化したい | AWS SAM |
| 言語スキルを活かしつつTFから移行したい | Pulumi |
「ツール選定」は技術的な問いである前に、組織設計の問いだ。Platform Engineeringチームが存在し中央集権的にモジュールを提供できるならTerraform/CDKの表現力を活かせる。チームが分散的でアプリ開発者が直接インフラを触るなら、SAMやCDKの高い抽象化が摩擦を下げる。
一つのツールに統一することへの圧力は常にあるが、「基盤インフラはTerraform、アプリ層はSAM」という分割統治が現実的に最も機能するケースも多い。重要なのはツールへの固執ではなく、チームの生産性・可観測性・変更の安全性を継続的に最大化することだ。
本記事は2024年時点の情報を元に執筆しています。各ツールのバージョンアップにより挙動が変わる可能性があります。