AWS Cost Optimization Vol2｜RI×Spot×Graviton×Right Sizing実践

なぜ Cost Optimization Vol2 か — 実行層5本柱概観

AWSのコスト最適化は「可視化層」と「実行層」の2段階で体系化すると、各施策の役割と優先順序が明確になります。Vol1では可視化層として Cost Explorer によるコスト分析、Budgets によるアラート設定、Savings Plans による割引適用の仕組み、Compute Optimizer による推奨確認、Cost Anomaly Detection による異常検知を習得しました。

Vol2ではその先の実行層に進みます。可視化で発見したコスト削減機会を「購入コミットメント・インスタンス変更・アーキテクチャ移行」として実行に移すのが本記事のテーマです。単にコストを「安くする」のではなく、ワークロード特性に合った最適な調達戦略と実行フレームワークを確立することを目標とします。

実行層5本柱の概観

コスト最適化実行層は5本柱で構成されます。それぞれ異なる割引メカニズムと適用条件を持ちます。

Reserved Instances（§2）

1年または3年のコミットメントと引き換えに最大72%の割引を受ける購入モデルです。Standard RI（割引率最大・変更不可）と Convertible RI（割引率やや低・インスタンスファミリー変更可）の2種類があります。安定稼働インスタンスへの適用で ROI が最大化します。

Spot Instances / Spot Fleet（§3）

AWSの余剰キャパシティを活用し、最大90%割引で実行する中断前提のモデルです。Spot Fleet の capacityOptimized 戦略と Mixed Instances Policy を組み合わせることで、バッチ処理・CI/CD ワークロードのコストを大幅に削減できます。

Graviton移行（§4）

AWS 独自の arm64 プロセッサ（Graviton2/3/4）に移行することで、x86 インスタンス比で最大40%のコスト削減を実現します。同等性能を低コストで実現できるため、中長期の ROI が最も高い施策の一つです。EC2・RDS・ElastiCache・Lambda の arm64 ランタイムが対象です。

Right Sizing（§5）

インスタンスの過剰スペックを解消し、適切なサイズに変更する施策です。Compute Optimizer の推奨に基づいて実行します。追加コストゼロで即時効果が得られるため、コスト最適化の最初のステップとして必ず実施します。

AWS Pricing Calculator（§5）

コスト削減ツールではなく、新規構成・移行シナリオの TCO を事前試算するツールです。RI 購入・Graviton 移行・リージョン選択などの意思決定根拠を数値化し、ROI 根拠の文書化に活用します。

推奨導入順序 — Right Sizing から始める理由

5本柱の導入には推奨される順序があります。特に Right Sizing を先に完了させてから Reserved Instances を購入する のが最重要ルールです。

過剰スペックのインスタンスに RI を購入すると、後からダウンサイズしたときに RI コミットが宙に浮きます。例として m5.xlarge の RI を購入後に m5.large にダウンサイズした場合、m5.large に対する RI 割引は適用されません。RI Marketplace での売却（Standard RI のみ）か期限まで保持するかの選択を強いられます。

1. Right Sizing（§5）: Compute Optimizer 推奨をもとに過剰スペックを解消。追加コストゼロで即時効果が得られる最優先施策。対象インスタンス全体で20〜30%のコスト削減が期待できる。
2. Reserved Instances（§2）: スペック確定後、安定稼働インスタンスにコミット割引を適用。利用率80%以上が継続確認できたインスタンスのみ購入対象。
3. Spot Fleet（§3）: バッチ処理・CI/CD ワークロードを Spot に移行し最大90%割引を享受。中断対策（チェックポイント設計・多様化・フォールバック）の実装が前提。
4. Graviton移行（§4）: arm64 互換アプリケーションを Graviton インスタンスに移行。Docker multi-arch ビルド整備と互換性検証が先行作業として必要。
5. Pricing Calculator（§5）: 上記施策の削減効果試算と新規構成の TCO 比較に活用。意思決定プロセスの文書化にも有効。

5本柱の組み合わせ — 複合削減戦略

5本柱は組み合わせることで相乗効果が生まれます。代表的な複合パターンを示します。

パターン1: 安定系（RI）+ バッチ系（Spot）の分離

本番 API サーバー（24時間安定稼働）に RI を適用し、夜間バッチ処理に Spot Fleet を適用する構成です。RI で安定ワークロードの割引を最大化しつつ、Spot で短時間ワークロードのコストを最小化します。RI と Spot は適用対象が重複しないため、両方を同時に適用できます。

パターン2: Graviton + Convertible RI の組み合わせ

Graviton 移行ロードマップがある場合、Convertible RI を購入しておくことで、移行完了後に x86→arm64 インスタンスファミリーへの交換が可能です。Graviton の割引（最大40%）と RI の割引（最大66%）が加算され、最大の削減効果が得られます。

パターン3: Right Sizing → RI の四半期サイクル

Compute Optimizer の推奨を四半期ごとに確認し、スペック最適化後に RI を購入するサイクルを確立します。RI 購入後のサイズダウン損失を防ぎつつ、継続的にコミット割引の対象を最適化し続けます。

Vol1 可視化基盤との連携

Vol1 で構築した可視化基盤は Vol2 の実行施策に直接つながります。以下の連携パターンが特に重要です。

Cost Explorer → RI 購入判断

Cost Explorer のインスタンス別コスト分析で、安定稼働コストが上位のインスタンスタイプを特定します。そのインスタンスタイプに対して RI 利用率レポートを確認し、80%以上の稼働実績があれば RI 購入の候補とします。

Budgets → RI 利用率・カバレッジ監視

Vol1 で設定した予算アラートに加え、Vol2 では RI 利用率・RI カバレッジ専用の Budgets を追加設定します。利用率70%未満でアラートを受信し、Savings Plans への移行判断のトリガーとして活用します（§2 で詳述）。

Compute Optimizer → Right Sizing の実行

Compute Optimizer の推奨は過去14日間のメトリクスに基づきます。バッチジョブや月次スパイクを持つワークロードの場合、Enhanced Infrastructure Metrics（有料・90日分析）を有効化することで推奨精度が向上します。

本記事の対象読者と前提知識

対象読者

• FinOps Engineer: コスト最適化施策の設計・実行・効果測定を担うエンジニア。RI 購入戦略の策定・Spot Fleet 導入判断・Graviton 移行計画の立案まで一気通貫で担当する。
• Cloud Architect: インスタンス購入戦略とアーキテクチャ設計でコストを制御するアーキテクト。Organizations 横断の RI 共有設計や Savings Plans との組み合わせ戦略を担当する。
• Platform Engineer: インフラ基盤のコスト効率化・Graviton 移行・Spot 活用を推進するエンジニア。Docker multi-arch ビルド整備・ECS/EKS Spot 統合・Right Sizing の継続運用を実装する。

前提知識（Vol1 で習得済みを想定）

本記事は Vol1 の内容を前提とします。特に以下の概念は習得済みであることを想定しています。

• Cost Explorer でのコスト分析・タグフィルタリング・期間比較の操作
• Budgets による予算アラートの設定と SNS/Email 通知の構成
• Savings Plans の仕組みと Compute SP / EC2 Instance SP の適用対象の違い
• Compute Optimizer の推奨タイプ（OVER_PROVISIONED / UNDER_PROVISIONED）と信頼性レベルの読み方
• Cost Anomaly Detection のモニター設定とアラート対応フロー

Vol2 では Savings Plans の詳細解説は行いません。§2 の RI→SP 移行判断の文脈でのみ言及します。Savings Plans の仕組みから理解したい場合は先に Vol1 をご覧ください。

Reserved Instances 本番運用

Reserved Instances（RI）は1年または3年のコミットメントと引き換えにオンデマンド料金から最大72%の割引を受ける購入モデルです。Savings Plans（Vol1参照）が柔軟性を重視した現代的な割引モデルであるのに対し、RI はインスタンスタイプ・リージョン・OS・テナンシーを固定したコミットメントです。

RI の特徴は Savings Plans より高い割引率（最大72% vs 最大66%） と キャパシティ予約の保証（Capacity Reservation型） にあります。確実に同一構成で長期稼働するワークロードや、特定 AZ でのキャパシティを確保したいケースでは、Savings Plans よりも RI の方が適しています。

Standard RI vs Convertible RI の選択基準

RI には2種類があり、柔軟性と割引率のトレードオフが存在します。

Standard RI（割引率優先）

• 割引率: オンデマンド比最大72%（3年 All Upfront）
• 変更可否: インスタンスファミリー・OS・テナンシー・リージョン変更不可（スコープ・AZ・インスタンスサイズの変更は可）
• 売却可否: RI Marketplace で売却可能（未使用分の回収手段あり）
• 適用ケース: 3年間同一構成で稼働すると確信できるワークロード

Standard RI の典型例:
– 本番データベースサーバー（RDS db.r6i.large を3年固定で運用）
– 安定した API サーバー（インスタンスタイプ変更予定なし）
– バッチ処理基盤（定期ジョブで安定稼働・スパイクなし）

Graviton 移行予定がある場合は Standard RI を購入しないのが原則です。インスタンスファミリー変更不可のため、x86→arm64 移行ができなくなります。

Convertible RI（柔軟性優先）

• 割引率: オンデマンド比最大66%（3年 All Upfront）
• 変更可否: インスタンスファミリー・OS・テナンシー変更可（等価以上のインスタンスへの交換のみ）
• 売却可否: RI Marketplace での売却不可
• 適用ケース: Graviton 移行予定がある、または将来のインスタンスタイプ変更が見込まれるワークロード

