クラウド

AWS CDKとは：CloudFormationとの違いと安全なデプロイ

2026/10/18 シリーズ「AWS 入門」 第10回 / 全10回

🤖 AIを使用して執筆

const table = new dynamodb.Table(this, 'Reservations', {
  partitionKey: { name: 'book_id', type: dynamodb.AttributeType.STRING },
  sortKey: { name: 'reserved_at', type: dynamodb.AttributeType.STRING },
  billingMode: dynamodb.BillingMode.PAY_PER_REQUEST,
});

const reserve = new lambda.Function(this, 'Reserve', {
  runtime: lambda.Runtime.NODEJS_22_X,
  handler: 'index.handler',
  code: lambda.Code.fromAsset('lambda'),
  environment: { TABLE_NAME: table.tableName },
});

table.grantReadWriteData(reserve);

Reservations25D4BAC6:
  Type: AWS::DynamoDB::Table
  Properties:
    BillingMode: PAY_PER_REQUEST
    KeySchema:
      - AttributeName: book_id
        KeyType: HASH
      - AttributeName: reserved_at
        KeyType: RANGE
  UpdateReplacePolicy: Retain
  DeletionPolicy: Retain

[-] AWS::DynamoDB::Table Reservations Reservations25D4BAC6 orphan
[+] AWS::DynamoDB::Table BookReservations BookReservations2E349B66
[~] AWS::IAM::Policy Reserve/ServiceRole/DefaultPolicy ReserveServiceRoleDefaultPolicyB7E9687B
[~] AWS::Lambda::Function Reserve Reserve3206C117

const live = new lambda.Alias(this, 'Live', {
  aliasName: 'live',
  version: reserve.currentVersion,
});

const errors = new cloudwatch.Alarm(this, 'LiveErrors', {
  metric: live.metricErrors({ period: Duration.minutes(1) }),
  threshold: 1,
  evaluationPeriods: 1,
  comparisonOperator: cloudwatch.ComparisonOperator.GREATER_THAN_THRESHOLD,
});

new codedeploy.LambdaDeploymentGroup(this, 'Deploy', {
  alias: live,
  deploymentConfig: codedeploy.LambdaDeploymentConfig.CANARY_10PERCENT_5MINUTES,
  alarms: [errors],
});

AWS CDK とは：プログラミング言語で書き、CloudFormation で配備する

AWS CDK は、クラウドの構成をコードで定義し、AWS CloudFormation を通して配備する、オープンソースの開発フレームワークである²。使える言語は TypeScript、JavaScript、Python、Java、C#、Go の六つである²。CDK 自体は TypeScript で作られ、ほかの言語からは、JSII という道具で作った対応の部品を通して使う¹⁶。

CDK を使うこと自体は無料である。払うのは、CDK で作った資源の料金で、画面から作ったときと変わらない¹⁷。今使うのはバージョン 2 で、バージョン 1 のサポートは 2023 年 6 月 1 日に終わった²。コマンドの道具（CDK CLI）と、資源を書くための部品の集まり（AWS Construct Library）は、別々に版を重ねる。部品の集まりの各版は、それが出た時点の CLI と組み合わせて使える。サポートが続いている部品の集まりを使っている限り、CLI の版を上げるのは常に安全だと、AWS は書く¹⁸。

アプリ、スタック、コンストラクト

CDK のプロジェクトの中に、CDK のアプリを一つ作る。アプリの中にスタックを書き、スタックの中に、資源と設定をコンストラクトで書く。CDK のスタックは、CloudFormation のスタックにそのまま当たる¹⁹。スタックは、配備の単位である。一つのスタックの中のものは、まとめて配備される²⁰。

コンストラクトは、抽象の度合いで三つの段に分かれる²¹。

