はじめに

「昨夜ステージングで通ったのに、本番だけ挙動が違う」
「Excel のパラメータ表と、コンソールの今の設定、どっちが正？」
こうしたつらさの多くは、手作業の再現性とドキュメントの陳腐化から生まれます。

Infrastructure as Code（IaC） は、手作業を減らすだけでなく、設計そのものを資産にする考え方です。AWS では CloudFormation が代表的なプロビジョニング手段のひとつで、テンプレートが「意図した構成」の説明責任を担います。画面のボタン位置は変わっても、レビューできるテキストは残る。これが現場で効く理由です。

こんな人におすすめ

CloudFormation を触り始めたが、用語と全体像がつながらない
スタックや YAML を会議で一言で説明したい
巨大テンプレート1枚にしがちで、変更が怖い
Terraform / CDK に行く前に、AWS ネイティブの型を押さえたい

この記事を読み終えると…

プロビジョニングと スタックのイメージが掴める
YAML を選ぶ理由と、テンプレートの最小の骨格が言語化できる
App / DB / Network の疎結合と、**依存の順番（KMS 含む）**で手戻りを減らす視点が持てる

動画版

この記事は、以下のYouTube動画をQiita向けに再構成したものです。動画では、CloudFormationを「手動構築を卒業し、インフラを資産に変える設計思想」として話しています。

YouTube: 【前編】AWS CloudFormation 入門：手動構築を卒業し、インフラを「資産」に変える設計思想

コンソールのメニュー名・既定値・上限・料金は更新されるため、作業時は必ず AWS CloudFormation の公式ドキュメントを参照してください。テンプレートの要素一覧はテンプレートの構文とセマンティクス（AWSTemplateFormatVersion / Description / Metadata / Parameters / Resources など）が手がかりになります。

先に結論

CloudFormationを最初に理解するときは、次の4つだけ押さえると迷いにくいです。

用語	ざっくり言うと	具体例
テンプレート	作りたい構成を書いたファイル	`template.yaml`
スタック	テンプレートから作られた一式	`dev-network-stack`
Parameters	環境ごとに変える値	`EnvironmentName: dev`
Outputs	他スタックへ渡す値	VPC ID、Subnet ID

最小構成のイメージは次のようなものです。

# テンプレート形式のバージョン。基本はこの値を使う
AWSTemplateFormatVersion: '2010-09-09'

# スタック一覧で人間が読む説明
Description: Minimal S3 bucket example

Parameters:
  EnvironmentName:
    # dev / stg / prod など、環境名を外から渡せるようにする
    Type: String
    Default: dev

Resources:
  AppBucket:
    # S3バケットを1つ作る最小例
    Type: AWS::S3::Bucket

Outputs:
  AppBucketName:
    # 作成されたバケット名を外から参照できるようにする
    Value: !Ref AppBucket

実務では、この小さな単位をどう分け、どうレビューし、どう安全に更新するかが大事です。S3バケット名のようにグローバル一意制約がある値は、明示する前に命名ルールを決めます。

用語の短い説明

この記事で使うCloudFormation周辺の用語を短く整理します。

用語	短い説明
IaC	Infrastructure as Code。インフラ構成をコードで管理する考え方
YAML	インデントで構造を書く設定ファイル形式。コメントを書きやすい
スタック	CloudFormationがまとめて作成・更新・削除するリソース一式
Parameters	環境ごとに変えたい値を外から渡す仕組み
Outputs	作ったリソースIDなどを外へ出す仕組み
KMS	暗号化キーを管理するAWSサービス
ARN	AWSリソースを一意に表す名前

なぜ「コンソールだけ」がつらいのか

手作業でマネジメントコンソールを触り続けると、次のような負債が溜まりやすくなります。

ヒューマンエラー：セキュリティグループの1ルール漏れなど、目視確認では抜けやすい。
ドキュメントと実機の乖離：急ぎの変更を誰かがコンソールだけで入れたあと、Excel のパラメータシートが「正」ではなくなる。

IaC に寄せると、テンプレートが意図した構成の説明責任を担うので、「今の正解はどれか」を議論するときの土台にできます。

ひとことで　コンソールは「その場の操作」、テンプレートは「チームで合意した設計」。後者に寄せるほど、夜間の突発対応が減りやすい、というのが実務の体感です。

プロビジョニングとは

ここでは簡単に、必要なリソースを、使える状態で用意することと捉えます。サーバー・DB・ネットワークなどを、都度コンソールで組み立てるのではなく、手順をコード化して再利用するイメージです。

コンソールの UI は変わりやすい一方、テンプレートに書いたリソース定義はレビュー・差分管理の対象にしやすく、長期運用ではこちらが「資産」になりやすいです。

スタックという単位

**「検証環境、もう要らないからポチッと消したい」**とき、コンソールだとリソースの取りこぼしが怖い。スタックなら まとめて life cycle を管理しやすい、というのが現場で刺さるポイントです。

CloudFormation では、関連リソースを スタック という単位でまとめて管理します。

作成：テンプレートに沿って一括でリソースを用意できる。
削除：スタック削除でまとめて片付けやすい（ただし DeletionPolicy などで挙動が変わる。後編で触れる）。

「環境ごとにスタックを分ける」「検証が終わったらスタックごと捨てる」といった運用と相性がよいです。

