Infrastructure as Codeと運用自動化 — CloudFormation・CDK・StackSets - AWS SAA-C03 合格と実務のためのAWS設計入門

学習者

CloudFormationって、AWSのリソースを作るYAMLを書くサービス、くらいの理解で止まっています。

CloudFormationは、AWSリソースをテンプレートとして定義し、スタックという単位で作成・更新・削除するサービスです。

SAA-C03では、CloudFormationの細かいテンプレート記法を暗記するよりも、どんな要件でInfrastructure as Codeを選ぶか、Change SetやDrift Detectionをどう使うか、複数アカウント・複数リージョンへどう展開するかを判断できることが重要です。

CloudFormationは、AWS構成をコードで再現可能にし、変更履歴を追跡しながら、複数リソースをスタックとしてまとめて管理するためのAWSネイティブなInfrastructure as Codeサービスです。

CloudFormationとは

CloudFormationでは、作りたいAWSリソースをテンプレートに書き、そのテンプレートからスタックを作成します。

テンプレートは「設計図」、スタックは「その設計図から作られたAWSリソースのまとまり」と考えると分かりやすいです。

用語	意味
Template	AWSリソースと設定を定義したJSONまたはYAMLのファイル
Stack	テンプレートから作成されたリソースのまとまり
Change Set	更新前に、どのリソースが追加・変更・削除されるか確認する仕組み
Drift Detection	手動変更などでテンプレートと実リソースがズレていないか検出する仕組み
StackSets	複数アカウント・複数リージョンへスタックを展開する仕組み
AWS CDK	TypeScriptやPythonなどのコードからCloudFormationテンプレートを生成する開発キット

先生

CloudFormationは「作成手順を自動化するサービス」ではなく、「あるべきAWS構成をコードで宣言して管理する仕組み」と捉えると理解しやすいです。

テンプレートとスタック

テンプレートの中心は Resources セクションです。ここに作成したいAWSリソースを定義します。

AWSTemplateFormatVersion: '2010-09-09'
Description: Simple S3 bucket example
 
Resources:
  AppBucket:
    Type: AWS::S3::Bucket
    Properties:
      VersioningConfiguration:
        Status: Enabled
 
Outputs:
  BucketName:
    Value: !Ref AppBucket

yaml

このテンプレートからスタックを作ると、CloudFormationがS3バケットを作成し、スタックの管理対象として扱います。

よく使うテンプレートセクション

セクション	役割
`Resources`	作成するAWSリソースを定義する。必須
`Parameters`	環境ごとに変えたい値を外から渡す
`Outputs`	作成したリソース名やARNなどを出力する
`Mappings`	リージョンや環境ごとの対応表を持つ
`Conditions`	条件に応じてリソース作成やプロパティを切り替える

試験では、細かい構文よりも「テンプレートを使うと、同じ構成を何度も再現できる」「スタック単位で変更・削除できる」という判断が問われます。

Change Setで変更前に差分を見る

CloudFormationの更新では、テンプレートやパラメータを変更すると、既存リソースに追加・変更・削除が発生します。

本番環境では、いきなり更新するのではなくChange Setで変更内容を確認します。

Change Setで確認したいポイントは次の通りです。

重要なリソースが削除されないか
RDSやEC2などが置き換えにならないか
セキュリティグループやIAMポリシーが意図せず広がらないか
更新対象が想定したリソースだけか

本番スタックの更新では、Change Setで差分を確認してから実行するのが基本です。

ただし、Change Setは「更新が必ず成功する」ことを保証するものではありません。権限不足、サービスクォータ、リソース側の制約などで更新に失敗することはあります。失敗時にはロールバックが発生するため、影響範囲を事前に把握しておくことが重要です。

Drift Detectionで手動変更を検出する

CloudFormationで管理しているリソースを、コンソールやCLIから直接変更すると、テンプレートの内容と実際のリソース設定がズレます。このズレをドリフトと呼びます。

たとえば、CloudFormationで作ったSecurity Groupに、運用中の一時対応として手動でインバウンドルールを追加した場合です。

CloudFormation Template
  -> Security Group: 443のみ許可
 
実際のAWSリソース
  -> Security Group: 443 + 22を許可

この状態を放置すると、次回のスタック更新で意図しない差分が出たり、セキュリティレビューで実態が追えなくなったりします。

Drift Detectionを使うと、スタックやリソースがテンプレート定義と一致しているかを確認できます。

状態	意味
`IN_SYNC`	テンプレートと実リソースが一致している
`DRIFTED`	実リソースがテンプレートからズレている
`NOT_CHECKED`	ドリフト検出の対象外、または未確認

実務では、手動変更を完全に禁止するよりも、「緊急対応で変更したらテンプレートへ反映する」「定期的にDrift Detectionを見る」といった運用ルールが重要です。