L1 は、CloudFormation の資源と一対一に対応し、抽象化をしない。たとえば CfnBucket は、AWS::S3::Bucket に当たる²¹。L2 は CDK の開発チームが作り、よく使われる。安全な既定の設定や、権限の書き方を含む²¹。DynamoDB の表を表す dynamodb.Table は L2 で、その grantReadWriteData は、表を読み書きする許可を与える。CloudFormation に新しく加わった資源や設定が L1 として使えるようになるまでに、最大で一週間ほどかかることがある²¹。L3 は、システムの大きな部分をまとめて作るためのもので、使い方を想定して選んだ既定の設定を持つ²¹。AWS の CDK の紹介のページに載っている、短い L3 のコードからは、500 行を超えるテンプレートと、50 を超える資源ができる²。

cdk synth、cdk diff、cdk deploy

CDK の主なコマンドは三つである。

cdk synth が作るものを、クラウドアセンブリという。スタックごとのテンプレートと、関数のコードやコンテナのイメージなどのファイル（アセット）の写しを含む⁵。cdk diff は、既定では CloudFormation の変更セットを作って、置換が起きるかどうかまで正しく示す。変更セットを作れないときは、テンプレートどうしの比較に切り替える。こちらは速いが、正確さは劣る¹¹。[~] が付いても、作り直しになるとは限らない。関数のコードを変えても関数は更新されるだけだが、関数の名前を変えると作り直しになることがある¹¹。

cdk deploy は、既定で変更セットを作ってから配備する。変更セットを作るだけで配備しない方法もあり、別の道具や人の承認を挟むときに使う¹⁰。許可の範囲を広げる変更（IAM の許可やセキュリティグループの規則）があれば、既定で承認を求める¹⁰。ほかに、CloudFormation を通さずに関数のコードなどを直接差し替える --hotswap がある。これは、テンプレートと実際の資源とのずれ（ドリフト）をわざと生むので、開発の環境だけで使い、本番では使わないよう、AWS は書いている¹⁰。

ブートストラップ

アセットを含むスタックを配備するには、アカウントとリージョンの組ごとに、一度ブートストラップをする。CDK は CDKToolkit というスタックで、ファイルを置く S3 のバケット、コンテナのイメージを置く ECR のリポジトリ、配備に使う IAM のロールを作る⁸。このロールのうち一つは、CloudFormation が配備を行うためのロールで、既定では、そのアカウントのどの資源も読み書きできる²²。誰がこのロールを使えるかは、ブートストラップのときに決める。

CloudFormation とは：テンプレートからスタックを作り、変える

CloudFormation は、テンプレートに書いた資源を作り、設定する²³。資源は、スタックという単位でまとめて作り、更新し、削除する¹。CDK を使うときも、資源を実際に作り、変え、失敗したときに戻すのは CloudFormation である。CDK のベストプラクティスでは、CloudFormation は、CDK が確実な配備のために使う実装の詳細として扱う²⁰。それでも、変更が何を起こすかは、CloudFormation の規則に従う。

変更セットと、三つの更新のしかた

変更セットは、スタックへの変更が、動いている資源にどう影響するかを、前もって示す一覧である。作った時点では、スタックは何も変わらない²⁴。CloudFormation が資源を更新するしかたは、変える設定によって三つに分かれる²⁵。

置換では、CloudFormation は、たいてい新しい資源を先に作り、ほかの資源からの参照を付け替え、古い資源を消す²⁵。たとえば RDS のデータベースのポート番号を変えると、新しいデータベースが作られ、古いデータベースは消される²⁵。バックアップを取っていなければ、古いデータベースのデータは失われる¹。どの設定が置換になるかは、資源の種類ごとの文書に書いてある。

変更セットを作るとき、CloudFormation は、設定の書き方の誤り、名前のぶつかり、上限などの、よくある失敗の原因を前もって調べる。文書には、六種類の検査が載っている（2026 年 10 月の時点）²⁶。それでも、変更セットは更新の成功を保証しない²⁴。

失敗すると、既定では巻き戻す

スタックの作成や更新が途中で失敗すると、CloudFormation は、既定では、それまでの変更を戻して前の安定した状態に戻す¹⁰。巻き戻しの途中で、戻せない変更に当たることもある。たとえば、CloudFormation の外で消されたデータベースに戻ろうとしたときである。このとき、スタックは UPDATE_ROLLBACK_FAILED という状態になり、そのままでは更新できない。原因を取り除いて巻き戻しを続けるか、スタックを消すしかない²⁷。

