AWS Graviton移行入門｜EC2・Fargate・LambdaをARM64に切り替えてコスト20%削減する実践ガイド

「クラウドの請求額が毎月じわじわ増えている。でも、どこから削ればいいかわからない」——オンプレから移行してきたインフラエンジニアからよく聞く相談です。

アーキテクチャを大きく変えずにすぐ試せるコスト削減策として注目されているのが、AWS Gravitonプロセッサ（ARM64アーキテクチャ）への移行です。EC2・Fargate・Lambdaのどのサービスでも、x86インスタンスからARM64に切り替えるだけで料金が約20%安くなります。

この記事では、GravitonへのARM64移行を検討しているインフラエンジニア向けに、料金の仕組み・互換性確認のやり方・移行の実際の手順を現場目線で解説します。

なぜGravitonか？コスト削減とパフォーマンス向上の背景

AWS Gravitonは、Amazonが独自設計したARM64アーキテクチャのプロセッサです。2018年の第1世代から始まり、現在はGraviton3（第3世代）が主流。一部のサービスではGraviton4も利用可能になっています。

オンプレのサーバーはx86（Intel/AMD）一択でしたが、クラウドではARM64という選択肢を持てるようになりました。この違いがコスト面でどう効くかを整理すると、以下の通りです。

「同じ処理をより安く実行できる」という単純な話なので、アプリケーションの互換性さえ確認できれば、すぐに移行を検討する価値があります。

Graviton対応サービスの全体像

ARM64移行の恩恵を受けられるAWSサービスは以下の通りです。

・Amazon EC2: M7g・C7g・R7g・T4gなど「gサフィックス」のインスタンスファミリー
・Amazon ECS / AWS Fargate: タスク定義でARM64アーキテクチャを指定
・AWS Lambda: ランタイム設定でarm64を選択
・Amazon RDS: Graviton3ベースのr7g・m7gインスタンスクラス
・Amazon ElastiCache: cache.m7g・cache.r7gインスタンス
・Amazon Aurora: db.r8g・db.r7gインスタンスクラス

この記事では、移行ニーズが特に多いEC2・Fargate（ECS）・Lambdaの3サービスに絞って手順を解説します。

EC2インスタンスをGraviton（ARM64）に移行する手順

EC2のGraviton移行は「インスタンスタイプの変更」が主な作業ですが、事前にAMI（Amazon Machine Image）の互換性確認が必須です。AMIはCPUアーキテクチャに紐づくため、x86向けのAMIはARM64インスタンスでは動きません。

1. 現在のAMIアーキテクチャを確認する

移行対象インスタンスで使っているAMIがx86_64かarm64かをAWS CLIで確認します。

# 現在のインスタンスのAMI IDを取得（AWS CLI）
aws ec2 describe-instances \
  --instance-ids i-0123456789abcdef0 \
  --query "Reservations[].Instances[].ImageId" \
  --output text

# 取得したAMI IDのアーキテクチャを確認
aws ec2 describe-images \
  --image-ids ami-0123456789abcdef0 \
  --query "Images[].Architecture" \
  --output text
# 出力例: x86_64

2. ARM64対応のAMIを探す

Amazon Linux 2023やUbuntu 22.04など主要OSはARM64対応AMIが公式提供されています。

# Amazon Linux 2023のARM64 AMIを検索（東京リージョンの例）
aws ec2 describe-images \
  --owners amazon \
  --filters \
    "Name=name,Values=al2023-ami-*" \
    "Name=architecture,Values=arm64" \
    "Name=state,Values=available" \
  --region ap-northeast-1 \
  --query "sort_by(Images, &CreationDate)[-1].{ImageId:ImageId,Name:Name}" \
  --output table

サードパーティのカスタムAMIやWindows ServerはARM64対応状況が異なるため、個別に確認が必要です。

3. インスタンスタイプをGravitonに変更する

AMIの準備ができたら、インスタンスを停止してタイプを変更します。

# インスタンスを停止
aws ec2 stop-instances --instance-ids i-0123456789abcdef0

# インスタンスタイプをm7g.largeに変更（Graviton3）
aws ec2 modify-instance-attribute \
  --instance-id i-0123456789abcdef0 \
  --instance-type '{"Value": "m7g.large"}'

# インスタンスを起動
aws ec2 start-instances --instance-ids i-0123456789abcdef0

既存のAMIがx86_64の場合は、新規インスタンスを起動し直す必要があります。ブルーグリーン方式でトラフィックを切り替えると安全です。移行後はAWS Cost Explorerで翌月の請求額の変化を確認しましょう。

ECS FargateタスクをARM64に切り替える手順

Fargateを使っている場合、コンテナレベルでARM64化できるため、EC2ほど複雑な作業は不要です。ただしコンテナイメージがARM64をサポートしていることが前提となります。

1. コンテナイメージのアーキテクチャを確認する

# Docker HubのイメージがARM64をサポートするか確認
docker buildx imagetools inspect nginx:latest | grep -A5 "Platform"
# linux/amd64 と linux/arm64 の両方が表示されればOK

2. ECSタスク定義でruntimePlatformをARM64に設定する

新しいタスク定義リビジョンを作成し、runtimePlatformにARM64を指定します。

