AWS Certified CloudOps Engineer - Associate (SOA-C03) #7 Domain 3-1 デプロイ — CloudFormation の深掘りと IaC
#6 まで信頼性ドメインを終えました。3 番目のドメインは デプロイ・プロビジョニング・自動化 (22%) であり、その中心に IaC (Infrastructure as Code) があります。運用で IaC が重要な理由は単純です。コンソールで手作業で作った環境は 再現されず、誰が何を変えたか追跡されません。CloudFormation は AWS のネイティブ IaC ツールで、インフラをテンプレート (コード) として宣言し、その状態を管理します。
スタックとテンプレート #
| 概念 | 説明 |
|---|---|
| Template | 作成するリソースを宣言した JSON・YAML ファイル |
| Stack | テンプレートで作成・管理されるリソースのまとまり (デプロイ単位) |
| Resource | スタックが作成する個々のリソース (EC2・S3・RDS など) |
スタックを削除すると、そのスタックが作成したリソースが一緒に整理されます。これが手作業で作った環境との決定的な違いです。作成・更新・削除が 1 つの単位で管理 されます。
テンプレートの主なセクション #
| セクション | 役割 |
|---|---|
| Parameters | デプロイ時の入力値 (環境・インスタンスタイプなど) |
| Mappings | キーで値を探す静的な表 (リージョンごとの AMI など) |
| Conditions | 条件に応じてリソースの作成可否を決定 |
| Resources | 実際に作成するリソース (唯一の必須セクション) |
| Outputs | 作成結果のエクスポート (他のスタックが参照) |
Parameters で環境の差を吸収し、Outputs と クロススタック参照 (Export/ImportValue) でスタックを分けて組み立てます。「VPC スタックとアプリケーションスタックを分離して連結せよ」の答えが Outputs export + ImportValue です。
変更セット (Change Set) とドリフト #
運用で最も重要な 2 つの機能です。
変更セット #
スタックを更新する前に 何が変わるかを事前に見る 機能です。特に一部の変更はリソースを 置換 (replacement) し、ダウンタイムやデータ損失を招きます (例: RDS の特定の属性変更)。変更セットで置換の有無を確認してから適用するのが安全な運用です。「本番スタックを更新するが影響範囲を事前に確認せよ」の答えが変更セットです。
ドリフト検出 (Drift Detection) #
スタックが作成したリソースを 誰かがコンソールで直接変更すると、実際の状態がテンプレートとずれます。これがドリフトです。ドリフト検出はテンプレートと実際のリソースを比較し、ずれたリソースと属性を報告 します。「IaC で作った環境だが誰が手作業で変えたか見つけよ」の答えがドリフト検出です。
スタック保護の仕組み #
| 仕組み | 役割 |
|---|---|
| Stack Policy | 更新中に特定のリソースを変更・置換から保護 |
| Termination Protection | スタック自体の誤削除を防止 |
| DeletionPolicy(Retain) | スタックを削除しても特定のリソース (DB・S3) は残す |
| Rollback | 更新・作成の失敗時に以前の状態へ自動復帰 |
運用の常連は DeletionPolicy: Retain です。スタックを削除してもデータベースや S3 バケットが一緒に消えてはいけないので、そのリソースに Retain をかけて保存します。
StackSets: 複数アカウント・リージョンへのデプロイ #
1 つのテンプレートを 複数のアカウントと複数のリージョンに一度にデプロイ・管理 する機能です。
- Organizations と連携して 新しいアカウントに自動で標準スタックをデプロイ
- セキュリティ基準線 (IAM ロール・ロギング・Config) を全アカウントに一括適用
- 一箇所で更新すれば全対象に伝播
「組織のすべてのアカウントに標準セキュリティ設定を一貫して敷き、新しいアカウントにも自動適用せよ」の答えが StackSets (+ Organizations) です。
他の IaC ツール: CDK・Terraform #
SOA-C03 は CloudFormation 以外のツールも範囲に入れています。関係を整理すると次のとおりです。
| ツール | 性格 |
|---|---|
| CloudFormation | AWS ネイティブ。宣言型テンプレート (JSON・YAML) |
| CDK | プログラミング言語 (TypeScript・Python など) で記述 → CloudFormation に合成 されてデプロイ |
| Terraform | サードパーティ (HashiCorp)。マルチクラウド。独自の状態ファイル (state) を管理 |
| SAM | サーバーレス特化。CloudFormation の拡張 |
核心となる区別は、CDK は結局 CloudFormation に変換 されてデプロイされる点、Terraform は AWS 外のリソースまで扱い、状態を独自ファイルで管理 する点です。「開発言語でインフラを記述しつつ AWS ネイティブなデプロイを使いたい」は CDK、「複数のクラウドを 1 つのツールで管理」は Terraform が正解です。
試験での出題パターン #
- スタック更新前の影響確認 → 変更セット (Change Set)
- IaC 環境の手動変更の追跡 → ドリフト検出
- スタック削除時の DB・S3 保存 → DeletionPolicy: Retain
- 更新中の特定リソース保護 → Stack Policy
- 全アカウント・リージョンへの標準デプロイ → StackSets + Organizations
- スタックの分離・連結 → Outputs Export + ImportValue
- 開発言語で IaC を記述、AWS ネイティブなデプロイ → CDK
よくある落とし穴 #
1) 更新が常に無停止だと考える #
一部の属性変更はリソースを 置換 します。変更セットで置換の有無を事前に見る必要があります。
2) ドリフトを CloudFormation が自動で防ぐと誤解する #
CloudFormation はドリフトを 検出・報告 するだけで、コンソールでの手動変更自体を防ぎはしません。変更を防ぐには IAM 権限で直接の修正を制限します。
3) StackSets なしでアカウントごとにスタックを別々に作る #
数十のアカウントに同じスタックを手作業でデプロイする答案は、運用負担を最小化する条件では誤答です。StackSets が定石です。
4) CDK が別のランタイムだと考える #
CDK は合成段階で CloudFormation テンプレートを生成 します。デプロイ・ドリフト・ロールバックは CloudFormation のものをそのまま使います。
まとめ #
この記事で押さえたこと:
- CloudFormation はインフラを テンプレート (コード) として宣言 し、スタック単位で作成・更新・削除する
- 変更セット で更新の影響 (特にリソースの置換) を事前に確認し、ドリフト検出 で手動変更を追跡
- DeletionPolicy: Retain でスタック削除時に DB・S3 を保存。Stack Policy・Termination Protection で保護
- StackSets + Organizations で複数アカウント・リージョンに標準を一括デプロイ
- CDK は CloudFormation に合成、Terraform はマルチクラウド + 独自の状態
次: Domain 3-2 Systems Manager #
インフラをコードでデプロイする方法を押さえたので、次は デプロイされたインスタンスを運用・管理するツール です。
#8 Domain 3-2 デプロイ: Systems Manager 運用自動化 では、Parameter Store で設定を管理する方法、Patch Manager でパッチを一括適用する方法、State Manager で望む状態を維持する方法、Session Manager でキーなしで接続する方法、そして Run Command と Automation まで整理します。