EC2 Graviton4 世代とは — R8g/C8g/M8g/X8gの違いとArm64移行の進め方

EC2 や ECS・EKS、RDS などを運用していると、「インフラコストをもう一段下げられないか」という相談を受ける場面は多いのではないでしょうか。その有力な選択肢のひとつが、AWS独自のArmプロセッサ Graviton への移行です。2024年7月に R8g インスタンスを皮切りにGAした Graviton4 は、その第4世代にあたります。

ただ、Graviton は「変えれば必ず安くなる」という魔法ではありません。効果は自分のワークロード次第で、測ってみて初めて分かるものです。この記事では、Graviton4 とは何か（前世代からの世代差）、R8g/C8g/M8g/X8g といったファミリーの使い分け、x86 からの Arm64 移行の進め方と判断軸までを、ベンチマークを前提とした誠実なトーンで整理してみましょう。なお「Arm64（aarch64）」とは、Graviton が採用しているCPUの命令セットアーキテクチャのことです。

Graviton4 とは — Graviton3 からの世代差

Graviton は、AWSが自社設計しているArm64プロセッサです。Graviton4 はその第4世代で、前世代 Graviton3 から性能が一段引き上げられています。

AWSの公式表現によれば、Graviton4搭載の R8g は、Graviton3搭載の R7g と比べて「Webアプリで最大30%、データベースで40%、大規模Javaアプリで45%高速」とされています。ここで大事なのは、この数字があくまで「対Graviton3」かつ「特定のワークロード」での値だということです。あなたのアプリでそのまま再現される保証はありません。前提付きの参考値として受け取るのが安全です。

ハードウェアの世代差（R8g 対 R7g）としては、メモリ帯域が約75%増、L2キャッシュが2倍、最大vCPUが3倍（最大192）、メモリが最大3倍（最大約1.5TB）、ネットワーク最大50Gbps・EBS最大40Gbpsといった強化が公表されています。コア構成（96 Neoverse V2 コア、DDR5 など）の細部も発表されていますが、こうしたスペックの数値は更新されることがあるため、正確な値はGraviton公式ページで確認してください。

ファミリーの使い分け — R8g / C8g / M8g / X8g

Graviton4 世代のインスタンスは、用途別に複数のファミリーが用意されています。「自分のワークロードならどれか」を判断できるよう、代表的なものを整理します。

ファミリー	種別	代表的な用途
R8g / R8gd	メモリ最適化	データベース、インメモリキャッシュ、リアルタイム分析（d付きはローカルNVMe SSD付き）
C8g	コンピュート最適化	HPC、バッチ処理、動画エンコード、CPUベースの推論
M8g	汎用	アプリケーションサーバ、マイクロサービス
X8g	大容量メモリ	最大3TiBメモリ。インメモリDB（Valkey / Redis OSS / Memcached 等）
C8gn / R8gn / R8gb / M8gn / M8gb	ネットワーク／EBS強化版	例: C8gn は最大600Gbpsネットワーク、R8gb は最大300Gbps EBS

ざっくりした覚え方としては、メモリが効くなら R8g、CPUを使い切るなら C8g、バランス重視の汎用なら M8g、とにかく大容量メモリが要るなら X8g です。末尾に n が付くものはネットワーク強化版、b はEBS（ブロックストレージ）帯域の強化版、d はローカルNVMe SSD付き、という命名の規則性も知っておくと選定が早くなります。

なお、各ファミリーがどのリージョン（東京を含むか等）で使えるかは順次拡大しており流動的です。利用検討時はEC2インスタンスタイプのページで最新の提供状況を確認してください。ここは断定を避けます。

価格性能をどう見るか — 「x86比◯%」と言わない理由

ここが、この記事でいちばん誠実にお伝えしたいところです。

