毎月の請求は増えているのに、どのチームのどの構成が増やしたのか答えられない。Savings Plans を買えば下がると聞くが、どれだけ買えばよいか決め手がない。予算を超えたと分かるのは月末の請求を見てから。コスト最適化の相談で多いのは、この3つが同時に起きている状態です。
この記事は、割引の種類の説明ではなく、見える化・構成・契約・予算・運用の5つをどの順番で、どの判断の軸で設計するかを整理します。規模や予算、体制が変わると答えがどう変わるかも並べます。
この記事の結論
- コスト最適化の設計は、見える化・構成・契約・予算と異常検知・運用の順に積み上げ、前の段を飛ばさないことが要になります。
- 「誰の費用か」はアカウントの分け方を一次の軸にし、コスト配分タグと Cost Categories で細かく分けると、付け忘れに強くなります。
- 構成で使う量を減らしてから、残った安定した量に Savings Plans や RI をコミットすると、無駄を割引つきで固定せずに済みます。
- 予算（AWS Budgets）は決めた額との比較、Cost Anomaly Detection は普段と違う増え方の検知で、役割が違うので両方置きます。
- 役割分担と週・月・四半期の定期レビューを決めておかないと、一度下げた費用は構成の追加とともに戻ります。
コスト最適化の設計とは何を決めることか
AWS Well-Architected のコスト最適化の柱は、クラウド財務管理の実践、支出と使用量の把握、費用対効果の高いリソース、需要と供給の管理、継続的な最適化、という5つの領域を置いています。この記事ではそれを設計者の手順に並べ直し、5つの段で考えます。
- 見える化 — どこに、誰の費用として、いくら使っているか。
- 構成で下げる — 使っていないものを止め、サイズと種類と置き場所を合わせる。
- 契約で下げる — 残った安定した量を、Savings Plans や RI で割り引く。
- 予算と異常検知 — 使いすぎと、普段と違う増え方に早く気づく。
- 運用 — 誰がいつ見て、誰が直すか。
COST DESIGN AXES先に確かめる軸
割引の種類からではなく4つの軸から決める
-
1.誰の費用か — アカウント・タグ・分類で分けられるか
未分類がどれだけ残るか。配賦の単位が後ろの段すべての単位になる
-
2.使い方の形 — 常時一定か、波があるか、中断できるか
適正サイズ・スポット・サーバーレスのどれが効くか
-
3.構成の見通し — 1〜3年でファミリーやサービスを変えるか
コミットの種類と期間と量
-
4.体制 — 誰が見て、誰が直すか
通知の宛先、見直しの頻度、自動化の深さ
どの段でも、答えは要件で変わります。先に次の4つを確かめます。
| 確かめる軸 | 何が決まるか | 確かめ方 |
|---|---|---|
| 誰の費用か分かるか | 配賦の単位（アカウント・タグ・分類） | 請求をアカウントとタグで割ったとき、未分類がどれだけ残るか |
| 使い方の形 | 適正サイズ・スポット・サーバーレスのどれが効くか | 常時一定か、時間帯で波があるか、中断してよい処理か |
| 構成の見通し | コミットの種類と期間と量 | 1〜3年の間にファミリー・リージョン・サービスを変える予定 |
| 体制 | 誰が見て誰が直すか、自動化の深さ | 財務・事業・技術の担当と、見直しの頻度 |
「どこにいくら」をどう見える化するのか
見える化の目的は、費用を「持ち主」に結びつけることです。Well-Architected は、事業部・部門・プロジェクトのような配賦の分類を先に決め、それを費用に結びつけることを求めています（COST03）。持ち主が決まらない費用は、誰にも直されません。
| 手段 | 何で分けるか | 強み | 弱み |
|---|---|---|---|
| アカウントの分け方（AWS Organizations の一括請求） | アカウント単位 | 付け忘れが起きない。権限と予算の境界にもなる | アカウントをまたぐ共有の費用は分けられない |
| コスト配分タグ | リソースに付けたキーと値 | アカウントの中をプロジェクトや環境で分けられる | 付け忘れ・表記揺れが出る。請求で使うには有効化が要る |
| AWS Cost Categories | アカウント・タグ・サービスなどのルール | 組織の分類を請求データに表せる。分割請求のルールで共有の費用を按分できる | ルールの保守が要る |
コスト配分タグは、リソースに付けるだけでは請求の集計に出ません。ユーザー定義のタグも AWS が生成するタグも、請求のコンソールで有効化してはじめて Cost Explorer やレポートで使えるようになり、公式ドキュメントでは有効化の対象として表示されるまで最大24時間かかるとされています。
設計の定石は、アカウントを一次の軸、タグを二次の軸にすることです。本番と開発、事業部ごとにアカウントを分けておけば、タグを付け忘れても大きな単位では配賦が崩れません。そのうえで Cost Categories が「事業部A＝このアカウント群＋このタグの値」といったルールを持ち、ネットワークやセキュリティの共有アカウントの費用は分割請求のルールで各事業部へ按分します。Cost Categories は Cost Explorer・Budgets・Cost Anomaly Detection の軸としても使えるので、ここで決めた分類が後ろの段すべての単位になります。
CHECK 1ここまでの確認
タグやアカウントを束ねて「事業部」という分類を作り、共有の費用もその分類へ割り振りたい。この記事が挙げた仕組みはどれ?
答えと解説
答え: 1. AWS Cost Categories と分割請求のルール
Cost Categories はアカウントやタグのルールで独自の分類を作り、分割請求のルールで共有の費用を按分できます。『「どこにいくら」をどう見える化するのか』を読み直してください。
構成で下げるには何から手をつけるのか
構成で下げる手は多いですが、効き方と手間の順に並べると迷いません。
- 止める・消す — 使われていない環境、夜間と週末に動かす必要のない開発環境、付けっぱなしのボリュームやスナップショット。AWS Trusted Advisor のコスト最適化のチェックも洗い出しに使えます。
- 適正サイズにする — AWS Compute Optimizer は使用状況のメトリクスを機械学習で分析し、EC2・Auto Scaling グループ・EBS・Lambda などの構成を推奨します。メモリの使用率は CloudWatch エージェントで集めると推奨に反映されるので、CPU だけで判断しないようにします。
- 種類を替える — Graviton（Arm ベースのプロセッサ）への移行は、アプリとライブラリが Arm で動くかの確認が前提です。
- 買い方を替える（スポット） — スポットインスタンスは、公式ドキュメントでオンデマンドより最大90%安く使えるとされる一方、EC2 が容量を取り戻すときは2分前の通知で中断されます。ステートレスで中断に耐える処理（バッチ・CI・コンテナのワーカーなど）に限ります。
- 形を替える（サーバーレス化） — 待機している時間の長い処理は、Lambda や Fargate に移すと「動いている時間」だけの支払いに近づきます。
- 置き場所と運び方を直す — S3 はライフサイクルのルールで安いストレージクラスへ移し、アクセスの傾向が分からないデータは S3 Intelligent-Tiering に任せます。データ転送は Well-Architected の COST08 に沿って、経路をモデル化してから直します。S3 と DynamoDB へのアクセスはゲートウェイ型の VPC エンドポイントを通すと NAT ゲートウェイの処理料金を避けられ、NAT ゲートウェイは通信の多いリソースと同じ AZ に置くと AZ 間の転送料金を減らせます。
この順番には理由があります。後ろの段ほど効果の見積もりが難しく、作り直しの手間とリスクが増えます。前の段を済ませずに作り直しに入ると、止めれば済んだ費用を作り直しの工数で払うことになります。
READ ALSO — 未経験向け・段1 入口
EC2 のインスタンスタイプと購入オプションの仕組み｜名前の読み方と払い方
CHECK 2ここまでの確認
この記事が勧めた「下げる順番」として正しいのはどれ?
答えと解説
答え: 2. 止める・適正サイズにするを先に済ませ、残った安定した量に Savings Plans を買う
大きすぎる構成のままコミットすると、無駄を割引つきで固定してしまいます。構成で下げてから契約で下げます。「構成で下げるには何から手をつけるのか」を読み直してください。
Savings Plans と RI はどう選び、どれだけコミットするのか
契約で下げる手段は、一定の利用を1年か3年約束する代わりに割り引くものです。EC2 について、AWS のドキュメントはリザーブドインスタンス（RI）より Savings Plans を勧めています。RI は特定のインスタンスの構成への約束、Savings Plans は1時間あたりの利用額（ドル）への約束で、構成を選ぶ自由が残ります。
| 購入方法 | 約束するもの | 適用の範囲 | 割引（公式の「最大」） |
|---|---|---|---|
| Compute Savings Plans | 1時間あたりの利用額 | EC2（ファミリー・サイズ・リージョン・OS を問わない）、Fargate、Lambda | オンデマンドより最大66% |
| EC2 Instance Savings Plans | 1時間あたりの利用額＋リージョンとファミリー | そのファミリーの中ならサイズ・OS を問わない | オンデマンドより最大72% |
| Database Savings Plans | 1時間あたりの利用額（1年） | Aurora・RDS・DynamoDB など対応するデータベース。エンジンやリージョンをまたいで適用 | 最大35%（2025年12月の発表時点） |
| SageMaker AI Savings Plans | 1時間あたりの利用額 | SageMaker AI のインスタンス（ファミリー・リージョン・用途を問わない） | 公式の料金ページで確認 |
| リザーブドインスタンス（RI） | 特定の構成 | EC2 のほか RDS・ElastiCache などサービスごとの予約 | サービスごとの料金ページで確認 |
COMMITMENT CHOICE買い方を2軸で
構成を変えるなら柔軟さ、変えないなら割引率を取る
構成（ファミリー・リージョン・サービス）を変える見込み →
オンデマンド＋スポット
波が大きく構成も動く。中断に耐える部分だけスポット
Compute Savings Plans
安定して使うが、構成やサービスは変える
先に止める・適正化
波があり構成は固定。まずサイズと稼働時間を直す
EC2 Instance Savings Plans
安定して使い、ファミリーとリージョンも固定
使用量の安定 →
種類は「構成をどこまで変えるか」で決める
割引の大きさと柔軟さは引き換えです。ファミリーとリージョンを数年変えないと言い切れるなら EC2 Instance Savings Plans、見直しやコンテナ・サーバーレスへの移行があるなら Compute Savings Plans。迷うときは、外れたときの損（使われない約束）のほうが、割引率の差より大きくなりやすいことを思い出します。
量は「安定した下限」から、分けて買う
コミットする量に決まった正解の割合はありません。考え方は次のとおりです。
- 適正サイズのあとに測る — 構成で下げる前の量で買うと、無駄を固定します。
- 下限を目安にする — 夜間や週末でも常に使っている、時間あたりの利用額の下限が候補です。波の上の部分はオンデマンドとスポットで受けます。
- 一度に買わない — 時期を分けて積み増すと、構成が変わったときに外れる額が小さくなります。
- 推奨は出発点として使う — Cost Explorer の購入の推奨と Purchase Analyzer は、過去の期間（ルックバック）の利用から、節約額・カバー率・使用率への影響を試算します。過去の期間に移行や一時的な増加が含まれていないかを確かめてから使います。
買ったあとは2つの指標を見ます。使用率は約束した額のうち実際に使われた割合で、下がっていれば買いすぎです。カバー率は対象となる利用のうち割引が効いている割合で、低ければ追加の余地があります。使用率を落とさない範囲でカバー率を上げる、が契約の運用の基本です。
CHECK 3ここまでの確認
来年は EC2 の一部を Fargate と Lambda に移す計画がある。移したあとも割引が効き続けやすい購入方法はどれ?
答えと解説
答え: 1. Compute Savings Plans
Compute Savings Plans はファミリーやリージョンを問わず EC2 に適用され、Fargate と Lambda にも適用されます。「Savings Plans と RI はどう選び、どれだけコミットするのか」を読み直してください。
予算と異常検知はどう置き分けるのか
見える化と契約が整っても、構成の追加やミスで費用は増えます。気づく仕組みは、役割の違う3つを組み合わせます。
| 仕組み | 何と比べるか | 向く場面 | 動けること |
|---|---|---|---|
| AWS Budgets | 決めた額・量・目標の使用率とカバー率 | 月の予算が決まっている、約束の使用率を守りたい | 実績と予測でのアラート、予算アクション（IAM ポリシーや SCP の適用、特定のインスタンスの停止など） |
| AWS Cost Anomaly Detection | その費用の普段のパターン | 予算の額がまだない、急な増え方に早く気づきたい | サービス・アカウント・タグ・Cost Categories ごとのモニター、影響額のしきい値つきの通知、原因の候補の提示 |
| AWS Cost Explorer | 過去の実績と予測 | 増えた理由を調べる、月次の見直し | 内訳の分析、Savings Plans の推奨とレポート |
Budgets には、費用・使用量のほか、Savings Plans と RI の使用率とカバー率の予算も作れます。予算アクションを使うと、サンドボックスのアカウントで予算を超えたら新しいリソースの作成を止める、といった抑止まで自動化できます。一方、Cost Anomaly Detection はしきい値を決めなくても、機械学習で普段と違う増え方を見つけ、影響の大きい原因をサービス・アカウント・リージョン・使用タイプの軸で示します。
設計のポイントは、通知の宛先を「その費用の持ち主」にすることです。見える化の段で決めた分類（アカウント・Cost Categories）ごとにモニターと予算を作ると、アラートを受けた人がそのまま直せます。全社の窓口にだけ届く通知は、読まれなくなります。
CHECK 4ここまでの確認
まだ予算の額を決めていない新しいプロジェクトで、普段と違う増え方に早く気づきたい。向くのはどれ?
答えと解説
答え: 1. AWS Cost Anomaly Detection のモニターとアラート
Budgets は決めた額との比較、Cost Anomaly Detection はしきい値を決めなくても支出のパターンから外れた増え方を機械学習で見つけます。「予算と異常検知はどう置き分けるのか」を読み直してください。
誰がいつ直すのか（役割分担と定期レビュー）
Well-Architected の COST01 は、コスト最適化の持ち主を決めること、財務と技術の協力関係を作ること、費用を意識する文化を作ることを求めています。FinOps と呼ばれる実践も同じ考え方で、技術・財務・事業の担当がそれぞれの役割で費用に関わります。
| 役割 | 持つもの |
|---|---|
| 事業の担当 | 費用と成果の対応（1件あたり・利用者あたりの費用）、予算の額 |
| 財務の担当 | 配賦のルール、予算と予測、コミットの購入の承認 |
| 技術の担当 | 構成の見直し（止める・適正サイズ・種類の変更）、タグと自動化 |
| 中心のチーム | 見える化の基盤、分類と通知の設計、定期レビューの運営 |
REVIEW CADENCE見直しの頻度
頻度ごとに見るものと決める人を分ける
-
毎週
異常の通知を、その費用の持ち主が確かめる
Cost Anomaly Detection・予算のアラート
-
毎月
未分類の費用と、適正サイズの推奨を見直す
Cost Explorer・Cost Categories・Compute Optimizer
-
四半期
使用率とカバー率から、コミットを積み増すか決める
Savings Plans のレポートと購入の推奨
-
毎年
構成の方針と配賦の分類を見直す
アカウントの分け方・タグの規約・役割分担
要件が変わると、この体制の厚みも変わります。
| 条件 | 見える化 | 構成と契約 | 予算と運用 |
|---|---|---|---|
| 小さなチーム・数アカウント | アカウントを環境で分け、タグは最小限 | 止める・適正サイズを先に。コミットは Compute Savings Plans で小さく | 全体の予算と異常検知を1つずつ。月1回の見直し |
| 事業部が複数・数十アカウント | Cost Categories で事業部の分類、共有の費用は分割請求で按分 | 推奨を事業部ごとに見る。コミットは中心で買い、効果を配賦 | 分類ごとの予算とモニター。月次の見直しを事業部と |
| 期限つきのプロジェクト | プロジェクトのタグとアカウントで区切る | コミットは期間に収まる分だけ。スポットとサーバーレスで波を受ける | 予算アクションで超過を抑止 |
| 予算が厳しい | 未分類を先に減らす | 止める・消すと適正サイズで先に下げ、コミットは下限だけ | 予測でのアラートを早めのしきい値に |
一度下げた費用は、構成の追加とともに戻ります。コスト最適化は一度きりの削減の作業ではなく、分類と通知と見直しの頻度を決めて回し続ける設計です。
参照ソース
- Cost Optimization Pillar（AWS Well-Architected） — コスト最適化の柱の5つの領域（2026年9月時点）
- Practice Cloud Financial Management（Cost Optimization Pillar） — COST01 の持ち主と財務・技術の協力（2026年9月時点）
- COST03-BP03 Identify cost attribution categories（Cost Optimization Pillar） — 配賦の分類を先に決める考え方（2026年9月時点）
- Plan for data transfer（Cost Optimization Pillar） — COST08 のデータ転送のモデル化、VPC エンドポイントと NAT ゲートウェイの置き方（2026年9月時点）
- Organizing and tracking costs using AWS cost allocation tags（AWS Billing） — タグの2種類と有効化が要ること（2026年9月時点）
- Activating user-defined cost allocation tags（AWS Billing） — 有効化の対象として表示されるまで最大24時間（2026年9月時点）
- Organizing costs using AWS Cost Categories（AWS Billing） — Cost Categories のルール（2026年9月時点）
- Splitting charges within cost categories（AWS Billing） — 分割請求のルールで共有の費用を按分すること（2026年9月時点）
- What is AWS Compute Optimizer?（AWS ドキュメント） — 推奨の対象と機械学習による分析（2026年9月時点）
- Spot Instances（Amazon EC2 ユーザーガイド） — 最大90%の割引、2分前の中断通知、向く処理（2026年9月時点）
- Managing the lifecycle of objects（Amazon S3 ユーザーガイド） — ライフサイクルのルールと Intelligent-Tiering への移行（2026年9月時点）
- Savings Plans types（Savings Plans ユーザーガイド） — 4つの種類、Compute の最大66%と EC2 Instance の最大72%、適用の範囲（2026年9月時点）
- Announcing Database Savings Plans（What’s New） — Database Savings Plans の最大35%と対象サービス（2025年12月の発表）
- Reserved Instances for Amazon EC2 overview（Amazon EC2 ユーザーガイド） — EC2 では RI より Savings Plans を勧めていること（2026年9月時点）
- Deciding which Savings Plans to purchase（Savings Plans ユーザーガイド） — Purchase Analyzer とルックバックの期間（2026年9月時点）
- Using the Savings Plans coverage report（Savings Plans ユーザーガイド） — カバー率の定義（2026年9月時点）
- Using the Savings Plans utilization report（Savings Plans ユーザーガイド） — 使用率の定義（2026年9月時点）
- Managing your costs with AWS Budgets（AWS Cost Management） — 予算の種類、実績と予測のアラート、予算アクション（2026年9月時点）
- Detecting unusual spend with AWS Cost Anomaly Detection（AWS Cost Management） — モニターの単位、しきい値つきの通知、原因の候補（2026年9月時点）
