はじめに
インフラをコードで作る（IaC）の練習で、ほぼ同じ構成を CloudFormation と Terraform の両方で作ってみました。VPC・サブネット・EC2・RDS・ALB 一式です。同じものを2つの書き方で作ると違いがはっきり見えて面白かったので、初心者目線でまとめます。
「同じ箱を、別の言葉で組み立てる感じでした😄」
環境
- AWS（VPC / public・private サブネット / EC2 / RDS / ALB）
- CloudFormation（YAML、
template.yaml。以下 CFN） - Terraform（HCL、
main.tf） - リージョン：ap-northeast-1
共通点（どちらも IaC）
- インフラをコードで定義して、コマンドで作る・消せる
- 手作業より再現性が高く、構成がファイルに残る
- 同じ「VPC・サブネット・EC2・RDS・ALB」を、どちらでも作れた
違い（書き方）
| やりたいこと | CloudFormation | Terraform |
|---|---|---|
| 言語 | YAML / JSON（AWS 専用） | HCL（AWS 以外のクラウドやサービスも扱える） |
| 別リソースの参照 |
!Ref / !GetAtt
|
リソース名.属性（例 aws_vpc.study.id） |
| AZ を自動取得 |
!GetAZs / !Select
|
data "aws_availability_zones" |
| 最新 AMI を取得 | SSM パラメータ（Systems Manager Parameter Store） | data "aws_ami" |
| 秘密の値 |
NoEcho パラメータ |
variable { sensitive = true } |
| 出力 | Outputs: |
output |
| 作成コマンド | aws cloudformation deploy |
terraform apply |
※秘密の値について：
NoEchoもsensitiveも**「表示を隠す」ための仕組みで、Secrets Manager などの秘密管理とは別に**考える必要があります。
例えば「VPC の ID を参照する」だけでも、こう変わります。
CloudFormation：
VpcId: !Ref StudyVpc
Terraform：
vpc_id = aws_vpc.study.id
違い（実行・運用）
| 観点 | CloudFormation | Terraform |
|---|---|---|
| 状態管理 | AWS 側のスタックが持つ | state ファイルが持つ |
| 差分確認 | Change Set | terraform plan |
| 対象範囲 | AWS 中心 | 複数クラウド・外部サービスも |
| 学習時の印象 | AWS 用語に近い | 差分が見やすい |
| 注意点 | YAML が長くなりがち | state の扱いに注意 |
Terraform の terraform plan は「これから何を作る／変える／消すか」を先に一覧で確認できて（Plan: 14 to add のように）、初心者には安心でした。CloudFormation にも Change Set という同様の仕組みがありますが、学習中に触った範囲では plan の方が直感的に見えました。
なお、Terraform の state ファイルはとても重要で、チーム利用や本番では保存場所・ロック・機密情報の扱いに注意が要ります。
どう使い分ける？（今のところの考え）
- AWS だけで完結し、AWS 標準の仕組みで管理したいなら CloudFormation
- 複数クラウドや外部サービスもまとめて管理したいなら Terraform
どちらが上、ではなく目的次第だと感じました。同じ構成を両方で書いたことで、片方だけでは気づかない「考え方は同じ・書き方が違うだけ」が腹落ちしました。
学び
- IaC は「インフラをコードで再現できる」のが核。CloudFormation も Terraform もそこは同じ。
- 違いは主に言語と参照の書き方・状態の持ち方・差分の見せ方・対象範囲。
- 同じものを2回作るのは遠回りに見えて、理解がいちばん深まった。
おわりに
同じ箱を2つの道具で組み立てると、道具の個性がよく分かりました😄 「CloudFormation と Terraform、何が違うの？」と思っている人の役に立てば嬉しいです🙌