2026 年 6 月 30 日には、資源が安定するのを待たずに完了とする「エクスプレスモード」が加わった。このモードでは、既定で巻き戻しをしない²⁸。CDK の文書は、本番の配備には勧めないと書く¹⁰。一方、AWS のブログの発表は、本番の場面も使い道に挙げている²⁹。

消さない、変えさせないための指定

テンプレートでは、DeletionPolicy と UpdateReplacePolicy に Retain を書くと、元の資源を消さずに残せる。DeletionPolicy は、スタックを消したときや、資源がスタックから外れたときに³⁰、UpdateReplacePolicy は、置換のときに³¹、元の資源をどうするかを決める。何も書かなければ、CloudFormation は資源を消す。スタックから外すときの RDS のデータベースの多くは例外で、既定でスナップショットを取ってから消す³⁰。置換のときは、RDS でも既定で消す³¹。CDK では、RemovalPolicy を一つ書けば、この二つが書き出される。データを持つ多くの L2 は、既定で残す（RETAIN）⁷。

スタックポリシーを付けると、指定した資源への更新を止められる。CloudFormation の文書は、これを誤った更新を防ぐための安全装置とし、誰に何を許すかは IAM で決めるよう書いている³²。

データベースのように状態を持つ資源は、状態を持たない資源とは別のスタックに置き、そのスタックに削除の保護を付ける。CDK のベストプラクティスが、そう勧めている。そうすれば、状態を持たないスタックは、データを失う心配なく消したり作り直したりできる。状態を持つ資源は、コンストラクトの名前を変えると置換になることにも、注意を促している²⁰。名前を変えても資源を作り直さずに動かす cdk refactor は、2026 年 10 月の時点でプレビューである³³。

CDK と CloudFormation の違いと、どちらで書くか

CloudFormation のテンプレートは宣言型で、望む状態をそのまま書く。CDK では、汎用のプログラミング言語で、手続きとして構成を組み立てられる¹⁹。繰り返しや条件、部品の再利用を、ふつうのプログラムと同じように書ける。DynamoDB の表を読み書きする許可を関数に与える grantReadWriteData のように、一行から許可のポリシーを作らせることもできる。

この違いには、実務者からの異論もある。2022 年の記事で、iRobot の研究者で AWS Serverless Hero と紹介されている Ben Kehoe は、cdk synth はコンパイラではなく、資源の定義をある言語から別の言語へ、情報を落としながら変える変換器だと書いた³⁴。Kehoe は、同じコードから毎回違う構成ができうる書き方を許すことにも、開発者の意図が手元のコードの中に留まり、AWS の側には変換した後のテンプレートしか渡らないことにも反対している³⁴。サーバーレスの開発者 Yan Cui は、2023 年の記事で、汎用の言語で構成を書けることは「恵みでもあり、呪いでもある」とし、決まった構造がないので、人ごとに作りがばらばらになると書いた。そのうえで、CDK を勧められる場面もあると述べている³⁵。CDK の開発チームの Adam Ruka は、2021 年 12 月、ポッドキャストでの CDK への批判に答えたブログで、CDK は、同じコードからいつも同じテンプレートができるように書くことを強く勧めていると書いた³⁶。

CloudFormation で直接書くか、CDK で書くかは、チームが読み書きしやすい方で選んでよい。ただ、CDK を使っても、変更が置換になるか、巻き戻しがどう進むかは、CloudFormation の規則に従う。CDK で書くチームも、変更セットと CloudFormation の資源の文書を読めるようにしておく必要がある。

変更を安全に出す：小さく、一部から、自動で戻す

AWS の考え方：運用上の優秀性の柱

Well-Architected フレームワークの運用上の優秀性の柱は、設計原則の一つに「可能な場合は安全に自動化する」を挙げ、アプリケーション、インフラ、設定、手順をコードで定義し、速度の制御、エラーのしきい値、承認といった歯止めを組み込むよう書く³。デプロイのリスクを減らすための四つのベストプラクティスは、次のとおりである³⁷。

