AWS向けIaCプラットフォームの現在地 —2025年版アーキテクチャ選定ガイド

IaCプラットフォームを取り巻く環境の激変

2024年から2025年にかけて、AWS向けIaCプラットフォームは歴史的な転換点を迎えています。これまで「無償で使えて当たり前」だったツールが有償化し、「安定していて変わらない」と思われていた基盤技術が大胆な方向転換を始めました。

特に注目すべきは、Serverless Framework v4の年商ベースでの有償化と、HashiCorpのBUSLライセンス変更に伴うOpenTofuの誕生です。これらの変化は、単にコストや技術の問題ではなく、オープンソースコミュニティのあり方や、企業の技術戦略そのものに影響を与える重要な出来事となっています。

さらに2025年3月10日にIBMによるHashiCorp買収が完了したことで、Terraformエコシステムの将来像もより明確になってきました。一方で、AWS CDKも2025年2月にCLIとConstruct Libraryのリリースサイクル分離を発表し、より柔軟な開発体制への移行を進めています。

こうした激変の中で、私たちエンジニアは改めて「なぜそのツールを選ぶのか」という本質的な問いに向き合う必要があります。単なる機能比較や流行追いではなく、組織の成長戦略やエンジニアリング文化に適合したツール選定が、これまで以上に重要になってきているのです。

Serverless Framework v4 —有償化がもたらす価値の再定義

ライセンス変更の衝撃と実務への影響

Serverless Frameworkは2024年にv4をリリースし、年商200万USD（約3億円）を超える組織に対して有償サブスクリプションを必須としました。これは単なる収益化ではなく、プラットフォームの持続可能性を確保するための戦略的な転換です。

最新バージョンは2025年8月21日リリースのv4.18.1となっており、継続的な更新が行われています。注目すべきは、v4以降で非AWSプロバイダが非推奨となり、事実上AWS専用のフレームワークへと舵を切ったことです。

この決断について、私は「選択と集中」の観点から評価しています。マルチクラウド対応を謳いながら中途半端な機能提供になるよりも、AWS専用として機能を研ぎ澄ますことで、より実践的な価値を提供できるようになったからです。

v4で強化された開発者体験

v4では以下の重要な機能強化が行われています。

Terraformとの連携機能が大幅に強化され、既存のTerraform state出力を変数として参照できるようになりました。

provider:
  environment:
    DATABASE_URL: ${terraform:outputs:database_url}

また、HashiCorp Vaultとの連携により、シークレット管理もより安全になりました。

provider:
  environment:
    API_KEY: ${vault:secret/data/myapp:api_key}

さらに、TypeScriptとesbuildがビルトインサポートされ、設定なしでTypeScriptプロジェクトを開始できるようになったことも大きな進化です。これまでプラグインに頼っていた機能が標準化されることで、プロジェクトの保守性が向上しています。

実践的な採用判断基準

Serverless Framework v4を採用すべきケースとして、以下の条件が揃った場合を推奨します。

まず、組織の年商が200万USD未満、もしくは有償化を受け入れられる予算がある場合です。次に、AWS専用でサーバーレスアーキテクチャを素早く立ち上げたい場合。そして、CI/CDや監視機能を含めた統合的な開発環境を求める場合です。

一方で、避けるべきケースも明確です。マルチクラウド戦略を採用している組織、ライセンスコストに敏感な組織、そして既存の非AWSプロバイダを利用したプロジェクトがある場合は、他の選択肢を検討すべきでしょう。

AWS SAM —AWSネイティブの安定性と進化

ローカル開発機能の充実

AWS SAMの最新CLIバージョンはv1.142.1（2025年7月1日リリース）となっており、ローカル開発支援機能が大幅に強化されています。

特に注目すべきは「sam sync」コマンドの進化です。これにより、ローカルでの変更を素早くクラウド環境に反映できるようになり、開発サイクルが劇的に短縮されました。