AWSは Graviton4 系の各ファミリーを「EC2で最高の価格性能（best price performance）」と表現しています。ただし、Intel や AMD などの x86 系インスタンスと比べて何%安い・速いといった定量的な比較は、公式が明示していない部分が多いのが実情です。ですから本記事でも、「Gravitonは x86 比◯%安い」といった断定はしません。ネット上ではそうした数字を見かけることもありますが、前提のはっきりしない比較を鵜呑みにするのは危険です。

参考として、AWSが挙げる顧客事例には、SmugMug が圧縮処理で Graviton4 が Graviton3 比 20〜40% の性能向上を得た、というものがあります。ただしこれも特定企業の特定ワークロードでの結果であり、汎用的な数字ではありません。

では、どう判断すればよいか。答えはシンプルで、自分のワークロードでベンチマークを取ることです。価格性能はワークロードの特性（CPU律速かメモリ律速か、スケールアウトの仕方など）で大きく変わります。「公式が best price performance と言っているから」ではなく、「自分の環境で測ったら効いた」を根拠にする。これがフリーランスとしての誠実さであり、信頼にもつながります。

Arm64移行の進め方と、向く/向かないワークロード

Graviton は Arm64 アーキテクチャなので、x86 から移すには「Arm64で動くようにする」作業が要ります。とはいえ、多くのモダンな言語・ランタイム（C/C++、Rust、Go、Java、Python、.NET Core、Node.js、Ruby、PHP など）が対応しており、実際には思ったより素直に移行できるケースも少なくありません。

移行の基本ステップは、おおむね次の流れです。

1. 依存のArm互換を確認する — x86バイナリ前提のライブラリやネイティブ拡張（C拡張など、特定CPU向けにコンパイルされた部分）が Arm64 に対応しているかを洗い出す。ここが最初の関門です。
2. Arm64で再ビルド／マルチアーキコンテナ化する — コンテナなら linux/arm64 を含むマルチアーキイメージをビルドする。「マルチアーキコンテナ」とは、x86とArmの両方のイメージを1つのタグで提供できる仕組みです。
3. 移行後にベンチマーク・回帰検証する — 性能と挙動が想定どおりかを、本番に出す前に測って確かめる。

公式の顧客事例では、Recruit が「コード変更なしで移行できた」、Sprinklr が「移行はシームレスで数日だった」と紹介されています。これらも前提付きの事例ですが、「多くの一般的なワークロードは現実的な工数で移行しうる」という肌感の裏付けにはなります。

向き不向きも整理しておきましょう。

	内容
向くワークロード	スケールアウト型のWeb/アプリサーバ、マイクロサービス、コンテナ、DB・インメモリキャッシュ、CPUベース推論・HPC、大容量メモリDB
向かない／注意	x86専用バイナリへの依存が強いソフト、Arm非対応の商用エージェントやドライバ、移行コストが削減効果を上回る小規模・短命なワークロード

なお、「AWS Graviton Ready」のようなパートナー／対応ソフトのプログラムや、公式の移行ガイドの有無・正確な名称については、本稿では断定しません。利用前にGraviton公式で最新の情報を確認してください。

まとめ

ポイントを3つに絞ります。

1. Graviton4 ＝ AWS独自Armプロセッサの第4世代。対Graviton3の世代差（最大30%など）は前提付きの値で、ファミリーは用途で使い分け（メモリ＝R8g／コンピュート＝C8g／汎用＝M8g／大容量メモリ＝X8g）。
2. 価格性能は「x86比◯%」と断定しない。AWSの best price performance という表現を踏まえつつ、自分のワークロードでベンチマークを取るのが誠実な見方です。
3. 移行は依存のArm互換確認 → 再ビルド／マルチアーキ化 → 移行後ベンチマークが基本。記事①〜③のコスト最適化テーマと地続きで、横断提案がしやすい領域です。

Graviton4 を含む最近のAWSアップデートは AWS最新サービスの解説ハブ に横断的にまとめています。あわせてご覧ください。