CDK vs Terraform vs CloudFormation｜インフラエンジニア目線の比較ガイド

# はじめに

こんにちは、博報堂テクノロジーズ・インフラ開発一部の近藤です。
本記事は、AWSにおけるIaCツールとして、CDK・Terraform・CloudFormation(以降、CFn)のどれを選択すべきか、実際の使用経験をもとに検討し、その内容を備忘録として記事にまとめました。

IaCツールの比較記事は数多く存在しますが、本記事ではインフラエンジニアの視点から、ツール選択の軸をまとめています。

**この内容は個人の見解に基づくものですので、こういった比較項目もあるんだな、というレベルで、あくまでIaCツール選定の際の参考情報としてお役立てください**。

# サマリ

結論、私個人としては、比較軸の評価に加え、所属チームがインフラチームであることや複数クラウドを組み合わせて使っているという現在の状況を加味し、**Terraformを選択しています**。

このようなツールは、案件や扱うチームごとに統一した方が認知負荷を減らし人員の流動性も高められます。ある担当者がA案件からB案件に変わった際、使用しているツールが変わると、その分学習が発生するためです。このため、**チームや組織の状況・習熟度・知識に合わせたツール選定が望ましいと考えています**。例えば、アプリケーション開発の知識が豊富なエンジニアが多数在籍している場合はCDKとの親和性が高く、既存の複数案件でCFnを利用している場合はCFnを採用すべき、といった具合です。

これからご紹介する比較に加え、このような環境要因を総合的に検討した上で、判断することをお勧めします。

# 比較結果

インフラエンジニアの視点から、各ツールの実務での扱いやすさについて比較を行いました。具体的には、開発の俊敏性と正確性、そしてメンテナンス性という観点から比較軸を設定し、評価を実施しました。

| **比較項目** | **優位** | **CDK** | **Terraform** | **CFn** |
| --- | :-: | :-: | :-: | :-: |
| 学習容易性 | CFn<br>Terraform  | 比較的高め | 比較的低め | 比較的低め |
| コード量・可読性 | CDK | 少～中・高 | 多・中 | 多・中 |
| ツール管理 | CFn | 必要 | 必要 | 不要 |
| トラブルシュート | Terraform | 環境に依る | やりやすい | 環境に依る |
| 手動インポート | Terraform | 事前定義 | importBlock活用で<br>事前定義不要 | 事前定義 |
| セキュリティ管理 | 同点| IAMロール | 実行環境による | IAMロール |
| 汎用性 | CDK<br>Terraform | 様々 | 様々 | AWSのみ |

繰り返しになりますが、これらの評価は個人的な見解であり、気になる観点については、ご自身で詳しく調査・確認されることをお勧めします。

以降、比較軸の詳細を記載します。

## 学習のしやすさ

IaCツールを選定する際には、通常、プロジェクトなど具体的な適用対象が既に決まっています。このような状況では期限が設定されているため、学習に多くの時間を費やすことができないケースがほとんどだと考えています。そのため、学習のしやすさを評価基準として設定しました。

### CDK

- CDKはTypeScriptやPythonといったプログラミング言語の知識が前提となるため、インフラエンジニアにとっては学習コストが比較的高め。

### Terraform

- HCLはTerraform独自の記述形式ですが、YAML形式に近い構造のため、比較的学習コストが低く、インフラエンジニアにとって直感的に理解しやすい。

### CFn

- YAMLまたはJSONで記述するため学習コストが低く、インフラエンジニアにとって直感的に理解しやすい。

## コード量

通常、IaC化はリソースやサービスの部分だけでなく、環境全体を対象とすることも多々あります。そのため、複数のサービスやリソースを効率的に管理するには、コード量をいかに最適化できるかが重要な観点と考えています。

### CDK

- コンストラクタでリソースを定義できるため、抽象化された簡潔な記述が可能。そのため、一見すると可読性は高いが、抽象化された部分の詳細を理解するにはドキュメント等の参照が必要となり、慣れが必要。

