Terraform・Pulumi・AWS CDKを徹底比較：IaCツール選定の実践ガイド

「インフラをコードで管理したいが、Terraform・Pulumi・AWS CDKのどれを選ぶべきか」。この問いに直面しているチームは多いのではないでしょうか。Infrastructure as Code（IaC）ツールの選定は、チームの生産性とインフラの保守性を長期的に左右する重要な意思決定です。

本記事では、2026年3月時点の最新情報をもとに、3つの主要IaCツールを言語設計・状態管理・エコシステム・ライセンスの4軸で比較します。それぞれのツールでS3バケットとLambda関数をプロビジョニングする実装例を示し、チームの技術スタックや組織戦略に応じた選定基準を提示します。

この記事でわかること

Terraform（HCL）・Pulumi（汎用言語）・AWS CDK（CloudFormation抽象化）の設計思想と根本的な違い
各ツールの状態管理・ドリフト検出・テスト戦略の具体的な実装方法
2026年時点の最新機能（CDK Mixins、Pulumi Neo、Terraform MCP統合）の実務への影響
OpenTofuフォークとBSLライセンス問題が組織のツール選定に与える影響
チーム規模・クラウド戦略・既存スキルセットに基づく選定フローチャート

対象読者

想定読者: IaCの導入・移行を検討しているMLエンジニア・SRE・バックエンドエンジニア
必要な前提知識:
- AWS（S3、Lambda、IAM）の基本的な理解
- Python / TypeScript いずれかの基礎文法
- コマンドライン操作の経験
- Gitの基本操作（ブランチ、コミット）

注意: IaC自体の概念については基礎から解説します。Terraformなどの個別ツール経験は不要です。

結論・成果

3ツールの比較結果を先にまとめます。

評価軸	Terraform	Pulumi	AWS CDK
対応クラウド	マルチクラウド（4,800+プロバイダー）	マルチクラウド（150+プロバイダー）	AWS専用
言語	HCL（独自DSL）	TypeScript / Python / Go / C# / Java	TypeScript / Python / Java / C# / Go
状態管理	リモートバックエンド（S3等）	Pulumi Cloud / S3 / ローカル	CloudFormation（AWS管理）
ライセンス	BSL 1.1（ソース公開）	Apache 2.0（OSS）	Apache 2.0（OSS）
学習コスト	HCL習得が必要（中程度）	既知言語で低い	AWS + CloudFormation理解が必要
リソース上限	状態ファイルあたり推奨1,000	スタックあたり推奨500	CloudFormationスタックあたり500

選定の結論:

マルチクラウド運用 + 大規模エコシステム重視 → Terraform（またはOpenTofu）
既存の開発言語でIaCを書きたい + マルチクラウド → Pulumi
AWS専用 + AWS Well-Architected準拠を自動化したい → AWS CDK

Pulumi NeoのAI支援機能を活用した早期導入企業では、インフラプロビジョニング時間を従来の3日から4時間に短縮（75%高速化）した事例がPulumiの公式ブログで報告されています。

Infrastructure as Codeの基礎を理解する

IaCツールの比較に入る前に、IaCの基本概念を整理しておきましょう。IaCとは、サーバー・ネットワーク・ストレージなどのインフラリソースを、手動のGUI操作ではなくコード（設定ファイル）で宣言的に定義・管理する手法です。

IaCが解決する3つの課題

再現性: 同じコードから同じインフラを何度でも構築できる（手動操作のミスを排除）
バージョン管理: Gitでインフラの変更履歴を追跡し、問題時にロールバック可能
レビュー可能性: Pull Requestでインフラ変更をチームでレビューできる

MLエンジニアの方にとっては、「学習パイプラインのハイパーパラメータをコードで管理するように、インフラの設定もコードで管理する」とイメージすると分かりやすいでしょう。config.yamlでモデルの設定を管理するのと同じ発想です。

宣言的アプローチと命令的アプローチ

IaCツールには宣言的（Declarative）と命令的（Imperative）の2つのアプローチがあります。

アプローチ	説明	類推（Python）
宣言的	「こうあるべき」を定義。ツールが差分を計算して適用	`expected_state = {"gpu": 4, "memory": "64GB"}`
命令的	「こうしろ」を手順で指示。逐次実行	`add_gpu(); set_memory("64GB")`

Terraform・Pulumiは宣言的、AWS CDKは宣言的コードをCloudFormationテンプレート（JSON/YAML）に変換する合成（Synthesize）アプローチです。実際には3ツールとも「望ましい状態を定義し、差分を適用する」という点で共通しています。

