Infrastructure as CodeとCloudFormation

1. コードとしてのインフラストラクチャ（IaC）とは

コードとしてのインフラストラクチャ（IaC）は、ネットワーク・コンピューティング・ストレージ・IAMなどのインフラストラクチャ構成をコードとして定義し、レビュー・バージョン管理・自動化の対象にする考え方です。

IaCの価値は自動化だけではなく、インフラストラクチャ定義を信頼できる正本として扱えることにあります。

2. AWS CloudFormationの基本モデル

AWS CloudFormationでは、希望するインフラストラクチャをテンプレートで定義し、そのテンプレートから作成されたAWSリソース群をスタックとして管理します。

テンプレート
インフラストラクチャ定義
        ↓
AWS CloudFormation
        ↓
スタック
        ↓
マネージドリソース

CloudFormationは「作成手順を逐次実行するスクリプト」ではなく、最終的に存在してほしいリソースと設定を宣言するIaC サービスとして捉えます。

3. テンプレートは希望するインフラストラクチャ定義

CloudFormation テンプレートには、プロビジョニングするリソースとそのプロパティを記述します。テンプレートのセクションのうち、Resourcesは必須です。

Resources:
  WebSecurityGroup:
    Type: AWS::EC2::SecurityGroup
    Properties:
      GroupDescription: Web security group

  WebServer:
    Type: AWS::EC2::Instance
    Properties:
      InstanceType: t3.micro

環境ごとの差はテンプレートを複製して手修正するのではなく、必要に応じてパラメータなどで明示します。

4. テンプレートとスタックを区別する

同じテンプレートから開発・テスト・本番など複数のスタックを作れます。1 テンプレート = 1回しかデプロイできない、という関係ではありません。

5. 再現可能デプロイ

再現可能デプロイは、すべての環境を同じ値にすることではありません。

共通テンプレート
+
明示的な環境差分
        ↓
同じ設計ルール
同じリソース定義
同じデプロイプロセス
        ↓
再現可能デプロイ

本番だけコンソールから追加設定するような暗黙の差分を減らし、意図した環境差だけをコードへ残します。

6. 変更セットで変更予定をプレビューする

スタックを更新する前に変更セットを作成すると、予定されるリソース変更を確認できます。

現在スタック
+
提案されたテンプレート / パラメータ
        ↓
変更セット
        ↓
レビュー
        ↓
実行
        ↓
スタック更新

変更セットでは、リソースに対するAdd・Modify・Removeなどのアクションを確認できます。さらに変更などの変更について、既存リソースの置換が必要になるかも確認できます。

置換は追加 / 変更 / 削除と同列のアクションではなく、変更によってリソース置換が発生するかを示す情報として区別します。

7. 変更セットを作成しただけではリソースは更新されない

変更セットの作成はプレビューです。作成しただけではスタックのリソースに変更は適用されません。

重要スタックで置換などを事前確認したいなら、プレビュー可能な変更セットが重要な判断材料になります。

8. 事前デプロイ検証と成功保証を分ける

現在 CloudFormationでは事前デプロイ検証がデフォルトで有効で、作成 スタック・更新スタック・作成 変更セットなどで一般的なデプロイ障害の一部を事前に検出できます。

変更セットでは、変更プレビューに加えてサービスクォータなどの追加検証も利用できます。

事前デプロイ検証
→ 一部の問題をデプロイ前に検出

しかし

検証通過
≠
デプロイ成功保証

実行時条件、カスタムリソースの処理、サービス固有の実行時条件などにより、検証後でも更新が失敗する可能性は残ります。

9. ドリフトとは

CloudFormation外からリソースを変更すると、テンプレートで期待する状態と実際のリソース設定がずれることがあります。この差をドリフトと呼びます。

期待される状態
テンプレート / パラメータ
        ↓
       ≠
        ↑
実際の状態
AWSリソース

= ドリフト

例えばテンプレートではHTTPSだけを許可したセキュリティグループへコンソールから別ポートを追加すると、CloudFormationの望ましい状態と実際の状態がずれます。