# リアルタイムでクラウドに同期
sam sync --watch

また、「sam local start-api」によるローカルHTTPサーバー機能も実用レベルに達しており、Lambda関数のローカルテストが容易になっています。

AWSエコシステムとの深い統合

SAMの最大の強みは、AWSサービスとのネイティブな統合にあります。特にStep Functions、EventBridge、AppSyncなどの比較的新しいサーバーレスサービスとの連携が、他のIaCツールと比較して圧倒的にスムーズです。

例えば、Step Functionsのワークフロー定義をSAMテンプレート内に直接記述でき、Lambda関数と同じようにローカルテストが可能です。

MyStateMachine:
  Type: AWS::Serverless::StateMachine
  Properties:
    DefinitionUri: statemachine/my_state_machine.asl.json
    Role: !GetAtt StatesExecutionRole.Arn
    Events:
      MyApiEvent:
        Type: Api
        Properties:
          Path: /workflow
          Method: post

SAMが輝くユースケース

実務経験から、SAMが特に威力を発揮するのは以下のようなケースです。

AWSの新サービスや新機能をいち早く活用したいプロジェクトでは、SAMのAWSネイティブな性質が大きなアドバンテージとなります。また、AWS CodePipeline、CodeBuild、CodeDeployといったAWSのCI/CDサービスを活用する場合も、SAMとの相性は抜群です。

さらに、エンタープライズ企業でAWSを標準プラットフォームとして採用している場合、SAMの安定性と予測可能性は大きな価値となります。AWSのサポートを受けやすく、長期的なメンテナンスも安心です。

AWS CDK —プログラマブルインフラの新たな地平

CLIとライブラリの分離がもたらす変革

2025年2月に発表されたCDK CLIとConstruct Libraryのリリースサイクル分離は、CDKの歴史において重要な転換点となりました。

これまでCDKは週次リリースを行っており、最新版はv2.212.0（2025年8月20日）となっていますが、頻繁なアップデートが運用上の負担となることもありました。新しいリリース体制では、CLIのバージョンが2.1000.0から始まる新体系に移行し、「CLIのリリース日 ≥ ライブラリのリリース日」という互換性ルールが導入されます。

この変更により、開発チームは必要に応じてライブラリのアップデートタイミングをコントロールできるようになり、より安定した開発環境を維持できるようになります。

Constructパターンによる再利用性の追求

CDKの本質的な価値は、Constructと呼ばれる再利用可能なコンポーネントにあります。L1からL3までの抽象化レベルを使い分けることで、詳細な制御と開発効率のバランスを取ることができます。

import { Stack, StackProps } from 'aws-cdk-lib';
import { Construct } from 'constructs';
import * as lambda from 'aws-cdk-lib/aws-lambda';
import * as apigateway from 'aws-cdk-lib/aws-apigateway';

export class ServerlessApiConstruct extends Construct {
  constructor(scope: Construct, id: string) {
    super(scope, id);

    // L2 Constructを使った簡潔な定義
    const handler = new lambda.Function(this, 'Handler', {
      runtime: lambda.Runtime.NODEJS_20_X,
      code: lambda.Code.fromAsset('lambda'),
      handler: 'index.handler',
    });

    // REST APIの作成
    new apigateway.LambdaRestApi(this, 'Api', {
      handler: handler,
      proxy: false,
    });
  }
}

実際のプロジェクトでは、こうしたConstructを組織内で共有することで、ベストプラクティスの標準化と開発速度の向上を同時に実現できます。

CDKが真価を発揮する組織とは

CDKは、以下のような特徴を持つ組織で特に効果を発揮します。

TypeScriptやPythonなどのプログラミング言語に精通したエンジニアが多い組織では、CDKの表現力を最大限に活用できます。また、マイクロサービスアーキテクチャを採用し、多数の似たようなサービスを管理する必要がある場合、Constructによる標準化が大きな価値となります。

