【FinOps入門】AWSコスト削減7ステップ：月6万→2万の実録

AWSの請求額を見て「なぜこんなに高いのか」と感じたことはないだろうか。

筆者もかつて、誰も使っていない開発環境のAWS請求が月6万円に膨らんでいることに気づいた。調査してみると、役割を終えたEC2インスタンスが起動したまま、テスト用に立てたRDSが本番並みのスペックで動き続けていた。3週間かけてリソースを整理した結果、月6万円→月2万円（67%削減） を実現できた。

この記事では、その手順をFinOps的な視点で体系化し、開発環境の見直しから本番環境のコミットメント割引まで使える7ステップで解説する。

この記事の対象読者

• AWSの請求額が増え続けているが何から手をつければいいかわからない
• 「誰かが作った放置リソース」が混在していると感じているインフラ・バックエンドエンジニア
• Reserved Instances / Savings Plansをまだ使ったことがなく概念から理解したい
• 社内でコスト削減を推進しようとしているが作業時間が確保できない

FinOpsとは何か

FinOps（ファイナンシャルオペレーション）とは、クラウドの財務管理と運用を組織横断で実践するフレームワークだ。2021年に設立されたFinOps Foundationが標準化を進めており、AWS・Google Cloud・Azureすべてに適用できる。

一言で言えば「クラウドコストを、コードを書くのと同じくらい真剣に管理する文化」だ。FinOpsの実践サイクルは3フェーズで構成される。

1. Inform（見える化） — コストを誰が・何に・いくら使っているかを把握する
2. Optimize（最適化） — 無駄を削除し、リザーブド購入で単価を下げる
3. Operate（運用） — 月次レビューで継続的に改善する

このサイクルを月次で回し続けることが、AWSコスト管理の本質だ。一度だけやって終わりにするのではなく、習慣として組み込むことが大切だ。

【実録】月6万→2万の削減ができた理由

筆者が担当したプロジェクトでは、開発環境のAWSコストが月約6万円に達していた。サービス構成を調べると、以下のような状態だった。

• 旧フェーズで使ったEC2インスタンスが3台起動したまま放置
• RDSが db.r5.xlarge（本番相当のスペック）で開発環境に使われていた
• 誰も参照していないCloudWatchのカスタムメトリクスが大量に蓄積
• 開発用S3バケットにテストデータが数GBたまったまま

これらを3週間で整理した結果、月2万円（67%削減）を達成した。削減の9割はRDSのダウンサイジングと未使用EC2の停止で実現できた。

施策別の削減内訳は以下のとおりだ（概算）。

この経験から言えることは「まず現状を把握しないと、どこに手をつけるべきかわからない」という当たり前の事実だ。次のセクションから7ステップに沿って手順を解説する。

STEP1: Cost Explorerで現状を可視化する

コスト削減の第一歩は、AWS Cost Explorerでどのサービスにいくらかかっているかを把握することだ。

Cost Explorerを開く: AWSマネジメントコンソール → 右上の「アカウント名」→ Billing and Cost Management → Cost Explorer

初めて開くと有効化を求められる。有効化後、過去12ヶ月のコストグラフが表示される。

見るべき3つのレポート

1. サービス別コスト内訳

グループ化条件を「Service」に変更すると、EC2・RDS・CloudFront・Lambda等どのサービスが何円かかっているかが一覧で見られる。最初にここを確認して「どこが高いのか」を把握する。

2. 日次コストグラフ

突然コストが跳ね上がった日がないかを確認する。急増した日に何をデプロイしたかと照合することで、意図しない大型リソース作成を発見できる。

3. Right-sizing推奨事項（適切なサイズ設定）

Cost Explorer の左メニュー「推奨事項」→「適切なサイズ設定の推奨事項」を開くと、AWSが「このEC2・RDSはスペックを下げても問題ない」と判断したリソース一覧が表示される。これがそのままアクションリストになる。

AWS Budgetsで上限アラートも同時に設定する

可視化と並行して、予算超過の通知も設定しておこう。

設定手順: Billing and Cost Management → Budgets → 「予算を作成」

予算タイプ: コスト予算
期間:       毎月
予算額:     ¥50,000（想定コストの120%に設定）
 