# タスク定義JSON（抜粋）
{
  "family": "my-app",
  "runtimePlatform": {
    "cpuArchitecture": "ARM64",
    "operatingSystemFamily": "LINUX"
  },
  "containerDefinitions": [...]
}

# AWS CLIでタスク定義を登録
aws ecs register-task-definition \
  --cli-input-json file://task-definition-arm64.json

3. サービスを更新して新タスク定義をデプロイする

# ECSサービスを新タスク定義リビジョンで更新（AWS CLI）
aws ecs update-service \
  --cluster my-cluster \
  --service my-service \
  --task-definition my-app:2

FargateのコストはARM64がx86_64比で約20%安いです（2026年3月時点、東京リージョン ap-northeast-1）。vCPU時間あたり$0.04048 → $0.03238、メモリGBあたり$0.004445 → $0.003560となります。

AWS LambdaをARM64に切り替える手順

Lambdaのアーキテクチャ変更は3ステップで完結します。3サービスのなかで最もシンプルに移行できるため、Graviton移行の入り口として最初に試すのに向いています。

1. Lambda関数のアーキテクチャをarm64に変更する

# AWS CLI: Lambda関数のアーキテクチャをarm64に変更
aws lambda update-function-configuration \
  --function-name my-function \
  --architectures arm64

マネジメントコンソールからは「設定」タブ → 「一般設定」→「編集」→「アーキテクチャ」で変更できます。

2. デプロイパッケージの再ビルド（必要な場合）

Python・Node.jsなどのインタープリタ言語は通常そのまま動きます。ただしネイティブコードを含むライブラリ（numpy・cryptographyなど）はARM64向けに再ビルドが必要です。

# ARM64向けにPythonパッケージをビルドする例
pip install \
  --platform manylinux2014_aarch64 \
  --target ./python \
  --implementation cp \
  --python-version 3.12 \
  --only-binary=:all: \
  numpy

3. テスト実行で動作確認する

# Lambda関数をテスト実行
aws lambda invoke \
  --function-name my-function \
  --payload '{"key": "value"}' \
  output.json
cat output.json

Lambdaの料金はARM64がx86_64比で約20%安いです（2026年3月時点）。x86_64の$0.0000166667/GB-secondに対し、arm64は$0.0000133334/GB-secondとなります。実行時間が同じであれば、それだけで20%のコスト削減です。

料金の仕組みとコスト削減試算

Graviton移行だけで「約20%削減」が見込めますが、Savings PlansやReserved Instancesと組み合わせるとさらに大きな効果が出ます。

※ 料金は2026年3月時点のものです。東京リージョン（ap-northeast-1）は米国東部（us-east-1）より高くなるため、AWSの公式料金ページで最新値を確認してください。

組み合わせ効果の試算例: EC2のGraviton移行（▲約20%）にCompute Savings Plans（▲30～40%）を重ねると、合計でオンデマンドx86比 40～50%のコスト削減が見込めます。Graviton移行は、Savings Plansを効かせるための「土台固め」としても有効です。

移行時によくあるトラブルと対処法

【トラブル1】ネイティブライブラリが動かない

C/C++でビルドされたバイナリやネイティブ拡張モジュールは、x86向けバイナリはARM64では動きません。

対処策: ソースからARM64向けにリビルドするか、ARM64対応バイナリが配布されているか確認します。主要OSSの多くはARM64ビルドを公式提供しています。Pythonライブラリはwheelのプラットフォームタグ（cp312-cp312-manylinux_aarch64 など）で確認できます。

【トラブル2】コンテナイメージにARM64版がない

自社ビルドのコンテナイメージでARM64対応が漏れているケースです。

対処策: Docker BuildXのマルチプラットフォームビルドで linux/amd64 と linux/arm64 を同時にビルドし、マルチアーキテクチャマニフェストとしてECRにプッシュします。

# マルチアーキテクチャビルドの例（Docker BuildX）
docker buildx build \
  --platform linux/amd64,linux/arm64 \
  -t 123456789012.dkr.ecr.ap-northeast-1.amazonaws.com/my-app:latest \
  --push .

【トラブル3】EC2の暗号化処理パフォーマンスが想定と違う

x86のAES-NI命令とGravitonのARM暗号化命令セットは別物です。暗号化処理が多いワークロードは、移行後に必ずベンチマークを取ってください。

対処策: OpenSSL 3.x以降やBoringSSLなど、AArch64の暗号化命令セットに対応したバージョンを使います。通常は問題になりませんが、TLS終端や大量の暗号化処理を行うサービスでは事前検証が必要です。

本記事のまとめ

AWS Graviton（ARM64）移行のポイントをまとめます。

・どのサービスもARM64移行だけで約20%のコスト削減が見込める
・Savings PlansやReserved Instancesと組み合わせると削減効果がさらに大きくなる
・移行の入り口はLambdaが最もリスクが低く試しやすい
・FargateはタスクARNのアーキテクチャ変更だけでシンプルに移行できる
・EC2は互換性確認とAMI再作成が必要なため、ブルーグリーン方式で段階的に移行するのが安全

オンプレではアーキテクチャ選択の自由度はほぼなかったですが、クラウドではx86とARM64を使い分けられます。まずはLambdaやFargateから試し、効果を確認してからEC2に広げていくのが現実的なアプローチです。

Linuxサーバーの基礎については、姉妹サイトLinuxMaster.JPで詳しく解説しています。