TerraformとCloudFormationを比較する設計判断|HCLとYAML・状態管理・マルチクラウド対応とロールバックの選択基準

宮崎智広 この記事の監修:宮崎智広(Linux実務・教育歴20年以上・受講者3,100名超)
HOMELinux技術 リナックスマスター.JP(Linuxマスター.JP)Terraform > TerraformとCloudFormationを比較する設計判断|HCLとYAML・状態管理・マルチクラウド対応とロールバックの選択基準
「AWSのインフラをコード化したいが、TerraformとCloudFormationのどちらを使えばいいのかわからない」——IaC導入を検討するチームが最初に直面する選択です。

TerraformはHashiCorp(現IBM傘下)が開発したオープンソースのIaCツールで、AWS以外のクラウドにも対応します。CloudFormationはAWSが提供するマネージドIaCサービスで、AWSサービスとの統合が深いのが特徴です。両者はコード記法・状態管理・適用範囲・エコシステムが根本的に異なります。

この記事では、Terraform(HCL・v1.6以降)とCloudFormation(JSON/YAML・現行世代)を状態管理・コード記法・マルチクラウド対応・エラー時の復旧の4軸で比較し、「どちらを選ぶべきか」の判断基準を整理します。

この記事のポイント

・TerraformはtfstateをS3等に保管し自分で管理するが、CloudFormationはAWSがStack状態を管理する
・HCL(Terraform)はYAML/JSON(CloudFormation)より変数・ループ・モジュール化が読みやすく書きやすい
・マルチクラウド(AWS+Azure+GCP)を扱う場合はTerraform一択、AWSのみならCloudFormationも有力な選択肢
・Terraformのapply失敗は手動ロールバックが必要だが、CloudFormationはStack単位の自動ロールバックが標準機能


「このままじゃマズい」と感じていませんか?
参考書を開く気力もない、同年代に取り残される不安——
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
姓・名・メールの3つだけ/30秒/解除は3秒 / 詳細はこちら

状態管理の仕組み:自己管理 vs AWSマネージド

IaCツールを比較する上で最も本質的な違いが「状態管理」です。

Terraformterraform.tfstateというJSONファイルに現在のインフラ状態を記録します。このファイルはデフォルトでローカルに保存されますが、チーム運用ではS3バケット+DynamoDBをbackendに指定して共有します。

# Terraform: S3バックエンドでstateを共有する例 terraform { backend "s3" { bucket = "mycompany-tfstate" key = "production/main/terraform.tfstate" region = "ap-northeast-1" encrypt = true dynamodb_table = "terraform-lock" # stateロック用 } }

CloudFormationにはtfstateのような外部ファイルはありません。AWSがStack内のリソース状態を管理し、コンソール・CLI・APIからStackの差分確認(Change Sets)や状態照会ができます。tfstateのバックアップや暗号化設定、stateロックの仕組みを自分で用意する必要がありません。

Terraform:stateファイルの保管・暗号化・ロックをチームで設計・運用する必要がある
CloudFormation:AWSがStack状態を管理。外部ストレージの設計不要

コード記法:HCL vs YAML/JSON

1. 変数・ループ・条件式の書きやすさ

TerraformのHCLは変数・ローカル値・for式・dynamic blockを使った動的なリソース定義が得意です。

# Terraform (HCL): for_eachで複数サブネットを一括定義 variable "subnet_cidrs" { type = map(string) default = { public_a = "10.0.0.0/24" public_c = "10.0.1.0/24" private_a = "10.0.2.0/24" } } resource "aws_subnet" "this" { for_each = var.subnet_cidrs vpc_id = aws_vpc.main.id cidr_block = each.value availability_zone = lookup(local.az_map, each.key, "ap-northeast-1a") }

CloudFormationで同等の繰り返しを表現するにはConditionsとMappings、またはNestedStackを組み合わせる必要があり、コードが冗長になりがちです。

# CloudFormation (YAML): サブネットを個別に定義(繰り返し構文がない) Resources: SubnetPublicA: Type: AWS::EC2::Subnet Properties: VpcId: !Ref VPC CidrBlock: "10.0.0.0/24" SubnetPublicC: Type: AWS::EC2::Subnet Properties: VpcId: !Ref VPC CidrBlock: "10.0.1.0/24" # 3つ目以降も同様に繰り返す...

2. モジュール設計の柔軟性

Terraformはmoduleブロックでコードを再利用単位に分割できます。入力変数・出力値・バージョン固定がmodule単位で管理でき、Terraform Registryで公開モジュールを利用することも可能です。

CloudFormationにはNested Stackという仕組みがありますが、親スタックからネストされたスタックへ値を渡す際の依存関係管理はTerraformのmodule参照より煩雑です。AWS CDKを使うとプログラミング言語でCloudFormationテンプレートを生成できるため、繰り返しや抽象化の問題はある程度解消できます。

マルチクラウド対応:Terraformの圧倒的な強み

TerraformがCloudFormationに対して最も差別化できる領域がマルチクラウド対応です。

TerraformはAWS・Azure・GCP・Kubernetes・GitHub・Datadogなど600以上のproviderに対応しており、1つのHCLコードベースで複数クラウドのリソースを管理できます。