Convertible RI の典型例:
– Graviton 移行ロードマップに乗っている EC2 ワークロード（x86→arm64 交換可能）
– 次世代インスタンスファミリーへの移行予定があるワークロード（m5→m7g など）
– 3年コミットだが構成変更の可能性を残したいワークロード

迷ったときの判断フロー

• Graviton 移行計画あり → Convertible RI 一択
• 3年間・同一構成・変更なしと確信できる → Standard RI（割引率最大化）
• 1年契約 → Standard でも Convertible でも差は小さい（柔軟性優先で Convertible 可）
• 迷う場合 → Convertible RI（6%の割引率差より柔軟性を優先）

RI 購入戦略 — 利用率80%ルール

RI の購入可否を判断する最重要指標は RI 利用率（Utilization Rate = 購入時間に対して実際に使用した時間の割合） です。

購入前確認の手順

1. AWS マネジメントコンソールで Cost Explorer を開く
2. 左メニューの「Reservations」→「Utilization report」を選択
3. 対象インスタンスタイプ・リージョン・OS でフィルタリング
4. 過去3か月の月次平均利用率を確認
5. 80%以上が継続している → 購入対象として候補入り
6. 80%未満、または月ごとにばらつきがある → Savings Plans（Compute SP）または On-Demand で対応

支払いオプションの ROI 比較

初めて RI を購入する場合は 1年 Partial Upfront から始め、利用実績を積んでから3年・All Upfront に移行するアプローチが安全です。一度に全インスタンスを3年 All Upfront で購入するのは、最も避けるべきアンチパターンです。

利用率モニタリング — Cost Explorer RI Utilization レポート

RI 購入後は継続的な利用率モニタリングが不可欠です。利用率低下を放置すると、未使用 RI のコストが累積します。

Cost Explorer での監視設定

1. Cost Explorer → 「Reservations」→「Utilization report」
2. 日時範囲: 直近3か月（月次グラフで推移を把握）
3. グループ化: 「Instance Type」でインスタンスタイプ別の利用率を把握
4. 利用率が 70%を下回ったインスタンスタイプ を警戒リストに追加

Budgets による自動アラート設定

手動確認だけでは見落としが発生します。AWS Budgets で RI 利用率専用アラートを設定します。

1. Budgets コンソールで「Create budget」→「Reservation budget」を選択
2. Budget type: 「RI utilization」
3. 閾値: 80%（この値を下回ったらアラート）
4. 通知先: SNS Topic → Email または PagerDuty

利用率が70%を下回り改善が見込めない場合は、RI Marketplace での売却（Standard RI のみ）または Savings Plans への移行を検討します。

RI→Savings Plans 移行判断フロー

RI のカバレッジ率（RI が適用されたコストの割合）が継続的に低下している場合、Savings Plans（Compute SP）への移行を検討します。

移行を検討すべきシグナル

• RI カバレッジ率が月間で60%を下回った
• インスタンスタイプの変更が頻繁に発生し、RI が使われていない
• マルチリージョン展開が増え、リージョン固定の RI の使い勝手が悪い
• Graviton 移行が具体化し、インスタンスファミリーの変更が必要になった

RI vs Compute Savings Plans の比較

移行フロー（既存 RI 期限切れに合わせる）

期限切れに近づいた段階で移行するのが損失を最小化する方法です。

1. Cost Explorer「Savings Plans」→「Recommendations」で現在の使用パターンに最適な SP タイプと購入額の推奨を確認
2. AWS CLI で現在保有 RI の期限日リストを取得: aws ec2 describe-reserved-instances --filters "Name=state,Values=active" --query 'ReservedInstances[*].{ID:ReservedInstancesId,Type:InstanceType,End:End}' --output table
3. 期限6か月前から SP 購入を開始し、RI 期限切れに合わせて SP カバレッジを高める
4. RI 期限切れ後は On-Demand にフォールバックせず SP が自動適用されることを確認

Organizations RI 共有設定と意図しない消費の防止

AWS Organizations 環境では、マスターアカウントで購入した RI をメンバーアカウントで自動共有できます。

RI 共有のメリット

組織全体の RI 利用率を向上させる効果があります。1つのアカウントで RI が余っている場合、他のアカウントのオンデマンドインスタンスに自動的に割引が適用されます。例えば、開発アカウントで使用していない RI が本番アカウントのインスタンスに適用され、組織全体の RI 利用率が向上します。

RI 共有はデフォルトで有効です。Organizations に新しいメンバーアカウントを追加した場合も、自動的に RI 共有の対象となります。意図しない RI 消費が発生していないか、定期的に確認することが重要です。

意図しない消費の防止策

特定アカウントが大量インスタンスを起動した場合、他アカウント向けの RI が消費される問題が発生します。以下の対策を実施します。

• RI 共有の無効化（アカウント単位）: Organizations マスターアカウントの Billing → Preferences → 「RI sharing」から特定メンバーアカウントとの共有を無効化
• コスト配分タグ: タグキー Environment や Team でインスタンスを分類し、RI 消費の帰属を Cost Explorer で追跡
• Charge Back レポート: Cost Explorer の「RI Coverage report」をアカウント別にフィルタリングし、各チームへのコスト配分を可視化

期限管理 — RI 期限切れ通知とリニューアル判断

RI の期限が切れると自動的にオンデマンド料金に戻ります。期限切れを見落とすと想定外のコスト増加が発生します。

期限切れ通知の設定

• AWS Budgets の「RI coverage budget」で RI カバレッジ低下時に自動アラートを受信
• AWS Health Dashboard で RI 期限切れを60日前・30日前に通知（Health イベント「AWS_EC2_RESERVED_INSTANCE_EXPIRATION」）

リニューアル判断の手順（期限6か月前から開始）

1. 対象インスタンスタイプの利用率を Cost Explorer で再確認（過去3か月の月次平均）
2. 利用率80%以上が継続 → リニューアル購入を検討
3. 利用率が低下・変動が大きい → Savings Plans への移行を検討
4. Graviton 移行が決定済み → リニューアルせず Convertible RI 交換または SP に移行
5. 判断が間に合わない場合 → No Upfront RI または Compute SP で一時対応

AWS CLI による RI 期限リスト取得

aws ec2 describe-reserved-instances \
  --filters "Name=state,Values=active" \
  --query 'ReservedInstances[*].{ID:ReservedInstancesId,Type:InstanceType,End:End,Count:InstanceCount}' \
  --output table

このコマンドでアクティブな RI の期限日・インスタンスタイプ・数量を一覧確認できます。EventBridge + Lambda で定期実行し、期限60日前に SNS アラートを送信する自動化を組み込むことを推奨します。

RI 購入推奨機能の活用

Cost Explorer には RI の購入推奨機能（RI Recommendations）が組み込まれています。過去の使用パターンに基づいて最適な購入数・タイプ・支払いオプションを自動計算し、月間推定節約額とROI（回収期間）を表示します。

推奨機能の使い方

1. Cost Explorer → 「Reservations」→「Recommendations」を開く
2. フィルター: 「Looking back period」を「30 days」または「60 days」に設定
3. 「Payment option」で支払いオプションを選択（All Upfront / Partial Upfront / No Upfront）
4. 「Term」で1年または3年を選択
5. 推奨リストの「Estimated monthly savings」と「Break-even point」を確認

推奨の精度と注意点

Cost Explorer の推奨は過去の実使用データに基づくため、季節性・月次スパイク・成長トレンドは考慮されません。以下の点に注意して推奨を評価します。

• 推奨数量がスパイク期間のインスタンス数に基づいている場合、閑散期に利用率が低下するリスクあり
• 新規サービスや急成長中のワークロードは使用実績が少なく、推奨精度が低い
• 推奨は「現状維持」を前提としており、Graviton 移行・インスタンスサイズ変更計画は反映されない

推奨を鵜呑みにせず、運用チームのロードマップと照合してから購入判断することが重要です。

flowchart TD
 A[RI購入検討開始] --> B[Cost Explorerで過去3か月の利用率確認]
 B --> C{平均利用率}
 C -->|80%以上・安定| D[購入対象インスタンス確定]
 C -->|80%未満・変動あり| E[Savings Plans検討へ]
 D --> F{Graviton移行計画}
 F -->|移行予定なし・3年固定| G[Standard RI]
 F -->|移行予定あり・変更可能性あり| H[Convertible RI]
 G --> I{支払いオプション}
 H --> I
 I -->|キャッシュフロー余裕あり| J[All Upfront 3年]
 I -->|初回・バランス重視| K[Partial Upfront 1年]
 J --> L[購入・適用完了]
 K --> L
 L --> M[Budgets RI利用率アラート設定]
 M --> N[月次モニタリング]
 N --> O{利用率チェック}
 O -->|80%以上維持| P[継続保持・期限管理]
 O -->|70%未満に低下| Q[原因分析]
 Q --> R{対応策選択}
 R -->|Standard RI| S[RI Marketplace売却]
 R -->|ワークロード変化| E
 P --> T[期限6か月前: リニューアル判断]
 T --> U{次期戦略}
 U -->|安定継続| V[RI リニューアル]
 U -->|Graviton移行決定| W[Convertible RI交換 または SP移行]
 U -->|変動増加| E
 E --> X[Compute Savings Plans推奨確認]
 X --> Y[SP購入・RI期限切れに合わせカバレッジ移行]

Spot Instances / Spot Fleet 本番運用

Spot Instancesは、AWSが余剰キャパシティをオンデマンド価格の最大90%オフで提供する仕組みです。コスト削減効果は絶大ですが、AWSが容量を必要とする際に2分前通知で中断されるという特性があります。この特性を設計に組み込むことで、本番グレードの低コスト基盤を構築できます。

Spot 配置戦略: 4つの allocationStrategy

