Amazon DVA-C02: CloudFormation と Infrastructure as Code (SAM, CDK) — 学習ガイド

By Laurynas Brazys · 28 July 2026 · #amazon #dva-c02 #certification #exam-prep #study-guide

こちらの一部です： AWS Developer Associate DVA-C02 — 学習ガイド. 検証済みの解答で練習： Amazon試験ハブ, または時間制限付き模擬試験に挑戦： ExamRoll.io.

CloudFormationのコアパターンとテンプレートのベストプラクティス

CloudFormationテンプレートは、宣言的でべき等なリソース記述として作成されるべきです。複雑なアーキテクチャには、小さく焦点を絞ったスタックやネストされたスタックを利用することが推奨されます。Resourcesセクションでは明示的な論理IDを使用し、構成と再利用のためには!Ref、!GetAtt、!Sub、Fn::FindInMap、Fn::Ifなどの組み込み関数を優先的に使用します。変更セットを作成する前に、aws cloudformation validate-templateや、SAM/CDKの同等コマンド（sam validate、cdk synth）でテンプレートを検証します。予期せぬ置換を避け、レビューを行うためにChangeSet（CreateChangeSet / ExecuteChangeSet）を使用します。スタックが実行するアクションを検査するにはDescribeChangeSetを使用します。大きなインラインコードをS3に移動して参照（CodeUri、S3Bucket/S3Key）するか、AWS::CloudFormation::Stackでネストされたスタックに分割することで、テンプレート本体をCloudFormationの制限内に収めます。DetectStackDriftとDescribeStackResourceDriftsを使用して、定期的にドリフト検出を実施します。データを保持するリソースを保護するためにDeletionPolicyとUpdateReplacePolicyを使用し、重要なスタックでは終了保護を有効にします。cfn-lintとcfn-guardをCI/CDに統合し、構造的な問題やポリシー違反を早期に検出します。迅速なイテレーションのためには、ChangeSetとリソースレベルの更新戦略を活用して影響範囲を最小限に抑えます。Lambda関数の場合は、バージョン管理されたデプロイを使用して、更新を安全かつ可逆的にします。

パラメータ化、マッピング、シークレット、機密データ

CloudFormationのParametersとMappingsで環境ごとの差異をパラメータ化し、AllowedValuesとConstraintDescriptionを使用して早期に失敗させます（フェイルファスト）。Parametersにシークレットや平文の認証情報を埋め込むことは避けてください。代わりに、SecureStringタイプのSSM Parameter StoreやSecrets Managerを使用し、{{resolve:secretsmanager:mysecret:SecretString:password}}のような動的参照やAWS::SSM::Parameter::Value<String>型で参照します。機密性の高いパラメータにはNoEcho: trueを設定してコンソールでの値をマスクしますが、NoEchoは保管時の暗号化を行わないことを認識してください。監査やローテーションのためにはSecrets Managerを使用します。決定論的で環境固有の値（リージョンごとのAMI IDなど）にはMappingsとFn::FindInMapを、アベイラビリティーゾーンの計算にはFn::GetAZsを使用します。同一リージョン/アカウント内のスタック間でリソースを参照するには、出力をエクスポートし、Fn::ImportValueでインポートします。インポートはアカウントやリージョンをまたげないことに注意してください。CloudFormationが使用するIAMプリンシパルは、最小権限でロールのスコープを限定して保護します。サービスマネージド型のStackSet権限を優先するか、限定されたスコープの管理ロールを明示的にプロビジョニングします。コンテナやLambdaに環境変数を渡す際は、Secrets ManagerのARNやSSM ParameterのARNを参照し、コード内で実行時に取得する方法を優先します。または、SAM/CDKの機能を使用して、KMSによる暗号化と共に安全な値を環境に注入します。

クロスアカウント/リージョンデプロイ、CDKおよびSAMのマルチアカウントパターン

クロスアカウントおよびクロスリージョンのデプロイには、単一スタックのエクスポートを超えるオーケストレーションが必要です。マルチアカウント/マルチリージョンのデプロイには、Organizations向けのサービスマネージド型のアクセス許可を持つCloudFormation StackSets（CreateStackSet、CreateStackInstances）か、ターゲットアカウントに実行ロールを配置するセルフマネージド型を選択します。アプリケーションコードのアーティファクトには、クロスアカウントレプリケーションやバケットポリシーを設定した中央集権的なS3バケットを使用するか、ツールにリージョンごとにアセットを発行させます。CDKはブートストラップスタックとcdk-assets経由で発行されるアセットを使用し、各アカウント/リージョンでcdk bootstrapが必要です。CDK Pipelines（pipelinesモジュール）や--role-arn付きのaws-cdk CLIは、クロスアカウントプロモーションをサポートします。SAMはsam package / sam deployを使用し、アーティファクトをS3バケットにアップロードします。マルチアカウントの場合は、CI/CDを使用してアーティファクトをパッケージングし、ターゲットアカウントのバケットにプッシュして、適切な認証情報でデプロイを実行します。synth時にアカウント固有の権限を必要とするCDKのコンテキストルックアップ（VPC.fromLookupなど）は避けてください。代わりに、synthの再現性を保つために、識別子をパラメータとして明示的に渡します。AWS CodePipelineやGitHub Actionsで引き受けたロール（sts:AssumeRole）を使用してターゲットアカウントへのデプロイを実行し、ブートストラップと必要なサービスにリンクされたロールが存在することを確認します。CloudFormationのエクスポートはリージョン単位であることを忘れないでください。クロスアカウントでの配布には、StackSetsやパイプライン駆動のデプロイを優先します。