アラート①: 実際のコストが予算の80%を超えたとき → メール通知（警告）
アラート②: 実際のコストが予算の100%を超えたとき → メール通知（緊急）

これを設定しておくだけで「気づいたら先月の2倍になっていた」という事態を防げる。

STEP2: 未使用・放置リソースを棚卸しする

Cost Explorerでコストの全体像が見えたら、次は放置リソースを探す。これが最もコストパフォーマンスの高い施策だ。

特別なツールは不要で、AWSコンソールを一通り見ていくだけで発見できる。

棚卸しチェックリスト

棚卸しの進め方

1. 上記リソースを一覧化する（スプレッドシートかNotionで管理）
2. 担当者に「このリソース、まだ使っていますか？」と確認する
3. 使っていないリソースはスナップショットを取ってから削除する（復旧用）
4. 削除後1週間問題なければ、スナップショットも削除する

STEP3: RDS/EC2のインスタンスサイズを適正化する

棚卸し後に最もインパクトが大きいのが、インスタンスサイズの見直しだ。

筆者の経験でも、RDSのダウンサイジングが削減額の4割以上を占めた。

なぜ過剰スペックになるのか

理由はシンプルだ。「最初に構築するときはバッファを持って大きいインスタンスを選ぶ」からだ。

プロジェクト初期は負荷予測が難しく、スペックを大きめにするのは悪くない判断だ。問題はその後、定期的に見直されないまま放置されることにある。本番でもないのに db.r5.xlarge の開発用RDSが動き続けているのは、よくある光景だ。

RDSの適正サイジング手順

1. 過去2週間のCPU・メモリ使用率を確認する

RDS → 対象のDBクラスター → 「モニタリング」タブ

過去14日間のCPU使用率を見る。平均10%以下であれば、インスタンスタイプを1〜2段落とせる可能性が高い。

2. 開発・本番で適切なインスタンスタイプを選ぶ

（料金はOn-Demand、2026年5月時点の概算）

開発環境が db.r5.xlarge（月約¥63,000）で動いているなら、db.t3.medium（月約¥12,000）に変更するだけで月5万円以上の削減になる。

3. Cost Explorerの推奨事項を参照する

AWS Compute Optimizer（Cost Explorerから連携）がインスタンスタイプを推奨してくれる。「リスクが低い」と判定されたものから優先的に対応しよう。

EC2の適正サイジング手順

AWS Compute Optimizerを使う:

1. AWS Compute Optimizer → 「EC2インスタンス」を選択
2. 推奨事項の「リスクが低い（LOW）」を優先的に確認する
3. 削減インパクト（月額）が大きい順にソートして作業する

STEP4: Reserved Instances / Savings Plansで割引を固定する

放置リソースの削除とサイジング最適化が終わったら、次はコミットメント割引で単価を下げる。これが「使い続けるリソースを安くする」施策だ。

Reserved Instances（RI）とは

1年または3年の使用をコミットすることで、On-Demand（従量課金）に比べて最大75%割引になる。購入オプションによって割引率が変わる。

Savings Plansとは

RIより柔軟なコミットメント割引だ。「1時間あたりXドルを使う」とコミットする代わりに割引を受ける。

2026年のベストプラクティス

• EC2メインで、インスタンスファミリーを変える可能性がある → Compute Savings Plans
• RDS・ElastiCacheも含めてコストを固定したい → Reserved Instances（各サービス個別RI）
• インスタンスファミリーをロックしてでも最大割引したい → EC2 Instance Savings Plans

2026年時点の推奨は「Compute Savings Plansをメインに使い、RDS・ElastiCache等のデータ層にはRIを使う」とされている。

購入前の3つの注意点

1. 必ず3ヶ月以上の利用実績を確認してから購入する — 3ヶ月未満のサービスに1年RIを買うのはリスクが大きい
2. Cost Explorerの「Savings Plans推奨事項」を参考にする — 過去の使用量から最適な購入量を自動計算してくれる
3. 開発環境には基本的にRIは不要 — 夜間・週末停止を前提にする開発環境では、RIの使用率が下がり逆に損することがある

STEP5: Instance Schedulerで夜間・週末を自動停止する

開発環境のEC2・RDSは24時間365日動かす必要はない。夜22時〜朝8時、土日に停止するだけで理論値40〜50%の削減になる。