3ツールの設計思想を比較する

ここから、各ツールの設計思想と実装の違いを具体的に見ていきましょう。同じリソース（S3バケット + Lambda関数）を3ツールそれぞれで定義し、コードレベルで比較します。

Terraform: HCLによる宣言的定義

Terraform（HashiCorp、現IBM傘下）は、独自のドメイン固有言語（DSL）であるHCL（HashiCorp Configuration Language）でインフラを定義します。2026年3月時点の最新バージョンはTerraform 1.11/1.12です。

# main.tf - Terraform 1.11+
# プロバイダー設定
terraform {
  required_version = ">= 1.11"
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }

  # S3バックエンドで状態管理（Terraform 1.10+のネイティブロック使用）
  backend "s3" {
    bucket       = "my-terraform-state"
    key          = "prod/terraform.tfstate"
    region       = "ap-northeast-1"
    use_lockfile = true  # S3ネイティブロック（DynamoDBは非推奨）
    encrypt      = true
  }
}

provider "aws" {
  region = "ap-northeast-1"
}

# S3バケット
resource "aws_s3_bucket" "data_bucket" {
  bucket = "ml-training-data-2026"

  tags = {
    Environment = "production"
    ManagedBy   = "terraform"
  }
}

# バケットのバージョニング有効化
resource "aws_s3_bucket_versioning" "data_bucket_versioning" {
  bucket = aws_s3_bucket.data_bucket.id
  versioning_configuration {
    status = "Enabled"
  }
}

# Lambda関数
resource "aws_lambda_function" "processor" {
  function_name = "data-processor"
  runtime       = "python3.12"
  handler       = "index.handler"
  filename      = "lambda.zip"
  role          = aws_iam_role.lambda_role.arn

  environment {
    variables = {
      BUCKET_NAME = aws_s3_bucket.data_bucket.id
    }
  }
}

# IAMロール（Lambda用）
resource "aws_iam_role" "lambda_role" {
  name = "data-processor-role"
  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Action    = "sts:AssumeRole"
      Effect    = "Allow"
      Principal = { Service = "lambda.amazonaws.com" }
    }]
  })
}

Terraformの特徴:

HCLは宣言的で可読性が高い。ただし汎用言語の機能（ループ、条件分岐、クラス）は制限される
terraform planで変更内容を事前確認し、terraform applyで適用する2段階フロー
4,800+プロバイダーが公開されており、AWS・Azure・GCP・Kubernetes・Datadog等あらゆるサービスに対応

なぜHCLという独自言語なのか:

汎用言語と異なり、副作用（API呼び出し、ファイル書き込み等）を言語レベルで排除できる
「何をデプロイするか」の宣言に集中でき、実行順序はTerraformが依存関係グラフから自動計算
一方で、複雑なロジック（条件付きリソース生成、動的なリスト操作）ではHCLの制約に苦労する場面がある

注意: HashiCorpは2023年8月にTerraformのライセンスをMPL 2.0からBSL 1.1に変更しました。BSL 1.1は「ソース公開」ではありますがOSIの定義するオープンソースではありません。商用IaCプラットフォームを構築する場合はライセンス条項の確認が必要です。

Pulumi: 汎用プログラミング言語でIaC

Pulumiは、TypeScript・Python・Go・C#・Javaといった汎用言語でインフラを定義するツールです。ライセンスはApache 2.0です。

# __main__.py - Pulumi (Python)
# pip install pulumi pulumi-aws
import pulumi
import pulumi_aws as aws
import json

# S3バケット
data_bucket = aws.s3.BucketV2(
    "data-bucket",
    bucket="ml-training-data-2026",
    tags={
        "Environment": "production",
        "ManagedBy": "pulumi",
    },
)

# バケットのバージョニング有効化
bucket_versioning = aws.s3.BucketVersioningV2(
    "data-bucket-versioning",
    bucket=data_bucket.id,
    versioning_configuration={
        "status": "Enabled",
    },
)

# IAMロール（Lambda用）
lambda_role = aws.iam.Role(
    "data-processor-role",
    assume_role_policy=json.dumps({
        "Version": "2012-10-17",
        "Statement": [{
            "Action": "sts:AssumeRole",
            "Effect": "Allow",
            "Principal": {"Service": "lambda.amazonaws.com"},
        }],
    }),
)

