Graviton vs x86 — EC2 インスタンスアーキテクチャの選択基準
EC2 のインスタンスファミリーを選んだあとに、もう 1 つの軸が残ります。同じ m 系の中でも x86(m7i、m8i)と ARM(m8g、m9g)に分かれるからです。結論を先に書くと、アーキテクチャを新しく決められるワークロードは Graviton が基本です。 時間単価が 10〜15% 低く、世代が進むほど性能差が広がり、価格性能比では数十 % の差になります。x86 が残る理由は性能ではなく互換性(商用バイナリ、特定命令セットへの依存、Windows のライセンス)です。ファミリーの選択自体は EC2 インスタンスファミリー比較で、移行の実務手順は Graviton 移行チェックリストで扱ったので、この記事は選択の判断に絞ります。料金は us-east-1 基準です。
一目でわかる比較 #
| 項目 | Graviton(ARM) | x86(Intel・AMD) |
|---|---|---|
| 時間単価(m 系 large) | m8g 約 $0.090 | m7i 約 $0.101 |
| 価格性能比 | 同等の x86 に対して数十 % 優位(ワークロードにより差) | 基準 |
| ソフトウェア互換 | オープンソース生態系の大部分が対応 | 事実上すべて |
| コンテナ | arm64 イメージ・マルチアーキビルドが必要 | 既存イメージそのまま |
| 商用ソフトウェア | ベンダーごとの対応確認が必要 | 大部分が対応 |
| Windows | 非対応 | 対応 |
| 最新世代 | Graviton5(m9g、2026-06 GA) | 世代を並行して更新 |
料金と性能 — 差の実際の大きさ #
時間単価から見ると、m8g.large(Graviton4)が約 $0.090、m7i.large(Intel)が約 $0.101 で、Graviton が約 11% 安くなります。単価差はこの程度ですが、実際の差は性能で開きます。AWS は Graviton4 ベースのインスタンスが同等の x86 に対して数十 % 良い価格性能比を出すとしており、Web サーバーや API サーバー系のベンチマークでは同じ vCPU 数でより高いスループットが出る結果が一般的です。vCPU の実体が違う点も効いています。x86 の vCPU はハイパースレッド 1 本ですが、Graviton の vCPU は物理コア 1 個です。
2026 年 6 月には Graviton5 ベースの m9g・m9gd が GA になりました。m8g より時間あたり約 9% 高いものの性能が最大 25% 上がり、価格性能比はさらに 15% ほど改善します。ただし提供リージョンが当初は限定的(バージニア、オハイオ、オレゴン、フランクフルトから)なので、リージョンの制約がなければ m9g、それ以外は m8g が現在の基本です。GPU や NVIDIA の世代表記と同じく、世代の情報は時点によって変わるため、導入時点で最新世代とリージョン対応を確認します。
削減の手段としての特徴は、コミットなしで単価が下がる点です。RI や Savings Plans は 1〜3 年のコミットの対価ですが、Graviton への移行はコミットなしで同じ幅の削減を作り、その上にコミットを重ねられます。コミットの体系は RI vs Savings Plans で扱いました。
どこから移すか — マネージドが先 #
移行の難易度は層によってまったく違います。
マネージドサービスが最も簡単です。 RDS、Aurora、ElastiCache、OpenSearch のようなサービスは、インスタンスクラスを db.m7i から db.m8g に変えるだけで終わりです。自分のコードがその上で動くわけではないので互換性の問題が構造的になく、再起動の時間枠だけ確保すれば済みます。Graviton の削減を始める場所は EC2 ではなくここです。
インタープリタ・JVM 系は比較的簡単です。 Python、Node.js、Ruby、PHP、Java、Go は arm64 ランタイムが成熟しており、大部分は再ビルドかイメージの差し替えで終わります。引っかかるのは言語ではなくネイティブ依存です。C 拡張を含むパッケージ、社内ビルドのバイナリ、古いベースイメージが arm64 ビルドを提供しているかの確認が必要です。
コンテナはマルチアーキビルドが関門です。 CI で amd64・arm64 のイメージを一緒にビルドしてマニフェストでまとめる体制を整えれば、ノードグループ単位で段階的に移行できます。詳細な手順と検証項目は移行チェックリストに整理してあります。
x86 が残る領域は明確です。arm64 ビルドを提供しない商用ソフトウェア、x86 特有の命令(AVX 系など)に最適化された数値計算、Windows のワークロード、そして検証コストを正当化できない小規模のレガシーです。このリストに該当しないのに x86 を使っているなら、惰性以外の理由があるか点検する価値があります。
選択の手順 #
- 新規ワークロードは Graviton で始めます: 最初から arm64 でビルドすれば移行コストは 0 です。リージョンが対応していれば m9g、そうでなければ m8g です。
- マネージドサービスから変えます: RDS・ElastiCache のインスタンスクラス変更はコード修正なしで単価だけ下がります。最も確実な最初の削減です。
- 自前のワークロードは依存関係のスキャン後にパイロットを回します: arm64 非対応の依存がないか確認し、カナリアや別ノードグループで実測の性能・料金を比較します。
- 混在期間を設計します: マルチアーキイメージとアーキテクチャ非依存のデプロイパイプラインを整えれば、サービス単位で段階的に移行できます。一度に全部移す必要はありません。
- x86 に残す一覧を明示的に管理します: 商用バイナリ・特定命令・Windows のように残る理由を記録しておけば、ベンダー対応が出たときに再検討できます。
まとめ #
- アーキテクチャを決められるワークロードは Graviton が基本です。時間単価が 10〜15% 安く、価格性能比の差はそれより大きくなります。
- 現在の基本は m8g(Graviton4)で、リージョンが対応していれば 2026 年 6 月に GA した m9g(Graviton5)が価格性能比をさらに 15% ほど上乗せします。
- 始める場所はマネージドサービスです。RDS・ElastiCache はインスタンスクラスの変更だけで削減が確定し、互換性のリスクがありません。
- 自前のワークロードの関門はネイティブ依存とマルチアーキビルドです。手順は移行チェックリストに従い、パイロットの実測で確定します。
- Graviton の削減はコミットなしで得られる単価の引き下げで、RI・SP と重ねられます。x86 に残すのは互換性の理由があるときだけです。