AWS CloudFormation vs Terraform 徹底比較｜IaCツール選定で失敗しないための実践ガイド

「Infrastructure as Code（IaC）を導入したいけど、AWS CloudFormationとTerraform、どっちを選べばいいんだろう？」

クラウド移行を進めるインフラエンジニアなら、一度はこの問いにぶつかるはずです。オンプレの時代は構成管理といえばAnsibleやChef、Puppetが定番で、選択肢はそこまで複雑ではありませんでした。ところがクラウドの世界では「インフラそのものをコードで定義する」IaCツールが主流になり、その筆頭がAWS CloudFormationとHashiCorp Terraformの2強です。

この記事では、CloudFormationとTerraformの違いを7つの比較ポイントで徹底整理し、実際のコード例やトラブル事例も交えながら、現場でのツール選定に使える判断基準を解説します。「とりあえずTerraformにしておけばいい」「AWSだからCloudFormation一択」という思い込みを捨てて、自分のプロジェクトに本当に合うツールを見極めましょう。

なぜIaCツール選びで迷うのか？

オンプレの世界では、サーバーの構成管理ツールとプロビジョニングツールの役割分担は比較的はっきりしていました。OSのセットアップはKickstartやPXEブート、ミドルウェアの設定はAnsibleやChef、ネットワーク機器はコンソールから手動設定、というのがよくあるパターンです。

ところがクラウドでは話が変わります。VPC、サブネット、セキュリティグループ、EC2、RDS、IAMロール。これらすべてがAPIで作成・変更・削除できるようになったことで、「インフラの全レイヤーをコードで管理する」という発想が生まれました。これがIaC（Infrastructure as Code）です。

迷いが生まれる原因は大きく3つあります。

・AWSネイティブ vs サードパーティ: AWS純正のCloudFormationと、HashiCorp製のTerraformではサポート範囲や思想が違う
・テンプレート言語の違い: YAML/JSONとHCLでは書き心地がまったく異なる
・チームのスキルセットと将来計画: AWS一本で行くのか、マルチクラウドを見据えるのかで最適解が変わる

「どちらが優れているか」ではなく「自分たちのプロジェクトにどちらが合うか」で判断するのがポイントです。以降のセクションで、具体的な違いを掘り下げていきます。

CloudFormationとTerraformの基本的な違い

1. AWS CloudFormationの特徴

AWS CloudFormationは、AWSが公式に提供するIaCサービスです。JSONまたはYAML形式のテンプレートファイルにAWSリソースの構成を記述し、「スタック」という単位でまとめてデプロイします。

オンプレ経験者にとってわかりやすく言えば、「AWSのリソースを発注するための注文書をコードで書く仕組み」です。AWSマネジメントコンソールでポチポチ作っていた作業を、テンプレートに落とし込んでバージョン管理できるようにしたものと考えてください。

主な特徴は以下のとおりです。

・AWS完全統合: 新サービスのリリースと同時、あるいは数日以内にCloudFormation対応が追加される
・追加料金なし: CloudFormation自体の利用料は無料（作成したリソースの料金のみ）
・スタック管理: リソースをスタック単位でまとめて作成・更新・削除できる
・ドリフト検知: テンプレートと実際のリソース構成のズレを検出する機能がある
・変更セット: 更新前に「何が変わるか」をプレビューできる

一方で、AWS以外のクラウドやSaaSのリソースは管理できません。あくまでAWSの世界に閉じたツールです。

2. HashiCorp Terraformの特徴

Terraformは、HashiCorp社が開発したオープンソースのIaCツールです。HCL（HashiCorp Configuration Language）という独自の宣言型言語でインフラを定義し、「Provider」と呼ばれるプラグインを通じて各クラウドやサービスのAPIを操作します。

オンプレ経験者向けに例えるなら、Ansibleが「OSとミドルウェアの構成管理ツール」だとすれば、Terraformは「クラウドインフラ全体のプロビジョニングツール」です。AnsibleのPlaybookが「サーバーの中身をどう設定するか」を記述するのに対し、Terraformは「どんなサーバーやネットワークを作るか」を記述します。

主な特徴は以下のとおりです。

・マルチクラウド対応: AWS、Azure、Google Cloud、その他多数のProviderに対応
・HCL（宣言型言語）: YAMLやJSONよりも可読性が高く、変数・ループ・条件分岐が使いやすい
・実行計画（plan）: 適用前に変更内容を確認できる（CloudFormationの変更セットに相当）
・Stateファイル: 管理対象リソースの現在の状態をStateファイル（tfstate）に記録する
・豊富なモジュール: Terraform Registryに公開されたモジュールを再利用できる

2023年8月にHashiCorp社はTerraformのライセンスをMPL 2.0からBSL（Business Source License）に変更しました。これに伴い、コミュニティがフォークした「OpenTofu」というプロジェクトも登場しています。ライセンスの選択がツール選定に影響するケースもあるため、2026年4月時点の状況として頭に入れておきましょう。