# Lambda関数
processor = aws.lambda_.Function(
    "data-processor",
    function_name="data-processor",
    runtime="python3.12",
    handler="index.handler",
    code=pulumi.FileArchive("./lambda"),
    role=lambda_role.arn,
    environment={
        "variables": {
            # Pulumiの出力値（Output）を直接参照
            "BUCKET_NAME": data_bucket.id,
        },
    },
)

# 出力値をエクスポート
pulumi.export("bucket_name", data_bucket.id)
pulumi.export("lambda_arn", processor.arn)

Pulumiの特徴:

Pythonのforループ、if分岐、クラス継承などをそのまま使える
IDEの補完・型チェック・リファクタリング機能がフル活用できる
pytestやunittestでインフラコードのユニットテストが書ける
シークレットがデフォルトで暗号化される（Terraformは別途設定が必要）

なぜ汎用言語なのか:

インフラの定義とアプリケーションロジックを同じ言語・同じリポジトリで管理できる
既存の開発チームがHCLを新たに学ぶ必要がなく、オンボーディング時間を約30%短縮できるとPulumiの公式ドキュメントで報告されている
一方で、「何でもできる」自由度が規約のないコードの乱立を招くリスクもある

AWS CDK: 高レベル抽象化によるAWS専用IaC

AWS CDK（Cloud Development Kit）は、AWSが公式に提供するIaCフレームワークです。汎用言語でインフラを定義し、内部でCloudFormationテンプレートに変換（合成: Synthesize）します。

// lib/infra-stack.ts - AWS CDK v2 (TypeScript)
// npm install aws-cdk-lib constructs
import * as cdk from "aws-cdk-lib";
import * as s3 from "aws-cdk-lib/aws-s3";
import * as lambda from "aws-cdk-lib/aws-lambda";
import * as iam from "aws-cdk-lib/aws-iam";
import { Construct } from "constructs";

export class InfraStack extends cdk.Stack {
  constructor(scope: Construct, id: string, props?: cdk.StackProps) {
    super(scope, id, props);

    // S3バケット（CDKがバージョニング等のベストプラクティスを自動適用）
    const dataBucket = new s3.Bucket(this, "DataBucket", {
      bucketName: "ml-training-data-2026",
      versioned: true, // 1行でバージョニング有効化
      encryption: s3.BucketEncryption.S3_MANAGED,
      removalPolicy: cdk.RemovalPolicy.RETAIN,
      blockPublicAccess: s3.BlockPublicAccess.BLOCK_ALL, // デフォルトで全公開ブロック
    });

    // Lambda関数
    const processor = new lambda.Function(this, "DataProcessor", {
      functionName: "data-processor",
      runtime: lambda.Runtime.PYTHON_3_12,
      handler: "index.handler",
      code: lambda.Code.fromAsset("lambda"),
      environment: {
        BUCKET_NAME: dataBucket.bucketName,
      },
    });

    // CDKの grant メソッドでIAM権限を自動設定
    // Terraformでは手動でIAMポリシーを記述する必要がある
    dataBucket.grantRead(processor);

    // 出力
    new cdk.CfnOutput(this, "BucketName", { value: dataBucket.bucketName });
    new cdk.CfnOutput(this, "LambdaArn", { value: processor.functionArn });
  }
}

AWS CDKの特徴:

dataBucket.grantRead(processor) のように、IAM権限を1行で安全に設定できる（Terraformでは10行以上のIAMポリシー記述が必要）
**L1（低レベル）/L2（高レベル）/L3（パターン）**の3層コンストラクトで抽象度を選択可能
2026年3月にGA（一般提供開始）したCDK Mixinsにより、.with()構文で暗号化・削除保護等を横断的に適用できる
状態管理はCloudFormationに委任されるため、S3バックエンドの設定が不要

なぜAWS専用なのか:

CloudFormationとの密結合により、新しいAWSサービスのリリース当日にCDKサポートが提供される
AWS Well-Architectedフレームワークのベストプラクティスがデフォルトで組み込まれている
一方で、Azure・GCPのリソースは管理できないため、マルチクラウド環境には不向き

注意: AWS CDKは内部でCloudFormationを使用しており、1スタックあたり500リソースの制限があります。大規模インフラではスタック分割の設計が必要です。

3ツールのコード比較まとめ

同じリソース（S3 + Lambda）の定義を比較すると、設計思想の違いが明確になります。