Spot FleetおよびAuto Scaling GroupのMixed Instances Policyで選択できる配置戦略は4種類あります。ワークロードの特性に合わせた選択が、中断リスクとコストのバランスを決定します。

1. lowestPrice

最安値プールに集中配置します。コストは最小化されますが、同一価格帯のプールに全台が集まるため、需要急増時に全台同時中断するリスクがあります。テスト環境や超短時間処理には使えますが、本番ワークロードには非推奨です。

2. capacityOptimized

最も空きキャパシティが大きいプールを優先します。中断リスクが最小化されるため、本番Spot利用における長年の定番策です。コストはlowestPriceより若干高くなりますが、安定稼働との兼ね合いで優れたバランスです。

3. diversified

フリートをすべてのプールに均等分散します。一部のプールが枯渇しても残りのキャパシティを維持できるため、長時間バッチ処理や段階的縮小が許容されるワークロードに適します。

4. priceCapacityOptimized（2022年11月追加・現在の第一選択）

コストと空きキャパシティのバランスを最適化します。capacityOptimizedの中断耐性に価格効率を加味したアルゴリズムです。新規設計ではこの戦略を第一選択とすることがAWS公式の推奨です。

{
  "SpotFleetRequestConfig": {
 "AllocationStrategy": "priceCapacityOptimized",
 "TargetCapacity": 20,
 "LaunchTemplateConfigs": [
{
  "LaunchTemplateSpecification": {
 "LaunchTemplateId": "lt-0abcd1234",
 "Version": "$Latest"
  },
  "Overrides": [
 {"InstanceType": "m5.xlarge",  "WeightedCapacity": 4},
 {"InstanceType": "m5a.xlarge", "WeightedCapacity": 4},
 {"InstanceType": "m6i.xlarge", "WeightedCapacity": 4},
 {"InstanceType": "m6a.xlarge", "WeightedCapacity": 4},
 {"InstanceType": "m6g.xlarge", "WeightedCapacity": 4}
  ]
}
 ]
  }
}

インスタンスタイプを5種類以上・複数AZにまたがって定義することで、特定プールの容量枯渇に対する耐性が飛躍的に向上します。

Interruption対策: 2分前通知のハンドリング

Spot Instanceが中断される2分前にEC2 Spot Instance interruption noticeがIMDSに書き込まれます。このウィンドウをジョブ状態保存に活用することが、Spot運用の中核です。

IMDSv2での通知ポーリング実装:

