developersIO
Aurora Serverless v2 プラットフォームバージョン4がリリースされました

Aurora Serverless v2 プラットフォームバージョン4がリリースされました

2026年4月21日、Aurora Serverless v2 のプラットフォームバージョン4（Platform Version 4）が発表されました。プラットフォームバージョンとは、データベースのエンジンバージョン（MySQL 8.0等）とは独立した、裏側のインフラ基盤の世代を示すものです。本記事では、PF版4の実機検証、Data APIを使ったCPUアーキテクチャ調査、アップグレード方法と注意点を紹介します。
Amazon AuroraAurora ServerlessAWS GravitonAWS
2026.04.23

2026年4月21日、Aurora Serverless v2 のプラットフォームバージョン4がリリースされました。

https://aws.amazon.com/jp/about-aws/whats-new/2026/04/aurora-serverless-smarter-scaling/

主なポイントは以下の通りです。

  • 前バージョン（プラットフォームバージョン3）比で最大30%のパフォーマンス向上
  • ワークロードを理解するスマートなスケーリングアルゴリズムの強化
  • ゼロへのスケールダウン継続対応
  • 追加コストなし

AWSブログの別記事ではベンチマーク結果も紹介されています。

https://aws.amazon.com/blogs/database/aurora-serverless-faster-performance-enhanced-scaling-and-still-scales-down-to-zero/

ベンチマーク v3比 完了時間 v3比 ACU消費 v2比 完了時間 v2比 ACU消費
Sysbench read heavy 27%高速 28%削減 41%高速 42%削減
Sysbench write only 32.9%高速 5.1%削減 42.4%高速 24.6%削減

今回、東京リージョンで Aurora Serverless v2 新規クラスターを作成し、プラットフォームバージョンや搭載CPUアーキテクチャなどの確認を試みる機会がありましたので、紹介します。

プラットフォームバージョンの概要

Aurora Serverless v2 には、エンジンバージョン（Engine Version）とプラットフォームバージョン（Platform Version）という2つのバージョン概念があります。エンジンバージョンはデータベースエンジンのバージョン（MySQL 8.0互換の 3.10.3 等）、プラットフォームバージョンはその下で動作するインフラ基盤の世代です。この2つは独立しており、同じエンジンバージョンでもプラットフォームバージョンが異なる場合があります。

公式ドキュメントに記載されているプラットフォームバージョンの一覧です。

https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-serverless-v2.how-it-works.html

プラットフォームバージョン ACU範囲 性能
1 0–128 ベースライン
2 0–256 ベースライン
3 0–256 v2比 最大30%向上
4 0–256 v3比 最大30%向上

プラットフォームバージョン1のみACU上限が128で、バージョン2以降は256です。なお、実際に利用できるACU範囲は、エンジンバージョンとプラットフォームバージョンの組み合わせで決まります。

確認方法

プラットフォームバージョンはクラスター単位で管理されています。AWSコンソールのインスタンス設定セクション、またはCLIで確認できます。

aws rds describe-db-clusters \
  --db-cluster-identifier <クラスター名> \
  --query 'DBClusters[0].{
    Cluster: DBClusterIdentifier,
    EngineVersion: EngineVersion,
    PlatformVersion: ServerlessV2PlatformVersion
  }' \
  --output table

-------------------------------------------------------------
|                    DescribeDBClusters                      |
+-------------------+---------------------------+------------+
|      Cluster      |      EngineVersion        | PlatformVersion |
+-------------------+---------------------------+------------+
|  my-cluster       |  8.0.mysql_aurora.3.10.3  |  4         |
+-------------------+---------------------------+------------+

新規クラスターでの検証結果

新規クラスターを作成した場合、プラットフォームバージョンはどうなるのでしょうか。異なるエンジンバージョンで検証しました。

※ 以下は検証アカウント（ap-northeast-1）での確認結果です。

