
こんにちは。
アプリケーションサービス部、DevOps担当の兼安です。
マイナーバージョン自動アップグレードとIaCのお話しです。
- はじめに
- 本記事のターゲット
- マイナーバージョン自動アップグレードにより発生するドリフト
- データベースとIaCのドリフトの確認
- AWS CDKを修正・再デプロイをしてドリフトを解消する
- CloudFormationテンプレートを修正してから、変更セットを作成してドリフトを解消する
- ドリフトの解消に伴うスタック更新に要する時間
はじめに
IaCでデータベースリソースをデプロイした後、マイナーバージョン自動アップグレードによりバージョンが変更された場合、IaC側との矛盾が発生します。
矛盾が残っていると、その後のIaCの更新がうまくいかなくなる原因になるので、早めに解消させておく方が適切です。
この矛盾は、IaCを修正して再デプロイするか、IaCの修正後に変更セットの作成と実行をすることで解消できますので、今回はこれらの手順を紹介します。
本記事では、データベースにAmazon Aurora Serverless v2 PostgreSQL互換、IaCにAWS CDKおよびAWS CloudFormationを用いた例を紹介します。
これらは以降、Aurora、CDK、CloudFormationと記載します。
データベースとIaCの矛盾のことは、AWSの用語でドリフトと呼ばれることが多いので、以降はドリフトと記載します。
本記事のターゲット
本記事はAWSにおけるデータベースとIaCの基礎知識をすでにお持ちの方を対象としています。
マイナーバージョン自動アップグレードにより発生するドリフト
AWSのAurora および RDSには、マイナーバージョン自動アップグレードの機能があります。
運用上の制約がなければこの機能をONにしておくほうがセキュリティ的には有利です。

マイナーバージョン自動アップグレードは、バージョンアップするのはリソース側でありIaCを直すわけではありません。
したがって、マイナーバージョン自動アップグレードが作動するとIaCとのドリフトが発生します。
このドリフトはIaC側を修正し、AWS CDKの場合は再デプロイ、AWS CloudFormationの場合はドリフト検出からの変更セットの作成と実行をすることで解消します。
flowchart TD
A[IaCでデプロイ] --> B[マイナーバージョン自動アップグレードで\nマイナーバージョンが変更]
B --> C[ドリフトの検出]
C --> D[IaC側を修正]
D --> E{使用ツール}
E -->|AWS CDK| F[再デプロイ]
E -->|AWS CloudFormation| G[ドリフト検出から\n変更セットの作成と実行]
F --> H[ドリフトの解消]
G --> H
データベースとIaCのドリフトの確認
マイナーバージョン自動アップグレードは意図して発生させるのが難しいので、デプロイ後に手動でマイナーバージョンを変更して同様の状況を再現します。
バージョンを17.6から17.7に変更することにします。
まず、Auroraのエンジンバージョンを17.6にしておきます。
CDKの記述は以下のようになります。
// Aurora Serverless v2 Cluster this.cluster = new rds.DatabaseCluster(this, 'Cluster', { engine: rds.DatabaseClusterEngine.auroraPostgres({ version: rds.AuroraPostgresEngineVersion.VER_17_6, }),
CloudFormationの記述は以下のようになります。
Type: AWS::RDS::DBCluster Properties: Engine: aurora-postgresql EngineVersion: '17.6'
次に、AWSマネジメントコンソールでAWS CDKまたはAWS CloudFormationでデプロイしたAuroraを開き、エンジンバージョンのマイナーバージョンを変更します。

次に、矛盾(=ドリフト)の検出を行います。
CDKの場合はcdk driftコマンドを実行します。
実行すると、コンソールには以下のように表示されます。
マイナーバージョンが17.6から17.7に変更されたことにより、ドリフトが発生していることがわかります。
> cdk drift
✨ Synthesis time: 4.19s
Stack MyAppCdkAuroraStack
Modified Resources
[~] AWS::RDS::DBCluster Cluster ClusterEB0386A7
└─ [~] /EngineVersion
├─ [-] 17.6.*
└─ [+] 17.7
1 resource has drifted from their expected configuration
✨ Number of resources with drift: 1 (1 unchecked)
CloudFormationの場合はAWSマネジメントコンソールから確認するのが簡単です。
CloudFormationのスタックの画面で「スタックアクション」の「ドリフトの検出」をクリックします。