三つ目は、すべての本番にいっぺんに失敗する変更を出して、すべての利用者に同時に影響が出ることを、避けるべき例に挙げる³⁸。四つ目は、期待した結果が得られないときや自動のテストに失敗したときに、ロールバックが自動で始まるようにする³⁹。

Amazon の配備のしかた：段階を踏み、待ち、鳴れば戻す

AWS の技術者 Clare Liguori は、Amazon Builders’ Library の記事で、Amazon の典型的な配備の流れを説明している⁴。変更は、ソース、ビルド、テスト、本番の四つの段を通る。本番の前に、alpha、beta、gamma といった本番前の環境で試す。本番でも、まず一台の仮想マシンや一つのコンテナ、Lambda の呼び出しのわずかな割合といった、最小の単位にだけ出す「ワンボックス」の段を置く⁴。ワンボックスに回る要求はわずかなので、サービス全体のアラームは鳴らないことがある。そこで、ワンボックスが受けた要求だけのメトリクスでも巻き戻す⁴。Lambda でも、別名を通した呼び出しのメトリクスを、実際に動いた版ごとに分けて見られる¹²。

本番へは、大きさを段々に増やす「波」に分けて出す。最初の波は、要求の少ないリージョンに出す⁴。各段の後には待ち時間（ベイクタイム）を置く。典型的な流れでは、ワンボックスの後に 1 時間以上、最初の波の後に 12 時間以上、残りの波のそれぞれの後に 2〜4 時間以上待つ。すべてのリージョンに出るまでに、営業日で 4〜5 日かかる⁴。待ち時間には、「作成の API に 100 回以上の要求が来るまで待つ」のように、データの数の条件も付ける⁴。待っている間に、チームの重大度の高いアラームが鳴れば、配備は自動で巻き戻る⁴。

Amazon でソフトウェア開発の管理職だった Mark Mansour は、かつてコードを入れてから本番に出るまで平均 16 日かかり、そのうち 14 日近くは、人が次の作業を始めるのを待つ時間だったと書いている⁴⁰。自動化は、配備を遅くするためではなく、待ち時間を減らして速く出すためのものである。

外部にも、同じ方向の考え方がある。Google の SRE の本は、カナリアを、変更をサービスの一部にだけ、期間を限って出して評価することと定義し、欠陥をできるだけ早く、サービスへの影響をできるだけ小さく見つけられるとする⁴¹。カナリアリリースという名前は、炭鉱にカナリアを連れて入り、安全を確かめた習慣から来ている⁴¹。Danilo Sato も、カナリアリリースでは、問題が見つかれば利用者を古い版へ回し直すだけで戻せると書く⁴²。

時間で止めるか、いつでも出すか

Liguori は、多くのチームが金曜日と夕方の遅い時間を配備の時間帯から外していると書く。配備の後に、夜や週末に当番の技術者を呼び出すリスクを減らすためである⁴。Liguori の記事より前の 2019 年に、Charity Majors はブログで逆の立場を取っていた。Majors のチームは、いつも一定の速さで出しているときの方がシステムが安定すると分かったので、金曜日や休日にも配備を止めないことにした。Majors は、問題は金曜日ではなく、速いフィードバックの循環だとした⁴³。どちらも、変更を小さく頻繁に出すことには賛成している。分かれているのは、時間帯で止めることが、リスクを減らすのか、変更をためて大きくするのかという点である。Liguori 自身も、時間帯を狭くしすぎると、閉じている間に変更がたまると書いている⁴。

AWS で段階的に出す仕組み

AWS では、段階的なデプロイを、サービスごとの仕組みで組む。Lambda では、別名に二つの版を重みを付けて結び付け、要求を分けられる¹²。CodeDeploy は、Lambda と Amazon ECS のための、決まった配分を用意している¹³。

CodeDeploy は、配備に失敗したときや、指定したアラームが鳴ったときに、前の版を新しい配備として出し直して巻き戻す⁴⁴。Amazon ECS には、失敗した配備を、前に完了した配備へ自動で戻すデプロイサーキットブレーカーがある⁴⁵。2025 年には、ECS の中だけでブルー/グリーンのデプロイ（7 月）と、線形とカナリアのデプロイ（10 月）ができるようになり、CloudWatch のアラームで失敗を見つけて巻き戻せる⁴⁶⁴⁷。

