IaCと構成管理 ― CloudFormation・CDK・StackSets

導入

手作業でコンソールからリソースを作っていると、「なぜこの設定になっているか」が誰にもわからなくなり、環境ごとの差異（ドリフト）も知らないうちに広がります。既存システムの改善では、まずインフラをコード化し、変更を追跡できる状態にすることが土台になります。

説明

AWSのIaC（Infrastructure as Code）の中心が CloudFormation です。

flowchart LR
    CDK["AWS CDK<br/>（プログラミング言語で記述）"] -->|"cdk synth"| CFN["CloudFormationテンプレート"]
    CFN --> Stack["1つのスタック<br/>（1アカウント/1リージョン）"]
    CFN --> SS["StackSets"]
    SS --> A1["アカウントA-リージョン1"]
    SS --> A2["アカウントB-リージョン2"]
    SS --> A3["アカウントC-リージョン1"]

• CDK: ループ・条件分岐・関数といったプログラミング言語の機能を使えるため、似た構成を大量に作る場合や、複雑な条件分岐を伴うインフラ定義で威力を発揮する。最終的にはCloudFormationにコンパイルされるため、実行基盤はCloudFormationと同じ。
• StackSets: マルチアカウント統治（第2章）と直結する機能。「全アカウントに共通のセキュリティ基盤（GuardDutyの有効化、CloudTrailの設定など）を配る」といった用途で使う。Organizations統合により、新しくアカウントが増えても自動でスタックが展開される設定も可能。
• ドリフト検出: CloudFormationで作成したリソースが、後から手動でコンソール変更されていないかを検出する機能。「テンプレートと実際の状態が一致しているか」を定期的に確認し、IaCで管理しているはずの環境が知らないうちに壊れる事態を防ぐ。

具体例

IaCで管理しているはずの環境で起きた「知らないうちに壊れる」事故と、その予防を見ます。

ある企業は本番環境をCloudFormationで構築していました。ところが障害対応中に、担当者が急いでコンソールから手動でセキュリティグループを変更。その場は直りましたが、テンプレートには反映されず、次のデプロイで手動変更が上書きされて障害が再発しました。テンプレートと実環境がズレる「ドリフト」の典型です。

対策と発展：

• ドリフト検出を定期実行し、「テンプレートと実環境が一致しているか」を確認。手動変更を早期に発見して是正する。
• 全アカウントに共通のセキュリティ基盤（GuardDuty有効化・CloudTrail設定）を配るなら、StackSetsでOU対象に一括展開。新アカウントが増えても自動で展開。
• 「本番だけ3台、開発は1台」のような条件分岐やループが多いなら、プログラミング言語で書けるCDKが書きやすい（内部でCloudFormationに変換）。

「複数アカウントへ一括展開＝StackSets、手動変更のズレ検出＝ドリフト検出、条件分岐が複雑・言語で書きたい＝CDK」。既存改善では、まずインフラをコード化し変更を追跡できる状態にするのが土台です。

読んでみよう

「複数アカウント・複数リージョンへ同じ設定を一括展開したい」はStackSets、「手動変更によってテンプレートと実環境がズレていないか調べたい」はドリフト検出が対応します。「なぜCDKでなくCloudFormationか / その逆か」は、条件分岐やループの複雑さと、チームの言語スキルセットで判断させる問題が多い点も覚えておいてください。