Graviton5世代（EC2 M9g/M9gd・RDS M9g）で何が変わったか — Arm世代更新をどのワークロードで取りに行くか
AWS Graviton5世代がEC2（M9g/M9gd）とRDS（M9g）で登場。Graviton4比の性能改善、対応エンジンバージョン、移行の進め方を整理し、どのワークロードでArm世代更新を取りに行くかを判断できるようにします。現時点では東京リージョン未提供のため、先行リージョンでの検証を前提に解説します。
- #Graviton
- #AWS
- #EC2
- #RDS
- #コスト最適化
- #Arm64
AWSのArm64プロセッサ「Graviton」の最新世代であるGraviton5が、EC2（M9g／M9gd）とRDS（M9g）で利用できるようになりました。Arm64インスタンスはコスト最適化の有力な選択肢で、世代が上がるたびに性能と価格性能が改善されています。一方で、2026年6月時点ではEC2・RDSともにアジアパシフィック（東京）では提供されていません。日本の案件で本番採用するのはまだ先になるため、本記事は「今すぐ使う」ではなく「先行リージョンで検証し、東京提供後に本番へ移す」前提で、Graviton5世代で何が変わったか、どのワークロードでArm世代更新を取りに行くかを整理します。
背景：Arm64移行のコスト最適化と世代更新
Graviton（Arm64）への移行は、同等のx86インスタンスより価格性能を改善しやすいことから、コスト最適化の定番手段になっています。前世代のGraviton4世代については EC2 Graviton4 世代の解説 で扱っています。基本的なArm64移行の考え方はそちらが前提になるため、まだ読んでいない場合は先に目を通すと理解しやすくなります。
世代更新（4→5）で見るべきは、(1) 性能・価格性能がどれだけ改善したか、(2) 自分のワークロードがArm64に対応しているか、(3) 提供リージョンが本番要件を満たすか、の3点です。
Graviton5世代とは（EC2 M9g/M9gd・RDS M9g）
Graviton5世代の対象は、EC2の汎用インスタンス M9g（ローカルNVMe SSD付きの M9gd を含む）と、RDSの M9g（PostgreSQL／MySQL／MariaDB）です。性能の改善幅は、いずれも前世代のGraviton4（M8g）と比較した公式の相対値であり、x86比でも固定の割安率でもありません。実際の効果はワークロードや条件によって変わります。
- EC2 M9g／M9gd（対Graviton4）：コンピュート最大25%、Webアプリケーション最大35%、機械学習（ML）推論最大35%、データベース最大30%の性能向上。
- RDS M9g（対同等サイズのGraviton4）：性能最大30%、オンデマンド価格性能最大23%の改善。
チップ面では、Graviton5は1パッケージあたり192コアを備え、L3キャッシュがGraviton4比で5倍、コア間レイテンシが最大33%削減されています。インスタンスのスペックは次のとおりです。
- EC2 M9g／M9gd：m9g.medium 〜 metal-48xl のレンジ。最大192 vCPU／768 GiBメモリ、ネットワーク帯域 最大100 Gbps、EBS帯域 最大72 Gbps。M9gdのローカルNVMeはサイズに比例（medium で1×59 GB、metal-48xl で3×3,800 GB）。
- RDS M9g：db.m9g.large 〜 48xlarge のレンジ。最大192 vCPU、ネットワーク 最大100 Gbps、EBS 最大72 Gbps。
なお、コンピュート最適化やメモリ最適化に相当する系統は本世代のM9gとは別であり、公式に記載のある汎用の M9g／M9gd（EC2）と db.m9g（RDS）に絞って解説します。
どのワークロードでArm世代更新を取りに行くか
世代更新を取りに行く判断は、EC2とRDSで論点が異なります。
- EC2（M9g／M9gd）：汎用コンピュートやML推論で効きますが、前提としてAMIやコンテナイメージがArm64に対応している必要があります。ビルドパイプラインのArm64対応が済んでいるかが判断の起点になります。
- RDS（M9g）：マネージドDBのため、アプリケーション側のArm依存が小さく、エンジンのバージョン要件を満たせば比較的移行しやすいのが特徴です。Arm世代更新の入口としてはRDSのほうが取りに行きやすい場面が多くなります。
Graviton4世代とGraviton5世代の比較観点を整理すると次のようになります。数値は前述のとおり対Graviton4の公式相対値であり、正確な効果は自分のワークロードでのベンチマークで確認してください。
| 観点 | Graviton4世代（M8g） | Graviton5世代（M9g） |
|---|---|---|
| 性能（対前世代） | 基準 | EC2：用途別に最大25〜35%／RDS：最大30% |
| 価格性能（RDS・対前世代） | 基準 | オンデマンドで最大23%改善 |
| 最大規模 | 前世代相当 | 最大192 vCPU／768 GiB（EC2 metal-48xl） |
| 対象ワークロード | 汎用・既存Arm移行 | 汎用・Web・ML推論・DB（世代更新） |
RDS M9g で対応する主なエンジンバージョン（2026年6月時点・最小バージョン以上）は、PostgreSQL 13.18／14.17／15.10／16.6／17.2／18.1、MySQL 8.0.40／8.4.3、MariaDB 10.5.27／10.6.19／10.11.9／11.4.3／11.8.3です。前世代のdb.m8g（Graviton4）より要求される最小バージョンがやや新しいため、既存DBをそのまま移せるとは限りません。比較的新しいメジャーバージョンが対象で、対応バージョンは順次拡大されるため、まずは現行のエンジンバージョンが要件を満たすかを確認し、最新の対応状況は公式ドキュメントで確認してください。
移行・採用の進め方
移行の進め方も、EC2とRDSで分けて考えます。
- EC2：AMIとコンテナイメージのArm64対応を済ませ、ビルドとテストをArm64で回せる状態にしてから切り替えます。依存ライブラリやネイティブ拡張の中にArm64非対応のものが残っていないかも、先行リージョンの検証環境で洗い出しておきます。
- RDS：対応エンジンバージョンへ更新したうえで、リードレプリカを経由した切り替えでダウンタイムを抑え、問題があればロールバックできる手順を用意します。マネージドDBはアプリのコード変更がほぼ不要なため、検証の主眼は性能とコストが見込みどおりかの確認になります。
最大の制約はリージョンです。EC2・RDSともに、現時点の提供は米国東部（バージニア北部／オハイオ）、米国西部（オレゴン）、欧州（フランクフルト）に限られ、東京リージョンは未提供です。拡大時期は公表されていないため、日本中心の案件では「先行リージョンで検証を進め、東京提供後に本番へ移す」段取りが現実的です。
料金については、時間単価が為替・改定・リージョン差で変動するため、本記事では具体額を示しません。価格性能の改善幅（RDSで対Graviton4 最大23%）を目安にしつつ、最新の時間単価は公式のEC2／RDS pricingページで確認してください。
まとめ
Graviton5世代（EC2 M9g／M9gd・RDS M9g）は、対Graviton4で性能と価格性能を改善したArm世代更新です。判断の指針は次の3点です。
- 性能改善はすべて対Graviton4の公式相対値。実効果は自分のワークロードでベンチマークする
- Arm世代更新の入口は、アプリ側のArm依存が小さいRDSが取りに行きやすい
- 東京リージョンは未提供のため、先行リージョンで検証し、東京提供後に本番移行する
Arm64移行はコスト最適化の柱の一つです。あわせて AWS FinOps Agent や Lambda SnapStart for Python など、コスト最適化の他の打ち手も組み合わせると効果を高めやすくなります。各サービスの性能値・料金・提供リージョンは流動的なため、採用時は公式の最新情報を必ず確認してください。