はじめに

皆様こんにちは、あかいけです。

AWS Summit Japan 2025 の一日目で行われた、
「進化する Amazon EC2 〜 AWS Nitro システムと独自プロセッサがもたらす価値とコスト効率」に参加してきました。
本記事ではそのレポートをお届けします。

セッション概要

タイトル :
進化する Amazon EC2 〜 AWS Nitro システムと独自プロセッサがもたらす価値とコスト効率

概要:
Amazon Elastic Compute Cloud (EC2) は、インフラストラクチャからプロセッサに至るまで進化を続けています。
AWS Nitro システム、AWS Graviton4 や AWS Trainium2 といった独自プロセッサは、お客様に新たな選択肢を提供しています。
コストと性能の両立・最適化にお悩みの方、EC2 を支える最新技術の知見をお求めの方に向けて、本セッションでは、基盤技術や独自プロセッサの特長について、詳しく解説します。

スピーカー :
池田 優

セッションレベル :
Level 400: 上級者向け

資料

AWS 公式から資料や動画がアップされたら追記します。

レポート内容

本セッションについて

• セッションの対象者
  • ワークロードのコスト、パフォーマンスに悩んでいる方
  • 既存のワークロードを AWS Graviton への移行を検討している方
  • AWS Nitro System、AWS Graviton に関する知見を求めている方
• セッションのゴール
  • AWS Graviton に移行する際のアプローチを理解する
  • AWS Nitro System、AWS Graviton がもたらすメリットを理解する

アジェンダ

• AWS のシリコンイノベーション
• AWS Nitro System が提供する効率性
• AWS Graviton が実現するコストパフォーマンス
• AWS Graviton 移行ガイド
• 実践ガイド：AWS Graviton 事例とアプローチ

AWS のシリコンイノベーション

まず AWS では用途に合わせて様々な専用チップ開発を行っています。

• AWS Nitro System
  • 用途：ハイパーバイザー、ネットワーク、ストレージ、SSD、セキュリティ
• AWS Graviton
  • パワフルで効率的なプロセッサ
• AWS Trainium、AWS Inferentia
  • 機械学習向けアクセラレーション

独自シリコンを開発する背景

AWS が独自シリコンを開発する背景として以下の理由があります。

• 最適化
  • AWS の仕様に合わせてハードウェアを最適化
  • それにより高い電力効率を実現
• スピード
  • 製品仕様から導入までのプロセスを一括で自社管理
  • それにより提供スピードを早める
• イノベーション
  • エンドツーエンドでの最適化
  • それによりより多くの価値を創造
• セキュリティ
  • 物理的な分離
  • それによりお客さまのコンテンツへのアクセスを分離

AWS Nitro System が提供する効率性

AWS Nitro System について

• Amazon EC2 独自の仮想化基盤
• C5、M5、R5 のインスタンスタイプの世代から対応
• 独自ハードウェアによって最適化されたパフォーマンスを提供

AWS Nitro System 以前の仮想化基盤について

AWS Nitro System 以前の仮想化基盤では、
監視、ストレージ仮想化、ネットワーク仮想化などの機能はお客様のインスタンス上と同じホスト上で実行されていました。
そのためコストパフォーマンスの低下、またオーバヘッドにより、お客様が利用できるリソース量に影響してしまいました。

AWS Nitro System では以下の設計により、そのようなオーバヘッドを軽減しました。

• ネットワークやストレージの仮想化を専用ハードウェアにオフロードしてホストと分離
• ホスト上で軽量ハイパーバイザーの Nitro Hypervisor を実行

AWS Nitro System によるパフォーマンス向上

• 世代を追うごとに、ネットワーク帯域性能あたりのコストパフォーマンスを向上させている
  • NITRO：10GBPS
  • NITRO v2：25GBPS
  • NITRO v3：100GBPS
  • NITRO v4：100GBPS
  • NITRO v5：200GBPS
  • NITRO v6：400GBPS

プロセッサ選択肢の増加

• 独自プロセッサの開発によりプロセッサアーキテクチャの選択肢が増加
  • Intel Xeon
  • AMD EPYC
  • AWS Graviton
  • Apple Silicon

AWS Graviton が実現するコストパフォーマンス

AWS Graviton 性能の進化

• ARM ベースプロセッサ
• コスト面
  • x86 に比べて、20% コスト低コスト
• 性能面
  • 世代を追うごとに性能向上
  • HammerDB TPROC-C 負荷テストによる MySQL 性能比較
    • R7g に比べ R8g は性能が約 1.4 倍
  • wrk2 を用いた Groovy Grails アプリケーション性能比較
    • R7g に比べ R8g は性能が約 1.4 倍

AWS Graviton 移行ガイド

AWS Graviton を使うには

• マネージドサービスでの利用 (RDS など)
• ARM アーキテクチャベースで新規開発
• 既存アプリケーションから移行