#!/bin/bash
# Spot中断通知をIMDSv2でポーリングするサイドカースクリプト
TOKEN=$(curl -s -X PUT "http://169.254.169.254/latest/api/token" \
  -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")

while true; do
  HTTP_STATUS=$(curl -s -o /dev/null -w "%{http_code}" \
 -H "X-aws-ec2-metadata-token: $TOKEN" \
 "http://169.254.169.254/latest/meta-data/spot/interruption-action")

  if [ "$HTTP_STATUS" = "200" ]; then
 echo "[$(date -u +%FT%TZ)] Spot中断通知検知 — チェックポイント保存開始"
 /opt/scripts/save_checkpoint.sh
 # SQSメッセージをキューに即時返却（可視性タイムアウトを0に変更）
 aws sqs change-message-visibility \
--queue-url "$SQS_QUEUE_URL" \
--receipt-handle "$RECEIPT_HANDLE" \
--visibility-timeout 0
 break
  fi
  sleep 5
done

チェックポイント設計のベストプラクティス:

1. S3/DynamoDBへの進捗記録: 処理済みレコードID・バッチ番号・タイムスタンプをアトミックに書き込む。DynamoDBの条件付き書き込みで競合を防ぐ
2. 冪等性の確保: 同一チェックポイントから複数回再開しても同じ結果になるよう設計する（べき等処理）
3. チェックポイント間隔: 30〜60秒ごと、または1,000レコードごとが目安。2分以内で保存完了できる単位であることが必須条件
4. SQSキューベース設計の活用: Spot中断後に可視性タイムアウトが切れたメッセージは自動的に再キューされる。Spot固有の再開ロジックをシンプルに保てる

EventBridge + Lambdaによる自動対応:

{
  "source": ["aws.ec2"],
  "detail-type": ["EC2 Spot Instance Interruption Warning"],
  "detail": {
 "instance-action": ["terminate"]
  }
}

このEventBridgeルールでLambdaをトリガーし、SQSのメッセージ可視性リセットやAutoScalingGroupへの容量補充シグナルを自動送信できます。2分前通知とSQSの組み合わせは、Spot運用でジョブ損失をゼロに近づける最もシンプルなパターンです。

Mixed Instances Policy: On-Demand + Spot の最適配分

Auto Scaling GroupのMixed Instances Policyを使用することで、On-Demandベースキャパシティ（安定性確保）とSpotキャパシティ（コスト削減）を1つのグループで管理できます。

# CloudFormation: Mixed Instances Policy設定例
MixedInstancesPolicy:
  InstancesDistribution:
 OnDemandBaseCapacity: 2
 OnDemandPercentageAboveBaseCapacity: 20
 SpotAllocationStrategy: price-capacity-optimized
 SpotInstancePools: 0
  LaunchTemplate:
 LaunchTemplateSpecification:
LaunchTemplateId: !Ref AppLaunchTemplate
Version: !GetAtt AppLaunchTemplate.LatestVersionNumber
 Overrides:
- InstanceType: m5.xlarge
- InstanceType: m5a.xlarge
- InstanceType: m6i.xlarge
- InstanceType: m6a.xlarge
- InstanceType: m6g.xlarge
- InstanceType: m5d.xlarge

設計のポイント:
– OnDemandBaseCapacity: アプリケーションの最低稼働に必要な台数（通常はデプロイ最小単位の1〜2台）
– OnDemandPercentageAboveBaseCapacity: 0〜100の範囲。コスト最優先なら10〜20%が現実的なバランス
– SpotInstancePools: priceCapacityOptimized選択時は0を指定するとAWSが自動最適化する

ECS Spot統合: FARGATE_SPOT Capacity Provider

ECSでのFARGATE_SPOTはコンテナワークロードのコスト最適化に効果的です。タスクレベルでSpot/On-Demandを混在させられ、安定性とコスト削減を両立できます。

Capacity Provider戦略の設定例:

{
  "capacityProviderStrategy": [
 {
"capacityProvider": "FARGATE_SPOT",
"weight": 4,
"base": 0
 },
 {
"capacityProvider": "FARGATE",
"weight": 1,
"base": 1
 }
  ]
}

基本タスク1件はFARGATEで確保し、追加タスクの80%をFARGATE_SPOTで起動する構成です。base: 1を設定することで、フリートが縮小してもOn-Demand最低1タスクが維持されます。

タスクドレイン設定（中断耐性の要）:

{
  "containerDefinitions": [
 {
"name": "app",
"stopTimeout": 120,
"linuxParameters": {
  "initProcessEnabled": true
},
"healthCheck": {
  "command": ["CMD-SHELL", "curl -f http://localhost/health || exit 1"],
  "interval": 30,
  "timeout": 5,
  "retries": 3,
  "startPeriod": 60
}
 }
  ]
}

運用上の注意点:
– stopTimeoutの最大値は120秒（Spot中断の2分前通知に対応する上限）
– ALBのderegistration delay（デフォルト300秒）をstopTimeout以下に調整する
– ECSサービスのdeploymentConfiguration.minimumHealthyPercentを適切に設定し、Spot中断によるデプロイ失敗を防ぐ

EKS Spot統合: Karpenter + Node Termination Handler

EKSでのSpot統合は、KarpenterとNode Termination Handler（NTH）の組み合わせが現在のベストプラクティスです。

Karpenter NodePool設定（Spot優先・Graviton混在）:

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: spot-optimized
spec:
  template:
 spec:
requirements:
  - key: "karpenter.sh/capacity-type"
 operator: In
 values: ["spot", "on-demand"]
  - key: "kubernetes.io/arch"
 operator: In
 values: ["amd64", "arm64"]
  - key: "node.kubernetes.io/instance-type"
 operator: In
 values:
- m5.xlarge
- m5a.xlarge
- m6i.xlarge
- m6a.xlarge
- m6g.xlarge
- m7g.xlarge
nodeClassRef:
  apiVersion: karpenter.k8s.aws/v1
  kind: EC2NodeClass
  name: default
  disruption:
 consolidationPolicy: WhenEmptyOrUnderutilized
 consolidateAfter: 1m
  limits:
 cpu: 200
 memory: 400Gi

Node Termination Handler（Helmインストール）:

helm repo add eks https://aws.github.io/eks-charts
helm repo update

helm install aws-node-termination-handler \
  eks/aws-node-termination-handler \
  --namespace kube-system \
  --set enableSpotInterruptionDraining=true \
  --set enableRebalanceMonitoring=true \
  --set enableScheduledEventDraining=true \
  --set nodeSelector."kubernetes\\.io/os"=linux

NTHはIMDSのSpot中断通知を検知すると、対象ノードにtaintを付与してPodのグレースフル退避（kubectl drain相当）を自動実行します。Karpenterのconsolidation機能と組み合わせることで、中断後の空きノード回収も自動化されます。

Spot Advisor の活用

Spot Instance Advisorは、各リージョン・インスタンスタイプごとの中断頻度スコアを無償公開しています。

スコアの読み方:
– < 5%: 中断が最も少ない（緑）— 本番Spot利用の最優先候補
– 5〜10%: 中断頻度は中程度（黄）— バッチ・開発環境に適合
– > 20%: 中断頻度が高い（赤）— コスト最小化優先の非重要ワークロードのみ推奨

活用フロー:
1. 候補インスタンスタイプ（5〜10種類）をSpot Advisorで中断率確認
2. 中断率 < 5%のタイプをLaunchTemplateConfigs.Overridesの先頭に列挙
3. priceCapacityOptimizedと組み合わせることで、低コスト×低中断のバランスを実現

Spot Fleet vs EC2 Fleet: 選択基準

現在のAWS推奨は、ほとんどのユースケースでAuto Scaling Group + Mixed Instances Policyを使用し、Spot Fleetは大規模HPC・レンダリング・ML学習など専用の大量Spot需要がある場合に限定する方向性です。

Graviton移行 本番運用

GravitonはAWSが自社設計したArmベースのプロセッサです。x86比較で同等性能をより低コストで提供します。EC2・RDS・ElastiCache・Lambdaと幅広いサービスに対応しており、段階的な移行によってコスト削減を積み重ねられます。

arm64互換性検証

Graviton移行前に最も重要なのが互換性検証です。ワークロードの種類によって検証アプローチが異なります。

ネイティブバイナリの場合:
– Cコンパイル済みバイナリ: arm64向けに再コンパイルが必要。file <binary>コマンドでELF 64-bit LSB executable, ARM aarch64を確認
– Goバイナリ: GOARCH=arm64 GOOS=linux go buildでクロスコンパイル可能。追加依存なし
– Rustバイナリ: cargo build --target aarch64-unknown-linux-gnuでクロスコンパイル対応

インタプリタ言語（Python/Node.js/Ruby/Java）の場合:
– 言語ランタイム自体はarm64ビルドが公式提供されており、移行コストは低い
– 純粋なPython/JS/Rubyコード: 変更不要
– C拡張モジュール（numpy/scipy/cryptography等）: arm64版パッケージの存在確認が必要
– Java: JDK 11以降はaarch64対応。amazon-correttoがGraviton最適化済みで推奨

コンテナの互換性確認:

# ベースイメージのアーキテクチャ確認
docker buildx imagetools inspect public.ecr.aws/amazonlinux/amazonlinux:2023

# arm64対応確認（QEMUエミュレーション経由で起動）
docker run --rm --platform linux/arm64 public.ecr.aws/amazonlinux/amazonlinux:2023 uname -m
# 出力: aarch64 → arm64対応済み

Pythonパッケージのarm64 wheel確認:

# arm64向けwheelが存在するか確認（インストールは不要）
pip download \
  --python-version 311 \
  --platform manylinux2014_aarch64 \
  --only-binary=:all: \
  -d /tmp/arm64-check/ \
  numpy scipy cryptography

# ダウンロード成功 → arm64対応wheel存在
# エラー → ソースビルドが必要 or arm64版パッケージ名が異なる

パフォーマンス比較: x86 vs Graviton

Graviton採用を判断する前に、実際のワークロードでベンチマークを実施します。カタログスペックではなく実測値で判断することが重要です。

sysbench: CPU/メモリ性能の基礎評価:

# CPU性能比較（素数計算）
sysbench cpu --cpu-max-prime=20000 --threads=$(nproc) run

# メモリ帯域幅比較
sysbench memory --memory-block-size=1M --memory-total-size=10G \
  --memory-oper=read run

# 比較結果の記録
sysbench cpu --cpu-max-prime=20000 --threads=$(nproc) run \
  | grep "events per second" >> benchmark_results.txt

wrk: Webアプリケーションの実負荷評価:

# 30秒間、4スレッド・100同時接続でWebアプリを評価
wrk -t4 -c100 -d30s --latency http://localhost:8080/api/health

# アウトプット例
# Requests/sec:  12453.67  ← Graviton移行後の目標値と比較
# Latency (avg): 7.98ms

ab（Apache Benchmark）: REST APIの性能評価:

# 1,000リクエスト・並列20での応答時間比較
ab -n 1000 -c 20 \
-H "Content-Type: application/json" \
http://localhost:8080/api/v1/endpoint

# Requests per second と Time per request を記録して x86 と比較

ベンチマーク結果の解釈:
– 同価格帯（m5.xlarge vs m6g.xlarge等）での比較では、多くのWebアプリで10〜25%高いスループットを実測
– メモリ帯域幅重視のワークロード（インメモリキャッシュ・ML推論）でGravitonの優位性が顕著
– 古いx86最適化コード（SSE/AVX命令を直接使用するネイティブライブラリ等）では性能低下するケースがあるため、必ず実測値で判断する

Docker multi-arch: buildx設定とCI/CD統合

buildx環境セットアップ:

# マルチプラットフォームビルダーの作成
docker buildx create --name multiarch-builder \
  --driver docker-container \
  --platform linux/amd64,linux/arm64 \
  --use

# ビルダーの起動確認
docker buildx inspect --bootstrap

ECRへのマルチアーキテクチャイメージプッシュ:

ECR_REGISTRY="<account-id>.dkr.ecr.ap-northeast-1.amazonaws.com"

# ECRログイン
aws ecr get-login-password --region ap-northeast-1 \
  | docker login --username AWS --password-stdin "$ECR_REGISTRY"

# amd64/arm64 両対応ビルド + プッシュ（1コマンド）
docker buildx build \
  --platform linux/amd64,linux/arm64 \
  --tag "${ECR_REGISTRY}/myapp:$(git rev-parse --short HEAD)" \
  --tag "${ECR_REGISTRY}/myapp:latest" \
  --push \
  .

# マルチアーキテクチャマニフェスト確認
docker buildx imagetools inspect "${ECR_REGISTRY}/myapp:latest"
# 出力例:
# Name: <account>.dkr.ecr.../myapp:latest
# MediaType: application/vnd.oci.image.index.v1+json
# Digest: sha256:...
# Manifests:
#Name: .../myapp:latest@sha256:...  Platform: linux/amd64
#Name: .../myapp:latest@sha256:...  Platform: linux/arm64

GitHub Actionsでのマルチアーキテクチャビルド自動化:

name: Build Multi-arch Image

on:
  push:
 branches: [main]

env:
  ECR_REGISTRY: ${{ secrets.AWS_ACCOUNT_ID }}.dkr.ecr.ap-northeast-1.amazonaws.com
  IMAGE_NAME: myapp

jobs:
  build:
 runs-on: ubuntu-latest
 steps:
- uses: actions/checkout@v4

- name: Configure AWS credentials
  uses: aws-actions/configure-aws-credentials@v4
  with:
 aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
 aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
 aws-region: ap-northeast-1

- name: Login to Amazon ECR
  uses: aws-actions/amazon-ecr-login@v2

- name: Set up QEMU (arm64エミュレーション)
  uses: docker/setup-qemu-action@v3
  with:
 platforms: linux/amd64,linux/arm64

- name: Set up Docker Buildx
  uses: docker/setup-buildx-action@v3

- name: Build and push multi-arch image
  uses: docker/build-push-action@v5
  with:
 context: .
 platforms: linux/amd64,linux/arm64
 push: true
 tags: |
${{ env.ECR_REGISTRY }}/${{ env.IMAGE_NAME }}:${{ github.sha }}
${{ env.ECR_REGISTRY }}/${{ env.IMAGE_NAME }}:latest
 cache-from: type=gha
 cache-to: type=gha,mode=max

QEMUエミュレーションの注意点:
– GitHub ActionsのランナーはamdベースのためQEMUでarm64をエミュレートしてビルド
– QEMUビルドはネイティブ比3〜5倍遅い。cache-from: type=ghaで変更のないレイヤーを再利用し高速化する
– ビルドステージとランタイムステージを分離（マルチステージビルド）することで、重いビルドステップの再実行を最小化できる

RDS Graviton移行

RDS GravitonインスタンスへはBlue-Greenデプロイを使用することで、最小ダウンタイムで移行できます。

対応インスタンスクラス（2025年時点）:

Blue-Greenデプロイによる移行手順:

# Step 1: Blue-Green環境を作成（Greenが新しいGravitonインスタンス）
aws rds create-blue-green-deployment \
  --blue-green-deployment-name "prod-db-graviton-migration" \
  --source "arn:aws:rds:ap-northeast-1:123456789:db:prod-mysql" \
  --target-db-instance-class db.r7g.2xlarge \
  --target-engine-version "8.0.36"

# Step 2: 同期完了を確認（Replication Lagが0に近くなるまで待機）
aws rds describe-blue-green-deployments \
  --blue-green-deployment-identifier bgd-0abc1234 \
  --query "BlueGreenDeployments[0].{Status:Status,Tasks:SwitchoverDetails}"

# Step 3: 切り替え実行（ダウンタイム数秒〜1分程度）
aws rds switchover-blue-green-deployment \
  --blue-green-deployment-identifier bgd-0abc1234

# Step 4: 切り替え完了確認後、旧環境（Blue）を削除
aws rds delete-blue-green-deployment \
  --blue-green-deployment-identifier bgd-0abc1234 \
  --delete-target

移行前チェックポイント:
– SHOW GLOBAL VARIABLES LIKE 'character_set%': 文字セット設定の確認
– SHOW BINARY LOGS: バイナリログ有効化確認（Blue-Greenデプロイの必須条件）
– SHOW GLOBAL STATUS LIKE 'Ssl_cipher': SSL設定の確認
– アプリケーション側DBクライアントのバージョンとGraviton対応確認

ElastiCache Graviton移行

対応ノードタイプ（2025年時点）:
– cache.r7g.*: 汎用メモリ最適化（x86比20%コスト削減）
– cache.m7g.*: バランス型（一般用途）

レプリケーショングループのオンライン変更:

# インスタンスタイプをcache.r7gへ変更
aws elasticache modify-replication-group \
  --replication-group-id prod-redis-cluster \
  --cache-node-type cache.r7g.xlarge \
  --apply-immediately

# 変更状態の確認
aws elasticache describe-replication-groups \
  --replication-group-id prod-redis-cluster \
  --query "ReplicationGroups[0].NodeGroups[0].NodeGroupMembers[*].{Id:CacheClusterId,Role:CurrentRole,Status:CacheClusterStatus}"

注意事項:
– apply-immediately: falseでメンテナンスウィンドウに変更をスケジュール可能
– クラスターモードが有効な場合、シャードごとの段階変更を推奨
– フェイルオーバー発生時の接続断を考慮し、アプリケーション側の再接続ロジックを確認しておく

Lambda arm64

Lambda関数のarm64移行は最もリスクが低く、ダウンタイムなしで実行可能です。

アーキテクチャ変更（CLI）:

# アーキテクチャをarm64へ変更
aws lambda update-function-configuration \
  --function-name my-function \
  --architectures arm64

# 変更確認
aws lambda get-function-configuration \
  --function-name my-function \
  --query "Architectures"
# 出力: ["arm64"]

レイヤー互換性の確認:

# 使用中のレイヤーのアーキテクチャ確認
aws lambda list-layer-versions \
  --layer-name my-layer \
  --query "LayerVersions[0].CompatibleArchitectures"
# 出力例: ["x86_64"] → arm64非対応 → レイヤーをarm64向けに再ビルドが必要

Lambda arm64のコスト効果:
– 同一メモリ設定でx86比20%コスト削減（実行時間×メモリコスト計算に対して）
– Node.js/Python/Rubyの多くの処理でarm64が10〜15%高速化 → 実行時間短縮でさらにコスト削減
– カスタムランタイム（provided.al2023）はarm64向けバイナリが必要

段階移行の推奨フロー:
1. 開発・ステージング環境でarm64に変更し、全テストを実行
2. Lambda Power Tuning（Step Functionsベース）でarm64の最適メモリサイズを検証
3. 本番環境へ適用（エイリアスのweighted routingで段階的トラフィック移行も可能）

Graviton移行チェックリスト

Phase 1: 依存ライブラリ確認
– [ ] pip download --platform manylinux2014_aarch64でパッケージのarm64 wheel存在確認
– [ ] ネイティブ拡張（C/C++ライブラリ）のarm64ビルド確認
– [ ] DockerfileのベースイメージのPlatform確認（docker buildx imagetools inspect）
– [ ] LambdaレイヤーのCompatibleArchitectures確認

Phase 2: ステージング検証
– [ ] Gravitonインスタンス上でアプリケーションを起動
– [ ] 全機能テストスイートを実行（エラー・警告を確認）
– [ ] sysbench/wrk/abでx86との性能差を計測・記録
– [ ] アプリケーションログにアーキテクチャ固有エラーがないか確認

Phase 3: 段階移行
– [ ] 非クリティカルワークロード（バッチ処理・開発環境）から先行移行
– [ ] CloudWatchでエラーレート・レイテンシ異常を7日間監視
– [ ] Cost Explorerのタグフィルタ（architecture: arm64タグ付与）でコスト削減効果を計測
– [ ] 問題なければ本番・クリティカルワークロードへ展開

ロールバック手順:
– EC2: Auto Scaling GroupのLaunch Templateを旧AMI（x86）に戻し、インスタンスをリフレッシュ
– ECS: タスク定義の新リビジョンでx86ベースイメージを指定してデプロイ
– Lambda: --architectures x86_64へ変更（即時反映・ダウンタイムなし）
– RDS Blue-Green: switchover実行前であれば元のBlueに切り戻し可能

Right Sizing 実践 + AWS Pricing Calculator

flowchart LR
 A[Compute Optimizer推奨] --> B[推奨内容レビュー]
 B --> C{リスク評価}
 C -->|低リスク| D[即時適用]
 C -->|中リスク| E[ステージング検証]
 C -->|高リスク| F[負荷テスト実施]
 D --> G[コスト効果測定]
 E --> G
 F --> G
 G --> H[Pricing Calculator TCO比較]
 H --> I[シナリオ比較]
 I --> J[稟議用見積書エクスポート]
 J --> K[共有URL発行]

Compute Optimizer 推奨→実行フロー

AWS Compute Optimizer は、CloudWatch メトリクスを機械学習で分析し、過剰プロビジョニングされたリソースを検出します。デフォルトでは過去14日間のデータを分析しますが、Enhanced Infrastructure Metrics を有効化すると過去3か月分のデータで精度の高い推奨が得られます。

Enhanced Infrastructure Metrics の費用対効果

月1回のバッチ処理や季節変動があるワークロードでは、14日分析では推奨が過小になりサイズダウン後に性能問題が発生することがあります。Enhanced Infrastructure Metrics の月額費用（EC2インスタンス1台あたり数十円程度）は、誤ったサイズダウンによる障害対応コストと比較すると極めて安価です。

推奨のリスク評価基準

Compute Optimizer の推奨には 推定削減率 と パフォーマンスリスク が付属します。適用判断の目安は以下の通りです。

EC2 Right Sizing の実施手順

変更前の確認事項

インスタンスタイプ変更の前に、以下の3点を確認します。

1. CPU/メモリ使用率の実績: CloudWatch で過去30日間の CPUUtilization と mem_used_percent を確認。ピーク時でも70-80%以下なら縮小候補。
2. EBS最適化の要件: 変更先インスタンスタイプが現在使用中の EBS ボリュームタイプ・IOPS に対応しているか確認。
3. ネットワーク帯域幅: 変更先インスタンスタイプのネットワーク帯域幅が現在のワークロードに十分か確認（NetworkIn/NetworkOut メトリクス）。

インスタンスタイプ変更の CLI 手順

# 現在のインスタンス情報を確認
aws ec2 describe-instances \
  --instance-ids i-0123456789abcdef0 \
  --query 'Reservations[].Instances[].{InstanceType:InstanceType,State:State.Name}'

# インスタンスを停止（停止中のみタイプ変更可能）
aws ec2 stop-instances --instance-ids i-0123456789abcdef0

# 停止完了を待機
aws ec2 wait instance-stopped --instance-ids i-0123456789abcdef0

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

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

変更前後のメトリクス比較

インスタンスタイプ変更後は、以下の指標で効果を測定します。

変更後1週間は CloudWatch ダッシュボードで CPU・メモリ・ネットワークを継続モニタリングし、パフォーマンス劣化がないことを確認してから変更を確定とみなします。ピーク時 CPU 使用率が変更後に80%を超える場合は元のインスタンスタイプに戻してください。

Lambda Power Tuning の活用

Lambda 関数のコスト最適化では、メモリ割り当てが鍵になります。Lambda の料金はメモリ量 × 実行時間で決まるため、最適なメモリ設定を見つけることがコスト削減の核心です。

aws-lambda-power-tuning ツール

aws-lambda-power-tuning は AWS Step Functions ベースのオープンソースツールで、複数のメモリ設定で関数を並列実行し、コスト・速度のトレードオフを可視化します。AWS Serverless Application Repository (SAR) から簡単にデプロイできます。

# SAR からデプロイ（CloudFormation 経由）
aws serverlessrepo create-cloud-formation-change-set \
  --application-id arn:aws:serverlessrepo:us-east-1:451282441545:applications/aws-lambda-power-tuning \
  --stack-name lambda-power-tuning \
  --capabilities CAPABILITY_IAM \
  --parameter-overrides '[{"Name":"lambdaResource","Value":"*"}]'

デプロイ後、Step Functions の入力として以下の JSON を指定します。

{
  "lambdaARN": "arn:aws:lambda:ap-northeast-1:123456789012:function:my-function",
  "powerValues": [128, 256, 512, 1024, 2048, 3008],
  "num": 50,
  "payload": "{}",
  "parallelInvocation": true,
  "strategy": "cost"
}

Step Functions の実行が完了すると、各メモリ設定での平均コスト・平均実行時間が出力されます。visualization_url フィールドに可視化グラフへの URL が含まれ、コスト vs レイテンシのトレードオフを直感的に確認できます。

コスト vs パフォーマンスの最適点の選び方

一般的なパターンとして、CPU バウンドな処理では 512MB → 1024MB に増やすと実行時間が半減しコストが同等になるケースが多いです。I/O バウンドな処理では 128MB で十分なことが多く、安易なメモリ増加はコスト増になります。strategy: "balanced" から始め、要件に応じて cost か speed に切り替える進め方が現実的です。

EBS gp2 → gp3 移行の実践

gp2 と gp3 のコスト・性能比較

gp3 のメリットは IOPS とスループットをボリュームサイズから独立して設定できる点です。gp2 では高 IOPS が必要なため、無駄にボリュームサイズを大きくするケースがありましたが、gp3 ではサイズと性能を個別に最適化できます。

modify-volume API によるオンライン変更

gp2 から gp3 への変更はインスタンスを停止せずにオンラインで実行できます。

# 対象ボリュームの確認
aws ec2 describe-volumes \
  --filters "Name=volume-type,Values=gp2" \
  --query 'Volumes[].{VolumeId:VolumeId,Size:Size,Iops:Iops,State:State}'

# gp2 → gp3 へ変更（ベースライン設定）
aws ec2 modify-volume \
  --volume-id vol-0123456789abcdef0 \
  --volume-type gp3 \
  --iops 3000 \
  --throughput 125

# 変更の進捗確認
aws ec2 describe-volumes-modifications \
  --volume-ids vol-0123456789abcdef0 \
  --query 'VolumesModifications[].{State:ModificationState,Progress:Progress}'

変更は最大数時間かかる場合がありますが、その間もボリュームは通常通り使用可能です。変更完了後、CloudWatch の VolumeReadOps/VolumeWriteOps で性能に影響がないことを確認します。

全 gp2 ボリュームの一括確認

大量の gp2 ボリュームを gp3 に移行する際は、まず対象を一覧化してから順次処理します。

# アカウント内の全 gp2 ボリュームを一覧表示
aws ec2 describe-volumes \
  --filters "Name=volume-type,Values=gp2" \
  --query 'Volumes[].{VolumeId:VolumeId,Size:Size,Iops:Iops,AttachedInstance:Attachments[0].InstanceId}' \
  --output table

# 変更後のコスト差分を試算（gp2 合計サイズ × $0.024 が月額削減額の目安）
aws ec2 describe-volumes \
  --filters "Name=volume-type,Values=gp2" \
  --query 'sum(Volumes[].Size)'

AWS Pricing Calculator による TCO 比較

見積書の作成手順

AWS Pricing Calculator は無料で使用できるウェブベースのコスト試算ツールです。アカウントログイン不要で利用でき、複数のシナリオを比較した見積書を作成できます。

見積書作成の基本フロー:

1. calculator.aws にアクセス → 「見積もりを作成する」をクリック
2. 対象の AWS リージョンを選択（東京: ap-northeast-1）
3. サービスを追加: EC2/RDS/EBS/Lambda などを個別に追加
4. 各サービスの設定を入力
5. EC2: インスタンスタイプ・台数・利用時間・支払いオプション（On-Demand/RI/Savings Plans）
6. RDS: エンジン・インスタンスクラス・マルチAZ・ストレージ
7. EBS: ボリュームタイプ・サイズ・IOPS・スループット
8. 「見積もりを表示する」で月額費用と年額費用を確認

シナリオ比較（On-Demand vs RI vs Spot vs Graviton）

Pricing Calculator では複数の見積もりを作成してシナリオ比較ができます。例として m5.xlarge（On-Demand）を起点にした東京リージョンの比較を示します。

Pricing Calculator でシナリオ比較をする際は、「見積もりグループ」機能を使って複数の見積もりを1つのページに並べると比較しやすくなります。

TCO 比較: オンプレミス vs AWS クラウド

AWS Pricing Calculator の TCO 比較機能では、オンプレミスからクラウドへの移行コストを試算できます。

オンプレミス構成の入力項目:

クラウド移行後は人件費（インフラ保守工数）の削減と電力・施設費用の撤廃が大きなコスト削減要因になることが多いです。一方で、ネットワーク転送費用（データ転送アウト）はオンプレミスにはないコスト項目であるため、必ず見積もりに含めてください。

見積書のエクスポートと稟議活用

作成した見積書は以下の形式でエクスポートできます。

共有 URL を使うと、URL にアクセスするだけで同一の見積もりをロードできます。稟議書には CSV/PDF を添付し、技術担当者への共有は URL だけで十分です。URL の有効期限はなく、削除するまで永続的に利用できます。

社内稟議フォーマットのポイント:

1. Before/After 比較表: 現状（On-Demand）と改善後（RI/Spot/Graviton）の月額・年額を並列表示
2. 削減額と削減率: 「月$5,000削減（33%コスト削減）」のように金額と率の両方を明記
3. 初期費用と回収期間: RI 全額前払い費用がある場合は回収期間（月数）を計算して記載
4. リスクと前提条件: 利用率の想定・変動要因・最低コミット期間などを明示
5. 段階実施計画: 全リソースを一度に変更するのではなく、優先度の高いリソースから段階的に実施するロードマップを添付

詰まりポイント7選 図解

コスト最適化の実行フェーズで多くのエンジニアがはまる7つの典型的な落とし穴を体系化しました。各パターンの「なぜ詰まるのか」と「どう抜け出すか」をep-boxで整理します。

詰まり1: RI購入後に利用率が低下して損失発生

Reserved Instances を購入したにもかかわらず、数か月後に利用率が60%を下回り、購入コミットが「負債」になるケースです。原因は購入前分析の不足と、ワークロード変化への対応遅れにあります。

購入判断の根拠となった稼働率データが「スパイク期間」を含む短期間だったため、平常時の利用率が過大評価されていたことが多い根本原因です。

# Budgets で RI 利用率70%未満アラートを設定
aws budgets create-budget \
  --account-id "$(aws sts get-caller-identity --query Account --output text)" \
  --budget '{
 "BudgetName": "RI-Utilization-Alert",
 "BudgetType": "RI_UTILIZATION",
 "TimeUnit": "MONTHLY",
 "CostFilters": {"Service": ["Amazon Elastic Compute Cloud - Compute"]},
 "BudgetLimit": {"Amount": "70", "Unit": "PERCENTAGE"}
  }' \
  --notifications-with-subscribers '[{
 "Notification": {
"NotificationType": "ACTUAL",
"ComparisonOperator": "LESS_THAN",
"Threshold": 70,
"ThresholdType": "PERCENTAGE"
 },
 "Subscribers": [{"SubscriptionType": "EMAIL","Address": "ops@example.com"}]
  }]'