CloudFormation にも、ロールバックトリガーがある。スタックの作成や更新の間と、その後の最大 180 分の監視の時間に、指定した CloudWatch のアラームが ALARM になれば、操作を巻き戻す⁴⁸。付けられるアラームは五つまでで、既定では、データが足りない状態（INSUFFICIENT_DATA）では巻き戻さない⁴⁸。

一部から出す方式は、要求が少ないと効きにくい。Lambda の文書は、要求が少ないと、設定した割合と実際の割合が大きくずれうると書く¹²。SRE の本も、わずかな要求を受けただけでカナリアを終えても、さまざまな要求を受けるシステムでは役に立つ判断材料にならないと書く⁴¹。

巻き戻せない変更：データの形と二段階のデプロイ

自動の巻き戻しで戻るのは、コードと設定である。Amazon の技術者 Sandeep Pokkunuri は、Amazon Builders’ Library の記事で、新しい版に上げるときにも、古い版に戻すときにも、ソフトウェアがうまく動かないことがあると書く⁴⁹。状態を持つソフトウェアでは、新しい版は古い版が書いたデータを読めなければならず、古い版も新しい版が書いたデータを読めなければならない⁴⁹。

そのために使うのが、二段階のデプロイである。Pokkunuri は、データの形を XML から JSON に変える場合を説明している。一段目では、すべてのサーバーが JSON も読めるようにするが、書くのは XML のままにする。二段目で、JSON で書き始める⁴⁹。二段目を巻き戻しても、一段目の版は JSON を読めるので、壊れない。Amazon は、配備のたびに、進める向きにも戻す向きにも安全かを確かめている⁴⁹。Sato も、カナリアリリースでは、データベースが新旧の両方の版を支えられるように変更を管理する必要があると書く⁴²。

CloudWatch と CloudTrail：変化を見る、誰が変えたかを見る

CloudWatch：メトリクスとアラーム

自動で巻き戻すには、何が「失敗」かを、機械が読める数で決めておく必要がある。Amazon CloudWatch は、AWS の資源と、その上で動くアプリケーションを監視するサービスである⁵⁰。CloudWatch は、メトリクス（時間とともに記録する数値）を集める。メトリクスは名前空間ごとにまとまり、次元（名前と値の組）で見分ける⁵¹。Lambda は、呼び出しの回数（Invocations）やエラーの数（Errors）などのメトリクスを CloudWatch に送る⁵²。

アラームは、一つのメトリクスか、メトリクスの式を見張る⁵³。状態は、しきい値の内側にある OK、外側にある ALARM、データが足りず判断できない INSUFFICIENT_DATA の三つである⁵⁴。アラームは、期間（一つのデータ点を作る時間の長さ）、評価期間（直近のいくつのデータ点を見るか）、アラームを実行するデータポイント（そのうちいくつがしきい値を超えたら ALARM にするか）で決まる⁵⁴。データが届かないときの扱いも決められる。CloudWatch の文書は、いつもデータを出すメトリクスで巻き戻しのためのアラームを作るなら、データが届かないことを異常とみなす設定を考えるよう書く⁵⁵。CloudWatch には、アプリケーションのログを集める CloudWatch Logs もある⁵⁶。

資源の数値に加えて事業の数値も記録し、ロールバックなどの判断の自動化に使う。これも CDK のベストプラクティスにある勧めである²⁰。

CloudTrail：誰が、いつ、何をしたか

AWS CloudTrail は、利用者、ロール、AWS のサービスが行った操作を、イベントとして記録する⁵⁷。資源を作る、設定を変えるといった管理の操作は管理イベント、資源の中のデータへの操作はデータイベントとして分けて記録する⁵⁸。過去 90 日の管理イベントは、イベント履歴として、リージョンごとに料金なしで見られる⁵⁷。それより長く残すには、証跡（トレイル）を作り、S3 のバケットに送る⁵⁷。

