Terraform
公式サイト：https://www.terraform.io/
汎用的な IaC ツールとして広く使われているものになります。特徴的なのは、AWS のみならず様々なクラウドベンダーや SaaS に対応している点です。SaaS に関しても、例えば Auth0 の設定等に関してもコード管理が可能です（参考：https://registry.terraform.io/providers/auth0/auth0/latest/docs ）
一度構築した構成が壊れたり、バージョンアップによる破壊的変更・仕様変更が少ないことも特徴です。安定性に関しては上記挙げている項目の中では最も優れており、インフラ構成が複雑になればなるほど力を発揮します。「モジュール」という機能があり、再利用性に優れ、拡張・管理しやすいです。
一方、設定項目が細かく、Serverless Framework に比べると慣れるまでは作業工数が増えることが想定されます。CloudFormation ベースではないのと、Terraform オリジナルの構文を学習する必要がある点も考慮が必要です。
AWS CDK
公式サイト：https://docs.aws.amazon.com/ja_jp/cdk/v2/guide/home.html
日本では AWS コミュニティを中心に近年かなり人気が出ている IaC になります。仕組み自体は Serverles Framework と似ており、serverless.yml に記載した内容がデプロイ時に CloudFormation のテンプレートに変換されスタックが作成されるように、AWS CDK はプログラミングコード（※TypeScript, Python, Java など様々）で記述したインフラ定義が CloudFormation テンプレートに変換されスタックが作成されます。
慣れ親しんだプログラミング言語でインフラが定義できるので柔軟性があり、ソースコードのパッケージ作成（特に Docker を利用した Container Image 作成など）も非常にシンプルな記述で容易に対応できます。特に TypeScript を利用すれば、型定義を活用してドキュメントをあまり見ずともインフラを作っていくことが可能で慣れれば IaC 開発経験は非常に良いです。
一方、便利さを求めて抽象度合いの高い機能（L3コンストラクタ）を利用すると構築は容易にできても運用や拡張で難が生じたり、バージョンアップが非常に頻繁に行われるためトラブルシュートに時間を取られることもしばしばあります。 抽象度合いを下げた記述方法では CloudFormation テンプレートとさほど変わらないため、全体的なインフラ構成の複雑度が上がるほど苦労することが多いです。
AWS SAM
サーバーレス構成をメインとする構成であれば、基本的には AWS では SAM を使うことが推奨されています。実態としては CloudFormation の拡張で、素の CloudFormation を利用する際に定義しづらかったり機能としてサポートして欲しい部分（Lambda のパッケージ作成や複雑難解な API Gateway 定義）をシンプルな記載で解決してくれることが特徴です。
CloudFormation に近い構造である点、また Lambda および API Gateway のローカル起動などが標準でサポートされていることから、CloudFormation になれていれば無難な選択肢となります。
一方で、インフラ構成が複雑になる程 CloudFormation のメンテナンスが大変になったり、サーバーレス関連のリソースを除けば素の CloudFormation を扱うのとあまり変わらないため、他のツールと比べて生産性の観点では慎重になる必要があると考えます。
Pros & Cons
以下項目における観点での評価を記載しました。
項目 | Terraform | AWS CDK | AWS SAM |
|---|---|---|---|
学習コスト | 【◯】低いが、慣れるまで多少の時間が必要 | 【◎】最も低い。別途構文を覚える必要がない。 | 【△】CloudFormation を理解する必要がある |
汎用性 | 【◎】AWS だけでなく様々なクラウドベンダーと SaaS に対応 | 【◯】AWS限定だが、スクリプトコードを書いてAWS外のリソースもデプロイサイクルに合わせて管理が可能 | 【△】AWSに限定（AWS外のリソースを対応したい場合、Shell Script などを書いて対応） |
IaC 開発経験 | 【◯】やりたいことは調べればほとんど見つかるので、基本的になんでもできる。モジュール機能があり、一度リソースを作成すれば使い回しが効きやすい。ただし、サーバーレス関連リソースに関しては他に比べて良いとは言えない。 | 【◎】最も良い。型定義や型注釈を活用すればスピーディーにインフラ構築ができる。やりたいことを実現したい時の初速も最も早い。 | 【◯】通常のサーバーレススタックであれば無難かつローカル起動などの機能も活用でき、開発経験は良い。 |
安定性 | 【◎】仕様変更が少なく、一度書いたコードの寿命が非常に長い | 【△】バージョンアップに伴う破壊的変更がまれにあり、また新しい機能がどんどんリリースされるが、CloudFormation と CDK 由来の両方のトラブルシューティングが必要になる場面が多々ある | 【◎】AWS 標準であるため安定性に優れ、仕様変更が少ない。 |
複雑な構成への対応 | 【◎】モジュール機能が優秀で再利用性が高く、構成が複雑になる程力を発揮する | 【△】シンプルな構成ほど長所が生きやすく、複雑になる程薄れる傾向がある | 【△】シンプルな構成ほど長所が生きやすく、複雑になる程薄れる傾向がある |
既存リソースのインポート機能 | 【◯】あり | 【◯】あり | 【◯】あり |
サーバーレス構成との相性 | 【△】基本設定項目が細かく便宜を図ってくれる抽象的な機能はないため、サーバーレスとの相性は良いとは言えない。パッケージ作成機能もないので自分で構成する必要がある。 | 【◎】非常に簡単かつスピーディーに構築できる。考慮事項が最も少ない。 | 【◯】無難。最小構成でない場合、素のCloudFormation と付き合わなければならないという点が悩ましいが、全体的に相性は非常に良い。 |
その他、生産性・利用シェア・参考情報量に関しては特筆すべき差分はないと考えたため、上記評価項目には含めていません。