【セッションレポート】「実践!Amazon RDS と Amazon Aurora のコスト最適化とパフォーマンス向上」

はじめに

こんにちは、インフラ担当の川島です。

先日、AWS Summit Japan 2026に参加してきましたので気になったセッションに関して紹介していきたいと思います。

皆さんはクラウド環境におけるデータベースのコストとパフォーマンスの両立について悩んだことはないでしょうか。

今回はそんな悩みを解決するためのセッション、「実践!Amazon RDS と Amazon Aurora のコスト最適化とパフォーマンス向上」について紹介していきたいと思います。登壇者はアマゾンウェブサービスジャパン合同会社の塚井知之氏でした。

本セッションでは、「パフォーマンス向上」と「コスト最適化」は両立できるというゴールを掲げ、架空の企業「AnyCompany」の事例を通じて具体的な実践テクニックが語られていました。

インフラ担当として非常に実践的で学びが多かったため、こちらの内容に焦点をあてて紹介させていただきます。

データベースにおける3つの主要コスト要素

まず、Amazon RDSおよびAuroraのコスト構造を理解する上で、最適化の対象となる3つの主要なコスト要素が挙げられていました。

コンピュート
ストレージ
バックアップ

これら3つの要素の最適化へ進む前に、今回の原因分析において極めて重要な役割を果たした「モニタリングの進化」について触れたいと思います。

性能分析の要：Amazon RDS / Aurora モニタリングの進化

データベースのトラブルシューティングや最適化において、「見えないものは改善できない → 可視化が重要」と言われるように、ワークロードの可視化は最も重要なステップです。

従来のインフラ運用では、データベースの性能分析を行うために以下のような多数のソースを個別に確認し、パズルのように組み合わせて原因を特定する必要がありました。

CloudWatch メトリクス
拡張モニタリング
Performance Insight
RDS ログ
RDS イベント
自作のモニタリングスクリプト

しかし、これらのツールを使う場合、全体像を把握するために複数の画面を行き来する必要がありました。こうした課題を解決するために登場したのが、モニタリング機能が統合・進化した「CloudWatch Database Insights」です。

CloudWatch Database Insightsは、データベース分析のためのメトリクスやログを1つのダッシュボードに統合し、複数のインスタンスを跨いだフリート全体のビューを提供してくれます。

今回のAnyCompanyの事例でも、このCloudWatch Database Insightsが原因分析のフェーズで大活躍していました。ダッシュボードを開くだけで、フリート全体の健全性はもちろん、DB負荷の上位を占めている実行効率の悪い具体的なSQLや、「CPU」「IO:BufFileWrite」といった上位の待機イベントを瞬時に一画面で特定できるようになっています。

上記の画面では、中央の「Database resources state summary」にてフリート全体の状態が確認でき、青色で示された1台（Warning状態）に問題が発生していることが直感的に分かります。また、右側のグラフではDB負荷（DB Load Utilization）の推移が示されており、ワークロードが急激にスパイクしている様子が視覚的に捉えられます。

コンピュートの最適化

最初はコンピュートリソースの最適化についてです。

顧客利用の急増によりCPU使用率が100%に到達し、パフォーマンスが劣化するという課題が発生していました。これに対して、単にインスタンスサイズを上げる（垂直スケーリングする）のではなく、以下のステップでアプローチしていました。

CloudWatch Database Insightsの活用: ダッシュボードを確認することで問題のあるインスタンスや、実行効率の悪いSQLを期間を指定してピンポイントで特定・分析しました。
インスタンスの適正化と新世代Gravitonへの移行: 特定した実行効率の悪いSQLを最適化した上で、インスタンスサイズを適正化しました。さらに、同じARMアーキテクチャであるGravitonインスタンスの中で、より新しい世代へと移行（R6g.2xlargeからR8g.xlargeへ変更）しています。

重いSQLの排除とインスタンスの適正化を組み合わせた結果、インスタンスコストを約46%削減し、平均CPU使用率も約70%削減することに成功しています。

また、社内のデータアナリストが運用データベースに重いレポートクエリを投げることで、顧客向けアプリケーションの性能が劣化する「ノイジーネイバー」問題も起きていました。

これに対しては、より大きなインスタンスへ垂直スケーリングするのではなく、リードレプリカを作成してレポートクエリをオフロードする「水平スケーリング」を採用していました。結果として、垂直スケーリングと比較して15%のコスト削減効果を得ながら、アプリケーションの一貫したパフォーマンスを確保しています。

ストレージの最適化

続いてストレージです。I/Oレイテンシが2msから500msまで増大し、データベースがAmazon EBSのIOPS上限に到達する課題が発生していました。