詰まり2: Spot中断でバッチジョブが全滅

Spot Instance を使ったバッチ処理が中断通知を受信したにもかかわらず、ジョブが途中で全滅し、全件再処理が必要になるケースです。

チェックポイント設計なし・単一インスタンスタイプ・単一AZという3つのリスクが重なると、中断時のダメージが最大化します。

# 1. 多様化: 最低5タイプ×3AZ のフリート設定
# SpotFleetRequestConfigのOverridesに複数タイプ指定
# (§3のpriceCapacityOptimized設定を参照)

# 2. チェックポイント: 中断通知を60秒ごとにポーリングして進捗保存
TOKEN=$(curl -s -X PUT "http://169.254.169.254/latest/api/token" \
  -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")

while true; do
  STATUS=$(curl -s -o /dev/null -w "%{http_code}" \
 -H "X-aws-ec2-metadata-token: $TOKEN" \
 "http://169.254.169.254/latest/meta-data/spot/interruption-action")
  [ "$STATUS" = "200" ] && /opt/save_checkpoint.sh && break
  sleep 30
done &

# 3. フォールバック: Mixed Instances Policy で On-Demand ベースを確保
# OnDemandBaseCapacity: 1 (最低1台は確保)

詰まり3: Graviton移行でネイティブバイナリ非互換

x86向けにコンパイル済みのネイティブバイナリやC拡張Pythonモジュールを含むDockerイメージを、そのままGravitonインスタンスに展開してアプリケーションが起動しないケースです。

# ステップ1: ベースイメージのアーキテクチャ確認
docker buildx imagetools inspect <your-image>:latest
# "Platform: linux/amd64" のみ → multi-archビルドが必要

# ステップ2: Pythonパッケージのarm64 wheel確認
pip download \
  --python-version 311 \
  --platform manylinux2014_aarch64 \
  --only-binary=:all: \
  -d /tmp/arm64-check/ \
  cryptography numpy scipy

# ステップ3: multi-arch buildxでarm64対応イメージを作成
docker buildx build \
  --platform linux/amd64,linux/arm64 \
  --tag myapp:latest \
  --push .

# ステップ4: QEMUエミュレーションでローカル動作確認
docker run --rm --platform linux/arm64 myapp:latest python -c "import cryptography; print('OK')"

詰まり4: Right Sizing推奨がスパイク負荷を考慮していない

Compute Optimizer の推奨に従ってインスタンスをダウンサイズしたところ、月次バッチ処理や季節変動のあるスパイク時にCPUが100%に張り付き、アプリケーションが応答不能になるケースです。

# CloudWatch で過去90日間のCPU最大値を確認
aws cloudwatch get-metric-statistics \
  --namespace AWS/EC2 \
  --metric-name CPUUtilization \
  --dimensions Name=InstanceId,Value=i-0123456789abcdef0 \
  --start-time "$(date -u -d '90 days ago' +%Y-%m-%dT%H:%M:%SZ)" \
  --end-time "$(date -u +%Y-%m-%dT%H:%M:%SZ)" \
  --period 86400 \
  --statistics Maximum \
  --query 'Datapoints[*].{Date:Timestamp,MaxCPU:Maximum}' \
  --output table
# Maximum値が一度でも80%超 → ダウンサイズ前に慎重な検証が必要

詰まり5: RI期限切れに気づかずオンデマンド課金

Reserved Instances の有効期限が切れた後、オンデマンド料金に自動的に切り替わるため、翌月の請求が突然増加するケースです。期限管理の仕組みがないと見落としが発生します。

# アクティブなRIの期限日を一覧で確認
aws ec2 describe-reserved-instances \
  --filters "Name=state,Values=active" \
  --query 'ReservedInstances[*].{
 Type:InstanceType,
 Count:InstanceCount,
 End:End,
 PaymentOption:OfferingType
  }' \
  --output table

