導入
サーバーやネットワークを毎回手作業でポチポチ作ると、時間がかかるうえミスも起きます。「構成を設計図（コード）に書いて、ボタン一つで再現する」——それがIaC（Infrastructure as Code）の考え方です。
説明
AWS CloudFormationは、インフラをテンプレート（YAMLまたはJSON）にコードとして記述し、そのとおりにAWSリソースを一括作成・更新・削除できるサービスです（この作られたリソースの集まりをスタックと呼びます）。手作業をなくすことで、次の利点が生まれます。
- 再現性 … 同じテンプレートから、開発用・本番用の環境を寸分違わず作れる。
- バージョン管理 … 構成の変更を Git などで履歴管理できる。
- 一貫性 … 手順書どおりのクリック漏れ・設定ミスが起きない。
flowchart LR
T["テンプレート YAML/JSON"] --> CF["CloudFormation"]
CF --> S["スタック"]
S --> R1["VPC"]
S --> R2["EC2"]
S --> R3["RDS"]
もう一つ、AWS Systems Managerは、稼働中のサーバー群に対する運用作業——OSのパッチ適用、設定値（パラメータ）の一元管理、コマンドの一括実行——を自動化・効率化するサービスです。CloudFormation が「作る」を自動化するなら、Systems Manager は「運用する」を自動化する、と捉えると分かりやすいでしょう。
具体例
「作る」と「運用する」の自動化を、具体的な作業で対比してみましょう。
- 作る（CloudFormation） … 新規プロジェクトで「VPC＋EC2 2台＋RDS」の環境が、開発・検証・本番と3つ必要。1つのテンプレートを書き、パラメータを変えて3回適用するだけで、3環境がまったく同じ構成で立ち上がる。手作業のクリック漏れによる「本番だけ設定が違う」事故が起きない。半年後に環境を1つ丸ごと削除するのも、スタックを消すだけ。
- 運用する（Systems Manager） … 稼働中の100台のEC2に、緊急のセキュリティパッチを当てたい。1台ずつSSHでログインして作業したら丸一日仕事。Systems Managerなら100台へ一斉にパッチ適用コマンドを実行でき、DBパスワードなどの設定値も一元管理できる。
「環境をコードから“作る”＝CloudFormation、動いているサーバーを“運用する”＝Systems Manager」。どちらも手作業を消して、ミスと時間を減らすのが狙いです。
読んでみよう
「インフラを設計図（コード）から再現＝CloudFormation（IaC）」「稼働中のサーバーの運用作業を自動化＝Systems Manager」。手作業を減らして一貫性を保つのが管理の要です。