Aurora Serverlessの2025年最新アップデート、ついに実現した「真のサーバーレス」への進化

なぜ今、Aurora Serverlessが注目されているのか

データベースの管理は長年にわたりエンジニアにとって悩みの種でした。「ピーク時に合わせてプロビジョニングすれば無駄が多い」「かといって小さくすると性能が足りない」というジレンマは、多くの開発チームが直面してきた課題です。

Aurora Serverlessは、このようなデータベース運用の根本的な問題を解決するサービスとして2018年に登場しましたが、v1には大きな制約がありました。2024年12月31日をもってAurora Serverless v1は終了し、すべてのユーザーがv2への移行を迫られています。しかし、これは決して悪いニュースではありません。むしろ、v2が成熟期を迎え、本当の意味でプロダクション利用に耐えうるサービスへと進化したことを示しているのです。

引用 : AWS公式

Aurora Serverless v1 のサポート終了日を発表: 2025 年 3 月 31 日

すべての Aurora Serverless v1 クラスター 2025 年 3 月 31 日までに移行されなかった場合は、メンテナンス期間中に Aurora Serverless v2 に移行されます。アップグレードが失敗した場合、Amazon Aurora はサーバーレス v1 メンテナンス期間中に、同等のエンジンバージョンを持つプロビジョニングされたクラスターにクラスターを割り当てます。該当する場合、Amazon Aurora は Amazon RDS 延長サポートで変換されたプロビジョニング済みクラスター。詳細については、「Amazon Aurora による Amazon RDS 延長サポート」を参照してください。

2024年後半から2025年の重要アップデート

ついに実現した「ゼロスケール」機能

2024年11月、Aurora Serverless v2に待望の「0 ACUへのスケーリング」機能が追加されました。「ACU」とは Aurora Capacity Unit の略で、データベースの処理能力を表す単位です（1 ACUは約2GBのメモリと対応するCPU・ネットワークリソースに相当）。

これまでのv2では、最小でも0.5 ACUを維持する必要があり、使っていない時間帯でも料金が発生していました。開発環境やステージング環境では、夜間や週末にまったく使われないにも関わらず、月額で一定のコストがかかり続けるという問題がありました。

新しい「一時停止機能」では、以下のような動作が可能になります。

• 5分から24時間の間で任意のアイドルタイムアウトを設定可能である
• 接続がない状態が設定時間続くと自動的に一時停止する
• 一時停止中はコンピュートコストが完全にゼロになる（ストレージコストのみ発生）
• 新しい接続要求があると15秒以内に自動的に再起動する

この機能により、開発環境での月額コストを最大90%削減できるケースも報告されています。個人的には、この機能の実装によってようやくAurora Serverlessが「サーバーレス」の名に恥じないサービスになったと感じています。Lambda関数と同じように「使った分だけ支払う」という真のペイパーユースモデルが、リレーショナルデータベースでも実現したのです。

最大容量が256 ACUへ倍増

2024年10月には、最大容量が従来の128 ACUから256 ACUへと倍増しました。これは512GBのメモリに相当する処理能力で、より大規模なワークロードにも対応できるようになりました。

この拡張により、Aurora Serverlessの適用範囲が大きく広がります。これまでは「小規模から中規模のアプリケーション向け」という位置づけでしたが、エンタープライズレベルの大規模システムでも十分に活用できる選択肢となりました。スケールアップが必要になった際も、インスタンスタイプの変更といった作業なしに、自動的に対応できる点は大きなメリットです。

パフォーマンスの大幅改善

2025年中頃には、新しい「Platform Version 3」が導入され、最大30%のパフォーマンス向上が実現しました。これは単純なベンチマーク上の数値ではなく、実際のクエリレイテンシやスループットの改善を意味します。

特筆すべきは、この改善がソフトウェアレベルで実現されている点です。既存のAurora Serverless v2クラスターも、簡単な再起動やBlue/Greenデプロイメントで新しいプラットフォームに移行でき、追加コストなしでパフォーマンスの恩恵を受けられます。

エンジンの互換性と最新バージョン対応

MySQL 8.0への完全対応