CDK v1は2023年6月1日にサポート終了となっているため、既存プロジェクトがある場合は早急なv2への移行が必要です。

Pulumi —汎用プログラミング言語による統一的なインフラ管理

マルチクラウド時代の現実解

PulumiはNode.js、TypeScript、Python、Go、.NET、Java、YAMLという幅広い言語をサポートしており、開発チームが既に持っているスキルセットを活かせることが大きな特徴です。

特に注目すべきはpulumi convertコマンドの存在です。既存のTerraform、ARM Template、Kubernetes YAMLなどを、Pulumiコードに変換できるため、段階的な移行が可能です。

# Terraformからの変換例
pulumi convert --from terraform --language typescript

Pulumiのアーキテクチャ哲学

Pulumiの設計思想は「インフラストラクチャはソフトウェアである」という考えに基づいています。これは単にコードで書けるということではなく、ソフトウェア開発のベストプラクティス（テスト、リファクタリング、コードレビュー）をインフラ管理にも適用できるということを意味します。

import * as pulumi from "@pulumi/pulumi";
import * as aws from "@pulumi/aws";

// 環境ごとの設定を型安全に管理
interface EnvironmentConfig {
  instanceType: string;
  minSize: number;
  maxSize: number;
}

const configs: Record<string, EnvironmentConfig> = {
  dev: { instanceType: "t3.micro", minSize: 1, maxSize: 2 },
  prod: { instanceType: "t3.large", minSize: 3, maxSize: 10 },
};

const env = pulumi.getStack();
const config = configs[env];

// 型安全なインフラ定義
const autoScalingGroup = new aws.autoscaling.Group("asg", {
  minSize: config.minSize,
  maxSize: config.maxSize,
  // ...
});

Pulumiが解決する実務上の課題

実際のプロジェクトでPulumiが特に有効なのは、以下のような課題を抱えている場合です。

AWS、Azure、GCPを跨いだマルチクラウド環境を統一的に管理する必要がある場合、Pulumiの汎用性が光ります。また、既存のソフトウェアエンジニアリングプラクティス（単体テスト、CI/CD、静的解析）をインフラコードにも適用したい場合も、Pulumiは最適な選択となるでしょう。

Terraform/OpenTofu —エコシステムの分岐と新たな可能性

ライセンス変更がもたらした二つの道

2023年にHashiCorpがTerraformのライセンスをBUSL（Business Source License）に変更したことで、コミュニティは大きな岐路に立たされました。その結果、Linux Foundation配下でOpenTofuプロジェクトが立ち上がり、現在では3,900以上のプロバイダと23,600以上のモジュールを擁する一大エコシステムに成長しています。

2025年3月10日にIBMによるHashiCorp買収が完了したことで、Terraformの将来性についても一定の安心感が生まれました。IBMは製品ラインの継続強化を発表しており、エンタープライズ向けの機能強化が期待されています。

AWS Provider v6の重要な変更点

Terraform AWS Provider v6のGAにより、マルチリージョン対応が大幅に改善されました。これまで課題となっていたリージョン間のリソース依存関係の管理が、より直感的に行えるようになっています。

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 6.0"
    }
  }
}

# マルチリージョン設定の改善例
provider "aws" {
  alias  = "us-east-1"
  region = "us-east-1"
}

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

# リージョン間でのリソース参照が簡潔に
resource "aws_s3_bucket" "primary" {
  provider = aws.us-east-1
  bucket   = "my-primary-bucket"
}

resource "aws_s3_bucket" "replica" {
  provider = aws.ap-northeast-1
  bucket   = "my-replica-bucket"

  # クロスリージョンレプリケーション設定
  replication_configuration {
    role = aws_iam_role.replication.arn
    rules {
      id     = "replicate-all"
      status = "Enabled"

      destination {
        bucket = aws_s3_bucket.primary.arn
        storage_class = "GLACIER"
      }
    }
  }
}