少し経つとドリフトの検出が終わるので、CloudFormationのスタックの画面で「スタックアクション」の「ドリフト結果を表示」をクリックします。
これで、ドリフトの結果が表示され、Auroraのエンジンバージョンが17.7に変更されたことによりIaCとの矛盾が発生していることがわかります。
cdk driftは内部的にCloudFormationのドリフト検出を利用しているため、実行後にCloudFormationのスタック画面から「スタックアクション」の「ドリフト結果を表示」をクリックしても同じ結果が表示されます。


AWS CDKを修正・再デプロイをしてドリフトを解消する
ドリフトが確認できたので、次はIaC側を修正して再度デプロイすることでドリフトを解消します。
まずはCDK側で解消してみます。
CDK上のAuroraのエンジンバージョンを17.7に変更します。
// Aurora Serverless v2 Cluster this.cluster = new rds.DatabaseCluster(this, 'Cluster', { engine: rds.DatabaseClusterEngine.auroraPostgres({ version: rds.AuroraPostgresEngineVersion.VER_17_7, }),
ソース修正後、それぞれ再度デプロイとドリフトの検出を行います。
CDKの場合はcdk deployコマンドを実行します。
> tsc > cdk deploy ✨ Synthesis time: 3.96s MyAppCdkAuroraStack: start: Building MyAppCdkAuroraStack Template MyAppCdkAuroraStack: success: Built MyAppCdkAuroraStack Template MyAppCdkAuroraStack: start: Publishing MyAppCdkAuroraStack Template (***) MyAppCdkAuroraStack: success: Published MyAppCdkAuroraStack Template (***) MyAppCdkAuroraStack: deploying... [1/1] MyAppCdkAuroraStack: creating CloudFormation changeset... ✅ MyAppCdkAuroraStack ✨ Deployment time: 54.32s Outputs: 省略 Stack ARN: 省略 ✨ Total time: 58.29s
そして、もう一度ドリフトの検出を行います。
> cdk drift ✨ Synthesis time: 6.24s Stack MyAppCdkAuroraStack No drift detected
今度はドリフトが検出されませんでした。
ドリフトの検出結果を表示しても、全てIN_SYNCになっていました。

これでCDK側の修正と再デプロイでドリフトが解消されたことがわかります。
CloudFormationテンプレートを修正してから、変更セットを作成してドリフトを解消する
今度はCloudFormation側でドリフトを解消してみます。
CloudFormationのテンプレート上のAuroraのエンジンバージョンを17.7に変更します。
Type: AWS::RDS::DBCluster Properties: Engine: aurora-postgresql EngineVersion: '17.7'
CloudFormationのスタックの画面から、「ドリフト結果の表示」をクリックします。

ドリフトの画面の「変更セットを作成」をクリックします。

変更セットの作成画面で、「既存のテンプレートを置換」を選択、Auroraのバージョンを修正したCloudFormationのテンプレートをアップロードして「次へ」をクリック。
途中のパラメータは変えずに進めます。

スタックのリソースに変化が発生しない旨が表示されますが、そのまま「変更セットを作成」をクリックします。

変更セットが作成されたら、「変更セットを実行」をクリックします。

変更セットの実行が完了したら、ドリフトは解消されているはずです。
ドリフトの検出を行うと、ドリフトが検出されないことがわかります。
以上が、AWSのデータベースのマイナーバージョン自動アップグレードによるIaCとの矛盾を是正する方法になります。
ドリフトの解消に伴うスタック更新に要する時間
今回は、自動アップグレードで発生したドリフトを解消することだけを目的としていますが、それでもスタックの更新には1分程度かかります。
また、スタックの構成として認証にSecrets Managerを使用している場合、クレデンシャルのリセットも発生することが確認できています。
この動きと所要時間から考えて、バージョンを合わせるだけであっても、瞬断が発生する可能性があることは考慮し、営業時間を避けるなど慎重な対応が必要であると考えます。
今回は以上です。
兼安 聡(執筆記事の一覧)
アプリケーションサービス部 DS3課所属
2025 Japan AWS Top Engineers (AI/ML Data Engineer)
2025 Japan AWS All Certifications Engineers
2025 AWS Community Builders
Certified ScrumMaster
PMP
広島在住です。今日も明日も修行中です。
X(旧Twitter)