AWSはリソースを使えば使うほど料金体系が複雑になり、気づいたら月額が予算を大幅にオーバーしていた、という状況に陥りやすいクラウドです。
この記事では、AWSコスト最適化の3本柱であるCost Explorer（現状把握）・Savings Plans（予約割引）・スポットインスタンス（スポット価格）を使って料金を削減する実践的な手順を解説します。
「どの割引プランを選べばいいか」「Savings PlansとReserved Instancesの違いは何か」など、実務でよく迷う判断基準も整理します。
動作確認環境: AWS マネジメントコンソール・AWS CLI v2（2026年7月時点）。
この記事のポイント
・Cost Explorerのレコメンデーション機能でSavings Plans購入額の目安がわかる
・Compute Savings Plansは1年・前払いなしで最大66%割引、新規にはこれを選ぶ
・スポットインスタンスは最大90%割引、中断2分前通知をメタデータAPIで検知できる
・Reserved InstancesよりSavings Plansのほうが柔軟で新規購入に向いている
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
なぜAWSのコストは「気づいたら膨らんでいる」のか
AWSで料金が想定を超えて膨らむ主な原因は次の3つです。・オンデマンド価格を使い続けている：EC2・Fargateをオンデマンド価格のままにしていると、Savings Plansで削減できたはずのコストを全額支払い続けます。月数万円のEC2費用も、Savings Plansで最大66%削減できます
・停止忘れリソースが放置されている：開発・検証環境のEC2やRDSが週末・深夜も動き続けているケースが多く見られます。稼働時間の30～40%を削減するだけでも大きな効果があります
・データ転送コスト（Egress）が見えにくい：EC2からインターネットへのアウトバウンド通信やリージョン間転送料金は、Cost Explorerで確認するまで気づきにくいコストです
コスト削減は「原因を把握する → 削減手段を選ぶ → 適用して確認する」の順番で進めることが重要です。この順番を逆にしてSavings Plansを先に購入してしまうと、コミット過剰・過少のどちらかになり、期待した削減効果が出ません。
Step 1: Cost Explorerで現状のコスト構造を把握する
1. Cost Explorerの有効化とサービス別コストの確認
Cost Explorerは有効化後24時間で過去12か月分のコストデータが閲覧可能になります。有効化はマネジメントコンソールの「Billing and Cost Management」→「Cost Explorer」から1クリックで完了します。AWS CLIでサービス別の月間コストを取得するには、以下のコマンドを使います。
# サービス別コストをAWS CLI v2で取得する（2024年6月分の例） $ aws ce get-cost-and-usage \ --time-period Start=2024-06-01,End=2024-07-01 \ --granularity MONTHLY \ --metrics "UnblendedCost" \ --group-by Type=DIMENSION,Key=SERVICE \ --query 'ResultsByTime[0].Groups[*].{service:Keys[0], cost:Metrics.UnblendedCost.Amount}' \ --output table ----------------------------------------------------- | GetCostAndUsage | +---------------------+-----------------------------+ | service | cost | +---------------------+-----------------------------+ | Amazon EC2 | 2341.28 | | Amazon RDS Service | 891.56 | | Amazon S3 | 234.12 | | AWS Lambda | 12.34 | +---------------------+-----------------------------+
2. コスト配分タグでプロジェクト・環境別に分析する
Cost Explorerのデフォルト表示はサービス別（EC2全体・RDS全体）です。プロジェクト別・環境別（本番/開発/検証）のコストを把握するにはコスト配分タグを使います。設定手順は以下の通りです。
・手順1：EC2やRDSにタグを付ける（例: `Project: my-web-app`、`Environment: Production`）
・手順2：マネジメントコンソール「Billing」→「コスト配分タグ」→「ユーザー定義のコスト配分タグ」でタグキーを有効化する
・手順3：有効化後24時間でCost Explorerのグループ化条件にタグが使えるようになる
タグが整備されていないと「EC2費用が高い」とわかっても「どのプロジェクトが高いか」が分からず、削減施策を打ちにくくなります。リソース作成時にタグ付けを標準化するのが、長期的なコスト管理の基盤になります。
3. AWS Budgetsで予算超過アラートを設定する
Cost Explorerはあくまでプル型（自分から確認する）です。予算超過にプッシュ型で気づくにはAWS Budgetsを組み合わせます。# 設定済みのBudgetを確認する（account-idは実際の値に置換） $ aws budgets describe-budgets --account-id 123456789012 \ --query 'Budgets[*].{name:BudgetName, limit:BudgetLimit.Amount, unit:BudgetLimit.Unit}' ----------------------------------------- | DescribeBudgets | +-------+--------------+----------------+ | limit | name | unit | +-------+--------------+----------------+ | 500 | monthly-cost | USD | +-------+--------------+----------------+
Step 2: Savings Plansで計算可能なコストを削減する
1. Savings Plansの3種類と選び方
Savings Plansは「1年または3年のコミット（毎時の使用額）を約束する代わりに割引を受ける」プランです。3種類あります。・Compute Savings Plans：EC2・Lambda・Fargateに適用。インスタンスファミリー・リージョン・OS問わず割引が適用され、最大66%割引。新規購入には通常これを選ぶ
・EC2 Instance Savings Plans：特定のインスタンスファミリー・リージョン固定。最大72%割引だが、インスタンスタイプを変更した場合は別途購入が必要
・SageMaker Savings Plans：Amazon SageMaker専用（機械学習ワークロード向け）
新規でSavings Plansを購入するなら、Compute Savings Plansを選んでください。将来インスタンスタイプを変更しても、同じSavings Plansが適用され続けます。EC2 Instance Savings Plansは、特定のインスタンスファミリーを長期固定することが決まっている場合のみ検討します。
2. レコメンデーションAPIで購入額の目安を確認する
Savings Plansの購入額（コミット額）を感覚で決めると、コミット過剰（購入しすぎ）または割引ロス（少なすぎ）のどちらかになります。まずAWS CLIでAWSのレコメンデーションを確認しましょう。# 過去60日の使用実績から1年・前払いなしのCompute Savings Plansを見積もる $ aws ce get-savings-plans-purchase-recommendation \ --savings-plans-type COMPUTE_SP \ --term-in-years ONE_YEAR \ --payment-option NO_UPFRONT \ --lookback-period-in-days SIXTY_DAYS \ --query 'SavingsPlansPurchaseRecommendation.SavingsPlansPurchaseRecommendationSummary' { "EstimatedROI": "25.30", "CurrentOnDemandSpend": "3891.20", "EstimatedSavingsAmount": "1234.56", "EstimatedMonthlySavingsAmount": "308.64", "EstimatedOnDemandCostWithCurrentCommitment": "2856.64" }
3. 購入後の適用確認コマンド
Savings Plansを購入してから適用開始まで最長60分かかります。適用後は以下のコマンドで確認できます。# アクティブなSavings Plansを確認する $ aws savingsplans describe-savings-plans \ --states ACTIVE \ --query 'savingsPlans[*].{id:savingsPlanId, type:savingsPlanType, commitment:commitment, end:end}' [ { "id": "sp-0a1b2c3d4e5f67890", "type": "Compute", "commitment": "1.50", "end": "2025-07-01T00:00:00.000Z" } ]
AWSのコスト最適化設計を体系的に学びたい方には、以下のコースも参考にしてください。
＞＞ AWSコスト設計・上級コースの詳細はこちら
Step 3: スポットインスタンスで変動ワークロードを安くする
1. スポットインスタンスが向いているワークロード・向いていないワークロード
スポットインスタンスはAWSの余剰EC2キャパシティをオンデマンド比最大90%割引で利用できます。ただし需要増加時にAWSから2分前通知で中断されることがあります。向いているワークロード：
・バッチ処理・ETLパイプライン（途中で止まっても再実行できる）
・機械学習の学習ジョブ（チェックポイントがあれば途中から再開できる）
・CI/CDのビルド・テスト環境（1ジョブの実行時間が短い）
・ECS/EKSのワーカーノード（Graceful shutdownを実装済みの場合）
向いていないワークロード：
・本番Webサーバーの全台（中断されるとサービス停止につながる。オンデマンドとのMix構成が安全）
・セッション情報をローカルに持つステートフルアプリ（ElastiCache等の外部ストアを使うこと）
・RDS等のDBサーバー（マネージドサービスを使うこと）
2. スポット中断の2分前通知をメタデータAPIで検知する
スポットインスタンスが中断される2分前にEC2メタデータサービス（IMDS）に通知が届きます。この通知をポーリングして正常終了処理（Graceful shutdown）を実行するのが実務上の標準パターンです。# IMDSv2でスポット中断通知を確認する（検証サーバー上で実行） TOKEN=$(curl -s -X PUT "http://169.254.169.254/latest/api/token" \ -H "X-aws-ec2-metadata-token-ttl-seconds: 21600") curl -s -o /dev/null -w "%{http_code}" \ -H "X-aws-ec2-metadata-token: $TOKEN" \ http://169.254.169.254/latest/meta-data/spot/termination-time # 通常時（中断予告なし）→ HTTPステータス 404 が返る 404 # 中断2分前に通知が来た場合 → HTTPステータス 200 が返る 200
3. Mixed Instances PolicyでスポットとオンデマンドをMixする
スポットインスタンスだけで構成すると、AZ全体の供給不足時に全台が中断されるリスクがあります。EC2 Auto ScalingのMixed Instances Policyを使って、オンデマンド2台ベース＋それ以上はスポット80%という比率を設定するのが実務の標準パターンです。# Auto ScalingグループのMixed Instances Policy設定を確認する $ aws autoscaling describe-auto-scaling-groups \ --auto-scaling-group-names my-batch-asg \ --query 'AutoScalingGroups[0].MixedInstancesPolicy.InstancesDistribution' { "OnDemandAllocationStrategy": "prioritized", "OnDemandBaseCapacity": 2, "OnDemandPercentageAboveBaseCapacity": 20, "SpotAllocationStrategy": "capacity-optimized", "SpotMaxPrice": "" }
コスト最適化の実務Tips
Reserved InstancesとSavings Plansはどちらを選ぶか
2019年以降、AWSはSavings Plansを主力の割引プランとして位置づけています。それでもReserved Instances（RI）は一定のシェアがあるため、違いを整理します。・Reserved Instances：特定のインスタンスタイプ・AZ・OSを固定。インスタンスタイプを変更したい場合は別途RIを購入または変換する手続きが必要。RDS・ElastiCacheはRIのみ対象
・Savings Plans（Computeタイプ）：毎時のコミット額（ドル）を約束する代わりに、EC2・Lambda・Fargateのインスタンスタイプ・リージョン・OS問わず割引が適用される
新規EC2購入なら迷わずCompute Savings Plansを選んでください。既存RIが有効期限切れを迎えるタイミングでSavings Plansに切り替えるのが現実的です。RDSのコスト削減はSavings Plans対象外なので、Reserved DBインスタンスを別途活用します。
未使用リソースの自動停止（Lambda＋EventBridge）
開発・検証環境のEC2を夜間・週末に自動停止するだけで、EC2コストを30～50%削減できる事例があります。以下は `Environment: Dev` タグのEC2を自動停止するLambda関数の基本形です。# "Environment: Dev" タグのEC2を自動停止するLambda（Python / boto3） import boto3 def lambda_handler(event, context): ec2 = boto3.resource('ec2', region_name='ap-northeast-1') filters = [ {'Name': 'tag:Environment', 'Values': ['Dev']}, {'Name': 'instance-state-name', 'Values': ['running']} ] instances = list(ec2.instances.filter(Filters=filters)) if not instances: return {'stopped': 0} ids = [i.id for i in instances] ec2.instances.filter(InstanceIds=ids).stop() return {'stopped': len(ids), 'instance_ids': ids}
よくある落とし穴と対処法
Savings Plansを購入したのにコストが期待ほど下がらない場合は、以下の原因を確認してください。・コミット額が少なすぎる：実際のオンデマンド使用量に対してコミット額が小さいと、残りのコストはオンデマンド価格のままです。Cost ExplorerのSavings Plans「カバレッジレポート」でカバレッジが80%未満なら追加購入を検討します
・RDSやElastiCacheはSavings Plans対象外：Compute Savings PlansはEC2・Lambda・Fargateにのみ適用されます。RDSのコスト削減はReserved DBインスタンスを別途購入する必要があります
・スポット中断の原因が不明：CloudTrailで `StopInstances` イベントを確認します。`stateTransitionReason` が `Server.SpotInstanceShutdown` ならスポット中断です。`Server.InsufficientInstanceCapacity` ならキャパシティ不足なので、`SpotAllocationStrategy: capacity-optimized` への切り替えを検討します
# スポット中断インスタンスをCloudTrailで確認する（過去7日間） $ aws cloudtrail lookup-events \ --lookup-attributes AttributeKey=EventName,AttributeValue=StopInstances \ --start-time "$(date -d '7 days ago' --iso-8601=seconds)" \ --query 'Events[?contains(CloudTrailEvent, `SpotInstanceShutdown`)].{time:EventTime, resource:Resources[0].ResourceName}' [ { "time": "2024-06-14T02:15:30+00:00", "resource": "i-0a1b2c3d4e5f67890" } ]
本記事のまとめ
AWSのコスト削減を進める際の3ステップと主要ポイントをまとめます。| ステップ | 施策 | ポイント |
|---|---|---|
| 1. 把握 | Cost Explorerでサービス別コストを確認 | EC2が高い → Savings Plans優先。Egress高い → CloudFront・VPCエンドポイント検討 |
| 2. 固定費削減 | Compute Savings Plansを購入 | レコメンデーションAPIで購入額を算出。1年・前払いなしで最大66%割引 |
| 3. 変動費削減 | スポットインスタンスを活用 | 最大90%割引。バッチ・CI/CD・ML学習ジョブが主な対象 |
| 追加Tips | 未使用リソースの自動停止 | Dev環境を夜間停止するだけで30～50%削減できる事例あり |
| RDS削減 | Reserved DBインスタンスを購入 | Savings Plans対象外。Reserved DBインスタンスで最大69%割引 |
Cost Explorerの確認を習慣化し、Savings Plansのカバレッジレポートを月1回見直すだけで、AWSコストの最適化は着実に進みます。スポットインスタンスはGraceful shutdownの実装が必須なので、まずは重要度の低いワークロード（開発・CI/CD）から段階的に適用してください。
AWSのコスト最適化設計をさらに深く学びたい方は、以下もご覧ください。
・＞＞ AWSコスト設計・上級コースの詳細はこちら
・＞＞ AWSをはじめて学ぶ方はこちら（入門LP）
AWSのコスト削減も「Linuxサーバーの設計・構築の型」を知っている人が最速で動ける
Savings PlansやスポットインスタンスはAWSコンソールから設定できても、「なぜこの設計にするか」を説明できるかどうかで現場での信頼が変わります。
現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、『Linuxサーバー構築入門マニュアル（図解60P）』を完全無料でプレゼントしています。
「独学の時間がもったいない」「プロから直接、現場の技術を最短で学びたい」という本気の方には、2日で実務レベルのスキルが身につく【初心者向けハンズオンセミナー】も開催しています。
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
登録10秒／合わなければ解除3秒 ／ 詳細はこちら
この記事を書いた人
宮崎 智広（みやざき ともひろ）
株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。
趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。
- 前のページへ：AWS Organizationsでマルチアカウントを設計する方法｜OU・SCP・一括請求によるアカウント統制入門
- この記事の属するカテゴリ：AWS(Amazon Linux)へ戻る
無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は1分、解除もいつでも可。
登録無料・いつでも解除できます