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単位の自動ロールバックが標準機能
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
状態管理の仕組み:自己管理 vs AWSマネージド
IaCツールを比較する上で最も本質的な違いが「状態管理」です。Terraformは
terraform.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ロック用 } }
・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 (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" }
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 | 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のIaC設計・運用をステップごとに学ぶなら Terraform実践コース(terraform.linuxmaster.jp) もご覧ください。
TerraformもCloudFormationも、Linuxサーバー運用の「型」があってこそ使いこなせる
TerraformやCloudFormationでインフラをコード化するには、VPC・サブネット・IAMロール・セキュリティグループといったAWSインフラの基本設計を理解していることが前提になります。ツール選定に迷う前に、現場で実際に使われる設計の「型」を体系的に身につけることが近道です。
現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、『Linuxサーバー構築入門マニュアル(図解60P)』を完全無料でプレゼントしています。
「独学の時間がもったいない」「プロから直接、TerraformとLinuxを含む現場の技術を最短で学びたい」という本気の方には、2日で実務レベルのスキルが身につく【初心者向けハンズオンセミナー】も開催しています。
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
姓・名・メールの3つだけ/30秒/解除は3秒 / 詳細はこちら
- 前のページへ:AWSを使わずMinIOでTerraformのstate共有基盤を用意する設計|互換オプションの指定と最小権限のアクセスキー発行
- この記事の属するカテゴリ:Terraformへ戻る

無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。
登録無料・いつでも解除できます