### Terraform

- HCL（YAML形式に似た構文）での記述となるため、コード量は多くなりがち。ただし、モジュールを活用することで効率的にコード量を削減できる。

### CFn

- 宣言的な記述方式を採用しており、コード量は他のツールと比べて多くなる傾向にある。

## ツール管理

IaCツールは一度限りのものではなく、ツール自体のバグ修正の適用やバージョンアップなど、継続的なメンテナンスが必要です。このため、メンテナンスのしやすさという観点からツール管理を評価項目として設定しています。

### CDK

- CDKでコーディングする言語のランタイム環境（Node.js等）のバージョン管理とCDK自体のバージョン管理が必要。ただし、LTSバージョンを利用することで、頻繁な更新は不要。

### Terraform

- 独立したバイナリとして動作するため、CDKのようなランタイムの考慮は不要ですがTerraform自体のバージョン管理が必要。プロバイダーのバージョンはコード内で指定するため、定期的なバージョンアップの検討が必要。

### CFn

- AWSのマネージドサービスのため、バージョン管理は不要。

## トラブルシュート

リソース展開時の問題発生時、トラブルシュートのしやすさは開発スピードや工数に直接影響します。また、トラブルシュートがしやすい環境では精神的な負荷が軽減されるため、健全な業務遂行において重要な要素と考えています。

### CDK

- CDKはバックグラウンドでCFnが動作していることもあり、エラーメッセージの解読には少し工夫が必要な理解(CDKの問題か、CFnの問題か)。規模が拡大し、リソース間の関連性が複雑になった時に備え、トラブルシュートの方法を確立した方が良いと思慮。

### Terraform

- 比較的トラブルシュートが容易な印象。

### CFn

- 過去経験上、小規模環境ではトラブルシュートが得意な印象。

## 手動作成リソースのインポート

必ずしもプロジェクト開始時からIaC化できるケースでは無い事や、緊急対応として手動でリソースを作成することもあると思います。そのため、手動作成したリソースのインポートのしやすさは、運用面で影響を与える要素となるため、重要な軸と考え設定しています。

### CDK

- リソースの事前定義が必要。

### Terraform

- importブロック機能※で事前定義不要。    
    ※：バージョン1.5以上で利用可能
    https://developer.hashicorp.com/terraform/language/v1.5.x/import
    

### CFn

- リソースの事前定義が必要。

## セキュリティ管理

AWSでのIaCデプロイ時はIAM権限が必要です。各ツールの権限設定方法とクレデンシャル漏洩リスクの観点から比較を行います。

### CDK

- CDK管理（CDK bootstrapで作成）のIAMロールで実行するため、実行時IAMユーザーのクレデンシャル漏洩リスクは無い。

### Terraform

- Terraformの実行環境にIAMクレデンシャルの設定が必要ですが、実行方法により対策可能。ただし、state fileの管理には注意が必要。

### CFn

- AWSネイティブのサービスであり、実行時にIAMロールを指定して使用するため、IAMユーザーのクレデンシャル漏洩リスクは無い。

# 汎用性

IaCの普及に伴い、マルチクラウドの利用が広がっていく可能性があります。その際、異なるクラウド環境への横展開のしやすさは重要なポイントとなるため、汎用性の観点から比較を行いました。

### CDK

- 基本はAWS。ただ、CDK for Terraformなどで他のパブリッククラウドにも展開可能。

### Terraform

- GCP、Azure等の他クラウドにも対応。

### CFn

- AWSのみ対応。

# まとめ

**IaCツールの選択は、単にツールを選ぶという枠組みのみならず、チームや組織の生産性に大きく影響すると考えています**。Terraformは豊富な情報とマルチクラウド対応で柔軟性が高く、CDKはアプリケーション開発者との親和性、CFnはAWSネイティブな機能で手軽に始められるなど、それぞれに特徴があります。**チーム・組織の状況に応じたツールを選ぶことが、持続的な成長に繋がると考えています**。