要件として最大20K IOPSのサポートと、I/Oレイテンシをサブミリ秒以下にすることが求められており、これに対して以下のステップでアプローチしていました。

CloudWatch Database Insightsの活用: ダッシュボードを確認することでI/Oレイテンシの急増や、EBSのIOPSも急増して上限に達していることを確認しています。
io2 Block Expressへの移行: 汎用ストレージ（gp2）からio2 Block Expressへ変更することで、20K provisioned IOPSを実現しました。これにより、一貫したサブミリ秒のI/Oレイテンシを確保しています。

上記変更はプライマリインスタンスに適用し、構成を最適化していました。

続いて、複雑なクエリ（JOIN, GROUP BY, ORDER BYなど）によるダッシュボードの読み込み遅延問題も紹介されました。

Amazon RDSでは、メモリに収まらない一時オブジェクトはEBSに配置・読み書きされるため遅延の原因になります。

CloudWatch Database Insightsの活用: ダッシュボードを確認し、「IO:BufFileWrite」の待機イベントが発生して一時書き込みが多発していることを把握し、複雑なクエリによる過剰なI/Oがボトルネックになっていることを特定しています。
RDS Optimized Readsの活用: ローカルNVMeベースのSSDブロック・ストレージを搭載した「d」タイプのインスタンス（例：R8gd.large）を利用することで、一時オブジェクトをローカルストレージに作成しクエリを最大100%高速化します。垂直スケーリングと比較して、より低コスト（43%削減）で2倍の性能向上を達成していました。

Aurora特有の最適化手法

これまでの内容はRDSに関するものでしたが、Amazon Auroraを利用している場合、突発的（スパイク）なI/Oが発生するとコストが増大する課題があります。

Aurora I/O-Optimized: I/Oリクエストごとの課金がされないこの料金モデルに切り替えることで、I/Oが多いワークロードにおいてストレージコストを削減（事例では23%削減）し、コストの予測を容易にしていました。

また、Auroraにおけるノイジーネイバー対策として、リーダーインスタンスを無闇に追加するのではなく、Aurora Optimized Readsを使用した内容が紹介されていました。

バッファプールの領域をNVMe SSDまで拡張する階層型キャッシュを利用することで、巨大なインスタンス用意することなく最大8倍の読み取りクエリ性能向上と、90%のコスト削減を実現しています。

バックアップの最適化

最後にバックアップコストです。

1週間以上古いデータはクエリで参照できれば良いという要件に対し、長期間（1ヶ月）バックアップを保持しておりコストが高くなっていました。

Amazon S3へのスナップショットエクスポート: 1週間より前のデータはオープンソースのApache Parquet形式でS3にエクスポートしてデータレイクで保持し、RDS側の自動バックアップ期間を短縮します。これにより、バックアップコストを30%削減していました。

まとめ

セッションの最後にまとめられていたAnyCompanyの7つの課題と成果の一覧です。

#	DB	課題	解決策	成果
課題1	RDS	CPU 100% スパイクと重い SQL	Database Insights 適正化 + Graviton	46% インスタンスコスト削減 70% CPU 使用率削減
課題2	RDS	ノイジーネイバー(レポートクエリ干渉)	リードレプリカ + クエリオフロード	15% コスト削減 50% API パフォーマンス改善
課題3	RDS	EBS I/O レイテンシ増(2ms → 500ms)	ストレージ適正化(gp2 → io2 Block Express)	20K IOPS 実現サブミリ秒レイテンシ
課題4	RDS	レポートクエリ遅延(一時オブジェクト)	RDS Optimized Reads (R8gd + NVMe SSD)	43% コスト削減 2倍読み取り性能
課題5	Aurora	Aurora I/O コスト増(スパイク I/O)	Aurora I/O-Optimized	23% コスト削減コスト予測性の向上
課題6	Aurora	Aurora ノイジーネイバー読み取り性能劣化	Aurora Optimized Reads (階層型キャッシュ + NVMe)	90% コスト削減最大8倍読み取り性能
課題7	RDS / Aurora	バックアップコスト削減(1ヶ月保持)	S3 Parquet スナップショットエクスポート	30% バックアップコスト削減

最後に「コストとパフォーマンスの最適化は相互補完的なタスク」であると語られており、インフラエンジニアとして考えさせられる言葉だと思いました。

パフォーマンスを追及することが結果的に無駄なリソースやコストの排除に繋がり、逆にコストを適正化しようとするプロセス（重いSQLの特定やキャッシュの活用など）が劇的な性能向上をもたらします。

そして、そのサイクルを回すための大前提として「可視化」があります。進化したCloudWatch Database Insightsのようなツールを使いこなしていくことの重要性を強く感じました。