# EventBridge + Lambda で60日前・30日前に自動通知を設定
# Health Event: AWS_EC2_RESERVED_INSTANCE_EXPIRATION

# RI カバレッジ budget を作成（カバレッジが80%を下回ったらアラート）
aws budgets create-budget \
  --account-id "$(aws sts get-caller-identity --query Account --output text)" \
  --budget '{
 "BudgetName": "RI-Coverage-Alert",
 "BudgetType": "RI_COVERAGE",
 "TimeUnit": "MONTHLY",
 "CostFilters": {},
 "BudgetLimit": {"Amount": "80", "Unit": "PERCENTAGE"}
  }' \
  --notifications-with-subscribers '[{
 "Notification": {
"NotificationType": "ACTUAL",
"ComparisonOperator": "LESS_THAN",
"Threshold": 80,
"ThresholdType": "PERCENTAGE"
 },
 "Subscribers": [{"SubscriptionType": "EMAIL","Address": "finops@example.com"}]
  }]'

詰まり6: Pricing Calculator見積もりと実課金の乖離

Pricing Calculator で試算した月額見積もりと実際の AWS 請求額が大きく乖離し、予算超過が発生するケースです。特にデータ転送費用と API 呼び出しコストの見落としが原因となることが多いです。

詰まり7: マルチアカウントRI共有の意図しない消費

