AWSの請求額、ちゃんと「説明」できますか？
AWSを使っていて、こんな状態になっていませんか？
- なんとなく毎月このくらい請求されている
- 高い気はするが、何が原因か分からない
- とりあえず動いているから触っていない
AWSコスト最適化は「節約テクニック」ではありません。
無駄なリソースを排除し、投資対効果（ROI）を最大化するための設計と運用の話です。
特に初心者〜中級者の環境では、
- オンデマンド料金のまま長期稼働
- 開発環境の止め忘れ
- 過剰スペックなEC2やRDS
が重なり、30〜50%程度の無駄なコストが発生していることも珍しくありません。
この記事では、今日から実装できて、実際に削減効果が出る5ステップに絞って解説します。
AWSコスト最適化の全体像：4つのアプローチ
AWSコスト最適化は、次の4つのアプローチで整理できます。
AWSが提唱する「Cloud Financial Management (CFM)」フレームワークに基づくアプローチです。
| アプローチ | 説明 | 削減率(目安) | 難易度 |
|---|---|---|---|
| 可視化 | 何に、いつ、いくら使っているかを把握する | - | 低 |
| 最適化(クイックウィン) | インスタンス停止や購入オプション活用など、即効性のある施策 | 平均20% | 中 |
| 最適化(アーキテクチャ) | サーバーレス化など、設計レベルでの抜本的な最適化 | 高 | 高 |
| 予測・計画（FinOps） | 予算管理やFinOpsの実践により、持続的な最適化体制を築く | - | 中 |
ステップ1：まずコストを「見える化」する
AWSコスト最適化で最初にやるべきことは1つだけです。
今、何にいくら使っているのかを把握する
これができていない状態では、どんな削減施策も「勘と気合」になってしまいます。
このステップでは、2つの設定だけを行います。
① 予算アラートの設定（AWS Budgets）
まずは「使いすぎに気づける仕組み」を作ります。これはガードレールです。
なぜ最初にやるのか
- AWSは従量課金なので上限がない
- 気づいた時には請求が確定している
- 初心者の高額請求は「気づけなかった」が原因
実装ステップ
- AWSマネジメントコンソールを開く
- AWS Budgets を開く
- コスト予算 を作成
- 予算額を設定
- 通知先メールアドレスを設定
- 使用率 80% / 100% で通知するよう設定
これだけで、
「いつの間にか使いすぎていた」事故を防げます。
② コストの可視化（AWS Cost Explorer）
次に、「何が高いのか」をはっきりさせます。
Cost Explorerで分かること
- 日次・月次のコスト推移
- サービス別の内訳（EC2 / RDS / S3 など）
- インスタンスタイプ別の利用状況
実装ステップ
1. Cost Explorer を有効化
2. 月次・日次グラフを確認
3. フィルタで以下を切り替えて確認
- サービス別
- 使用タイプ別
- インスタンスタイプ別
これを行うことで、「EC2が高い」「RDSが想定より重い」「ストレージが増え続けている」
といった “次に触るべきポイント” が明確になります。
ステップ2：設計不要で削減できる「クイックウィン」
次にやるべきは、考えなくても削減できる部分を消すことです。
これらは、「設計変更なし」「リスク低」で進められ、一定の削減効果が出ることもあります。
| 施策 | 実施時間 | 期待目安 | 難易度 | 優先度 |
|---|---|---|---|---|
| 未アタッチEBSの削除 | 10分 | 中 (100%削減) | 低 | 高 |
| アイドルELB/EIPの削除 | 15分 | 小〜中 | 低 | 高 |
| EBSのGP2→GP3移行 | 30分/vol | 中 (〜20%) | 低 | 高 |
| S3 Intelligent-Tiering有効化 | 15分 | 中 (〜40%自動) | 低 | 高 |
| 開発環境の夜間/週末停止 | 1時間 | 大 (〜70%) | 中 | 中 |
このステップの目的
・「考えなくても削減できる無駄」を先に消す
・本命施策（価格モデル・設計）に集中するための下準備
ステップ3：価格モデルを理解すると世界が変わる
AWSコスト最適化において、最もインパクトが大きいのが「価格モデルの選択」 です。
同じリソース・同じ性能でも、どの価格モデルを使うかだけで請求額が2〜3倍変わる ことは珍しくありません。
AWSの主要な価格モデルの特性を一覧化しました。導入ハードルと割引率のバランスを可視化しています。
価格モデル比較表
| 価格モデル | 最大割引率 | コミット期間 | 主な適用対象 | 向いている用途 | 導入難易度 | 注意点 |
|---|---|---|---|---|---|---|
| On-Demand | なし | なし | 全サービス | 短期利用、検証、開発初期 | 低 | 長期利用では割高 |
| Savings Plans (SP) | 最大72% | 1年 / 3年 | EC2 / Fargate / Lambda / SageMaker | 24時間365日稼働するベースロード | 中 | 利用量（$/時）をコミット |
| Reserved Instances (RI) | 最大72% | 1年 / 3年 | EC2 / RDS / Redshift / ElastiCache | DBなど構成変更が少ないリソース | 中〜高 | 柔軟性が低い |
| Spot Instances | 最大90% | なし | EC2 / Fargate / SageMaker | バッチ処理、テスト、ステートレス | 高 | 予告付きで中断される |
| Database Savings Plans | 35〜50% | 1年 | RDS / Aurora / DynamoDB | 複数DBを使う環境 | 中 | 割引率が低い。RIとの併用不可 |
① On-Demand (オンデマンド)
一言で言うと「使った分だけ払う、最もシンプルな料金モデル」
概要
初期費用や長期契約が不要で、リソースを起動している時間（または秒）分だけ料金が発生します。
予測が難しいワークロードや、短期間の利用に向いています。
メリット
- 柔軟性が最大：いつでも起動・停止・削除でき、縛りが一切ない
- 初期投資ゼロ：前払い不要なので、すぐに使い始められる
- 検証・試行錯誤に最適：サイズが分からない段階のベンチマークに向いている
デメリット・注意点
- 単価が高い：長期間使い続けると最もコストが高くなる
- 予算管理が難しい：使用量次第で請求額が青天井になりやすい
- スパイクに弱い：トラフィック急増時にそのままコストが跳ね上がる
導入判断基準
- 短期・一時的な利用
- 検証・PoC・開発初期
- 利用量が予測できないワークロード
② Savings Plans（SP）
一言で言うと「安定稼働するリソースを安く使うための定額割引」
概要
1年または3年の期間、利用金額をコミットすることで、オンデマンドより大幅な割引を受けられるモデルです。
Compute SP（柔軟性高）とEC2 Instance SP（割引率高）の2種類が主流です。
メリット
- 柔軟性が高い（Compute SP）：インスタンスタイプ・リージョン・OSが変わっても適用される
- 管理が楽：RIよりも細かな管理・交換作業が少ない
- 対象が広い：EC2だけでなく、FargateやLambdaにも適用可能
デメリット・注意点
- コミット額は減らせない：使用量が減っても、コミット分の支払いは発生する
- 割引率と柔軟性はトレードオフ：EC2 Instance SPは割引率が高いが条件が固定される
- 購入後7日間の制限：7日を過ぎると変更・キャンセル不可
導入判断基準
- 1年以上安定して稼働するベースロードがある
- 将来的に構成変更の可能性がある
- 初めて割引モデルを導入する
③ Reserved Instances（RI）
一言で言うと「構成が固定されたリソースを最安で使うための予約」
概要
1年または3年の期間、インスタンスタイプ・リージョンなどを指定して予約することで、高い割引を受けられるモデルです。
RDSやRedshiftなど、Savings Plansの対象外となるデータストア系サービスで特に重要です。
メリット
- キャパシティを確保できる：AZ指定により、キャパシティ不足回避できる
- 割引率が高い：条件次第で最大72%割引
- 売却できる可能性：Standard RI は Marketplace で売却できる場合がある
デメリット・注意点
- 柔軟性が低い：Standard RI はインスタンスタイプ変更不可
- 管理コストが高い：構成変更のたびに見直しが必要
- 未使用リスク：条件に合うリソースが動いていないと割引が無駄になる
導入判断基準
- RDS / Redshift などのステートフルなサービス
- 構成が長期間変わらないことが確実
- 可用性を重視する本番環境
④ Spot Instances（スポットインスタンス）
一言で言うと「中断されても問題ない処理を激安で回す方法」
概要
AWSの空きキャパシティを利用することで、最大90%オフ でEC2などを使えるモデルです。
ただし、AWS側の都合でインスタンスが回収（中断）される可能性があるため、耐障害性のある設計が必要です。
メリット
- 圧倒的な低コスト：オンデマンド比で最大90%削減
- 大規模処理に強い：バッチ処理やHPCを低コストで実行可能
- ステートレス処理に最適：Webサーバー、CI/CD、コンテナ処理と相性が良い
デメリット・注意点
- 中断リスクがある：中断は2分前通知のみ
- 在庫は保証されない：リージョンやAZによって使えないことがある
- 用途が限定される：DBや中断不可の処理には不向き
導入判断基準
- バッチ処理
- CI/CD、テスト環境
- 中断してもリトライ可能なワークロード
⑤ Database Savings Plans（上級者向け）
一言で言うと「データベースの変動負荷を柔軟に低コスト化する方法」
概要
AWSのマネージドデータベース（Aurora、RDS最新世代、DynamoDBなど）で、1年一定使用量をコミットし最大35%オフ（前払いなし）で利用可能。 エンジン・インスタンスファミリー・リージョンを変更しても割引が自動適用される柔軟さが特徴ですが、RIより割引率が低く対象制限あり。
メリット
- 高い柔軟性：移行時（例: RDS Oracle→Aurora、EU→USリージョン）も割引継続
- Serverless対応：Aurora Serverless v2、DynamoDB On-DemandなどRIなしサービスに最適。
- 自動適用：RIカバー外のオンデマンド分を拾い、ハイブリッド運用可能
デメリット・注意点
- 割引率控えめ：Aurora/RDSで20%、DynamoDBで12-18%とRI（最大63%）に劣る
- 対象制限：RDS/Auroraは第7/8世代のみ、Redshift/OpenSearch/MemoryDB（Redis）は対象外
- RI併用不可：同一ワークロードで重複適用せず、変動負荷以外はRI優先推奨
導入判断基準
- RIなしサービス（DocumentDB、Neptune、Timestream）
- 移行プロジェクト中の保険（エンジン/リージョン変更予定）
- 変動負荷（ベース60-80%はRI、残りはDB SPのハイブリッド）
ステップ4：価格モデルは「組み合わせて使う」
AWSの価格モデルは、どれか1つを選ぶものではありません。
ワークロードの性質に応じて安定性とコストを両立させる「ポートフォリオ設計」 が重要です。
ここでは、実務でよく使われる代表的な組み合わせを紹介します。
ポートフォリオ設計
① Reserved Instance / Savings Plans + Spot の「ベース＆バースト」戦略
一言で言うと 「最低限は安定割引、増えた分は激安で吸収」
最もコスト効率が高く、多くの本番環境で採用されている構成です。
- ベース部分（常時稼働）
- 24時間365日稼働する最低限のリソース
- Savings Plans または RI を適用して確実に割引
- スパイク部分（変動負荷）
- 一時的なアクセス増、夜間バッチなど
- Spot Instances を使い最大90%割引を狙う
なぜこの構成が強いのか
- 固定費は安定した割引で抑えられる
- 需要変動は最も安いリソースで対応できる
- 可用性とコストのバランスが取りやすい
② Savings Plans + On-Demand
一言で言うと「安定分だけ割引し、変動は縛らない」
割引を効かせつつ、オーバーコミットのリスクを避けたい場合 に向いています。
- 70〜80%程度のベースロード
- Savings Plans でカバー
- 残りの変動部分
- On-Demand で支払う
なぜ100%をカバーしないのか
- ダウンサイジングや構成変更時にコミット額が無駄になるリスクがあるため
- 将来の負荷変動に対応しやすい
運用イメージ
- Auto Scaling と組み合わせ
- 通常時は SP でカバー
- ピーク時のみ On-Demand でスケール
③ RI / RC + Database Savings Plans
一言で言うと「DBの固定負荷と変動負荷を分けて最適化」
データベースは、構成変更・移行・サーバーレス化が発生しやすく、単一の割引モデルでは最適化しづらい領域です。
- ベース部分（60〜80%）
- 固定負荷の RDS / Aurora / DynamoDB（Provisioned）
- RI / RC を優先（最大約60%オフ）
- 変動・移行部分（20〜40%）
- Aurora Serverless v2
- DynamoDB On-Demand
- エンジン / リージョン移行予定のDB
- Database Savings Plans を適用（20〜35%オフ）
この構成の強み
- RIでベースをガッチリ固める
- DB SPで「RIが使えない部分」を自動的にカバー
- マイグレーション中でも割引を効かせられる
環境別おすすめポートフォリオ
本番環境（Production）
| リソース | 推奨構成 |
|---|---|
| DB（固定） | RI / RC（ベース）+ Database SP（変動・移行） |
| Web / API | Savings Plans（ベース）+ Spot（Auto Scaling混合） |
開発・検証環境（Dev / Test）
| リソース | 推奨構成 |
|---|---|
| 基本 | On-Demand（夜間・週末は停止） |
| 中断OK作業 | Spot Instances |
| DB検証 | Database SP（RI未対応サービスのPoC向け） |
ステップ5：アーキテクチャ最適化は「最後にやる」
設計やアプリケーションの見直しを伴う最適化です。
実装コストは高いものの、最終的なコスト効率はこのフェーズが最も高くなります。
長期的施策一覧（アーキテクチャ改善）
| 施策 | 期待削減額 | 難易度 | 優先度 |
|---|---|---|---|
| スポットインスタンス活用 | 特大（〜90%） | 高 | 中 |
| サーバーレス化（Lambda等） | 変動（高効率） | 高 | 低 |
| DBのサーバーレス化（Aurora v2） | 変動（アイドル削減） | 中 | 低 |
| データ転送経路の最適化 | 中〜大 | 高 | 低 |
| Auto Scaling 導入 | 変動（高効率） | 中 | 中 |
このフェーズの位置づけ
- すぐやる必要はない
- ただし、「トラフィック増加」「ユーザー数拡大」「グローバル展開」が見えてきたら避けて通れない
重要な考え方
- いきなりサーバーレス化しない
- 先に「料金モデル」と「無駄」を潰す
- 最後に設計を変える
まとめ：AWSコスト最適化は「説明できる状態」を作ること
AWSコスト最適化は、単なる節約ではありません。
「何にいくら使っているか」を説明できる状態を作り、投資対効果（ROI）を最大化するための設計・運用です。
この記事で紹介した5ステップを振り返ると、流れはシンプルです。
- ステップ1（可視化）：Budgetsで事故を防ぎ、Cost Explorerで原因を特定する
- ステップ2（クイックウィン）：設計変更なしで消せる無駄を先に潰す
- ステップ3（価格モデル）：同じ性能でも支払い方でコストは2〜3倍変わる
- ステップ4（組み合わせ）：ベースと変動を分けて「ポートフォリオ」で最適化する
- ステップ5（アーキテクチャ最適化）：最後に設計を変えて、長期の効率を取りに行く
ここまで整うと、AWSの請求は「高い/安い」ではなく、
“設計の結果”としてコントロール可能なものになります。
AWSコスト最適化は「やり切る」ものではなく、可視化 → 改善 → 再確認 を回していく“習慣”です。
まずは 「説明できる請求」 を作りましょう。
その状態に入れた時点で、あなたのAWS運用は一段強くなります。
参考資料