例えば、検証環境なら次のように分けると説明しやすくなります。

# 変更頻度が違うものをスタックで分ける例
dev-network-stack
  -> VPC / Subnet / RouteTable

dev-db-stack
  -> RDS / SecurityGroup / ParameterGroup

dev-app-stack
  -> ECS / ALB / CloudWatch Logs

削除や更新の頻度が違うものを同じスタックに詰め込みすぎないのがコツです。

テンプレートは YAML を推奨したい理由

3ヶ月後の自分は別人、はインフラあるあるです。JSON だけだと「当時の意図」が消えやすく、レビューで 「なぜこの値？」 に答えにくくなります。

CloudFormation テンプレートは JSON と YAML の両方に対応していますが、実務では YAML が選ばれやすいです。最大の理由は コメントが書けることです。「なぜこの値にしたか」「誰がいつ決めたか」をテンプレート内に残せます。

拡張子 `.yaml` と `.yml`

どちらも使えますが、プロジェクト内で統一しておくと、エディタのハイライトや拡張機能の認識が安定しやすいです。

最小の骨格

多くのテンプレートで、次のような要素が土台になります。

AWSTemplateFormatVersion … テンプレート形式の宣言（よく使われる値は公式どおり）。
Description … 任意。スタック一覧で人間が読む説明に使える（長文にしすぎない）。
Resources … 実際に作る AWS リソースの定義（必須に近い中心）。

最初から完璧を目指さず、小さな Resources から動かすのが学習では安全です。

レビューでは、最低限次を見ます。

見る場所	確認すること
`Description`	何のスタックか人間が分かるか
`Parameters`	環境差分がここに寄っているか
`Resources`	作るリソースが意図どおりか
`Outputs`	他スタックへ渡す値が明確か
コメント	なぜその値にしたか残っているか

設計のコツ：疎結合（App / DB / Network）

**「アプリのデプロイだけのつもりが、DB まで巻き込んで事故った」**を減らすのが疎結合です。頻繁に変える層と、触りたくない層を スタックの境界で分ける、と覚えると説明もしやすいです。

アプリケーション層・データ層・ネットワーク層を、可能なら 別テンプレート／別スタックとして切り出す疎結合にすると、変更の波及を抑えやすくなります。

アプリだけ頻繁に更新したい
DB は触りたくない
ネットワークは土台として安定させたい

といった責務の違いに沿って分割すると、レビューもしやすくなります。

分割の判断は、次のように考えると実務向きです。

層	変更頻度	分ける理由
Network	低い	変更すると影響範囲が広い
DB	低〜中	データ保護や削除方針を別管理したい
App	高い	デプロイ頻度が高く、独立して更新したい
Monitoring	中	通知先やしきい値だけ変えたいことがある

依存関係の順番（つまずきどころ）

プロビジョニングでは、後から参照される ID や ARN を持つリソースが、先に存在している必要があります。例として次が挙げられます。

VPC・サブネット・ルート・セキュリティグループ
IAM ロール
ターゲットグループ、証明書
ログやアーティファクト用のバケット

スタックを分ける場合は、上流からデプロイし、Outputs と Parameters で値を渡す順番が噛み合っているかを設計段階で決めておくと手戻りが減ります。CloudFormation は暗黙の依存で並べ替えることもありますが、足りない場合は DependsOn で明示することがあります。

暗号化でも同様で、SSE-KMS や RDS の保管時暗号化などで KMS の CMK を参照するなら、キーが先に確定している必要があります。キー用スタックを切り出すなら、キー側を先にデプロイして ARN やエイリアスを渡す、という割り切りが効きます。

CDK や Terraform も、根本は 依存グラフの話に行き着きます。

今日からのチェックリスト

プロビジョニングは「手順の再現」であり、設計の説明責任の置き場でもある。
スタックでまとめて作る・捨てる単位を決める。
YAMLでコメントを残し、拡張子はチームで統一する。
App / DB / Network を分けて、変更の波及を抑える。
依存の順（参照されるものを上流に。分割時はデプロイ順と Outputs／Parameters）。必要なら DependsOn。暗号化は KMS を先に。

関連記事

AWSインフラ工程を5ステップで整理する要件定義・設計・実装・検証
CloudFormation後編｜本番更新が怖い人向け（今後公開予定）
AWS構成図をテンプレートで作る手順（今後公開予定）

参考・確認先

補足（Qiita 用）

Well-Architected の運用性や、資格試験では「テンプレートで何を担保するか」が問われやすい、というのは学習上の位置づけです。最新の出題範囲は公式ガイドで確認してください。
**続き（長期運用・ドリフト・Lint・削除方針など）**は、後編として別記事化予定です。**前編は「設計の地図」、後編は「壊さず育てる守り」**とセットで読むと腹落ちしやすいです。
Windows 端末から CLI で触る場合は、改行コード（BOM）などで YAML が壊れることがあるため、エディタ設定と公式のトラブルシュートも併せて確認するとよいです。

おわりに

CloudFormationは、テンプレートを書く作業というより、インフラの意図を残す作業として捉えると使いやすくなります。
Wealthy Designでは、Webシステム開発、クラウド活用、AIを使った業務改善に取り組んでいます。

会社の取り組みは、会社サイトにまとめています。
https://wealthy-design.com/