比較項目	Terraform	Pulumi	AWS CDK
言語	HCL	Python（上記例）	TypeScript（上記例）
コード行数（上記例）	約60行	約50行	約35行
IAM設定	手動でポリシーJSON記述	手動でポリシーJSON記述	`grantRead()`で自動生成
暗号化設定	明示的に設定	明示的に設定	L2コンストラクトでデフォルト適用
型安全性	HCLの型システム（限定的）	言語ネイティブ（完全）	言語ネイティブ（完全）
テスト	`terraform test`（HCL内）	pytest / Jest 等	Jest / pytest 等

状態管理とドリフト検出を実装する

IaCツールにおける状態管理（State Management）は、「コードで定義したインフラ」と「実際にクラウド上に存在するインフラ」の対応関係を追跡する仕組みです。MLの文脈で言えば、「モデルの重みファイル」に相当するもので、これを失うと再構築が困難になります。

各ツールの状態管理アーキテクチャ

Terraform: リモートバックエンド方式

Terraformの状態ファイル（.tfstate）はJSON形式で、リソースのID・属性・メタデータをすべて保持します。

# backend.tf - Terraform 1.10+推奨設定
terraform {
  backend "s3" {
    bucket       = "my-terraform-state"
    key          = "prod/terraform.tfstate"
    region       = "ap-northeast-1"
    encrypt      = true
    use_lockfile = true  # Terraform 1.10+: S3ネイティブロック
    # dynamodb_table は非推奨（Terraform 1.10+）
  }
}

Terraform 1.10の重要な変更: 状態ロックがS3ネイティブロック（use_lockfile = true）に移行し、DynamoDBテーブルが非推奨になりました。これにより、DynamoDBの追加コストとプロビジョニングが不要になっています。詳細は公式ドキュメントを参照してください。

よくある失敗: 状態ファイルをGitにコミットしてしまうケースがあります。状態ファイルにはリソースIDやARNが含まれるため、絶対にGitリポジトリにコミットしてはいけません。.gitignoreに*.tfstateを追加するのはIaCプロジェクト開始時の必須作業です。

Pulumi: デフォルト暗号化方式

Pulumiの状態管理はPulumi Cloud（SaaS）またはセルフホスト（S3、Azure Blob等）を選択できます。

# Pulumi.yaml での設定例
# name: my-infra
# runtime: python
# backend:
#   url: s3://my-pulumi-state?region=ap-northeast-1

# Pulumiではシークレットがデフォルトで暗号化される
import pulumi

config = pulumi.Config()
# get_secret() で取得した値は自動的に暗号化されて状態ファイルに保存
db_password = config.require_secret("dbPassword")

Pulumiの差別化ポイント: シークレット（パスワード、APIキー等）がデフォルトで暗号化されて状態に保存されます。Terraformでは状態ファイル内のシークレットが平文で保存されるため、S3のサーバーサイド暗号化（SSE-KMS）で補完する必要があります。

AWS CDK: CloudFormation委任方式

AWS CDKは状態管理をCloudFormationに完全に委任します。開発者が状態ファイルを直接管理する必要はありません。

# CDKのデプロイフロー
cdk synth    # TypeScript → CloudFormationテンプレート（JSON）に変換
cdk diff     # 現在のスタックとの差分表示
cdk deploy   # CloudFormation経由でデプロイ

制約条件: CloudFormationスタックの500リソース制限があるため、大規模インフラではスタックをネスト（入れ子）にするか、複数スタックに分割する設計が必要です。このアプローチはスタックあたり1,000リソースを推奨するTerraformと比べて制約が厳しく、設計段階でのリソース配置計画が求められます。

ドリフト検出の比較

ドリフトとは、IaCコードと実際のインフラ状態が乖離することです。例えば、誰かがAWSコンソールから手動でセキュリティグループのルールを変更した場合に発生します。

機能	Terraform	Pulumi	AWS CDK
ドリフト検出方法	`terraform plan`	`pulumi preview`	`cdk diff` + AWS Config
自動検出	HCP Terraform（有料）	Pulumi Cloud（有料）	AWS Config（別サービス）
検出精度	リソース属性レベル	リソース属性レベル	CloudFormation依存（制限あり）
修復	`terraform apply`	`pulumi up`	`cdk deploy`（再合成）

注意: 3ツールとも基本的なドリフト検出はplan/preview/diffコマンドで無料で利用可能です。自動定期検出は有料プランまたは別サービスが必要です。

2026年の最新機能を把握する

2026年に入り、3ツールそれぞれで注目すべきアップデートがありました。

Terraform: MCP統合とProject Infragraph