OpenTofuという新たな選択肢

OpenTofuは「Terraformのドロップイン代替」として設計されており、既存のTerraformコードがそのまま動作します。しかし、単なるフォークではなく、コミュニティ主導による独自の進化も始まっています。

OpenTofuを選択する理由として、以下の点が挙げられます。

ライセンスの透明性を重視する組織にとって、OpenTofuのMPL-2.0ライセンスは安心材料となります。また、コミュニティ主導の開発により、ユーザーの要望が反映されやすいという利点もあります。

一方で、IBMのバックアップを受けたTerraformも依然として強力な選択肢です。エンタープライズサポートが必要な場合や、HashiCorpの他製品（Vault、Consul、Nomad）との統合を重視する場合は、Terraformを選ぶべきでしょう。

2025年における実践的な選定フレームワーク

プロジェクト特性による判断マトリクス

ここまで各プラットフォームの特徴を見てきましたが、実際の選定においては、プロジェクトの特性を多角的に評価する必要があります。以下の表は、主要な評価軸での各プラットフォームの適合性を示したものです。

表 IaCプラットフォーム選定マトリクス2025

※年商200万USD超の組織の場合

この表から分かるように、完璧なツールは存在せず、各プラットフォームにはそれぞれトレードオフがあります。重要なのは、自組織の制約条件と優先順位を明確にすることです。

組織の成熟度による段階的アプローチ

IaCプラットフォームの選定は、組織の技術的成熟度によっても変わってきます。私の経験では、以下のような段階的アプローチが効果的です。

スタートアップやPoC段階では、迅速性を重視してServerless FrameworkやSAMから始めることをお勧めします。これらのツールは学習コストが低く、すぐに成果を出せるためです。

成長期に入り、インフラの複雑性が増してきたら、CDKやPulumiへの移行を検討します。この段階では、コードによる抽象化と再利用性が重要になってくるためです。

エンタープライズ段階では、TerraformやOpenTofuのような成熟したエコシステムを持つツールが適しています。豊富なモジュールと実績により、安定した運用が可能になります。

ハイブリッドアプローチの現実性

実は、単一のIaCツールですべてを管理する必要はありません。実際の大規模プロジェクトでは、複数のツールを組み合わせたハイブリッドアプローチが採用されることも多いです。

例えば、以下のような使い分けが考えられます。

基盤となるネットワークやセキュリティ設定はTerraformで管理し、変更頻度が低く安定性を重視します。アプリケーション層のサーバーレスコンポーネントはServerless FrameworkやSAMで管理し、開発速度を優先します。共通コンポーネントやライブラリはCDKのConstructとして開発し、再利用性を高めます。

このアプローチには管理の複雑性というデメリットもありますが、各ツールの強みを最大限に活かせるという大きなメリットがあります。

移行戦略と注意点

Serverless Framework v4への移行における考慮事項

v3からv4への移行は、単なるバージョンアップではありません。非AWSプロバイダの非推奨化により、Azure FunctionsやGoogle Cloud Functionsを使用している場合は、根本的な見直しが必要です。

また、ライセンス適用の判定基準となる「年商200万USD」の計算方法や、「サービスインスタンス」のカウント方法についても、事前に確認しておく必要があります。特に、開発環境と本番環境で別々にカウントされる点は、コスト計算において重要です。

CDKのCLI/Library分離への対応

2025年2月に発表されたCLI/Library分離により、CI/CD環境の設定見直しが必要になります。

これまでのように、CDK全体を一括アップデートするのではなく、CLIとLibraryを個別に管理する必要があります。具体的には、以下のような対応が必要です。

// package.jsonの例
{
  "devDependencies": {
    "aws-cdk": "^2.1000.0",  // CLI（新バージョン体系）
    "aws-cdk-lib": "^2.212.0"  // Library（従来のバージョン体系）
  }
}

CI/CDパイプラインでは、CLIを最新に保ちつつ、Libraryは検証済みのバージョンに固定するという運用が推奨されます。