コード例で見る違い（EC2インスタンス作成）

言葉だけでは違いがピンと来ないので、同じ処理を両方のコードで見比べてみましょう。東京リージョン（ap-northeast-1）にt3.microのEC2インスタンスを1台作成する例です。

AWS CloudFormation（YAML形式）:

# CloudFormation テンプレート（YAML）
AWSTemplateFormatVersion: "2010-09-09"
Description: "EC2 instance for demo"

Parameters:
  AmiId:
    Type: AWS::SSM::Parameter::Value<AWS::EC2::Image::Id>
    Default: /aws/service/ami-amazon-linux-latest/al2023-ami-kernel-default-x86_64

Resources:
  DemoInstance:
    Type: AWS::EC2::Instance
    Properties:
      InstanceType: t3.micro
      ImageId: !Ref AmiId
      Tags:
        - Key: Name
          Value: demo-server

Outputs:
  InstanceId:
    Value: !Ref DemoInstance

Terraform（HCL形式）:

# Terraform 設定ファイル（HCL）
provider "aws" {
  region = "ap-northeast-1"
}

data "aws_ssm_parameter" "al2023_ami" {
  name = "/aws/service/ami-amazon-linux-latest/al2023-ami-kernel-default-x86_64"
}

resource "aws_instance" "demo" {
  ami           = data.aws_ssm_parameter.al2023_ami.value
  instance_type = "t3.micro"

  tags = {
    Name = "demo-server"
  }
}

output "instance_id" {
  value = aws_instance.demo.id
}

どちらも同じEC2インスタンスを作りますが、書き味はかなり違います。CloudFormationはYAMLの構造に従って記述するためインデントのネストが深くなりがちです。一方、TerraformのHCLはブロック構造でフラットに書けるため、コードの見通しが良いと感じる人が多いでしょう。

ただし、CloudFormationのYAMLは「特別な言語を覚えなくてよい」という利点があります。すでにAnsibleのPlaybookをYAMLで書いていたエンジニアなら、CloudFormationのテンプレートは馴染みやすいはずです。

7つの比較ポイントで徹底整理

ここからは、現場でのツール選定に直結する7つのポイントで両者を比較します。

それぞれ補足します。

対応クラウド
CloudFormationはAWS専用です。「AWSしか使わない」と決まっているなら何も問題ありません。しかし、AzureやGoogle Cloudも並行して使う環境、あるいはCloudflareやDatadogのようなSaaSのリソースもコードで管理したいなら、Terraform一択になります。

テンプレート言語
CloudFormationのYAMLは馴染みやすい反面、条件分岐やループの表現力が弱いのが弱点です。Fn::IfやFn::Selectといった組み込み関数はありますが、複雑なロジックを書こうとするとテンプレートが読みにくくなります。TerraformのHCLは、for_each・count・dynamic blockなどでループや条件分岐を自然に書けます。

状態管理
ここは実務上もっとも大きな違いです。CloudFormationはスタックの状態をAWS側で管理してくれるので、ユーザーは何も意識する必要がありません。一方、TerraformはStateファイル（terraform.tfstate）を自分で管理しなければなりません。チーム開発ではAmazon S3とAmazon DynamoDBを使ったリモートState管理が事実上の必須構成です。このState管理の手間がTerraform導入のハードルになることも少なくありません。

モジュール化
Terraformのモジュールは、ディレクトリ単位でインフラの部品を切り出して再利用できる仕組みです。Terraform Registryには公式・コミュニティ作成のモジュールが豊富に公開されており、VPCやECSクラスターの標準構成を数行で呼び出せます。CloudFormationにもネストされたスタックがありますが、TerraformのModule機構ほどの柔軟性はありません。

学習コスト
CloudFormationはYAMLさえ読み書きできれば始められますが、AWS固有の関数（!Ref、!Sub、Fn::GetAtt等）を覚える必要があります。TerraformはHCLという新しい言語の習得が必要ですが、HCL自体はシンプルな構文なので1〜2週間あれば基本は押さえられます。

エコシステム
CloudFormationはAWS公式ドキュメントが充実しており、AWSサポートにも問い合わせられます。TerraformはHashiCorpのドキュメントに加え、コミュニティの知見やTerraform Registryのモジュール群が強力です。Stack Overflowでの情報量はTerraformの方が多い傾向があります。

ライセンス
2023年8月以降、TerraformはBSL 1.1ライセンスに変更されました。個人利用や自社インフラ管理では影響ありませんが、Terraformを競合サービスとして商用提供する場合は制約があります。この変更を受けてLinux FoundationのもとでフォークされたOpenTofuも選択肢に入ります。CloudFormationはAWSサービスなのでライセンスの心配は不要です。

どちらを選ぶべきか？判断フローチャート

「結局どっちがいいの？」という問いへの答えは、プロジェクトの状況によって変わります。以下のフローで判断してみてください。

