AWS認定資格 WEB問題集&徹底解説DevOpsエンジニア プロフェッショナル(DOP)

AWS Cloud Development Kit (CDK) の概要と試験出題ポイントは?

AWSサービスの一つであるAWS Cloud Development Kit (CDK)はどんな内容なのでしょうか?また、AWS認定資格のDevOpsエンジニア-プロフェッショナル(DOP)に合格するためには、サービスのどんなポイントを押さえておけばよいのでしょうか?
ここでは、そんなあなたの疑問に回答していきたいと思います

AWS CDK(Cloud Development Kit) 徹底解説 | AWS認定試験の頻出ポイントまとめ

1. サービス概要

AWS Cloud Development Kit(AWS CDK)は、TypeScript、JavaScript、Python、Java、C#/.NET、Goといった汎用プログラミング言語でクラウドインフラを定義し、AWS CloudFormationを通じてプロビジョニングするオープンソースのIaCフレームワークです。 ループや条件分岐、IDEの補完、単体テストといったソフトウェア開発の道具立てをインフラ定義に持ち込めます。

CDKは大きく2つの部品からなります。再利用可能な部品群であるConstruct Library(v2ではaws-cdk-libに統合)と、合成やデプロイを行うCDK Toolkit(コマンドラインのCDK CLIと、プログラムから呼び出すCDK Toolkit Library)です。 CDK v1は2023年6月1日にサポートを終了しており、現在はv2が対象です。CDK CLIはConstruct Libraryとは別の版番号(2.1000系)でリリースされています。

試験では、「CDKのコード → CloudFormationテンプレートへ合成 → CloudFormationがデプロイ」という関係を軸に、ブートストラップ、cdk synth/diff/deploy、コンストラクトのレベル、CDK Pipelinesによるマルチアカウント展開が問われます。

2. 主な特徴と機能

2.1 コンストラクトの3つのレベル

  • L1(CFNリソース): CfnBucketのようにCfnで始まり、CloudFormationのリソース型と1対1に対応する。全プロパティを自分で指定する。
  • L2(キュレーテッド): s3.Bucketやlambda.Functionなど、安全な既定値と便利なメソッドを備えた高水準の部品。bucket.grantRead(fn)のようなgrantメソッドで最小権限のIAMポリシーを自動生成できる。
  • L3(パターン): ecs_patterns.ApplicationLoadBalancedFargateServiceのように、複数のリソースを組み合わせた構成一式を少ないコードで定義する。

2.2 App・Stack・Stage・Construct

CDKアプリ(App)の中にスタック(Stack)を置き、スタックの中にコンストラクトを木構造で積み上げます。1つのStackが1つのCloudFormationスタックになります。複数スタックをまとめて1つの環境(開発・本番など)として扱う単位がStageです。 CloudFormationの論理IDはコンストラクトの木構造上のパスから決まるため、コンストラクトのIDや親を変えると論理IDが変わり、リソースが作り直される点に注意します(コードの整理でリソースを保ったまま移すにはcdk refactorを使う)。

2.3 環境とコンテキスト

スタックにアカウントとリージョン(env)を指定すると環境固定のスタックになり、Vpc.fromLookup()のような既存リソースの参照(コンテキストルックアップ)が使えます。 ルックアップ結果はcdk.context.jsonにキャッシュされるため、このファイルをリポジトリにコミットして合成結果を再現可能にするのがベストプラクティスです。

2.4 テストとガバナンス

  • assertionsモジュール: Template.fromStack()で合成結果を取り出し、hasResourceProperties()などでリソースの有無やプロパティを検証する(きめ細かいテスト)。テンプレート全体を保存して差分を見るスナップショットテストも書ける。
  • Aspects: コンストラクトの木全体を巡回して、設定の検査や一括変更を行う仕組み。暗号化の強制、タグ付け、cdk-nagのようなルールチェックに使う。
  • RemovalPolicy: S3バケットやDynamoDBテーブルなどステートフルなL2リソースは既定でRETAIN(スタック削除時も残る)。開発環境で消したい場合はDESTROYを明示する。

2.5 既存資産との連携

  • CfnInclude: 既存のCloudFormationテンプレートをCDKアプリに取り込み、段階的にCDKへ移行する。
  • エスケープハッチ: L2で表現できないプロパティは、配下のL1リソースを取り出してaddPropertyOverride()などで直接上書きする。

3. アーキテクチャおよび技術要素

  1. 開発者がCDKアプリ(コード)を書き、cdk synthでクラウドアセンブリ(cdk.out:CloudFormationテンプレート、アセット、マニフェスト)を合成する。
  2. cdk deployは、アセットをブートストラップ済みのS3バケット/ECRリポジトリへ公開する(ファイル公開用・イメージ公開用のロールを引き受ける)。
  3. CDK CLIがデプロイ用ロールを引き受けてCloudFormationの変更セットを作成・実行する。
  4. CloudFormationはCloudFormation実行ロールの権限で実リソースを作成・更新し、失敗時はロールバックする。

ブートストラップは、デプロイ先のアカウント×リージョンごとに1回必要な準備作業です。cdk bootstrapでCDKToolkitスタックが作られ、アセット用のS3バケット、ECRリポジトリ、5つのIAMロール(CloudFormation実行・デプロイ・ファイル公開・イメージ公開・ルックアップ)、バージョンを示すSSMパラメータが用意されます。 未実施の環境へデプロイすると「/cdk-bootstrap/hnb659fds/version が見つからない」というエラーになります。再実行すれば新しいテンプレート版へ更新されます。

