IaCを選定すると大抵Terraformになるのだが、その理由を言語化してまとめておく。
なお比較のために他のIaCを挙げているが、それらを批判する意図はない。

宣言的に記述できる

手続き的ではなく、宣言的に記述できることが特徴である。
このため記述が多様化しづらく、少ないルールで統一感を持たせることができる。
これはアプリケーションフレームワークを使うことで実装方法が定まり、統一感が持たせられることに似ている。
例えばAWS CDKは手続き的に記述できるため関数やデータを柔軟に定義が可能であるが、逆に言えば記述が多様化しやすいということでもある。
AWS CDKは条件分岐も記述できるため、ロジックの組み方によってはIaCのテストコードが必要となる場合もあるだろう。

また宣言的であることは、テストコードが不要になるということでもある。
テストコードによってプロダクトコードをテストするのは「手続き的に記述されたプロダクトコードに対して、宣言的に記述されたコードでテストするため」であり、 もしプロダクトコードが宣言的に記述されていたらテストコードを書く意味はない。
もちろんテスト自体は必要だし、Terraformにもバグは有り得るし、不適切な記述をすると意図しない動作をすることはあるので注意は必要。

その他、宣言的な記述のおかげで学習コストも低い。
例えば「PCの仕様を記述する」のは宣言的な記述の一例で、PCの仕様さえ知っていればあとは文法に則って記述するだけだ。
もし「Terraformが難しい」と感じるのであれば、それは「Terraformが分からない」のではなく「Terraformで操作しようとしている対象サービス（例えばAWS）が分かっていない」ということだろう。

冪等性がある

冪等性があるので、実行手順などを考える必要がない。
エラーの際には再実行を試みればよいし、ロールバックの際には以前のバージョンのコードでapplyを実行すればよい。
依存関係や必要な手続きはすべて自動的に組み立ててくれるので、非常に扱いやすい。

ただし明示的に依存関係を指定しないとエラーになる場合もあるし、複数回applyしたのをまとめてapplyしようとするとエラーになることもあり得るので、過信は禁物。
変更内容をこまめにapplyしていくことも重要で、このあたりはプロダクトコードのリリースにも通ずるものがある。

様々なTerraform Providerが提供されている

Terraformでは様々なTerraform Providerが用意されており、以下のような特徴がある。

• AWS・Azure・GCPのマルチクラウドに対応
• DatadogやGitHubなどのサービスにも対応
• AWSにもawsとawsccというproviderがあり、どちらも利用できる

特に複数のサービスを扱う際に手作業を挟むとミスの原因となるため、サービス間を跨いで記述できるのは大きなメリット。
例えばGitHubのProviderを使えば「GitHub ActionsのIPリストを取得して、AWSのWAFにIPリスト設定する」こともできる。
AWSのIaCにはCloudFormation, SAM, AWS CDKなどがあるが、これらはもちろんAWSのサービス内しか扱うことはできない。

GitHub Providerを使ってGitHub ActionsのIPリストを取得する方法については、こちらを参照