Aurora Serverless v2 のプラットフォームバージョンをクラスター停止・開始でアップデートしてみた
はじめに
Aurora Serverless v2 のプラットフォームバージョン 3 は最大 30% のパフォーマンス向上が見込めます。本記事ではクラスターの停止・開始によるもっとも簡単なアップデート方法を検証しました。プラットフォームバージョン 2 から 3 への移行手順と注意点を紹介します。
検証結果のサマリ
本記事の検証で確認できた主な内容は以下です。
- クラスターの停止・開始で自動的にバージョン 3 へアップデート（特別な設定不要）
- 私の検証環境では停止に約 13 分、起動に約 10 分かかった
- スナップショットから復元しても自動的に最新バージョンが適用される
- 旧バージョン（1 や 2）の環境を複製したい場合でも、スナップショット復元やクローン作成では最新バージョンになってしまう
- つまり、同環境のクラスターを別に用意しての検証はできない
背景
Aurora Serverless v2 にプラットフォームバージョンが存在することを知りました。バージョン 3 では最大 30% のパフォーマンス向上が見込めます。検証環境で利用していた Serverless v2 でアップデートを試しました。
参考記事は以下です。
検証環境
検証環境の構成は以下です。
- データベース: Aurora Serverless v2 MySQL
- エンジンバージョン: 8.0.mysql_aurora.3.08.0
- プラットフォームバージョン: 2
非稼働時に 0 ACU まで縮退させるため Serverless v2 を採用しています。HPC クラスター環境と相性が良く、実運用で利用中です。今回はお客様への案内を目的に動作検証しました。
プラットフォームバージョンについて
Aurora Serverless v2 には 3 つのプラットフォームバージョンがあります。
| プラットフォームバージョン | ACU 範囲 | パフォーマンス |
|---|---|---|
| 1 | 0-128 | ベースライン |
| 2 | 0-256 | ベースライン |
| 3 | 0-256 | バージョン 2 と比較して最大 30% 向上 |
バージョン 3 はバージョン 2 と比較して最大 30% 性能が向上します。ACU 範囲の上限は 256 でバージョン 2 と同じです。
現在のプラットフォームバージョンは、以下の方法で確認できます。
- AWS マネジメントコンソールのインスタンス設定セクション
- API の
ServerlessV2PlatformVersionパラメーター
参考: How Aurora Serverless v2 works - Amazon Aurora
アップデート方法
既存クラスターのプラットフォームバージョンをアップデートする方法は 2 つあります。
- クラスターを停止して再起動する（本記事で検証）
- 停止中はサービスが利用不可
- もっとも簡単な方法
- Blue/Green デプロイメントを使用する
- ダウンタイムを最小化できる
検証環境ではダウンタイムを許容できるため、クラスター停止・開始でのアップデートを試します。本番環境でダウンタイムを最小化したい場合は Blue/Green デプロイメントを検討してください。また、クラスターの停止・開始ができる条件も確認が必要です。
クラスター停止・開始の条件
以下のケースでは停止・開始機能を利用できません。
- Aurora グローバルデータベース（単一クラスターの場合を除く）
- クロスリージョンリードレプリカを持つクラスター
- Blue/Green デプロイメントの一部であるクラスター
- Aurora Serverless v1 クラスター（v2 では利用可能）
参考: Limitations for stopping and starting Aurora DB clusters
補足
プラットフォームバージョンアップに関するドキュメントを探しましたが、アップデート方法について詳述された公式ドキュメントは確認できませんでした。アナウンス記事のみが参考情報となります。
※ 2025 年 11 月 11 日時点。
Blue/Green デプロイメントの参考手順
Aurora PostgreSQL の例ですが以下が参考にしてください。
アップデート手順
事前確認
まず現在のプラットフォームバージョンを確認します。クラスターではなくインスタンスの詳細から、プラットフォームバージョンが 2 であることを確認できます。
クラスターの停止
クラスターを停止します。停止操作を実行すると確認画面が表示されます。普段は 0 ACU への縮退でインスタンスレベルの停止相当の動きは頻繁に発生していましたが、今回はクラスターレベルでの停止・開始が必要です。
内容を確認して実行します。
停止が完了しました。アイドル状態の DB インスタンスを含めたクラスーたの停止ですが、0 ACU からの起動と最大 10 ACU 構成で 13 分かかりました。
クラスターの開始とアップデート
停止したクラスターを再度開始します。
起動中の状態で確認すると、プラットフォームバージョンがすでに 3 に更新されています。
データベースの起動が完了しました。プラットフォームバージョン 3 での稼働が確認できます。起動には 10 分かかりました。
スナップショットから復元した場合の動作確認
本番環境でクラスターの停止・開始でアップデートする場合、事前に停止時間を把握しておく必要がでてきます。スナップショットから復元して別のクラスターで検証することが多いと思います。
ここで気になる仕様があります。
新規作成するクラスター、スナップショットからの復元、クローン作成では自動的に最新のプラットフォームバージョンが適用されます。つまり、スナップショットから今回ですとプラットフォームバージョン 2 の環境は作成できないことになります。ちょっと試してみました。
クラスター停止・開始でバージョン 3 にアップデートする前の、前日取得したスナップショット（バージョン 2 時点）から復元しました。復元されたクラスターはプラットフォームバージョン 3 で起動しました。仕様通りの動作です。
こうなると単純にクラスターの停止と、開始に要する時間の計測くらいしかできないです。プラットフォームアップデートにかかる時間も込みでの動作確認はできません。
まとめ
Aurora Serverless v2 のプラットフォームバージョンを停止・開始で 2 から 3 へアップデートできることを確認しました。
操作手順は非常にシンプルです。以下の流れで完了します。
- データベースを停止
- データベースを開始
開始時に自動的にプラットフォームバージョンが最新化されます。特別な設定は不要です。
また、以下の仕様も確認できました。
- 古いスナップショットから復元した場合でも最新のプラットフォームバージョンが適用される
- スナップショットから旧バージョンの環境は作成できない
おわりに
プラットフォームバージョン 3 では最大 30% のパフォーマンス向上が見込めます。というアップデートを見逃しており 3 ヶ月遅れで知りました。実際に動作検証した記事がなかったので自分の検証環境のアップデートついでに記事にしました。
