Terraform vs CloudFormation vs Pulumi vs CDK: IaCツール選定

はじめに

Infrastructure as Code（IaC）は、インフラ構成をコードで管理する手法です。手作業でのインフラ構築は再現性が低く、ミスが起きやすい。IaCを使えば、インフラの構築・変更・削除をコードベースで管理でき、バージョン管理やレビューも可能になります。

身近な例えで理解するIaC

IaCは「設計図」のようなものです。

手作業でインフラを構築する = 口頭の指示で家を建てるようなもの（毎回微妙に違う家ができる） IaCでインフラを構築する = 詳細な設計図を元に家を建てるようなもの（何度建てても同じ家ができる）

各ツールの例え:

• Terraform = 汎用設計図。どの工務店（クラウド）でも使える標準的な書き方
• CloudFormation = AWS専用設計図。AWS純正で安心だが、AWS以外では使えない
• Pulumi = プログラミング言語で書ける設計図。TypeScriptやPythonでインフラを定義
• CDK = AWSの設計図をプログラミング言語で書けるようにしたもの。内部的にはCloudFormationに変換される

各ツールの概要

Terraform

HashiCorp社が開発するオープンソースのIaCツール。HCL（HashiCorp Configuration Language）で記述。

特徴:

• マルチクラウド対応（AWS、GCP、Azure、その他多数）
• 宣言的な記述
• State管理（tfstate）
• 豊富なプロバイダーエコシステム
• Plan/Applyのワークフロー（変更の事前確認が可能）

CloudFormation

AWS純正のIaCサービス。JSON/YAMLで記述。

特徴:

• AWS完全対応（新サービスに最も早く対応）
• 追加コストなし（AWS利用料のみ）
• スタック管理（リソースのグループ化）
• ドリフト検出（手動変更の検知）
• Change Sets（変更の事前確認）

Pulumi

プログラミング言語でインフラを定義できるIaCツール。

特徴:

• TypeScript、Python、Go、C#、Java等で記述可能
• マルチクラウド対応
• 条件分岐やループなどプログラミングの機能をフル活用
• テストフレームワークとの統合
• Pulumi AI（自然言語からインフラコードを生成）

AWS CDK（Cloud Development Kit）

AWSのインフラをプログラミング言語で定義し、CloudFormationテンプレートに変換するツール。

特徴:

• TypeScript、Python、Java、C#、Go対応
• 高レベルのコンストラクト（L2/L3）で簡潔な記述
• CloudFormationの全機能を利用可能
• AWS公式が提供するベストプラクティスパターン
• cdk diffで変更の事前確認

比較表

基本機能

料金比較

コード量の比較（VPC + サブネット + EC2の作成例）

コード例の比較

S3バケットの作成

Terraform:

resource "aws_s3_bucket" "my_bucket" {
  bucket = "my-unique-bucket-name"
}

resource "aws_s3_bucket_versioning" "my_bucket" {
  bucket = aws_s3_bucket.my_bucket.id
  versioning_configuration {
    status = "Enabled"
  }
}

CloudFormation:

Resources:
  MyBucket:
    Type: AWS::S3::Bucket
    Properties:
      BucketName: my-unique-bucket-name
      VersioningConfiguration:
        Status: Enabled

Pulumi (TypeScript):

import * as aws from '@pulumi/aws'

const bucket = new aws.s3.Bucket('my-bucket', {
  bucket: 'my-unique-bucket-name',
  versioning: {
    enabled: true,
  },
})

CDK (TypeScript):

import * as s3 from 'aws-cdk-lib/aws-s3'

const bucket = new s3.Bucket(this, 'MyBucket', {
  bucketName: 'my-unique-bucket-name',
  versioned: true,
})

判断フローチャート

[IaCツール選定]
    |
    v