カスタムリソース、スタック保護、およびローカル/インクリメンタルデプロイメントの高速化

CloudFormationにネイティブなリソースタイプがない場合は、カスタムリソースを使用します。Create/Update/Deleteイベントに対するCloudFormationの応答プロトコルに従う、Lambdaをバックエンドとするプロバイダーを実装します。べき等なハンドラーを構築し、cfn-responseまたはCloudFormation CLIフレームワークで応答し、長時間実行されるアクションは、進捗イベントを利用するか、DynamoDBに状態を保存することで処理します。カスタムリソースのタイムアウトに注意してください。CloudFormationにはスタック操作の最大タイムアウトがあり、Lambdaをバックエンドとするリソースはその時間内に完了しないと、スタックのロールバックを引き起こします。スタックポリシー（SetStackPolicy）で重要なリソースを保護し、スタック更新時に指定された論理IDの置換や更新をブロックします。また、削除してはならない環境には終了保護を有効にします。インクリメンタルなローカル開発には、AWS SAM CLI（sam build、sam local invoke、sam local start-api）と、コードのみの迅速な更新のためのsam syncを使用します。また、CDK watchや、アセット付きのcdk deployを使用して変更されたリソースのみを更新します。これらのツールはアセットハッシュ（lambda asset hashing）を計算するため、変更されたコードのみが再発行されます。安全なデプロイメントのために、CloudFormation ChangeSets、Lambdaのバージョニング（SAMのAutoPublishAliasまたはCDKのlambda.Version）、およびCodeDeployのトラフィックシフトを統合します。よくある落とし穴には、テンプレートやパラメータの制限超過、クロスアカウントインポートの不適切な使用、そして、ハンドラー内で重いSDKクライアントを初期化することによるコールドスタートのレイテンシー発生などがあります。タイムアウトやリトライ動作を設定可能な、グローバルで遅延初期化されるクライアントを使用することが望ましいです。

実践的な問題：ユースケースシナリオ

シナリオ：AcmeMedia社は、us-east-1リージョンにDev、Staging、Prodの個別アカウントを持つマルチアカウントAWS Organizationを管理しています。サーバーレスの画像処理サービス（Lambda + S3 + DynamoDB）を、中央で管理される共有の機密設定とともに、すべてのアカウントに一貫してデプロイする必要があります。

課題：同じCloudFormation/SAM/CDKスタックを複数のアカウントにデプロイし、テンプレートにシークレットを含めずに、各ターゲットアカウントでLambdaコードアーティファクトを安全に利用できるようにします。

推奨アプローチ：

サービスマネージド型のアクセス許可を持つAWS CloudFormation StackSetsを使用し（aws cloudformation create-stack-set --stack-set-name ImageProcessor --template-body file://template.yaml）、その後aws cloudformation create-stack-instancesでターゲットアカウントとリージョンを指定するか、CDK Pipelinesを設定してアカウントごとにロールを使ってsynthとデプロイを行います。
CDKのアセット発行機能（各アカウント/リージョンでcdk bootstrapを実行）またはsam packageを使用してLambdaアセットを各ターゲットアカウントのS3バケットにパッケージ化します。CI（aws s3 cpを使用するCodeBuildまたはS3レプリケーション）を介してアセットのコピーを自動化し、ターゲットアカウントの認証情報を使用してcdk deployまたはsam deployを実行します。
機密設定は各アカウントのAWS Secrets Managerに保存し、動的参照（{{resolve:secretsmanager:arn:aws:secretsmanager:us-east-1:123456789012:secret:ImageProcSecret:SecretString:apiKey}}）を介してテンプレートで参照するか、NoEchoパラメータを避け、Secrets Managerのレプリケーション機能でレプリケートされたシークレットをデプロイします。
ChangeSets（create-change-set、execute-change-set）を使用し、本番スタックで終了保護を有効にし、スタックポリシーを使用して更新時にDynamoDBテーブルやS3バケットが誤って置換されるのを防ぎます。

論理的根拠：StackSetsとパイプライン駆動のデプロイは、安全で監査可能なマルチアカウント/リージョンへの展開を提供します。一方、アセット発行とアカウントごとのシークレット管理は、認証情報をローカルに保ち、監査可能にします。ChangeSets、終了保護、およびスタックポリシーは、反復的なデプロイメント中のリスクを低減します。

← Amazon DynamoDB と NoSQL 設計 · すべてのドメイン · デプロイと CI →

これらの問題を練習する → · ExamRoll.ioで時間制限付き練習 →