aws rds create-db-cluster \
  --db-cluster-identifier test-pf-v4-check \
  --engine aurora-mysql \
  --engine-version 8.0.mysql_aurora.3.10.3 \
  --manage-master-user-password \
  --master-username admin \
  --no-deletion-protection \
  --serverless-v2-scaling-configuration MinCapacity=0,MaxCapacity=2 \
  --db-subnet-group-name <サブネットグループ名>

aws rds describe-db-clusters \
  --db-cluster-identifier test-pf-v4-check \
  --query 'DBClusters[0].{Engine:EngineVersion, PlatformVersion:ServerlessV2PlatformVersion}' \
  --output table
エンジン エンジンバージョン プラットフォームバージョン
Aurora MySQL 8.0.mysql_aurora.3.10.3（最新） 4
Aurora MySQL 8.0.mysql_aurora.3.04.0（初期のServerless v2対応） 4
Aurora PostgreSQL 17.4 4

エンジンバージョンに関係なく、新規作成時は一律でプラットフォームバージョン4が割り当てられました。公式ドキュメントにも以下の記載があります。

All new clusters, database restores, and new clones launch with the latest platform version available in your AWS Region.

スナップショットからのリストアやクローンも、最新のプラットフォームバージョンで起動されます。

CPUアーキテクチャの調査

プラットフォームバージョン3の公式説明には「powered by Graviton 3 processors」と明記されています。プラットフォームバージョン4で30%の性能向上が実現されているなら、Graviton 4への世代更新が行われた可能性があります。Data APIを使ってDB内部からCPU情報を取得し、確認しました。

Data APIの有効化

Serverless v2でData APIを有効化するには、aws rds enable-http-endpoint オペレーションを使用しました。

aws rds enable-http-endpoint \
  --resource-arn <クラスターARN>

create-db-cluster 時に --enable-http-endpoint フラグを付与すれば、作成時から有効化することもできました。

調査結果

MySQL:

aws rds-data execute-statement \
  --resource-arn <クラスターARN> \
  --secret-arn <シークレットARN> \
  --database mysql \
  --sql "SELECT @@version, @@version_compile_machine, @@version_compile_os"
項目 値
@@version 8.0.42
@@version_compile_machine aarch64
@@version_compile_os Linux

PostgreSQL:

aws rds-data execute-statement \
  --resource-arn <クラスターARN> \
  --secret-arn <シークレットARN> \
  --database postgres \
  --sql "SELECT version()"

PostgreSQL 17.4 on aarch64-unknown-linux-gnu,
compiled by aarch64-unknown-linux-gnu-gcc (GCC) 10.5.0, 64-bit

MySQL、PostgreSQLともに aarch64（ARM アーキテクチャ）で動作していることが確認できました。

考察

参考までに、Graviton3と4の主な違いです。

Graviton 3 Graviton 4
コア 64x Neoverse V1 96x Neoverse V2
アーキテクチャ Armv8 Armv9
メモリ DDR5 DDR5-5600
メモリ帯域 ベースライン 75%増
L2キャッシュ/vCPU ベースライン 2倍
公称性能差 ベースライン 30-40%向上

DB内部のクエリだけではGraviton 3か4かを直接特定することはできませんでした。しかし、以下の状況証拠からGraviton 4が採用されている可能性が極めて高いと考えられます。

  • aarch64 = ARM/Gravitonで動作していることは確定
  • プラットフォームバージョン3は「powered by Graviton 3」と公式に明記
  • プラットフォームバージョン4の30%性能向上は、Graviton 3→4の公称値（30-40%向上）と一致
  • Amazon RDSでは2025年6月時点でGraviton 4の採用が公式ブログで確認されている

https://aws.amazon.com/blogs/database/leveling-up-amazon-rds-with-aws-graviton4-benchmarks/

アップグレード方法と注意点

既存クラスターのプラットフォームバージョンを更新する方法を紹介します。公式ドキュメントには以下の記載があります。

When a new platform version becomes available, existing clusters on previous platform versions can be upgraded directly to the latest platform version by stopping and restarting the cluster or by using blue/green deployments.

なお、一度アップグレードするとダウングレードはできません。ステージング環境での事前検証を推奨します。

