はじめに
こんにちは。株式会社シーイーシーのAWSコミュニティチームです。
今回は、CDKで構築した開発環境のコスト削減について考えてみたいと思います。
開発環境のコスト削減について
早速ですが、CDKで構築した開発環境において、土日や夜間など利用が少ない時間帯の開発コストを抑えたいと考えたことはありませんか？
私自身も同様の課題を感じ、さまざまな情報を調べてみましたが、意外にも参考となる具体的な事例はあまり見つかりませんでした。
そこで本記事では、考えられる対応案をいくつか整理し、メリット・デメリットを交えながらご紹介したいと思います。
本記事が少しでも参考になれば幸いです。
前提条件
本記事は、本番環境ではなく開発環境を対象としており、
開発データが消失しても問題ない、あるいは再作成・再同期が可能な環境であることを前提としています。
紹介する方法は、設定変更やリソース削除を伴います。
そのため、適用方法を誤るとデータが完全に失われる可能性があります。
データ消失が許容できない環境や本番相当の重要なデータを扱う環境では、本記事の内容をそのまま適用しないでください。
必ず事前にバックアップ取得および十分な検証を実施してください。
なお、今回は以下のサービスを想定しております。
- Amazon Aurora：Provisioned
（Serverlessではなく、インスタンスタイプを選んで立ち上げる方式） - Amazon Bedrock Knowledge Bases：RAGとして使用
- Amazon OpenSearch Serverless：RAGのベクトルストアとして利用
- Amazon EC2：開発用インスタンス
※ Amazon AuroraはAmazon RDSと異なり、Shared Storage Volumeがデータを保持するので、インスタンスを削除してもデータは残ります。詳しくはAmazon Auroraのドキュメントを参照してください。
コスト削減の基本戦略（何をどうするか）
それでは、上述した前提をもとに、3つの戦略をご紹介します。
戦略1：データベース関連リソースを停止する
平日夜間および休日にリソースを停止し、平日朝に再度起動します。
メリット
- データが保持される
デメリット
- 停止できないサービスが存在する
- 長時間停止できず、最大停止期間後は自動的に起動されるものもある
戦略2：データベース関連リソースを削除する
平日夜間や休日にリソースを削除し、平日朝に再作成します。
なお、CDK管理外でリソースを削除した場合、次回デプロイ時にCDKの差分検出によって「既存リソースあり」と判定され、意図どおりに再作成されない可能性があります。
そのため、Amazon Bedrock Knowledge BasesやAmazon OpenSearch Serverlessについては、CDK定義を調整したうえで削除・デプロイを行い、その後あらためてCDKで再作成しデプロイする、といった手順が必要になります。
今回想定するサービスでは、以下のような削除方法です。
Amazon Aurora
- クラスターを停止し、Reader/Writerインスタンスを削除する
（ストレージ料金は発生するが、インスタンス料金は削減可能。データは保持されるが、インスタンス削除中はアクセス不可）
Amazon RDS
- Amazon Auroraと同様に、インスタンスを削除またはスケールダウンする
※インスタンスにデータが保存されている構成の場合、すべて削除するとデータ消失する可能性があるため注意
Amazon Bedrock Knowledge Bases+Amazon OpenSearch Serverless
- リソースを削除する
（データも削除されるため、再作成および再同期が必要）
メリット
- Amazon Aurora/Amazon RDSのインスタンス料金を削減できる
- Amazon Bedrock Knowledge Bases+Amazon OpenSearch Serverlessの
固定費を削減できる
デメリット
- 再作成、再同期の時間が必要
- やり方、サービス次第ではデータが消える
戦略3：環境ごとすべて削除する（シンプルだが大胆な方法）
平日夜間や休日にcdk destroyを実行して、平日朝にcdk deployで環境を再作成する。
メリット
- 手順が非常にシンプルで分かりやすい
- すべてのリソースを削除するため、無駄なコストを減らすことが可能
デメリット
- 環境を毎回フルで再作成するため、起動までに時間がかかる
-
cdk destroy実行時に削除ポリシー（RemovalPolicyなど）の影響でリソースが残ると、
次回cdk deployが失敗する可能性がある - データは原則すべて消えるため、再同期・再投入が前提となる
実行方式の比較（誰がいつ実行するか）
「何をするか（Stop/Delete/Destroy）」とは別に、「誰が」「いつ」「どのように」実行するかという観点も重要です。
| 実施方式 | 概要 | メリット | デメリット | 向いているケース |
|---|---|---|---|---|
| 方法1：退勤時に手動で実行 | ユーザーが手動で操作する | 実行者自身が制御できる | 手間がかかる／実行漏れのリスクがある | まずは簡単に始めたい場合 |
| 方法2：GitHub Actions+Cron | Workflowのschedule（cron）で実行 | Workflowがコードとして残る | AWS認証の設定が必要 | GitHub上で完結させたい場合 |
| 方法3：Amazon EventBridge+AWS Lambda | Amazon EventBridgeルールからAWS Lambdaを起動 | 削除順序や条件分岐をコードで制御できる | AWS Lambdaコードの保守が必要 | 軽量なワークフローが必要な場合 |
| 方法4：Amazon EventBridge Scheduler（AWS Lambdaなし） | APIを直接呼び出す | AWS Lambda不要で構成が最小 | 待機処理・分岐・複雑なリトライには不向き | 管理コストを極力下げたい場合 |
また、AWS Step Functionsを利用して非同期削除の完了待ちやリトライ処理を実装する方法も考えられますが、構成がやや大きくなるため、今回は割愛させていただきます。
（補足）cdk.jsonのtrue/falseフラグで制御し、cdk deployで削除する方法
少し変わった方法として、cdk.jsonのcontextにフラグを用意し、その値によってリソースの有無を切り替える方法があります。
フラグを変更してcdk deployを実行することで、差分検出によりリソースの削除を発生させることが可能です。
仕組み
const enableKb = this.node.tryGetContext("knowledge-base") ?? true;
if (enableKb) {
// Amazon Bedrock Knowledge Bases/Amazon OpenSearch Serverlessを作成
}
// cdk.json
{
"context": {
"knowledge-base": false,
"aurora-cluster-instance": true,
"aurora-allow-running-all-night": false
}
}
メリット
- 消したいものだけを削除できる
デメリット
- 依存関係が残ると更新に失敗しやすい
-
knowledge-base=falseの時は参照元も含めて「まとめて作らない」が鉄則
-
- RemovalPolicyの設計が必須（DESTROYを明示）
選び方のガイド
どれを選ぶべきかは、環境の特性やチームの運用方針によって最適解が異なります。
そのため、自身の環境や優先事項（コスト削減幅・運用負荷・安全性など）を踏まえて選択するのがよいと考えます。
パターン別のおすすめ
| やりたいこと | おすすめの組み合わせ |
|---|---|
| とにかく簡単に始めたい | cdk.jsonフラグ×方法1（手動実行）または方法4（Amazon EventBridge Scheduler） |
| とにかくコスト効果を最大化したい | cdk destroy×方法2（GitHub Actions+Cron） |
| 管理工数を抑えたい | cdk.jsonフラグ×方法2（GitHub Actions+Cron）または方法4（Amazon EventBridge Scheduler） |
| 柔軟にコスト削減したい | cdk.jsonフラグ×方法3（Amazon EventBridge+AWS Lambda） |
実際に、どの方法を採用しているのか
私は現在、私は2つのプロジェクトに参画しており、それぞれ異なる方法で運用しています。
プロジェクト1（Amazon Aurora）
やり方
- cdk.jsonでAmazon AuroraのWriterインスタンスの作成有無をフラグで制御
- 必要なときに
cdk deployで起動し、退勤時に再度cdk deployで削除 - Amazon AuroraのWriterインスタンス数を定期的にチェックし、削除漏れがあった場合は以下を実施
- Teamsへ通知
- Amazon EventBridge Schedulerから
DeleteDBInstanceAPIを実行して削除 - 次回出社時にフラグをfalseにしてCDK上から削除→
cdk deploy - その後trueに戻して再度
cdk deployで再作成
メリット
- 必要なときに必要な分だけ起動・削除するため、コスト削減効果が高い
- Amazon EventBridge Schedulerの有効／無効を別フラグで制御できるため、柔軟に対応可能
デメリット
- 手動操作が多いので、運用コストがかかる
- CDK外で削除されるので、新しく作成する時に少し手間がかかる（
cdk deployが2回必要） - 削除漏れがあった時の対応が少し複雑
プロジェクト2（Amazon Bedrock Knowledge Bases+Amazon RDS）
やり方
- cdk.jsonでAmazon Bedrock Knowledge Bases/Amazon OpenSearch Serverlessの作成有無をフラグで制御
- 必要なときに
cdk deployで起動 - 金曜日の夜にGitHub Actions+Cronで実行し、AWS CLIで環境情報を取得
- cdk.jsonのフラグをfalseに変更して
cdk deployで削除
メリット
- CDK上で完結するため、構成がシンプル
- GitHub Actionsにより自動化されており、手動操作が少ない
デメリット
- 一時的に削除したくない場合の制御がやや不便
- developブランチのコードがそのままデプロイされる可能性がある
まとめ：自分の環境に合わせて選ぶ
今回は、開発環境におけるコスト削減の方法についてご紹介しました。
正解は一つではありません。
コスト削減効果、運用負荷、自動化レベルなどのバランスを踏まえ、自身の環境に合った方法を選択することが重要です。
ぜひ、自分たちの環境に合わせて無理のない方法から試してみてください。
※本記事は2026年3月時点の情報に基づいて執筆しています。