Aurora Serverless v2は、Aurora MySQL version 3（MySQL 8.0互換）を採用しています。2025年5月にリリースされたAurora MySQL 3.09は、MySQL 8.0.40をベースとしており、最新のセキュリティパッチと性能改善が含まれています。

MySQL 5.7互換のAurora MySQL version 2は2024年にサポートが終了したため、現在はMySQL 8.0が標準となっています。MySQL 8.0の主要な機能である以下の要素がすべて利用可能です。

• ウィンドウ関数による高度な分析クエリ
• 共通テーブル式（CTE）による可読性の高いクエリ記述
• JSONドキュメントの高速処理
• パラレルクエリによる大規模データセットの高速処理

PostgreSQL 16までサポート

PostgreSQL互換エディションでは、PostgreSQL 16までがサポートされています。2025年時点では、PostgreSQL 17のプレビューサポートも開始されており、最新のPostgreSQL機能をいち早く活用できます。

Aurora PostgreSQLで利用可能な主要な拡張機能は以下の通りです。

• pg_cron（スケジュールジョブの実行）
• PostGIS（地理空間データの処理）
• pg_partman（自動パーティション管理）
• pgaudit（詳細な監査ログ記録）

v1では利用できなかった「論理レプリケーション」や「バイナリログ」もv2では完全にサポートされており、既存システムからの移行やデータ連携が容易になっています。ただし、これらの機能を有効にすると、レプリケーションストリームがアクティブとみなされるため、0 ACUへの自動一時停止は動作しない点に注意が必要です。

コスト最適化の新しいアプローチ

I/O-Optimizedプライシングモデル

2023年に導入された「I/O-Optimized」プライシングモデルは、Aurora Serverlessでも利用可能です。このモデルでは、以下のような料金体系となります。

表：Aurora StandardとI/O-Optimizedの料金比較

この表が示すように、I/Oコストが全体の25%を超えるようなワークロードでは、I/O-Optimizedモデルを選択することで最大40%のコスト削減が可能です。

特にOLTP（オンライントランザクション処理）システムや、頻繁にデータを更新するアプリケーションでは、I/O-Optimizedモデルが有効です。料金の予測可能性も向上し、突発的なI/Oスパイクによる想定外のコスト増加を防げます。

きめ細かいスケーリングによるコスト最適化

Aurora Serverless v2は0.5 ACU単位でスケーリングするため、必要最小限のリソースのみを使用します。従来のプロビジョンドインスタンスでは、例えば「db.r5.large（2 vCPU、16 GBメモリ）」から「db.r5.xlarge（4 vCPU、32 GBメモリ）」へのスケールアップは、リソースが2倍になりコストも倍増します。

一方、Aurora Serverless v2では、実際の負荷が1.5倍程度なら、ACUも1.5倍程度にしか増えません。この「必要な分だけ」のスケーリングにより、オーバープロビジョニングを避けながら適切な性能を維持できます。

さらに、v1と比較してスケールダウンが最大15倍高速化されたことも重要です。トラフィックのピークが過ぎた後、素早くベースラインの容量に戻ることで、無駄なコストの発生を最小限に抑えられます。

本番環境での実践的な活用ポイント

高可用性とディザスタリカバリ

Aurora Serverless v2は、プロビジョンドAuroraと同等の高可用性機能を備えています。主要な機能は以下の通りです。

• マルチAZ配置による自動フェイルオーバー（30秒以内）
• 最大15個のリードレプリカによる読み取り負荷分散
• グローバルデータベースによるリージョン間レプリケーション
• ポイントインタイムリカバリ（最大35日間）

特に興味深いのは、同一クラスター内でサーバーレスインスタンスとプロビジョンドインスタンスを混在させられる点です。例えば、ライターノードはプロビジョンドインスタンスで安定稼働させ、リードレプリカはサーバーレスで需要に応じてスケールさせるという構成も可能です。

セキュリティ機能の強化

2024年から2025年にかけて、以下のセキュリティ機能が強化されています。

• IAMデータベース認証による一時的な認証トークンの利用
• AWS GuardDutyとの統合による異常なデータベースアクセスの検出
• CloudWatch Logsへの監査ログのリアルタイム配信
• Data API経由のアクセスをCloudTrailでデータイベントとして記録