Terraform 1.11/1.12では、Model Context Protocol（MCP）サーバー統合が導入されました。これにより、AIエージェントがTerraformの操作（plan、apply、state確認）を直接実行できるようになります。また、Project Infragraphにより、複数のTerraform構成を1つの依存関係グラフとして可視化・管理できる機能が追加されています。

# Terraform MCP統合の概念的な使い方
# AIエージェント → MCPサーバー → terraform plan/apply

# Terraform Stacks: 複数構成の統合管理
# deployments.tfdeploy.hcl
deployment "production" {
  inputs = {
    region      = "ap-northeast-1"
    environment = "prod"
  }
}

一方で、HashiCorpはCDKtf（CDK for Terraform）を廃止しました。5年間の開発を経て、HCLと汎用プログラミング言語の統合が技術的に困難であると判断した結果です。これは公式ブログでも言及されており、「HCLとプログラミング言語のギャップは根本的なもの」という見解が示されています。

Pulumi Neo: AI駆動のインフラ管理

Pulumi Neoは、Pulumiが提供するAI支援インフラ管理エージェントです。自然言語でインフラ操作を指示でき、既存のポリシー・ガバナンスルールを自動的に遵守します。

Pulumi Neoの動作モード:

モード	説明	用途
Review	すべての操作に承認が必要	本番環境
Balanced	デプロイのみ承認が必要	ステージング環境
Auto	完全自律実行	開発環境

Werner Enterprisesの事例では、Pulumi Neoの導入によりインフラプロビジョニング時間を3日から4時間に短縮しつつ、SOC 2コンプライアンスを維持したとPulumiの公式ブログで報告されています。

制約条件: Pulumi Neoは現時点でPulumi Cloudの有料プラン契約が必要であり、セルフホスト環境では利用できません。また、AIエージェントの判断を無条件に信頼するのはリスクがあるため、本番環境ではReviewモードの使用が推奨されます。

AWS CDK Mixins: コンポーザブルな抽象化

2026年3月にGA（一般提供開始）したCDK Mixinsは、既存のコンストラクトに機能を後付けで追加できる仕組みです。

// CDK Mixins の使用例（2026年3月 GA）
import * as s3 from "aws-cdk-lib/aws-s3";

// 既存のL1/L2コンストラクトに .with() で機能を追加
const bucket = new s3.Bucket(this, "MyBucket")
  .with(s3.AutoDelete())       // スタック削除時に自動削除
  .with(s3.Encryption.KMS())   // KMS暗号化
  .with(s3.Versioning())       // バージョニング
  .with(s3.BlockPublicAccess.BLOCK_ALL);  // 公開アクセスブロック

Mixinsが解決する課題: 従来のCDKでは、暗号化やロギングといった横断的関心事（Cross-Cutting Concerns）を適用するには、カスタムコンストラクトを作成するか、各リソース定義に個別にプロパティを設定する必要がありました。MixinsによりPythonのデコレータ、あるいはMLのコールバック関数のように機能を合成できるようになっています。

その他の2026年CDK更新として、EKS v2 L2コンストラクト（Access Entry認証対応）、Bedrock統合（基盤モデルのIaC管理）、合成エンジンの高速化（大規模スタックの合成が数分→数秒に短縮）があります。

OpenTofuとライセンス問題を理解する

IaCツールの選定において、2026年現在はライセンスが見過ごせない判断要素になっています。

BSL 1.1とMPL 2.0の違い

2023年8月、HashiCorpはTerraformのライセンスをMPL 2.0（オープンソース）からBSL 1.1（ソース公開）に変更しました。これを受けて、Linux Foundation/CNCF傘下でOpenTofuがフォーク（分岐）されました。

項目	Terraform（BSL 1.1）	OpenTofu（MPL 2.0）
ライセンス	ソース公開（OSIオープンソースではない）	オープンソース（OSI認定）
商用利用	自社インフラ管理はOK。競合製品構築は制限あり	制限なし
ガバナンス	IBM/HashiCorpの企業主導	Linux Foundation/CNCFの中立的ガバナンス
プロバイダー数	4,800+	4,200+（Terraform Registryと互換）
最新バージョン	1.11/1.12	1.11
独自機能	MCP統合、Infragraph、Stacks	ネイティブ状態暗号化、動的バックエンド、プロバイダーモック

2025年のPulumi調査によると、41%のプラットフォームエンジニアがIaCツールのライセンス不確実性をツールチェーン計画のトップ3リスクとして挙げています。