4. セキュリティと認証・認可

  • ブートストラップロール: デプロイ操作は利用者の認証情報を直接使わず、ブートストラップで作られたロールを引き受けて行う。これによりクロスアカウントのデプロイが可能になる。
  • 実行ポリシーの制限: CloudFormation実行ロールに付けるポリシーは--cloudformation-execution-policiesで指定する。既定は広い権限のため、組織では許可範囲を絞ったポリシーを渡す。
  • クロスアカウントの信頼: パイプライン用アカウントからデプロイさせる場合、デプロイ先をcdk bootstrap --trust パイプラインのアカウントIDで準備する。
  • ブートストラップスタックの保護: 削除するとパイプラインが動かなくなるため、--termination-protectionで削除保護を付ける。
  • 権限変更の承認: cdk deployはIAMポリシーやセキュリティグループを広げる変更を検知すると既定で確認を求める(--require-approvalで制御)。cdk diffでもIAM変更が一覧表示される。

5. 料金形態

AWS CDKはオープンソースで無料です。料金はCDKで作成したAWSリソースの利用料として発生します。

  • CloudFormation: AWSのリソース型を扱う限り、CloudFormation自体の追加料金はない(サードパーティのリソース型やフックなど一部の拡張操作は課金対象)。
  • ブートストラップ資源: アセット用S3バケットとECRリポジトリの保存料金がかかる。古いアセットはcdk gcで整理できる。
  • CDK Pipelines: 実体はCodePipelineとCodeBuildなので、それらの料金が発生する。

6. よくあるアーキテクチャ・設計パターン

  • CDK Pipelinesによるマルチアカウント展開: ツール用アカウントにパイプラインを置き、開発・ステージング・本番アカウントを--trust付きでブートストラップする。Stage単位でデプロイし、本番の前にManualApprovalStepやテスト用のShellStepを挟む。
  • 自己更新(セルフミューテーション): CDK Pipelinesはパイプライン自身の定義もCDKコードから更新する。ステージを追加するコードをコミットすれば、パイプラインが自分を作り替えてから新しいステージへデプロイする。
  • 社内標準コンストラクトの配布: 暗号化・ログ・タグなどの標準を組み込んだ独自コンストラクトをライブラリ化し、AWS CodeArtifactで社内配布する。Service CatalogのProductStackと組み合わせて製品として提供することもできる。

7. 設定・デプロイ手順(ハンズオン例)

  1. CDK CLIをインストールする: npm install -g aws-cdk
  2. プロジェクトを作成する: cdk init app --language typescript
  3. デプロイ先をブートストラップする: cdk bootstrap aws://123456789012/ap-northeast-1
  4. テンプレートを合成して確認する: cdk synth
  5. デプロイ済みスタックとの差分を確認する: cdk diff
  6. デプロイする: cdk deploy(IAMの変更があれば確認プロンプトが出る)
  7. 開発中はコード変更を素早く反映する: cdk watch または cdk deploy --hotswap(CloudFormationを経由せず一部リソースを直接更新するため、開発環境専用)
  8. 不要になったら削除する: cdk destroy

8. 試験で問われやすいポイント

8.1 CDKとCloudFormationの関係

  • Q: CDKで定義したインフラは何を通じてデプロイされる?
    A: CDKがCloudFormationテンプレートを合成し、CloudFormationスタックとしてデプロイされる。ロールバックやドリフト検出などもCloudFormationの仕組みを使う。
  • Q: 既存のCloudFormationテンプレート資産を活かしながらCDKへ移行するには?
    A: CfnIncludeでテンプレートを取り込み、段階的にL2へ置き換える。

8.2 ブートストラップ

  • Q: 初めてのデプロイで「SSMパラメータ /cdk-bootstrap/.../version が見つからない」と失敗した。対処は?
    A: そのアカウント・リージョンでcdk bootstrapを実行する。
  • Q: ブートストラップの単位は?
    A: アカウント×リージョンごと。新しいリージョンへ展開する前にも必要。
  • Q: 別アカウントのパイプラインから本番アカウントへデプロイさせるには?
    A: 本番アカウントをcdk bootstrap --trust パイプラインのアカウントID --cloudformation-execution-policies ポリシーARNで準備する。

8.3 CLIコマンド

  • Q: デプロイせずにCloudFormationテンプレートを生成・確認するコマンドは?
    A: cdk synth(出力先はcdk.out)。
  • Q: デプロイ済みスタックと比べて何が変わるか(IAM変更を含む)を事前に確認するには?
    A: cdk diff。
  • Q: Lambdaのコード修正を開発環境に数秒で反映したい場合は?
    A: cdk deploy --hotswapまたはcdk watch。CloudFormationを迂回してドリフトを生むため本番では使わない。

8.4 コンストラクト

  • Q: CloudFormationの新しいプロパティがL2で未対応の場合は?
    A: L1(Cfn*)を使うか、エスケープハッチで配下のL1プロパティを上書きする。
  • Q: LambdaにS3バケットの読み取り権限を最小権限で与える簡単な方法は?
    A: bucket.grantRead(fn)。必要なIAMポリシーが自動生成される。

8.5 CDK Pipelinesとテスト

  • Q: パイプラインにステージを追加したとき、パイプライン自体の更新を手作業でしないで済む理由は?
    A: CDK Pipelinesは自己更新(セルフミューテーション)するため、コードの変更をコミットすればパイプラインが自分自身を更新する。
  • Q: 本番デプロイの前に承認を入れるには?
    A: 本番Stageの事前ステップにManualApprovalStepを置く。
  • Q: 合成されたテンプレートに暗号化設定が入っているかをCIで検証するには?
    A: assertionsモジュールのTemplate.fromStack()とhasResourceProperties()で単体テストを書く。全リソースへの一括チェックはAspectsやcdk-nagを使う。
  • Q: 同じコードから毎回同じテンプレートを合成させるためにコミットすべきファイルは?
    A: コンテキストルックアップの結果を保存するcdk.context.json。