AWS Graviton への移行ステップ

x86 などから Graviton へ移行する場合は CPU アーキテクチャが変わるため、
以下のようなステップを踏む必要があります。

• 準備
  • Graviton プロセッサーを理解
  • 現在のソフトウェアの棚卸し
• 移行計画
  • 既存ソフトウェアのアーキテクチャ特有の要件を確認
  • ARM サポート状況確認
    • もし ARM サポートがなければ、x86との並行利用も検討する
  • マルチアーキテクチャ環境の戦略
• テストと最適化
  • 機能/単体テストを実行
  • パフォーマンス測定/最適化
  • スケーリング設定を最適化
• 本番展開
  • デプロイプロセスを更新
  • 段階的移行を実施
  • 本番環境の監視

AWS Graviton Technical Guide

プログラミング言語に応じた考慮事項は以下のリポジトリに記載されています。
Graviton への移行を検討される際は、ぜひご確認ください。

https://github.com/aws/aws-graviton-getting-started

実践ガイド：AWS Graviton 事例とアプローチ

事例概要

• 現行：k8s をベースとしたさまざまなワークロードが存在
• 要望：ユーザー数は増加しているが、パフォーマンスは落としたくない
• 移行先として AWS Graviton を選んだ理由：
  • イノベーションの最前線
  • CPU コアあたりの価格効率、効率的なリソースの活用
  • エネルギー効率と排出量削減

移行スケジュール

PoC から 18 ~ 20 ヶ月で本番ワークロードの 9 割の移行を完了

• Poc で確認したこと
  • ARM 対応にあたり、アプリ側の変更が必要か確認
  • 移行に必要なアップグレードの特定
  • 負荷テストによるパフォーマンス分析

移行にあたる考慮事項と対応

• ビルドプロセスの最適化

  • 考慮事項
    • Golang 製サービスに比べて、Python 製サービスのビルド速度が遅かった
  • 対応
    • まずは変更が少ない、Golang 製サービスから移行を進めた
    • 最終的に Bazel を利用して、Python 製サービスのビルドプロセスを改善した

• コンテナイメージ戦略

  • 考慮事項①
    • ARM 移行に伴い、複数アーキテクチャ向けのビルドパイプラインの拡張が必要
    • 実行環境に応じて適切なイメージを自動選択する仕組みが必要
  • 対応①
    • レジストリをマルチアーキテクチャ対応にした
    • ECR はマニフェストリストをサポートしている
    • 一つのイメージリポジトリから、異なるアーキテクチャのコンテナイメージがデプロイ可能
  • 考慮事項②
    • 複数アーキテクチャ向けイメージを管理するため、
      ECR で管理するイメージの数が倍増
  • 対応②
    • ライフサイクルポリシーを設定することで、イメージのライフサイクルを実装
    • 複数のルールや優先順位を作成可能
    • デプロイ済みのイメージを削除しない仕組みも実装

• 安全なデプロイの実装

  • 考慮事項
    • Graviton インスタンスが利用できない場合でもサービスを継続したい
  • 対応
    • マルチアーキテクチャ Auto Scaling Group を適用

まとめ

• AWS Nitro System と AWS Graviton は進化し続けており、より優れたコストパフォーマンスを提供している
• 大規模ワークロードを移行してコストパフォーマンスを最適化する場合は、
  移行の各ステップでの適切な考慮や実装をすることで成功率を高められる

さいごに

AWS Nitro System や Graviton などの独自プロセッサは普段からお世話になっていますが、
その技術的背景や進化の過程について詳しく知る機会がありませんでした。

本セッションに参加することで、AWS が独自シリコンを開発する理由や、Nitro System による仮想化オーバーヘッドの解決方法など、EC2 の根幹技術への理解が大幅に深まりました。

特に印象的だったのは、実際の移行事例で示された段階的なアプローチです。
PoC での検証から始まり、18-20ヶ月で本番ワークロードの9割を移行完了させた具体的なステップは、今後の実務で大いに参考になります。
ビルドプロセスの最適化、マルチアーキテクチャ対応のコンテナイメージ戦略、安全なデプロイの実装など、実践的な課題とその解決策が詳細に紹介されていたのも実践的で非常に価値がありました。

また私の観測範囲では、RDS などのマネージドサービスでは Graviton への移行が進んでいますが（CPU アーキテクチャをユーザー側が意識する必要が少ないため）、EC2 においてはアーキテクチャ変更の複雑さから、まだ踏み込めていないシステムが多いのが実情です。
しかし、本セッションで学んだ移行ガイドラインと実践事例を参考にすれば、20% のコスト削減と性能向上を両立できる可能性が見えてきました。

今後は本セッションで得た知見を活かし、ワークロードの特性を適切に分析した上で、最適なインスタンス選定とアーキテクチャ移行の提案ができるよう努めていきます。