特にGuardDuty RDS Protectionは、機械学習を使用してデータベースへの不正アクセスを検出します。エージェントレスで動作し、パフォーマンスへの影響もないため、本番環境でも安心して有効化できます。

Data APIによるサーバーレスアーキテクチャとの統合

Aurora Serverless v2でのData APIサポートは、Lambda関数からのデータベースアクセスを劇的に簡素化しました。従来のデータベース接続では、以下のような課題がありました。

• コネクションプールの管理が複雑
• VPC内にLambda関数を配置する必要がある
• コールドスタート時の接続確立オーバーヘッド

Data APIを使用することで、これらの問題が解消されます。HTTPSエンドポイント経由でSQLを実行できるため、VPCの設定も不要です。また、以前の1,000リクエスト/秒という制限も撤廃され、クラスターの容量に応じたスケーラビリティが実現しています。

個人的な見解：Aurora Serverlessの未来

ここまでの技術的な詳細を踏まえて、Aurora Serverless v2の現状と将来について個人的な考察を述べたいと思います。

まず、0 ACUへのスケーリング機能の実装は、Aurora Serverlessにとって歴史的な転換点だと考えています。これまでは「サーバーレス」と名乗りながらも、常に最小限のコストが発生する点で、真のサーバーレスとは言えませんでした。しかし今回のアップデートで、ようやくLambdaやFargateと同じレベルの「使った分だけ課金」モデルが実現しました。

特に開発環境やステージング環境での活用価値は計り知れません。これまで多くの企業では、コスト削減のため夜間や週末に開発環境のデータベースを手動で停止する運用を行っていました。Aurora Serverless v2の自動一時停止機能により、このような運用負荷から解放され、エンジニアはより本質的な開発作業に集中できるようになります。

一方で、すべてのワークロードにAurora Serverlessが最適というわけではありません。24時間365日安定したトラフィックがあるシステムでは、Reserved Instancesを活用したプロビジョンドインスタンスの方がコスト効率が良い場合もあります。

また、Babelfish for Aurora PostgreSQL（SQL Server互換機能）がまだサーバーレスでサポートされていない点は、レガシーシステムの移行を検討している企業にとっては制約となるでしょう。

しかし、全体的に見れば、Aurora Serverless v2は確実に成熟期を迎えています。パフォーマンス、スケーラビリティ、コスト効率のすべてにおいて、本番環境での利用に十分耐えうるレベルに達しました。特にスタートアップや、トラフィックが予測しづらい新規サービスにとっては、第一選択肢として検討すべきデータベースソリューションだと考えています。

移行を検討すべきタイミング

Aurora Serverless v1からv2への移行は避けて通れません。しかし、これを機会と捉え、データベースアーキテクチャ全体を見直すチャンスでもあります。以下のようなケースでは、積極的にAurora Serverless v2への移行を検討することをお勧めします。

• 開発・テスト環境のコスト削減を図りたい
• トラフィックの変動が激しいWebアプリケーション
• 定期的なバッチ処理のみでデータベースを利用する
• マイクロサービスアーキテクチャで複数の小規模データベースが必要
• サーバーレスファーストのアーキテクチャを採用している

まとめ

Aurora Serverless v2の2024年後半から2025年にかけてのアップデートは、単なる機能追加ではなく、サービスの本質的な進化を示しています。「0 ACUへのスケーリング」「256 ACUまでの拡張」「30%のパフォーマンス向上」といった改善により、Aurora Serverlessは名実ともに「真のサーバーレスデータベース」となりました。

データベース管理の複雑さから解放され、ビジネスロジックの開発に集中できる環境が整いつつあります。まだAurora Serverlessを試していない方は、ぜひこの機会に検証してみることをお勧めします。特に、新規プロジェクトや開発環境から始めることで、その真価を実感できるはずです。

クラウドネイティブなアプリケーション開発において、Aurora Serverless v2は今後ますます重要な役割を果たすことになるでしょう。技術の進化を適切にキャッチアップし、最適なソリューションを選択することが、競争力のあるシステム構築の鍵となります。