Terraform/OpenTofu選択の判断基準

TerraformとOpenTofuの選択は、技術的な観点だけでなく、組織のポリシーやコンプライアンス要件も考慮する必要があります。

引用：OpenTofu公式サイト OpenTofuは、Terraformのオープンソースフォークであり、コミュニティ主導で開発されています。MPL-2.0ライセンスの下で提供され、永続的に無償で利用可能です。

ライセンスコンプライアンスが厳格な組織では、OpenTofuの透明性が評価されるでしょう。一方、エンタープライズサポートが必要な場合は、IBMのバックアップを受けたTerraformが安心です。

今後の展望と個人的見解

AIとIaCの融合が生む新たな可能性

2025年以降、生成AIとIaCの融合が加速することは間違いありません。既に、GitHub CopilotがTerraformやCDKのコード生成を支援していますが、これはまだ始まりに過ぎません。

私が特に期待しているのは、自然言語によるインフラ定義です。「東京リージョンに3層アーキテクチャのWebアプリケーション基盤を構築して」という指示から、適切なIaCコードが生成される未来は、そう遠くないでしょう。

ただし、AIが生成したコードを盲目的に信頼することは危険です。セキュリティやコスト最適化の観点から、人間による検証は依然として重要です。AIは効率化のツールであって、責任を代替するものではないということを忘れてはいけません。

プラットフォーム選定における本質的価値

これまで多くのプロジェクトでIaCプラットフォームの選定に関わってきた経験から言えるのは、「完璧なツールは存在しない」ということです。重要なのは、ツールの制約を理解し、それを前提とした設計を行うことです。

例えば、Serverless Frameworkの有償化を「コスト増」と捉えるのではなく、「持続可能な開発への投資」と捉えることもできます。OpenTofuの登場を「分断」と見るのではなく、「選択肢の拡大」と見ることもできます。

技術選定において最も避けるべきは、「流行っているから」「無料だから」といった表面的な理由での決定です。組織の文化、チームのスキルセット、プロジェクトの特性を総合的に評価し、長期的な視点で判断することが重要です。

エンジニアリングチームへの投資の重要性

どのIaCプラットフォームを選んでも、最終的に成功を左右するのは、それを使いこなすエンジニアの力量です。ツールの習得だけでなく、ベストプラクティスの理解、セキュリティへの配慮、コスト最適化の視点など、総合的なスキル向上への投資が不可欠です。

特に、IaCは「書いて終わり」ではありません。継続的なメンテナンス、セキュリティパッチの適用、新機能への対応など、運用フェーズでの取り組みが重要です。この点を軽視すると、技術的負債が蓄積し、将来的な開発速度の低下を招きます。

まとめ —変化を恐れず、本質を見極める

2025年のIaCプラットフォーム選定は、これまで以上に複雑な判断を要求されます。Serverless Frameworkの有償化、CDKのアーキテクチャ変更、Terraform/OpenTofuの分岐など、大きな変化が同時に起きています。

しかし、こうした変化は、各プラットフォームがより明確な方向性を持ち、それぞれの強みを研ぎ澄ましている証でもあります。AWS専用で迅速な開発を求めるならServerless FrameworkやSAM、プログラマブルな抽象化を求めるならCDKやPulumi、成熟したエコシステムを求めるならTerraformやOpenTofuという、より明確な選択基準が生まれています。

最後に強調したいのは、ツールは手段であって目的ではないということです。本当に重要なのは、ビジネス価値を生み出すシステムを、安全に、効率的に、持続可能な形で構築・運用することです。IaCプラットフォームの選定も、この大きな目的に向けた一つのステップに過ぎません。

変化の激しい時代だからこそ、表面的なトレンドに惑わされず、自組織にとっての「本質的な価値」を見極める冷静な判断が求められます。この記事が、そうした判断の一助となれば幸いです。