[マルチクラウドが必要?]
    |
    +-- はい --> [チームのプログラミングスキルが高い?]
    |               |
    |               +-- はい --> Pulumi
    |               |           （TypeScript/Python等で記述）
    |               |
    |               +-- いいえ --> Terraform
    |                              （HCLは比較的学びやすい）
    |
    +-- いいえ（AWSのみ）
         |
         v
    [チームのプログラミングスキルが高い?]
         |
         +-- はい --> [既存のCloudFormation資産がある?]
         |               |
         |               +-- はい --> CDK（CloudFormationと共存可能）
         |               |
         |               +-- いいえ --> CDK or Pulumi
         |
         +-- いいえ
              |
              v
         [シンプルな構成?]
              |
              +-- はい --> CloudFormation（追加ツール不要）
              |
              +-- いいえ --> Terraform（モジュールエコシステム活用）

State管理の重要性

Stateとは

IaCツールが管理するインフラの「現在の状態」を記録したファイル。このファイルをもとに、コードの変更内容と実際のインフラの差分を計算する。

Terraformのtfstate

Terraformではterraform.tfstateファイルにState情報が保存される。

チーム開発でのState管理:

S3バックエンドの設定例:

terraform {
  backend "s3" {
    bucket         = "my-terraform-state"
    key            = "prod/terraform.tfstate"
    region         = "ap-northeast-1"
    dynamodb_table = "terraform-lock"
    encrypt        = true
  }
}

CloudFormation/CDKのState管理

CloudFormationはAWSがStateを管理するため、開発者がState管理を気にする必要がない。これはCloudFormation/CDKの大きなメリットの一つ。

ユースケース別の推奨

スタートアップ（AWSのみ）

推奨: CDK

• TypeScriptで直感的に記述
• L2コンストラクトで簡潔
• AWS公式のベストプラクティスが組み込まれている

マルチクラウド環境

推奨: Terraform

• AWS、GCP、Azure全てに対応
• プロバイダーエコシステムが最も充実
• 業界標準として最も普及

エンタープライズ（AWS）

推奨: CloudFormation or CDK

• AWS公式サポート
• 追加コストなし
• AWSサービスへの対応が最速

SaaS/PaaS管理も含む

推奨: Terraform or Pulumi

• Datadog、PagerDuty、GitHub等のSaaSリソースも管理可能
• 例: TerraformでAWSインフラ + Datadogモニタリング + GitHub設定を一元管理

チーム規模別の運用パターン

1-3人チーム

5-20人チーム

50人以上

実際の企業での採用事例

Terraform

• Uber: マルチクラウド環境のインフラ管理にTerraformを採用
• Slack: AWSインフラの管理にTerraformを使用
• 多くのSaaS企業がTerraformをデファクトスタンダードとして採用

CloudFormation

• Amazon自身: AWS内部のサービスもCloudFormationで管理
• エンタープライズのAWS環境で広く使用

Pulumi

• Snowflake: クラウドインフラの管理にPulumiを採用
• Mercedes-Benz: 自動車関連のクラウドインフラ管理

CDK

• AWS内部チーム: 多くのAWSサービスチームがCDKを利用
• Liberty Mutual: 保険業界のクラウドインフラにCDKを採用

IaCのベストプラクティス

移行パスの考え方

CloudFormation → CDK

CDKはCloudFormationに変換されるため、段階的な移行が可能。既存のCloudFormationテンプレートをCDKにインポートすることもできる。

CloudFormation → Terraform

cf2tfなどのツールで変換可能だが、完全な自動変換は難しい。段階的に新規リソースからTerraformで管理し、既存リソースはterraform importで取り込む方法が現実的。

Terraform → Pulumi

Pulumiはpulumi importやpulumi convertでTerraformからの移行をサポートしている。HCLからPulumiコードへの変換ツールも提供されている。

まとめ

2025年現在、TerraformがIaC全体のデファクトスタンダードであり、CDKがAWS限定のプロジェクトで急速にシェアを拡大している。チームのスキルセットとプロジェクトの要件に合わせて選択しよう。

参考リンク

• Terraform公式ドキュメント
• AWS CloudFormation公式ドキュメント
• Pulumi公式ドキュメント
• AWS CDK公式ドキュメント
• Terraform Registry