AWS Organizations 環境でマスターアカウントが購入した Reserved Instances が、想定外のメンバーアカウントで消費され、本来の適用対象アカウントへの割引が機能しないケースです。

# Organizations マスターアカウントで特定メンバーとの RI 共有を無効化
# マネジメントコンソール: Billing → Preferences → RI sharing
# または AWS CLI:

# 現在の共有設定を確認
aws organizations describe-organization \
  --query 'Organization.{Id:Id,MasterAccount:MasterAccountId}'

# 特定アカウントへのRI共有をオフ（マスターアカウントで実行）
# コンソール: Billing & Cost Management → Reservations → RI sharing
# → 対象メンバーアカウントのトグルをOFFに設定

# インスタンスに Environment タグを付与してRI消費を追跡
aws ec2 create-tags \
  --resources i-0123456789abcdef0 \
  --tags Key=Environment,Value=Production Key=Team,Value=Backend

# Cost Explorerで "Group by: Tag: Environment" でRI消費をアカウント別に可視化

アンチパターン→正解パターン変換（5問）

コスト最適化の現場で繰り返される典型的なアンチパターンを5問形式で整理しました。各問のアンチパターンを読んでから、正解パターンと解説を確認してください。

AP1: 全インスタンスをStandard RI 3年で購入

❌ アンチパターン

AWS 導入直後の初期フェーズで、コスト削減を最大化しようとして全 EC2 インスタンスを3年 Standard RI・All Upfront で一括購入する。「3年コミットが一番安い」という認識で、ワークロード特性の分析をせずに決断する。

問題が発生するシナリオ

• 購入後6か月でサービスがPivotし、インスタンスタイプを大幅変更
• Graviton 移行計画が浮上したが Standard RI でファミリー変更不可
• 一部サービスをコンテナ（Fargate）に移行したが EC2 RI は適用不可
• RI Marketplace での売却を試みるも、希望価格で売れず損失確定

【アンチパタームの構成例】
全インスタンス: m5.xlarge × 20台
購入: Standard RI 3年 All Upfront 全量
購入費用: 約$70,000（一括）

6か月後の状況:
- 実際に稼働: 12台（8台が余剰）
- 余剰 RI の月次コスト: 約$1,200/月が無駄
- 3年間の総損失試算: 約$43,200

✅ 正解パターン: 安定度に応じたRI/SP/Spot混在戦略

ワークロードの特性（安定度・変動パターン・将来計画）に応じて、最適な調達戦略を組み合わせます。

【正解パターンの構成例】
安定稼働インスタンス（DB・基幹API）: Convertible RI 1年 Partial Upfront
  → 利用率90%以上が確認済み・Graviton移行計画あり
  → 6台 × 約$80/月 = $480/月

変動ワークロード（API拡張分・ステージング）: Compute Savings Plans 1年
  → 利用パターンが不定期・リージョン横断利用
  → 月$300コミット

バッチ処理・CI/CD: Spot Fleet
  → 中断許容・夜間実行
  → オンデマンド比70%削減

新規・変動大: On-Demand
  → 実績が出てから移行判断

ポイント

Right Sizing → Spot/SP 適用 → RI 検討の順序を守ることが最重要。購入判断は 実績3か月分 のデータが揃ってから行い、初回は1年・Partial Upfront から始める。全量を一括でコミットするのは、実績が十分に積み上がった2回目以降の契約からが安全です。

AP2: Spot 1タイプ1AZのみ

❌ アンチパターン

コスト削減のために Spot Instance を導入する際、設定の簡便さから「m5.xlarge × ap-northeast-1a のみ」という構成にする。Spot の仕組みを理解せずに単一プールに依存する。

問題が発生するシナリオ

• AWS の容量需要増加により ap-northeast-1a の m5.xlarge プールが枯渇
• 全台が2分前通知なしに中断（terminate アクション）
• チェックポイントがないため全ジョブが失敗
• On-Demand での代替実行コストがSpotの節約分を超える

【アンチパターンのフリート設定】
AllocationStrategy: lowestPrice
LaunchSpecifications:
  - InstanceType: m5.xlarge
 SubnetId: subnet-ap-northeast-1a-only
TargetCapacity: 10

✅ 正解パターン: 4タイプ×3AZ分散 + Mixed Instances

{
  "SpotFleetRequestConfig": {
 "AllocationStrategy": "priceCapacityOptimized",
 "TargetCapacity": 10,
 "LaunchTemplateConfigs": [
{
  "LaunchTemplateSpecification": {
 "LaunchTemplateId": "lt-0abcd1234",
 "Version": "$Latest"
  },
  "Overrides": [
 {"InstanceType": "m5.xlarge",  "SubnetId": "subnet-1a"},
 {"InstanceType": "m5.xlarge",  "SubnetId": "subnet-1c"},
 {"InstanceType": "m5.xlarge",  "SubnetId": "subnet-1d"},
 {"InstanceType": "m5a.xlarge", "SubnetId": "subnet-1a"},
 {"InstanceType": "m5a.xlarge", "SubnetId": "subnet-1c"},
 {"InstanceType": "m6i.xlarge", "SubnetId": "subnet-1a"},
 {"InstanceType": "m6i.xlarge", "SubnetId": "subnet-1c"},
 {"InstanceType": "m6g.xlarge", "SubnetId": "subnet-1a"}
  ]
}
 ]
  }
}

ポイント

最低5種類以上のインスタンスタイプ × 3 AZ の組み合わせで、特定プールの枯渇による全台同時中断リスクを大幅に低減します。priceCapacityOptimized 戦略は AWS が自動的に空きキャパシティの大きいプールを選択するため、中断リスクとコストのバランスが最適化されます。Spot Advisor で中断率5%未満のインスタンスタイプを優先的に列挙することも有効です。

AP3: x86コンテナをそのままGravitonで起動

❌ アンチパターン

コスト削減のために既存の EC2 インスタンスを x86 から Graviton に変更した際、既存のコンテナイメージを検証なしにそのままデプロイする。「イメージはそのままでいい」と判断して本番環境に即時適用。

問題が発生するシナリオ

• exec format error でコンテナが起動しない（アーキテクチャ不一致）
• Python C 拡張モジュールのインポートでセグメンテーション違反
• 動作はするが、x86 最適化コードが arm64 では想定より低速
• ステージング環境なしで本番適用したためロールバックに時間がかかる

# アンチパターン: 検証なしで本番Gravitonインスタンスにデプロイ
aws ecs update-service \
  --cluster production \
  --service my-service \
  --task-definition my-task:15  # x86専用イメージのまま

# 結果: タスクが起動直後にexit 1で終了（exec format error）

✅ 正解パターン: multi-archビルド + ステージング検証

# Step 1: multi-archイメージをビルドしてECRにプッシュ
docker buildx build \
  --platform linux/amd64,linux/arm64 \
  --tag "$ECR_REGISTRY/myapp:v2.1.0-multiarch" \
  --push .

# Step 2: ステージング環境でGravitonインスタンスを使って検証
aws ecs update-service \
  --cluster staging \
  --service my-service \
  --task-definition my-task-graviton-test

# Step 3: ステージングで全機能テスト + 負荷テスト実施
# sysbench / wrk でx86比のスループット・レイテンシを実測

# Step 4: 問題なければ本番をGravitonに切り替え（段階デプロイ）
aws ecs update-service \
  --cluster production \
  --service my-service \
  --task-definition my-task-graviton \
  --deployment-configuration "minimumHealthyPercent=50,maximumPercent=200"

ポイント

Graviton 移行は「動くかどうか」の確認よりも「本番グレードの性能が出るか」の確認が重要です。アーキテクチャ互換性の確認（docker buildx imagetools inspect）、Cコンパイル済み依存ライブラリの arm64 wheel 確認、ステージングでの実負荷テストを3ステップとして必ず実施してください。

AP4: Compute Optimizer推奨を全自動適用

❌ アンチパターン

コスト最適化の自動化を進めるために、Compute Optimizer の推奨を人手の確認なしに Lambda + AWS 運用自動化ツール（Automation ランブック）で全インスタンスに自動適用する。「推奨通りにするのが最適」という思い込みから実装。

問題が発生するシナリオ

• 月次バッチ処理がないタイミングに取得した推奨でダウンサイズ
• 月末バッチ実行時に CPU が飽和しサービス影響が発生
• 自動適用でインスタンスが停止→再起動するため稼働中サービスに影響
• 高リスク推奨（パフォーマンスリスク Medium/High）も自動適用されてしまう

# アンチパターム: リスク評価なしの全自動適用
def auto_resize_all(event, context):
 optimizer = boto3.client('compute-optimizer')
 ec2 = boto3.client('ec2')

 recommendations = optimizer.get_ec2_instance_recommendations()
 for rec in recommendations['instanceRecommendations']:
  if rec['finding'] == 'OVER_PROVISIONED':
# リスク評価なしで即時適用（危険）
target_type = rec['recommendationOptions'][0]['instanceType']
resize_instance(ec2, rec['instanceArn'], target_type)

✅ 正解パターン: リスク評価 + 段階適用 + メトリクス確認

def safe_resize_pipeline(event, context):
 optimizer = boto3.client('compute-optimizer')
 cloudwatch = boto3.client('cloudwatch')

 recommendations = optimizer.get_ec2_instance_recommendations()

 for rec in recommendations['instanceRecommendations']:
  if rec['finding'] != 'OVER_PROVISIONED':