AWS Instance Schedulerの設定

AWSが提供するオープンソースソリューションで、CloudFormationスタックを1つデプロイするだけで使える。

対象インスタンスに以下のタグを付けるだけで、自動起動・停止が有効になる。

タグキー:   schedule
タグ値:     dev-office-hours   ← DynamoDBで定義したスケジュール名

スケジュールは「平日 9:00〜22:00 のみ起動」など自由に設定できる。

Lambda + EventBridgeで自前実装する方法

Instance Schedulerの導入が手間であれば、以下のLambda関数をEventBridgeで定期実行するシンプルな方法もある。

import boto3
 
def lambda_handler(event, context):
    ec2 = boto3.client('ec2', region_name='ap-northeast-1')
 
    # タグ "Environment: dev" がついたインスタンスを停止
    instances = ec2.describe_instances(
        Filters=[
            {'Name': 'tag:Environment', 'Values': ['dev']},
            {'Name': 'instance-state-name', 'Values': ['running']}
        ]
    )
 
    instance_ids = [
        i['InstanceId']
        for r in instances['Reservations']
        for i in r['Instances']
    ]
 
    if instance_ids:
        ec2.stop_instances(InstanceIds=instance_ids)
        return {'stopped': instance_ids}
    return {'stopped': []}

EventBridgeのcron式で「平日22:00停止 / 平日8:00起動」を設定すれば、作業時間帯のコストのみに絞れる。

停止: cron(0 13 ? * MON-FRI *)   # JST 22:00（UTC 13:00）
起動: cron(0 23 ? * SUN-THU *)   # JST 08:00（UTC 23:00）

STEP6: タグ設計でコストの責任を明確にする

コスト削減を「一度やれば終わり」ではなく継続的に行うには、誰がどのリソースにいくら使っているかを構造的に見えるようにする必要がある。そのための仕組みがタグ設計だ。

最低限設定すべきタグ

Environment: dev / staging / prod
Service:     api / frontend / batch / monitoring
Team:        backend / infra / ml
Owner:       miyawaki@example.com（担当者のメールアドレス）

「Owner」タグは特に重要だ。リソースの担当者がわかれば、棚卸し時に直接確認できる。

Cost Allocationタグの有効化

Billing → コスト配分タグ → 上記タグを選択して有効化

有効化後48時間でCost Explorerにタグ別コストが反映される。これにより「Environment: dev のコストが月いくら」「Team: ml のコストが月いくら」が一目でわかるようになる。

STEP7: 月次コストレビューを習慣化する

筆者が最も後悔していることは「月次でコストを確認する習慣がなかったこと」だ。

AWSのコスト肥大化の多くは「作って放置」から生まれる。月1回でもコストを確認していれば、未使用リソースを3ヶ月以内に発見できる。

月次レビューのチェックリスト（15分で完了）

□ Cost Explorerで先月比のコスト増減を確認する
□ 前月比+10%以上のサービスを調査する
□ Right-sizing推奨事項に新しいリソースが増えていないか確認する
□ Savings Plans / RIのカバレッジ率を確認する
□ Budgetsのアラートが発報していないか確認する
□ 新しいリソースにタグが付いているか確認する

カバレッジレポートの確認方法

Cost Explorer → 「Savings Plansカバレッジ」 で、購入済みのSavings Plansがどの程度の使用量をカバーしているかを確認できる。

• カバレッジ率 80%以上 → 適正に管理できている
• カバレッジ率 60%未満 → 追加購入または既存リソースの見直しを検討する

FinOps導入ロードマップ

初めてFinOpsに取り組む場合、3〜6ヶ月かけて段階的に進めることを推奨する。

FinOpsを社内で推進するためのコツ

コスト削減の技術的な手順はわかった。しかし実際のボトルネックは技術より「時間確保と合意形成」にあることが多い。

筆者の経験でも、コスト削減作業のための時間確保が最も難しかった。機能開発と運用保守が優先され、「後でやろう」とずるずる後回しになる。

経営・マネジメント層への説明の仕方

コスト削減を提案するとき「もったいないから」という言い方は通らない。

効果的な言い方はこうだ。

