AWS の IaC 成熟度 - CloudFormation・CDK・SAM が築く宣言的インフラ管理の優位性
CloudFormation、CDK、SAM を中心とする AWS の Infrastructure as Code エコシステムの成熟度を、Azure ARM/Bicep や GCP Deployment Manager と比較し、多言語対応の CDK がもたらす開発体験の差を解説します。
IaC はクラウド運用の成熟度を測る指標である
Infrastructure as Code (IaC) は、クラウドインフラの構成をコードとして管理する手法です。手動でコンソールからリソースを作成する運用は、環境の再現性が低く、変更履歴の追跡も困難です。IaC を導入することで、インフラの構成がバージョン管理され、レビュー可能になり、テスト可能になります。クラウドプロバイダーの IaC ツールの成熟度は、そのプラットフォーム上での運用品質に直結します。AWS は 2011 年に CloudFormation をリリースして以来、10 年以上にわたって IaC エコシステムを拡充してきました。CloudFormation を基盤として、SAM によるサーバーレス特化の抽象化、CDK によるプログラミング言語での定義という 3 層構造を構築しています。この重層的なアプローチが、他社にない柔軟性と成熟度を生んでいます。
CloudFormation - AWS IaC の基盤
CloudFormation は AWS のネイティブ IaC サービスであり、JSON または YAML でインフラリソースを宣言的に定義します。2025 年時点で 800 以上のリソースタイプをサポートしており、AWS の新サービスがリリースされると速やかに CloudFormation 対応が追加されます。CloudFormation の強みは、スタックという単位でリソースのライフサイクルを一元管理できる点です。スタックの作成・更新・削除が原子的に実行され、更新失敗時には自動ロールバックが行われます。変更セット (Change Set) 機能により、実際の変更を適用する前に影響範囲をプレビューできます。ドリフト検出機能は、手動変更によるコードと実態の乖離を検知します。StackSets を使えば、複数アカウント・複数リージョンへの一括デプロイも可能です。これらの機能が長年の運用フィードバックを経て洗練されている点が、CloudFormation の成熟度を示しています。
CDK の多言語対応がもたらす開発体験の革新
AWS CDK (Cloud Development Kit) は 2019 年に GA となった、プログラミング言語でインフラを定義するフレームワークです。TypeScript、Python、Java、C#、Go の 5 言語に対応しており、開発者が使い慣れた言語でインフラを記述できます。CDK の本質的な価値は、プログラミング言語の表現力をインフラ定義に持ち込める点にあります。条件分岐、ループ、関数による抽象化、型システムによる静的検証、IDE の補完機能やリファクタリング支援をインフラコードに適用できます。L1 コンストラクト (CloudFormation リソースの 1 対 1 マッピング)、L2 コンストラクト (ベストプラクティスを組み込んだ高レベル抽象化)、L3 コンストラクト (複数リソースのパターン) という 3 層の抽象化レベルにより、初心者から上級者まで適切な粒度でインフラを定義できます。Construct Hub にはコミュニティが公開した再利用可能なコンストラクトが集積されており、エコシステムの広がりも加速しています。
Azure ARM テンプレートと Bicep との比較
Azure の IaC は、ARM (Azure Resource Manager) テンプレートを基盤としています。ARM テンプレートは JSON 形式で記述しますが、冗長な構文が開発者から批判を受けてきました。この課題に対応するため、Microsoft は 2021 年に Bicep を GA としました。Bicep は ARM テンプレートにトランスパイルされる DSL (ドメイン固有言語) であり、簡潔な構文でリソースを定義できます。Bicep の構文は CloudFormation の YAML よりも簡潔で読みやすいという評価もあります。しかし、Bicep はあくまで DSL であり、CDK のような汎用プログラミング言語の表現力は持ちません。条件分岐やループは限定的にサポートされていますが、関数による抽象化やオブジェクト指向的な設計パターンの適用は困難です。Azure にも CDK for Terraform (CDKTF) 経由で CDK 的なアプローチを適用できますが、Azure ネイティブの CDK 相当ツールは存在しません。また、ARM テンプレートのドリフト検出機能は CloudFormation ほど成熟しておらず、変更セットに相当する What-If 機能も 2020 年に追加されたばかりです。
GCP Deployment Manager と Terraform の位置づけ
GCP のネイティブ IaC ツールは Deployment Manager ですが、Google 自身が Terraform の利用を推奨する方向にシフトしています。Deployment Manager は YAML と Jinja2 / Python テンプレートで構成を定義しますが、サポートされるリソースタイプの網羅性や更新頻度で CloudFormation に劣ります。新しい GCP サービスの Deployment Manager 対応が遅れるケースも報告されています。Google は 2023 年に Infrastructure Manager をプレビューとして発表しました。これは Terraform をバックエンドとして使用するマネージドサービスであり、GCP が Terraform エコシステムに寄せていく戦略を明確にしています。Terraform は優れたマルチクラウド IaC ツールですが、プロバイダー固有の機能への対応速度では、ネイティブツールに劣る場合があります。AWS においても Terraform は広く利用されていますが、CloudFormation と CDK のネイティブ統合 (変更セット、ドリフト検出、StackSets) に相当する機能は Terraform Cloud / Enterprise の有償機能に依存する部分があります。
SAM によるサーバーレス IaC の特化
AWS SAM (Serverless Application Model) は、CloudFormation の拡張としてサーバーレスアプリケーションの定義を簡潔にするフレームワークです。Lambda 関数、API Gateway、DynamoDB テーブル、Step Functions ステートマシンといったサーバーレスリソースを、CloudFormation よりも少ない記述量で定義できます。SAM CLI はローカル環境での Lambda 関数の実行、デバッグ、テストをサポートしており、サーバーレス開発のイテレーションを高速化します。sam sync コマンドによるホットデプロイは、コード変更を数秒でクラウド環境に反映します。Azure や GCP にはサーバーレスに特化した IaC フレームワークが存在せず、汎用的な IaC ツールでサーバーレスリソースを定義する必要があります。Serverless Framework のようなサードパーティツールはマルチクラウド対応ですが、AWS ネイティブの SAM ほど深い統合は実現できません。IaC の設計パターンを体系的に学ぶには関連書籍 (Amazon) も参考になります。
まとめ
AWS の IaC エコシステムは、CloudFormation (宣言的定義の基盤)、CDK (プログラミング言語による高レベル抽象化)、SAM (サーバーレス特化) という 3 層構造で構成されています。CloudFormation は 10 年以上の運用実績に裏打ちされた成熟度を持ち、変更セット、ドリフト検出、StackSets といった運用機能が充実しています。CDK の多言語対応は、インフラ定義にプログラミング言語の表現力を持ち込む革新であり、Azure Bicep や GCP Deployment Manager にはない柔軟性を提供します。Azure は Bicep で構文の簡潔さを改善しましたが、汎用言語の表現力には及びません。GCP は Terraform への依存を深めており、ネイティブ IaC の成熟度では AWS に後れを取っています。IaC の選択は運用品質に直結するため、エコシステム全体の成熟度を重視した判断が重要です。