CloudFormation の API の呼び出しは、すべて CloudTrail に記録される⁵⁹。2024 年に、自分たちの道具を CDK の上に作るのをやめた SST のブログは、CloudFormation の失敗の知らせが大まかすぎるときは、CloudTrail で元のイベントとエラーの文を見るとよいと書いている⁶⁰。同じブログは、巻き戻しの途中で失敗してスタックを更新できなくなる状態を「ロールバック地獄」と呼び、本番へ大きな更新を出したチームから、多くの相談を受けたと書いている⁶⁰。

段階的に出しても防げない障害：2021 年の東京の Direct Connect

段階的なデプロイは、影響の範囲を小さくし、見つけるための時間を稼ぐ。ただし、すべての欠陥を見つけられるわけではない。2021 年 9 月 2 日、東京リージョンで、自社のネットワークと AWS を専用線でつなぐ AWS Direct Connect に障害が起きた。日本時間の午前 7 時 30 分から、つながったり切れたりし、パケットの消失が増えた。午後 1 時 42 分に解消した⁶¹。

原因は、新しいプロトコルを有効にした、ネットワークの機器の OS に潜んでいた欠陥だった。AWS は、ネットワークの機器の OS への変更を、ゆっくりと管理された形で本番に出している。この OS は 2021 年 1 月に初めて本番に出て、8 か月かけてすべてのリージョンに広げられ、その間は問題が出ていなかった⁶¹。AWS は、実験の環境では、すべての通信と、パケットの組み合わせは試せないと書いている⁶¹。技術者は、新しいプロトコルを、まず一つのアベイラビリティーゾーンで止めて回復を確かめ、並行して東京リージョン全体に広げる準備を進めた⁶¹。止める操作も、一部から出している。

費用

CDK には料金がかからない¹⁷。CloudFormation も、AWS:: で始まる AWS の資源の操作には料金を取らない。レジストリーに登録した拡張の資源（自分で作ったものも含む）を使うと、操作 1 回ごとに 0.0009 USD と、30 秒を超えた時間の分の料金がかかる。操作は 1 か月に 1,000 回までは無料である⁶²。失敗して巻き戻した作成でも、その間にできた資源の料金はかかる⁶³。CodeDeploy で EC2、Lambda、ECS に出す分には、追加の料金がかからない⁶⁴。

CloudWatch には無料の枠があり、標準のアラームを 10 個のメトリクスの分まで、ログを 5 GB まで使える⁶⁵。それを超えると、標準のアラームは 1 メトリクスあたり月 0.10 USD、ログの取り込みは東京で 1 GB あたり 0.76 USD である（2026 年 10 月 7 日付けの AWS の価格表）⁶⁶。CDK の既定では、ログは無期限に残る。本番では、要らないデータが積み上がり、料金も増えるので、保存の期間を決めるよう、CDK の文書は書いている²⁰。CloudTrail のイベント履歴は料金がかからず、管理イベントの最初の一つの写しを S3 に送る証跡も無料である⁶⁷。

変更は壊しうる前提で、確かめ、小さく出し、戻せるようにする

AWS CDK は、プログラミング言語で書いた構成を、CloudFormation のテンプレートに変換して配備する道具である。資源を作り、変え、失敗したときに戻すのは CloudFormation である。名前の変更やキーの変更は、資源の置換になり、データを持つ資源では、中身を失うことがある。配備の前に cdk diff と変更セットで置換と削除を確かめ、データを持つ資源には残す指定を付ける。

本番へは、一部の要求から段階的に出し、CloudWatch のアラームが鳴れば自動で巻き戻す。巻き戻しで戻るのはコードと設定で、データの形の変更は、二段階に分けて、どちらの向きにも戻せるようにしておく。それでも、まれな条件でしか表れない欠陥は、段階的に出しても見つけきれない。問題が起きた変更を止めるときも、一部から止めて確かめる。

この記事はAIを使用して執筆されました。内容には誤りが含まれる可能性があります。事実や数字の出典は脚注から確かめられます。