よくある間違い: 「OpenTofuはTerraformの完全な互換品」と考えるのは危険です。OpenTofu 1.7以降で状態暗号化を適用した場合、Terraformへの逆移行が困難になります。暗号化された状態ファイルはTerraformで読み取れないため、手動でのデマイグレーションが必要です。ツール選定は「片道切符」になり得る点に注意してください。

チームと組織に合った選定基準を策定する

ここまでの技術的な比較を踏まえ、実際の選定で考慮すべき判断軸を整理します。

5つの選定軸

選定軸	Terraform向き	Pulumi向き	AWS CDK向き
クラウド戦略	マルチクラウド / ハイブリッド	マルチクラウド / ハイブリッド	AWS専用
チームスキル	インフラ専任チームあり	開発者主導のDevOps	AWS経験豊富なチーム
既存資産	Terraform moduleが多数	Python/TS資産が多い	CloudFormation資産あり
ガバナンス要件	Sentinel / OPA連携	CrossGuard / OPA連携	AWS Config / Security Hub
ライセンス要件	BSL許容 or OpenTofu移行	Apache 2.0（制約なし）	Apache 2.0（制約なし）

組織規模別の推奨パターン

スタートアップ（〜50名）:

推奨: Pulumi（TypeScript） or AWS CDK
理由: 少人数チームではインフラ専任者がおらず、開発者が兼務するケースが多い。既知の言語でIaCを書ける方が学習コストを抑えられる

中規模企業（50〜500名）:

推奨: Terraform + モジュール共有基盤 or Pulumi + コンポーネント共有
理由: チーム間でインフラパターンを標準化・共有する仕組みが重要になる。Terraformのモジュールレジストリ or Pulumiの多言語コンポーネント機能が有効

エンタープライズ（500名〜）:

推奨: Terraform / OpenTofu（ガバナンス・監査重視） + 一部チームでPulumi / CDK
理由: BSL 1.1ライセンスへの法務対応が必要。大規模組織ではOpenTofuへの移行やライセンス精査が進んでいる。Boeing、Capital One、AMD等の大企業がOpenTofuを採用

よくある問題と解決方法

問題	原因	解決方法
`terraform plan`が遅い（数分以上）	状態ファイルが肥大化（1,000+リソース）	ステートを環境・ドメイン別に分割
Pulumi `up`でタイムアウト	クラウドAPIのレート制限	`--parallel`フラグの値を下げる（デフォルト10→5）
CDK `synth`でリソース上限エラー	1スタック500リソース超過	ネストスタックまたはスタック分割
状態ファイルの競合（ロック失敗）	複数人が同時に`apply`	CI/CDパイプラインでの直列実行を強制
ドリフト検出で差分が大量に出る	手動変更が蓄積	コンソール操作禁止ポリシー + 定期的な`plan`実行

まとめと次のステップ

まとめ:

Terraform: 最大のエコシステム（4,800+プロバイダー）とマルチクラウド対応が強み。HCLの学習コストとBSL 1.1ライセンスがトレードオフ
Pulumi: 汎用言語によるIaCで開発者体験を重視。デフォルト暗号化とPulumi Neoが差別化要因。プロバイダー数はTerraformの約3%
AWS CDK: AWS専用だがL2コンストラクトの生産性とgrantメソッドのIAM自動設定が強力。CloudFormationの500リソース制限に注意
OpenTofu: Terraformのオープンソースフォーク。ライセンスの自由度とネイティブ状態暗号化が利点。ただしTerraformとの互換性は徐々に分岐中
ライセンス問題: 41%のプラットフォームエンジニアがIaCツールのライセンスをトップ3リスクと認識。長期的なツール選定ではライセンス条項の精査が必須

次にやるべきこと:

チームのクラウド戦略（マルチクラウド or AWS専用）を確認し、候補ツールを2つに絞る
小規模なPoCプロジェクト（S3 + Lambda程度）で候補ツールを実際に試し、チームの開発体験を比較する
状態管理の設計（バックエンド選定、暗号化、ロック方式）を早期に決定し、ドキュメント化する

関連記事: マルチクラウド戦略の設計パターンについては、Crossplane・Terraform・SPIFFEで設計するマルチクラウド・ハイブリッドクラウド戦略の実践ガイドも参考にしてください。

参考

注意: この記事はAI（Claude Code）により自動生成されました。内容の正確性については複数の情報源で検証していますが、実際の利用時は公式ドキュメントもご確認ください。