Step 1: pending maintenance の確認

まず、プラットフォームバージョン更新の案内（pending maintenance action）が届いているか確認します。

aws rds describe-pending-maintenance-actions \
  --query 'PendingMaintenanceActions[*].{
    Resource: ResourceIdentifier,
    Actions: PendingMaintenanceActionDetails[?Action==`serverless-platform-version-update`]
  }'

Step 2a: 案内が届いている場合

apply-pending-maintenance-action コマンドで適用します。

# 即時適用
aws rds apply-pending-maintenance-action \
  --resource-identifier arn:aws:rds:<リージョン>:<アカウントID>:cluster:<クラスター名> \
  --apply-action serverless-platform-version-update \
  --opt-in-type immediate

# 次回メンテナンスウィンドウで適用
aws rds apply-pending-maintenance-action \
  --resource-identifier arn:aws:rds:<リージョン>:<アカウントID>:cluster:<クラスター名> \
  --apply-action serverless-platform-version-update \
  --opt-in-type next-maintenance

Step 2b: 案内が届いていない場合

案内の到着を待たずに先行して更新したい場合は、以下のいずれかの方法で更新できます。

方法A: クラスターの停止・再起動

最もシンプルな方法です。再起動すると最新のプラットフォームバージョンで起動されます。

aws rds stop-db-cluster --db-cluster-identifier <クラスター名>
# stopped 確認後
aws rds start-db-cluster --db-cluster-identifier <クラスター名>

停止・再起動中はダウンタイムが発生します。所要時間はクラスター規模やデータ量によって異なるため、本番相当のデータが登録されたステージング環境で先行実施し、実際の所要時間を確認しておくことを推奨します。

方法B: Blue/Greenデプロイメント

ダウンタイムの短縮を優先し、並行稼働中のコスト増加が許容できる場合におすすめの方法です。

  • Green環境は新規クラスターとして作成されるため、自動的にプラットフォームバージョン4になります
  • ストレージ層はクローン（Copy-on-Write）で作成されるため、ストレージの追加コストは差分のみです
  • Blue→Green間のレプリケーション（Aurora MySQLの場合はbinlog）が発生するため、Blue側のACU消費が増加する可能性があります
  • Green環境が稼働している間は、そのインスタンス分のACUコストが追加で発生します
  • スイッチオーバーは1分未満で完了します

詳細は公式ドキュメントを参照してください。

https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/blue-green-deployments.html

Step 3: 更新後の確認

更新後、プラットフォームバージョンが4になっていることを確認します。確認方法は「プラットフォームバージョンの概要」セクションを参照してください。

方法の比較

方法 ダウンタイム レプリケーション負荷 自動化
pending maintenance（即時） あり なし 手動実行
pending maintenance（次回MW） あり なし メンテナンスウィンドウで自動
停止・再起動 あり（要事前計測） なし 手動実行
Blue/Green スイッチオーバー1分未満 あり（binlog） 手動実行

まとめ

プラットフォームバージョン4は、追加コストなしで最大30%のパフォーマンス向上が得られるアップデートです。パフォーマンスの向上により同じワークロードをより少ないACUで処理できるようになるため、ACU消費量の抑制とコスト削減が期待できます。

新規クラスターは自動的にプラットフォームバージョン4で作成されますが、既存クラスターは明示的なアップグレードが必要です。まずはステージング環境で動作確認のうえ、アップデートをご検討ください。

参考リンク

この記事をシェアする

関連記事

[アップデート] Amazon Aurora Serverless v2 で、最新のサーバーレスプラットフォームバージョン (バージョン 3) で実行されるデータベースのパフォーマンスが最大 30% 向上しました
若槻龍太
2025.08.09
AuroraクラスターをServerless v2に移行してみる
えがわ
2025.12.03
Aurora Serverless v2 のプラットフォームバージョンをクラスター停止・開始でアップデートしてみた
大村 保貴
2025.11.11
AWS CLIでAurora Serverless v2の最小ACUを0から1に変更してコールドスタートを回避してみた
小林翔馬
2025.05.18