StackSetsで複数アカウント・複数リージョンに展開する

StackSetsは、CloudFormationスタックを複数のAWSアカウントや複数リージョンへ展開する機能です。

マルチアカウントとフェデレーションで扱ったように、実務では本番、ステージング、監査、共有サービスなど、複数アカウントに分けてAWS環境を管理することがあります。

このとき、各アカウントに共通のIAM Role、CloudTrail、Config、GuardDuty設定などを手作業で入れると、設定漏れや差分が起きやすくなります。

StackSetsが向いている例:

全アカウントに共通の監査用IAM Roleを作る
複数リージョンに同じネットワーク・監視設定を展開する
AWS Organizations配下の新規アカウントへ共通設定を配布する
セキュリティ基準を複数アカウントへ揃える

SAA-C03では、「複数アカウント・複数リージョンに同じCloudFormation構成を展開したい」という要件があれば、StackSetsを候補にします。

AWS CDKとの違い

AWS CDKは、TypeScript、Python、Java、C#、Goなどのプログラミング言語でAWSインフラを定義し、最終的にCloudFormationを通じてデプロイする仕組みです。

CloudFormationテンプレートを直接書く場合と、CDKを使う場合の違いは次の通りです。

選択肢	向いている場面
CloudFormation	AWSネイティブなIaCをYAML/JSONで明示的に管理したい
AWS CDK	プログラミング言語の抽象化、再利用、条件分岐、型チェックを使いたい
Terraform	AWS以外のクラウドやSaaSも含めて同じIaCツールで管理したい

CDKはCloudFormationの代替というより、CloudFormationテンプレートをより開発者向けに生成・管理するための層です。

import * as cdk from 'aws-cdk-lib';
import * as s3 from 'aws-cdk-lib/aws-s3';
 
export class AppStack extends cdk.Stack {
  constructor(scope: cdk.App, id: string) {
    super(scope, id);
 
    new s3.Bucket(this, 'AppBucket', {
      versioned: true,
    });
  }
}

typescript

このようなCDKコードは、内部的にはCloudFormationテンプレートへ変換され、CloudFormationスタックとしてデプロイされます。

学習者

試験ではCDKとCloudFormationをどう見分ければいいですか？

問題文が「プログラミング言語でインフラを定義したい」「再利用可能な構成部品を作りたい」と言っていればCDKが候補です。一方で、「AWSネイティブにテンプレートでリソースをプロビジョニングしたい」「Change SetやStackSetsを使いたい」という文脈ではCloudFormationが中心になります。

CloudFormationを選ぶ問題文

SAA-C03では、CloudFormationは「AWSリソースをコードで一貫して管理したい」要件で出てきます。

問題文の表現	選ぶ候補
同じAWS構成を複数環境に再現したい	CloudFormationテンプレート
本番更新前に差分を確認したい	Change Set
手動変更で設定がズレていないか確認したい	Drift Detection
複数アカウント・複数リージョンへ同じ構成を展開したい	StackSets
TypeScriptやPythonでインフラを定義したい	AWS CDK
インフラ変更をGitでレビューしたい	Infrastructure as Code

関連する判断として、監査ログやイベント検知は監視と運用、マルチアカウント管理はマルチアカウントとフェデレーション、バックアップや復旧は災害対策と復旧設計と組み合わせて考えます。

よくあるハマりどころ

テンプレート外の手動変更を放置する

コンソールで直接変更すると、目の前の問題は解決してもテンプレートとの差分が残ります。緊急対応として手動変更した場合も、後でテンプレートへ反映し、必要ならDrift Detectionで状態を確認します。

1つの巨大なスタックに詰め込みすぎる

VPC、アプリ、DB、監視、IAMをすべて1つのスタックにすると、更新影響が大きくなります。ライフサイクルが違うものはスタックを分けると運用しやすくなります。

例:

ネットワーク基盤スタック
アプリケーションスタック
監視・通知スタック
共通IAM・監査スタック

CloudFormationはAWSネイティブなInfrastructure as Codeサービス。テンプレートからスタックを作り、複数リソースをまとめて管理する
本番更新ではChange Setで差分を見てから実行する
手動変更によるズレはDrift Detectionで検出する
複数アカウント・複数リージョンへ同じ構成を配るならStackSetsを使う
CDKはプログラミング言語でインフラを定義し、CloudFormation経由でデプロイする

この本を読み終えたら、模擬問題を解きながら「なぜそのサービスが正解で、なぜ他が不正解か」を言語化していきましょう。

AWSクイズに挑戦するこの章で学んだAWSの知識を、4択クイズでアウトプットして定着させよう

Infrastructure as Codeと運用自動化 — CloudFormation・CDK・StackSets