10. ドリフト検知には対象範囲がある

ドリフト検知はAWSアカウント全体のすべての差分を完全に検出する機能ではありません。

• ドリフト検知をサポートするリソースタイプが対象です。
• 基本的にテンプレートまたはパラメータで明示したプロパティを期待される状態として比較します。
• ドリフト検知非対応リソースはNOT_CHECKEDになる場合があります。

また、通常のドリフト検知は差分を検出する機能であり、検出したドリフトを自動的に望ましい状態へ戻すことと同義ではありません。

11. 従来型変更セットの盲点

従来型 変更セットは、前回デプロイ時の状態と新しい望ましい状態の比較が中心です。

前回デプロイ時の状態
        ↓
        対
        ↓
希望する状態

CloudFormation外で手動変更が行われて実際の状態がずれている場合、そのドリフトを中心に比較する仕組みではありません。インシデント対応などで手動変更が入ったスタックでは、この違いが重要になります。

12. ドリフト対応変更セット

ドリフト対応変更セットは、対応するリソース / プロパティについて次の3つを使った3方向比較を提供します。

実際の状態
+
前回デプロイ時の状態
+
希望する状態
        ↓
ドリフト対応変更セット

これにより、テンプレート変更だけでなく、実環境に存在するドリフトが更新でどう扱われるかを確認しやすくなります。

3方向比較に対応していないリソースでは、前回デプロイ時の状態と望ましい状態を使う従来の比較へフォールバックします。

ドリフト対応変更セットを実行すると、対応範囲ではドリフトを考慮して実際の状態を望ましい状態へ一致させることができます。ただし、すべてのリソース / プロパティを必ず3方向比較・修復できるわけではありません。

13. 信頼できる正本を維持する

インシデント対応などでCloudFormation管理リソースを手動変更すること自体が常に誤りとは限りません。重要なのは、その後に望ましい状態との関係を整理することです。

実際の状態だけを変更したままテンプレートを古い状態で放置すると、次回デプロイで意図しない変更が起きる可能性があります。

14. 障害モード

15. SAP-C02判断フロー

インフラストラクチャを繰り返し構築したい
        ↓
コードとしてのインフラストラクチャ（IaC）
        ↓
希望する状態をテンプレートで定義
        ↓
スタックとして管理
        ↓
変更する？
        ↓
変更セットで予定変更をプレビューする？
        ↓
実際の状態にドリフトがある可能性は？
        ↓
ドリフト検出 / ドリフト対応変更セット
        ↓
希望する状態と実際の状態を整合
        ↓
再現可能デプロイを維持

まとめ

• IaCはインフラストラクチャをコード化し、レビュー・バージョン管理・再現可能性を持たせます。
• テンプレートは希望するインフラストラクチャ定義、スタックはCloudFormationが管理するリソース群です。
• 再現可能デプロイは、共通定義と明示された環境差分から同じ設計を再現することです。
• 変更セットは予定変更をプレビューし、置換の可能性も確認できます。
• 事前デプロイ検証は有効ですが、デプロイ成功を保証するものではありません。
• ドリフトは期待される状態と実際の状態の差です。
• 通常のドリフト検知は検出であり、自動整合性確認ではありません。
• ドリフト対応変更セットは対応範囲で実際の / 以前 / 希望するを比較し、ドリフトを考慮した更新を可能にします。
• 手動変更を正式採用する場合はテンプレートへ反映し、信頼できる正本を維持します。

主要AWS公式資料

• AWS Certified Solutions Architect - Professional（SAP-C02）試験ガイド
• AWS CloudFormation ユーザーガイド
• CloudFormation テンプレートのセクション
• スタックを使用してAWSリソースを単一単位として管理する
• 変更セットを使用したCloudFormationスタックの更新
• 事前デプロイ検証
• ドリフト検出による管理外の設定変更の検出
• ドリフト対応変更セットの使用
• AWS Well-Architected Framework — 運用エクセレンス 柱