EC2 の Graviton 移行 — 削減幅と移行チェックリスト

インスタンス単価を構造的に下げる手段として単独では最大のレバーが Graviton 移行です。Graviton は AWS が自ら設計した arm64 CPU で、同等の x86 インスタンスより時間単価がおおむね 20% 前後低く、世代によっては性能まで加味した価格性能比が最大 40% まで開きます。これまでの記事が無駄を減らす側だったとすれば、この記事は同じ仕事をより安い単価でやる側です。「うちのワークロードも移せるのか?」に答えるチェックリストとして整理しました。

世代の現況 — 何を選ぶか #

2026 年半ば時点の状況はこうです。

Graviton5 は Graviton4 比でコンピューティング性能が最大 25% 高いと発表されていますが、移行を始める立場では世代の選択は二次的な問題です。arm64 へ移す作業そのものは世代と無関係なので、いったん移せば以降の世代交代はインスタンスタイプの変更だけで済みます。新規の移行なら、利用可能なリージョンと価格を見て Graviton4 系をデフォルトにすれば十分です。バースト型が必要な開発環境には t4g が今もコスパの良い選択です。

移行の難易度 — ワークロード別の目安 #

移行の本質は一つです。arm64 で動くバイナリを用意できるか?

• 簡単 — インタープリタ・VM 言語: Python、Node.js、Ruby、PHP、JVM(Java・Kotlin)のアプリケーションは、ランタイムが arm64 用でありさえすればコード変更はほとんどありません。最新ディストリビューションのパッケージリポジトリは arm64 を標準でサポートします。
• 普通 — ネイティブ依存がある場合: Python の C 拡張、Node のネイティブモジュールは大半に arm64 のホイールやプリビルドがありますが、古くピン留めされたバージョンが足を引っ張ることがあります。再ビルドで解決するかを CI で先に確認します。
• 直接確認 — 自前のネイティブコード、サードパーティのエージェント: Go・Rust はクロスコンパイルが楽な部類で、C/C++ は SIMD イントリンシック(AVX 系)を使っていたなら NEON/SVE への移植可否を見る必要があります。APM・セキュリティエージェントのようなサードパーティのバイナリは、ベンダーの arm64 サポートを確認します。主要ベンダーはほぼ対応していますが、社内で長く使い回されてきたエージェントが伏兵になります。
• 不可 — x86 専用の商用ソフトウェア: ベンダーが arm64 ビルドを提供しないなら、そのワークロードは対象から外します。すべてを移す必要はありません。

移行チェックリスト #

実際の順序は次のとおりです。

1. 依存関係のインベントリ — アプリケーションのネイティブ依存、ベースイメージ、インストールしているエージェントを並べて arm64 サポートを確認します。ここで詰まる項目がなければ半分は終わりです。
2. マルチアーキテクチャイメージのビルド — コンテナのワークロードなら docker buildx で amd64・arm64 を一つのタグにまとめます。ビルド方法は Docker 上級 #2 で扱いました。CI ランナーが x86 だとエミュレーションビルドが遅いので、arm64 ネイティブのランナー(GitHub Actions の arm64 ランナー、CodeBuild の Graviton 環境)を使うほうが速いのです。
3. ステージングでの機能・性能検証 — 機能テストに加えて負荷テストで p99 レイテンシとスループットを x86 の基準線と比較します。大半は同等かそれ以上ですが、ワークロードの特性によって変わるので、実測が基準です。
4. カナリア切り替え — ASG や EKS のノードグループに arm64 ノードを少数混ぜて、実トラフィックの一部を受けさせます。コンテナオーケストレーターは、イメージがマルチアーキテクチャならノードのアーキテクチャに合う側を自動でプルします。問題がなければ比率を上げて完全に切り替えます。
5. マネージドサービスへ拡大 — EC2 より簡単な対象が多いのです。RDS・Aurora・ElastiCache はインスタンスクラスを g 系に変えるだけで終わり(アプリケーションの変更なし)、Lambda は関数のアーキテクチャを arm64 に変えると実行単価が 20% 下がります。Fargate も arm64 をサポートします。むしろこちらから始めて感覚をつかむのも良い順序です。

よく引っかかる罠 #

• 古い AMI・カスタム AMI パイプライン — x86 の AMI を焼いていた Packer テンプレートなどを arm64 用に複製する必要があります。ソース AMI の ID がアーキテクチャごとに異なります。
• ロックファイルに固定された x86 専用ホイール — ロックファイルが x86 ホイールのハッシュを固定していると、arm64 でのインストールがソースビルドに落ちて遅くなったり失敗したりします。マルチプラットフォームのロックとして再生成します。
• 「性能は同じだろう」という仮定 — 大半のウェブ・API ワークロードは同等以上ですが、特定のライブラリが x86 SIMD に最適化されていると逆転します。3 番の実測を飛ばさないでください。
• 混在運用期間のイメージタグの事故 — 移行期間には amd64 単体のイメージが arm64 ノードにデプロイされる事故が起きがちです。マルチアーキテクチャのマニフェストを標準として強制すれば予防できます。

削減幅の計算方法 #

移行の効果は「単価差 × 移した割合」です。オンデマンド単価は同世代の x86 比でおおむね 20% 前後低く、そこに Savings Plans を重ねると割引が掛け算されます。注意点が一つ、EC2 Instance Savings Plans はインスタンスファミリーに縛られるということです。移行の計画があるなら、ファミリーを固定するコミットより、Compute Savings Plans のようにアーキテクチャが変わってもついてくるコミットが安全です。コミットの構造は SAA Domain 4-1 で扱いました。

まとめ #

• Graviton 移行は同等の x86 比で単価約 20% を構造的に下げるレバーで、いったん arm64 に移せば以降の世代交代(現在の主力は Graviton4、Graviton5 が GA)はタイプ変更だけで済みます。
• 要は arm64 バイナリの用意です。インタープリタ・JVM 系は簡単で、ネイティブ依存とサードパーティのエージェントが確認ポイントです。
• 順序は依存確認 → マルチアーキテクチャイメージ → ステージング実測 → カナリア → 拡大です。実測を飛ばさないでください。
• RDS・ElastiCache・Lambda は EC2 より移行が簡単です。感覚をつかむ出発点としても良いのです。
• 移行の計画があるなら、ファミリー固定のコミットではなく Compute Savings Plans を選びます。