「会社の利益を上げる方法は2つしかありません。売上を増やすか、コストを下げるかです。 現状、月6万円かかっている開発環境コストを2万円に下げられる見込みがあります。 3週間の作業で年間48万円の削減効果です。一度やれば毎月効果が続きます。」

数字で語ることで「コスト削減 = 地味な裏作業」から「ビジネスに直結する投資対効果の高い施策」に変わる。

時間確保の現実的なアプローチ

AWSコスト最適化に役立つ公式ツール一覧

AWSを体系的に学びたい方へ

FinOpsはAWSの基礎知識があるほど実践しやすくなる。コスト最適化の各手法（RI・Savings Plans・Spot活用）はAWS認定試験の出題範囲とも重なっており、資格勉強がそのまま実務に直結する。

AWS認定資格の学習ロードマップは「クラウドエンジニアの学習ロードマップ2026」でも解説している。

よくある質問（FAQ）

Q1. Reserved Instancesを買ったが使い切れなかった場合はどうなりますか？

使い切れなかったRI分は費用が発生したまま無駄になる。ただし、スタンダードRIはAWSマーケットプレイスで第三者に売却できる。コンバーティブルRIは売却はできないが別のインスタンスタイプに交換できる。このリスクを避けるため、最初は1年・一部前払いの小さな単位から始めることを推奨する。

Q2. Savings PlansとRIは同時に使えますか？

使える。AWSはまずSavings Plansの割引を適用し、その後に合致するRIの割引を適用する。ただし重複購入による無駄が生じやすいため、両方を使う場合はCost Explorerの推奨事項を見ながら管理することを推奨する。

Q3. マルチアカウント（AWS Organizations）でのコスト管理はどうすればよいですか？

Organizations内ではSavings PlansとRIの割引がアカウント間で共有される（デフォルト設定）。コスト配分は管理アカウントのCost Explorerで一括管理できる。各チームや機能ごとにAWSアカウントを分けていれば、タグなしでも「アカウント別コスト」として自然に分類できるのでおすすめだ。

Q4. 外部のFinOpsツール（CloudHealth・Cloudabilityなど）は必要ですか？

月間コストが50〜100万円未満であれば、AWS純正ツール（Cost Explorer + Budgets + Compute Optimizer）で十分対応できる。外部ツールはマルチクラウド管理・詳細なチャージバック・カスタムアラートなどが必要になった段階で検討するとよい。

Q5. Spotインスタンスはコスト削減に使えますか？

On-Demandと比べて最大90%削減できるが、AWSの都合で突然停止される可能性がある。バッチ処理・CI/CDビルド・機械学習のトレーニングジョブなど「途中で止まっても再起動できる」ワークロードには非常に有効だ。本番のWebサーバーには使いにくいが、開発・テスト環境には積極的に活用できる。

Q6. コスト削減の作業時間が取れない場合はどうすればよいですか？

まず「確認するだけ」から始めるのがおすすめだ。Cost Explorerで現状を把握するだけでも価値がある。Budgetsアラートを設定しておけば「知らぬ間に増えていた」を防げるので、最初の15分だけでも投資する価値がある。その後の削減作業は、最初の確認で見えた「削減インパクト×時間」の試算を上司に見せて時間を確保してもらうのが現実的だ。

まとめ：今日からできるアクション

AWSコスト最適化は、特別な知識がなくても今日から始められる。

• 今日（10分）: Cost Explorerを開き、サービス別コストを確認する
• 今日（15分）: Budgetsで月次アラートを設定する
• 今週（1〜2時間）: 未使用リソースのリストを作り、担当者に確認する
• 今月: Right-sizing推奨事項から1つアクションし、削減実績を作る

これだけで、多くのケースで月20〜30%のコスト削減が見込める。

筆者の経験では、最初の「月4万円削減」という実績が社内での信頼につながり、その後のインフラ改善提案を通しやすくなった。コスト最適化は技術スキルとビジネス感覚の両方を示せる、エンジニアにとって価値の高い施策だ。

インフラ設計の観点でコストを意識したい方は、「Terraform × AWS IaCガイド」も合わせて読んでほしい。コードとしてインフラを管理することで、タグ設計の統一やリソースの棚卸しがはるかにやりやすくなる。

まず小さく始め、習慣として月次レビューを続けることが、長期的なFinOps実践の鍵だ。