continue

  best_option = rec['recommendationOptions'][0]
  risk = best_option.get('performanceRisk', 999)

  # リスク評価による振り分け
  if risk < 0.5:
# Very Low: Jiraチケット自動作成（実行は人間が判断）
create_low_risk_ticket(rec, best_option)
  elif risk < 3.0:
# Low: ステージング環境のみ自動適用、本番は人間確認
if is_staging_instance(rec['instanceArn']):
 schedule_resize_with_approval(rec, best_option)
  else:
# Medium/High: 自動化対象外・手動レビュー必須
create_manual_review_ticket(rec, best_option, risk)

ポイント

Compute Optimizer の推奨を「参考情報」として扱い、最終判断は人間が行う設計にします。Very Low リスクでも本番インスタンスへの自動適用は避け、ステージング検証→本番適用のパイプラインを経由することを推奨します。Enhanced Infrastructure Metrics（90日分析）の有効化により推奨精度を向上させてから自動化を検討してください。

AP5: Pricing Calculatorを使わず口頭見積もり

❌ アンチパターン

新規 AWS 環境の構築コストや移行コストを、担当者の記憶とカタログ料金の暗算で「月額○○万円程度」と回答する。稟議書に数値の根拠が記載されず、実際の課金との乖離が問題になる。

問題が発生するシナリオ

• 口頭見積もり「月100万円」が実際には「月150万円」になり稟議を再提出
• 見積もりに含めていなかったデータ転送費・サポートプランが予算オーバーを引き起こす
• 見積もりの根拠が残らないため、将来の見直しができない
• 複数のシナリオ比較（On-Demand vs RI vs Graviton）を定量的に示せない

【アンチパターンの稟議書例】
AWS移行コスト試算（根拠なし）
- EC2: 月50万円程度
- RDS: 月20万円程度
- その他: 月10万円程度
合計: 月80万円（口頭で概算）

→ 実際の請求: 月120万円（データ転送40万円が未計上）

✅ 正解パターン: Pricing Calculator でTCO比較 + 見積書共有

【正解パターンの稟議書例】

AWS Pricing Calculator による試算（共有URL添付）
試算日: 2026-05-26  リージョン: ap-northeast-1

シナリオA（On-Demand）: $4,850/月
  - EC2 (m5.xlarge × 8台): $1,216
  - RDS (db.r6g.xlarge Multi-AZ): $740
  - ALB (100GB転送): $28
  - データ転送アウト (500GB): $57
  - CloudWatch Logs (50GB): $38
  - NAT Gateway (200GB): $124
  - サポート (Business 10%): $220
  - その他（S3/Route53等）: $427

シナリオB（Convertible RI 1年 + Graviton）: $2,960/月（39%削減）
シナリオC（Savings Plans + Spot混在）: $3,100/月（36%削減）

推奨: シナリオB（初期費用 $21,600 → 7か月で回収）
根拠URL: https://calculator.aws/pricing/2/estimate?id=xxxxx

ポイント

Pricing Calculator の見積もりには「見積書共有 URL」が生成され、関係者が同一の見積もりを再現可能です。稟議書には共有 URL と PDF エクスポートの両方を添付し、見積もり根拠を透明化します。シナリオ比較（On-Demand / RI / Graviton / Spot）を並列表示することで、経営層への説明が容易になります。見積もり総額には15〜20%のバッファを加えた金額で予算申請することを推奨します。

まとめ — Cost Optimization二部作完成・57記事化達成

本記事（Vol2）では、AWSコスト最適化の実行層を構成する5本柱を詳説しました。Vol1（可視化層）と組み合わせることで、「見る・知る・検知する」から「買う・変える・最適化する」までの完全なコスト最適化フレームワークが完成します。

Vol2 実行層5本柱の総括

§2 Reserved Instances 本番運用

Standard RI（割引率最大・変更不可）と Convertible RI（柔軟性優先・Graviton対応）の選択基準を習得しました。最重要ルールは「Right Sizing 完了後に購入」と「80%利用率ルール」です。RI 購入後は Budgets でカバレッジ・利用率を継続監視し、期限管理は EventBridge による自動通知で属人化を防ぎます。

§3 Spot Instances / Spot Fleet 本番運用

バッチ処理・CI/CD ワークロードに最大90%割引を適用するための3層防御（多様化・チェックポイント・フォールバック）を実装しました。priceCapacityOptimized 戦略 + 5タイプ × 3AZ 分散 + SQS キューによる冪等処理が本番Spot運用の骨格です。ECS（FARGATE_SPOT）・EKS（Karpenter + NTH）それぞれの統合パターンも確認しました。

§4 Graviton移行 本番運用

arm64 互換性検証（pip download --platform manylinux2014_aarch64）→ Docker multi-arch buildx → ステージング実測 → 段階本番移行のフローを確立しました。RDS は Blue-Green デプロイ、ElastiCache はオンライン変更、Lambda はダウンタイムなしでの移行が可能です。EC2で最大40%、Lambda で20%、RDS で20〜30%のコスト削減が期待できます。

§5 Right Sizing + Pricing Calculator

Compute Optimizer の推奨をリスク評価（Very Low → 即時適用候補 / Medium → 負荷テスト必須）で振り分けて段階適用するフローを確立しました。Lambda Power Tuning による最適メモリ設定の発見、EBS gp2→gp3 のオンライン移行（20%コスト削減）、Pricing Calculator による TCO 比較と稟議書作成まで一連の実行ができます。

§6 詰まり7選 + §7 アンチパターン5問

現場で頻出する失敗パターンを体系化しました。特に「RI購入後の利用率低下」「Spot多様化なし」「Graviton非互換」「スパイク考慮漏れ」「RI期限切れ」「見積もり乖離」「RI共有の意図しない消費」の7パターンと、5つのアンチパターン演習で本番コスト実行力を習得できます。

Vol1 × Vol2 の統合的な活用フロー

コスト最適化は「可視化」と「実行」の継続サイクルで成果が積み上がります。両ボリュームを組み合わせた推奨フローを示します。

次のアクションとして、まず Right Sizing から始めることを強く推奨します。追加コストゼロで即時効果が得られる唯一の施策であり、その後の RI 購入判断の精度を高める基盤にもなります。

【可視化層（Vol1）→ 実行層（Vol2）の連携フロー】

Cost Explorer→  RI購入候補インスタンスを特定
Budgets→  RI利用率・カバレッジを継続監視
Savings Plans推奨  →  SP購入判断・RI期限切れ後の移行先
Compute Optimizer  →  Right Sizing実行候補を特定
Cost Anomaly Detection→  コスト急増の早期検知・Spot設計見直しトリガー

↓↓↓ 実行層に連携 ↓↓↓

Right Sizing → スペック最適化（RI購入前の必須ステップ）
Reserved RI  → 安定インスタンスへのコミット割引適用
Spot Fleet→ バッチ・CI/CDを最大90%削減
Graviton移行 → arm64で追加的なアーキテクチャ削減
Pricing Calc → 削減効果の定量化と次期計画

コスト最適化 本番運用 統合チェックリスト

Vol1・Vol2 の全施策を網羅した実行チェックリストです。新規環境構築時・四半期レビュー時に活用してください。

フェーズ1: 可視化基盤の確立（Vol1）

• [ ] Cost Explorer でサービス別・タグ別のコスト分布を確認
• [ ] Budgets で月次予算アラートを全主要サービスに設定
• [ ] Cost Anomaly Detection で異常コスト検知モニターを有効化
• [ ] Compute Optimizer で Over-Provisioned インスタンスを特定
• [ ] Savings Plans Recommendations で最適な SP タイプと購入額を確認

フェーズ2: Right Sizing の実施（Vol2 最優先）

• [ ] Compute Optimizer の推奨をリスク別（Very Low / Low / Medium / High）に分類
• [ ] Enhanced Infrastructure Metrics を有効化（スパイク・バッチが多いワークロード）
• [ ] ステージング環境でパフォーマンス実測後に本番へ適用
• [ ] EBS gp2→gp3 移行（全 gp2 ボリュームを一覧化→オンライン変更）
• [ ] Lambda Power Tuning で最適メモリ設定を発見・適用

フェーズ3: RI / Savings Plans の最適化（Vol2）

• [ ] RI 利用率レポートで過去3か月の平均利用率を確認（80%ルール）
• [ ] Right Sizing 完了済みインスタンスのみを RI 購入対象に選定
• [ ] Graviton 移行計画に応じて Standard / Convertible RI を選択
• [ ] Budgets で RI 利用率・カバレッジアラートを設定（閾値80%）
• [ ] RI 期限6か月前からリニューアル判断を開始

フェーズ4: Spot / Graviton の活用（Vol2）

• [ ] Spot Advisor で中断率5%未満のインスタンスタイプを確認
• [ ] priceCapacityOptimized + 5タイプ × 3AZ 分散で Spot フリートを設定
• [ ] SQS キュー + チェックポイント設計で Spot 中断耐性を実装
• [ ] Graviton 互換性検証（arm64 wheel / Docker multi-arch / ベンチマーク）
• [ ] RDS / ElastiCache / Lambda の Graviton 移行を段階実施

フェーズ5: 継続モニタリング（Vol1 + Vol2 の組み合わせ）

• [ ] 月次: Cost Explorer で削減効果を測定・次のアクションを特定
• [ ] 四半期: Compute Optimizer 推奨を再確認・RI 利用率をレビュー
• [ ] 半年: Graviton 移行ロードマップを更新・新インスタンスファミリーを評価
• [ ] 年次: RI 期限管理・リニューアル or SP 移行の判断