ステップ1: 利用クラウドの確認
→ AWS以外のクラウド（Azure、Google Cloud等）も管理対象に含まれる → Terraform
→ AWSだけを使う → ステップ2へ

ステップ2: チームの技術スタックと経験
→ チーム内にTerraform経験者がいる、またはHCLの学習コストを許容できる → Terraform
→ YAMLベースで手早く始めたい、新しい言語の習得コストを避けたい → ステップ3へ

ステップ3: 運用の複雑さ
→ State管理の運用負荷を避けたい、AWSサポートに問い合わせたい → CloudFormation
→ モジュールの再利用やDRY原則を重視する、将来のマルチクラウド化を見据えている → Terraform

現場でよくある判断パターン:

・スタートアップや小規模チーム（AWS一本）: CloudFormationで十分。Stateファイル管理の手間がない分、運用がシンプル
・中〜大規模の開発チーム: Terraformのモジュール機構が活きる。複数環境（dev/stg/prod）の管理もしやすい
・マルチクラウド・ハイブリッド環境: Terraform一択。AWS+Azure+SaaS連携をひとつのツールで管理できる
・AWS CDKとの組み合わせ: プログラミング言語でインフラを定義したいなら、CloudFormation + AWS CDK（Python/TypeScript等）という選択肢もある

Linuxサーバーの基礎については、姉妹サイトLinuxMaster.JPで詳しく解説しています。

よくあるトラブルと対処法

IaCツールを導入すると、手作業では起きなかった種類のトラブルに遭遇します。ここでは両ツールに共通、またはそれぞれ固有の代表的なトラブルと対処法を紹介します。

1. Terraformのstateファイル破損・競合

チーム開発でローカルにStateファイルを置いていると、複数人が同時にterraform applyを実行した際にState競合が発生します。最悪の場合、Stateファイルが壊れてリソースの追跡ができなくなります。

→ 対処法: Amazon S3 + DynamoDBによるリモートState管理を必ず設定する。バックエンド設定の例は以下のとおりです。

# backend.tf — リモートState設定
terraform {
  backend "s3" {
    bucket         = "my-terraform-state-bucket"
    key            = "prod/terraform.tfstate"
    region         = "ap-northeast-1"
    dynamodb_table = "terraform-state-lock"
    encrypt        = true
  }
}

2. CloudFormationのスタック更新失敗（ROLLBACK状態）

CloudFormationでスタックの更新に失敗すると、UPDATE_ROLLBACK_FAILED状態に陥ることがあります。こうなると更新も削除もできない「詰み」状態になりがちです。

→ 対処法: ContinueUpdateRollback APIを使ってロールバックを続行し、問題のあるリソースをスキップするのが定番の対処です。それでも解決しない場合は、AWSサポートに問い合わせるのが確実です。

# ロールバック失敗時の続行コマンド
aws cloudformation continue-update-rollback \
  --stack-name my-stack \
  --resources-to-skip "FailedResourceLogicalId"

3. ドリフト（手動変更によるズレ）

IaCツールで管理しているリソースを、コンソールやCLIで直接変更してしまうケースです。CloudFormationにもTerraformにもドリフト検知機能はありますが、検知するだけで自動修復はしてくれません。

→ 対処法: 運用ルールとして「IaC管理下のリソースは手動変更禁止」を徹底する。AWS Configの変更通知やTerraform Cloudの定期planでドリフトを早期発見する仕組みを入れておくのが現実的です。

4. リソース削除保護の未設定

terraform destroyやスタック削除で、本番のRDSインスタンスやS3バケットまで消してしまう事故は実際に起きています。

→ 対処法: Terraformではlifecycleブロックのprevent_destroy、CloudFormationではDeletionPolicyのRetainを設定しておく。特にデータベースやストレージ系のリソースには必ず設定しましょう。

# Terraform — 削除保護の設定例
resource "aws_db_instance" "production" {
  # ...省略...

  lifecycle {
    prevent_destroy = true
  }
}

本記事のまとめ

AWS CloudFormationとTerraformは、どちらも優れたIaCツールですが、設計思想と得意分野が異なります。この記事のポイントを振り返ります。

・CloudFormation: AWS専用。追加料金なし。State管理不要。AWS一本の環境ならシンプルに始められる
・Terraform: マルチクラウド対応。HCLの表現力が高い。モジュールの再利用性に優れる。ただしState管理の運用設計が必須
・ツール選定の基準: 対応クラウドの範囲、チームのスキル、運用負荷の許容度で判断する
・どちらを選んでも共通: ドリフト検知と削除保護の設定は必須。IaC管理下のリソースを手動変更しない運用ルールを徹底する

オンプレの構成管理（Ansible等）の経験がある人なら、「コードでインフラを定義する」という考え方自体はすでに馴染みがあるはずです。その経験を活かして、まずは小さなスタック（VPC+EC2の1台構成など）から試してみてください。実際に手を動かしてみると、テンプレートの書き心地やデプロイのワークフローが肌感覚でわかるようになります。