2026年6月10日、AWSが新世代ARMプロセッサーを搭載したEC2インスタンス「M9g」と「M9gd」をGA（一般提供）として発表した[1]。Graviton5（グラビトン5）はAWSが独自設計したCPUの第5世代で、192コアを最大構成とし、前世代のGraviton4（M8g）と比べてWebアプリケーション35%・ML推論35%・データベース30%の性能向上を実現する[1]。コストパフォーマンス重視のEC2ファミリーに何が変わったのか、移行時の試算と注意点を整理する。
Graviton5の性能仕様
| 項目 | Graviton4（M8g） | Graviton5（M9g） | 向上率 |
|---|---|---|---|
| 最大コア数 | 192（m8g.48xlarge） | 192（m9g.48xlarge） | 同等 |
| Webアプリ性能 | 基準 | +35% | — |
| ML推論 | 基準 | +35% | — |
| データベース性能 | 基準 | +30% | — |
| ネットワーク帯域 | 基準 | +15% | — |
| EBS帯域幅 | 基準 | +20% | — |
Nitro 6 smartNICがNIC処理をオフロードすることでネットワーク帯域とEBS帯域が向上した[1]。ClickHouseはベンチマークで36%の改善、HubSpotのMySQL本番環境では最大60%の改善を報告している。
「M9gd」はNVMeローカルSSD搭載バリアントで、I/OレイテンシーにシビアなDBワークロードやAIトレーニングのチェックポイント書き込みに向く。
対象ワークロードと移行判断
Graviton5への移行対象として優先度が高いのは次の3カテゴリだ。
1. Webアプリ・APIサーバ：最も移行容易で、性能向上が最大の35%に達する。Java（JVM）・Node.js・Goで書かれたマルチスレッドアプリは特に恩恵が大きい。コンパイル済みバイナリを使っていない限り、arm64対応の確認と再テストのみで移行できる。
2. RDBMSおよびNoSQL：MySQLやPostgreSQL、Amazon RDSもGraviton5インスタンスをサポートしている。30%の性能向上は、読み取り負荷が高いREPLICA系インスタンスから試すのが低リスクだ。
3. ML推論：INT8/FP16推論でGraviton5はInferentia不使用のCPU推論ワークロードをカバーできる。レイテンシー要件が100ms以内のバッチ推論は試す価値がある。
一方、次のワークロードは移行の前提確認が必要だ。
- x86専用バイナリ（ビルドが再現できない古い依存ライブラリ）
- AVX-512命令を使うHPC（High Performance Computing）ワークロード
- Windows Server（GravitonはLinuxのみ対応）
コスト試算の実例
仮に現在 m7g.4xlarge（Graviton3）を10台、オンデマンドで月間720時間稼働させているケースを考える。東京リージョン（ap-northeast-1）の概算単価を用いると：
| インスタンス | 世代 | 単価（概算USD/h） | 月間コスト（10台） |
|---|---|---|---|
| m7g.4xlarge | Graviton3 | $0.704 | $5,069 |
| m8g.4xlarge | Graviton4 | $0.726 | $5,227 |
| m9g.4xlarge | Graviton5 | $0.748（推定） | $5,386 |
価格差は5〜6%増だが、性能が35%向上するため「同じアプリを1台少ない構成で動かせる」換算で逆にコスト削減になるケースがある。実測スループットと必要台数を再計算してからSavings Planまたはリザーブドインスタンスへ移行するのが最善の順序だ。
arm64移行チェックリスト
コンテナイメージのマルチアーキテクチャビルド確認：
docker buildxでlinux/arm64のイメージをビルドしているか、DockerHub・ECRにarm64対応タグが存在するかを確認する。言語・ランタイムのarm64対応確認：Python 3.9+・Node.js 18+・JDK 17+はarm64でフルサポート済み。Go・Rustはネイティブクロスコンパイル対応。C/C++の場合はコンパイルオプションの確認が必要。
依存ライブラリの確認：PyPI・npmのパッケージはほぼarm64対応済みだが、ネイティブモジュール（C拡張）は個別確認が必要。
pip install --platform manylinux2014_aarch64でarm64ホイールの有無を確認できる。段階的移行：Kubernetes環境では
nodeAffinityでGravitonノードプールを追加し、tolerationsでテスト用Podを誘導してから全面移行するブルーグリーン方式が安全だ。
まとめ
Graviton5（M9g）はWebアプリ・DB・ML推論で前世代比30〜35%の性能向上を実現し、コンテナ・Linux環境で稼働する大多数のワークロードで移行の障壁が低い。コスト面でも性能当たり単価が改善されており、次のEC2インスタンス更新タイミングではまず評価の対象に入れてほしい世代だ。
よくある質問（FAQ）
Q1. M9g と M9gd はどちらを選べばよいですか？
ステートレスなWebアプリやAPIサーバは M9g で十分です。DBのデータファイルやAIトレーニングのチェックポイントのように、高速な一時ストレージが必要なワークロードは M9gd のNVMe SSDを活用してください。
Q2. RDSのGraviton移行はインプレースで可能ですか？
Amazon RDSはスナップショットリストアによるインスタンスタイプ変更が可能で、arm64（Graviton）への移行もサポートしています。ただし対応エンジン・バージョンの確認が必要です。MySQLとPostgreSQLは対応済みです。
Q3. 既存のSavings PlanはGraviton5にも適用されますか？
Compute Savings PlanはGraviton5インスタンスを含む全ファミリー・サイズに適用されます。EC2 Instance Savings Planはインスタンスファミリーとリージョンが固定されるため、M9gを対象にした場合は旧世代に適用されたプランとは別のプランが必要です。