# Terraform: AWSとAzureを1つのコードで管理する例 terraform { required_providers { aws = { source = "hashicorp/aws", version = "~> 5.0" } azurerm = { source = "hashicorp/azurerm", version = "~> 3.0" } } } # AWS側のリソース resource "aws_s3_bucket" "logs" { bucket = "mycompany-logs-aws" } # Azure側のリソース(同じtfstateで管理) resource "azurerm_storage_account" "logs" { name = "mycompanylogsazure" resource_group_name = azurerm_resource_group.main.name location = "japaneast" account_tier = "Standard" account_replication_type = "LRS" }

CloudFormationはAWSリソースのみが対象です。Azure・GCPのリソースを同じコードベースで管理したい場合はTerraform一択になります。

TerraformのIaC設計をより体系的に学びたい方は Terraform実践コース(terraform.linuxmaster.jp) も参考にしてください。

エラー時の動作とロールバック

3. CloudFormationの自動ロールバック

CloudFormationはStack更新中にエラーが発生すると、自動的に以前の状態にロールバックします。デプロイの途中でリソース作成が失敗しても、AWS側がStack内のリソースを整合性のある状態に戻すため、手動での後処理が不要です。

# CloudFormation: Stack更新失敗時のログ例(自動ロールバックあり) Status: UPDATE_ROLLBACK_COMPLETE Status reason: The following resource(s) failed to update: [WebServer]. Rollback requested by user. # Stackの状態は自動的に更新前に戻る aws cloudformation describe-stacks --stack-name my-stack --query 'Stacks[0].StackStatus' # "UPDATE_ROLLBACK_COMPLETE"

4. Terraformのapply失敗と手動ロールバック

Terraformはapply中にエラーが発生すると、その時点で処理が停止します。成功したリソースはそのまま残り、失敗したリソースはtfstateに「tainted」または「未作成」として記録されます。

# Terraform: apply失敗後の状態確認 $ terraform apply aws_instance.web: Creating... Error: InvalidParameterValue: Invalid availability zone: ap-northeast-1x # 成功したリソースはtfstateに記録済み $ terraform state list aws_vpc.main aws_subnet.public_a # aws_instance.web は作成されていない(途中停止) # 対処: エラーを修正してterraform applyを再実行 # または作成済みリソースを一部破棄してからapply $ terraform destroy -target aws_subnet.public_a

Terraformにはロールバック機能がないため、apply失敗後の後処理はエンジニアが行います。本番環境では変更前にterraform planの出力を必ずレビューし、`-target`を使った段階的なapplyや、スナップショット(terraform state pull)でのtfstate保存を習慣化することが重要です。

選択基準まとめ

観点 Terraform CloudFormation
対応クラウド AWS・Azure・GCP・他600以上 AWSのみ
状態管理 tfstateを自己管理(S3+DynamoDB推奨) AWSがStackとして管理(外部ストレージ不要)
コード記法 HCL(変数・for_each・dynamic block) YAML/JSON(繰り返し構文が少ない)
モジュール化 moduleブロック・Terraform Registry Nested Stack・AWS CDK
apply失敗時 途中停止・手動対処が必要 自動ロールバック標準装備
AWSリソース追跡 プロバイダー更新の遅れがある場合あり AWSが提供→新サービスへの対応が速い
チームの学習コスト HCL・tfstate管理の習得が必要 YAML/JSONの知識でAWSエンジニアは比較的入りやすい
結論として、マルチクラウド・複雑な繰り返し設定・既存のTerraformエコシステムを活用したい場合はTerraformAWSのみ・自動ロールバックを活用したい・新サービスへの即日対応が必要な場合はCloudFormationが適しています。多くのAWSオンリーチームではCloudFormationとTerraformを併用するケースも多く、「新規構築はTerraform、既存のCloudFormation Stackはそのまま維持」という移行パターンも一般的です。

TerraformのIaC設計・運用をステップごとに学ぶなら Terraform実践コース(terraform.linuxmaster.jp) もご覧ください。

TerraformもCloudFormationも、Linuxサーバー運用の「型」があってこそ使いこなせる

TerraformやCloudFormationでインフラをコード化するには、VPC・サブネット・IAMロール・セキュリティグループといったAWSインフラの基本設計を理解していることが前提になります。ツール選定に迷う前に、現場で実際に使われる設計の「型」を体系的に身につけることが近道です。
現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、『Linuxサーバー構築入門マニュアル(図解60P)』を完全無料でプレゼントしています。

「独学の時間がもったいない」「プロから直接、TerraformとLinuxを含む現場の技術を最短で学びたい」という本気の方には、2日で実務レベルのスキルが身につく【初心者向けハンズオンセミナー】も開催しています。

無料メルマガで学習を続ける

Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。

登録無料・いつでも解除できます

暗記不要・1時間後にはサーバーが動く

3,100名以上が実践した「型」を無料で公開中

プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。

姓・名・メールの3つだけ/30秒/解除は3秒 / 詳細はこちら

Linux無料マニュアル(図解60P) 名前とメールで30秒登録
宮崎 智広

この記事を書いた人

宮崎 智広(みやざき ともひろ)

株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。

趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。