継続的な改善サイクルを回すには、インフラの変更が再現可能かつ追跡可能であることが不可欠です。本記事ではInfrastructure as Code (IaC) の運用を、マルチアカウントの観点から解説します。

SAA レベル：基礎概念

CloudFormationの基本

テンプレート（YAML/JSON）でインフラをコードとして定義し、スタックとしてデプロイ・管理する
スタックを更新・削除すると、関連するリソースも自動的に更新・削除される

SAA 試験のポイント

CloudFormationは冪等性を持ちます。同じテンプレートを何度適用しても、既存の状態から差分のみが適用される（変更セットの仕組み）ため、手動でのリソース管理より安全で再現性が高い、という基本原則がSAAで問われます。

AWS CDKの基本

TypeScript、Python等のプログラミング言語でインフラを定義し、最終的にCloudFormationテンプレートに変換（synth）される
ループや条件分岐、関数といったプログラミング言語の機能をそのままインフラ定義に活用できる

SAP レベル：高度な設計シナリオ

CloudFormation StackSetsによるマルチアカウント/マルチリージョン展開

SAP 試験のポイント

組織内の数十〜数百のアカウントに、同じベースラインリソース（IAMロール、CloudTrail設定、GuardDuty有効化等）を展開したい場合、アカウントごとに手動デプロイするのは非現実的です。StackSetsを使うと、管理アカウント（または委任された管理者アカウント）から、Organizations内の対象OU全体に対して一括でスタックを作成・更新・削除できます。

ドリフト検出

SAP 試験のポイント

CloudFormationで管理されているリソースが、コンソールやCLIから手動で変更（テンプレートの定義外の変更）されると、テンプレートの状態と実際のリソースの状態に**ドリフト（乖離）**が生じます。SAPレベルでは、ドリフト検出を定期的に実行し、意図しない手動変更を検知・是正する運用フローを組み込むことが、IaCの実効性を保つ上で重要な論点として問われます。

設計上の落とし穴

「一度CloudFormationでデプロイしたら、その後は手動変更しても問題ない」という運用は、ドリフトを蓄積させ、次回のスタック更新時に予期しない挙動（意図しないリソースの上書き等）を引き起こすリスクがあります。SAPでは、手動変更を禁止するガバナンス（SCPによる直接変更の制限等）と、ドリフト検出の組み合わせが問われることがあります。

CDKによる抽象化のメリット

CDKのConstruct（再利用可能なインフラ部品）を使うことで、「セキュアなS3バケット + CloudFrontディストリビューション」のような複雑な構成をカプセル化し、組織内の複数プロジェクトで再利用できる
L2/L3 Constructと呼ばれる高レベルの抽象化により、ベストプラクティス（暗号化の自動有効化等）がデフォルトで組み込まれたインフラ定義が可能になる

CI/CDパイプラインとの統合

CDK PipelinesやCodePipelineと組み合わせ、インフラの変更もアプリケーションコードと同様にプルリクエスト・レビュー・自動テストを経てデプロイする、GitOps的な運用が大規模組織のベストプラクティスとして定着しつつある

まとめ

SAA: CloudFormationの冪等性、CDKがプログラミング言語でインフラを定義できることを理解する。
SAP: StackSetsによるマルチアカウント一括展開、ドリフト検出による乖離の是正、CDK Constructによる再利用可能な抽象化ができる。

ここまでで 3-1 運用性向上戦略 の全4記事が完了しました。次は 3-2 セキュリティ改善戦略 に進みます。