AWSのコスト削減・最適化手法とコスト管理の勘所

本記事では私が行ってきたAWSでのコスト削減、最適化の手法とコスト管理全般に関わることを記載します。
執筆時点(2025/11)の情報となりますので記事閲覧日によっては新しいサービスや機能改修により記事内容が適切ではない可能性がございますのでご留意ください。

不要・余分なコスト発生の調査方法

コスト削減の第一ステップとしてまず対象のAWSアカウントでどのようなコストが発生しているか確認する必要があります。
あらかじめ予想・見積もりしていたコストなのか、予定外のコストなのかを特定及び分析し、コスト削減・最適を進めてください。

Cost Explorerでの確認

AWSマネージドコンソールにログインし、画面左上部の検索窓に「Cost」と入力し、サービス一覧から[Billing and Cost Management]を選択してください。

左ナビゲーションから[Cost Explorer]を選択してください。

Cost Explorerの表示は過去半年のコストが月別で表示されます。
※個人の検証環境のため利用金額が少なく、わかりにくくすいません。。。

半年分の傾向を見るにはデフォルトの画面でもいいですが、詳細に分析するには適さないため、日付を1ヶ月ほどに絞り、粒度を日別にしてください。
また、ディメンションが[なし]になっていれば[サービス]に変更してください。

画面下部に日別でサービスごとの料金が表示されるため表示された金額を確認し、まずはどのサービスで料金がかかっているかを把握します。
日別で料金が表示するため、特定日のみ料金が跳ね上がっているなども合わせて確認します。

サービスを特定したら更に深堀りを行います。
使用タイプでフィルターし、サービスのどの箇所で料金が発生しているかを確認します。

下記はスナップショットの日別毎でフィルターしています。
APN1-EBS:SnapshotUsageを選んでおり、{リージョン}-{サービス名}などリージョン毎にフィルターも可能です。

また、使用タイプグループでもフィルターが有効です。
EC2: Data Transfer - Inter AZなどはAZ間通信料のコストを確認ができますのでネットワーク通信料の更にどの箇所で料金が発生しているかなど分析することが可能です。

コスト削減・最適化について

前記の手順で大まかにどのサービスのコストが高いか把握できればコストが高いサービスからコスト削減・最適化行うとより効果的になります。
以下にコスト削減・最適化の手順や方針を記載しますので適意ご自身のAWSアカウント、保守を行っているお客様のAWSアカウントのコスト利用状況と合わせて試していってください。

EC2の自動停止、インスタンスサイズの自動変更

• EventBridgeなどを利用して利用していない休日または夜間は停止する。
• EventBridge+SSMを利用して日中は性能を必要としないバッチサーバなどのインスタンスサイズを下げる。
• オートスケーリングで自動停止、縮小なども可能。

スポットインスタンスの活用

• stg環境やdev環境などのEKSクラスターなどで利用するノードにスポットインスタンスを利用し、コスト削減を実施する。最低必要台数はオンデマンドで稼働し、余剰ノードをスポットインスタンスで利用するなど行う。prd環境は稼働できないリスクがあるためスポットインスタンスは利用しない。

RIの適用

• 停止できない、スポットインスタンスなど利用できない24時間365日稼働するEC2はRIなどを利用してコストダウンを行う。ただし最低でも1年間利用する前提のシステムのみ適用する。
• RDSは部分的なRI適用ができるため、世代、タイプが決まっていれば25%や50%などの購入ができるためサイズが変更になる可能性のインスタンスも最小サイズくらいでRIの購入をしておく。(例:r7.largeのRIを購入するとr6.xlargeの50%が適用される)
• キャパシティ予約も行いたい場合はRIが有効。
• [Billing and Cost Management]の左ナビゲーション内にある[予約]→[推奨事項]を開くと利用しているインスタンスなどに応じて購入推奨台数などが表示されます。

SPの適用

• ECSやLambdaなどはSPを適用する。SPの選択肢があるアカウントはEC2もRじゃなくてSP適用でまとめるのもありだと思います。
• 1時間あたりの料金コミットで購入を行う必要があるので1時間$1〜の指定なのでECS、Lambdaなどがメインであれば過去の料金を確認して下回らないように注意が必要です。
• [Billing and Cost Management]の左ナビゲーション内にある[Savings Plans]→[推奨事項]を確認すると推奨購入コミット金額が表示されますので参考にしてください。[購入アナライザー]を実行することで1時間あたりの料金分析もしてもらえますので合わせてご利用ください。
  

EBSのタイプ変更

• EBSのタイプをgp2からgp3に変更することでコストダウンを図る。gp3リリース前に作成したEBSはgp2のまま稼働しているケースがあるため、IOPSやスループット値が要求されないEBSはgp3に変更する。gp3はUSD 0.096/GB、gp2はUSD 0.12/GB。
  • ログ保管用途やバックアップファイル保管用途であればst1やsc1などHDDタイプに変更する。sc1はUSD 0.018/GBなのでgp2に比べて1/10くらいのコストダウンになる。
  • sc1はIOPSは250が最大ですが、スループットは250MiBと結構速い速度が出るため読み書きを頻繁にしないディスクであればsc1でも十分の場合があります。
  • ただし、ルートボリュームやCドライブなどブートボリュームでは利用できませんのでご注意ください。
    
    https://docs.aws.amazon.com/ja_jp/ebs/latest/userguide/ebs-volume-types.html

リージョン間コピーをしているEBSスナップショットの暗号化解除

EBSの暗号化をするケースはセキュリティ要件でよくあるかと思いますが、DRなどの目的で他のリージョンにスナップショットをコピーしている場合は注意が必要です。
EBSを暗号化している場合、データ転送量が圧縮されずディスクフルサイズの転送量となります。リージョン間転送量が高い場合は暗号化済みEBSのスナップショットをレプリケーションしていないか見てください。

ログ保存を　CloudWatch LogsからS3にする。

• CloudWatch Logsのログ保管はUSD 0.76/GBと高額。S3の場合はUSD 0.0047/1,000リクエストと安価のため視認性や検索性の要件が厳しくない場合はS3の保管を優先する。
• CloudWatch Logsの要件が外せない場合は低頻度アクセス(USD 0.38/GB)などを検討する。

CloudWatch Logsの自動削除

• 保持期間が[失効しない]になっている場合、長期でログが保存されている可能性があります。[CloudWatch]→[ロググループ]を開き、歯車マークを選択して[保持されているバイト数]をオンにして保持されている容量を確認してください。
• 肥大化している場合は手動で削除が保持期間を短くして最適化を行ってください。
  

VPC Flow logを拒否だけ取得する

• EKSなどpod間の通信が多く、VPC Flow logが肥大化している場合は拒否だけ取るようにする。
• 取得先がCloudWatch Logsになっている場合はS3などに変更する。

CloudTrailを複数取得している場合は1個にする

• CloudTrailの証跡を複数取得設定している場合は2個目の証跡から料金が発生しているため、1個に絞る。
• セキュリティ要件などで自AWSアカウントと監査用AWSアカウントどちらにも取得する必要があるなどの要件がある場合はAWS Organizationsなどで一括で管理・集約なども検討する。

CloudWatchメトリクスの読み取りコストの削減

• 請求書明細の[metrics requested using GetMetricDataAPI {Region name}]が高騰している場合、Datadog、NewRelic、Splunkなどのオブザビリティサービスが影響している可能性があります。取得しているリージョン、取得するサービス、取得頻度などを確認し、余剰にメトリクスデータを取得している場合は調整をしてください。

S3の不要ファイル削除、ストレージクラスの変更

• 不要なデータがないかチェックする。[Amazon S3]→[Storage Lens]を開くと各バケットの容量などを一括で確認できます。
• ログなどで長期保管が不要であればライフサイクルポリシーを設定して削除する。
• バックアップファイルの保管などの用途の場合、バージョニングを設定することで過去すべてのバックアップファイルが残ってしまう場合があるため、バージョニングを適切に設定する。
• アクセス頻度が低いファイルはGlacierなどコストが安いストレージクラスに変更する。

VPCエンドポイントの削除

• VPCエンドポイントを削除し、Nat Gateway経由でアクセスをさせる。
  • セキュリティ要件などがないかは確認する。
  • 変更時は通信断が発生していないか確認する。

Nat Gatewayの共通化

• 共通用VPCを立ち上げ、共通用のNat Gatewayを設置、各VPC間をTransit Gatewayで接続し、複数のVPCから共通用VPCのNat Gatewayを使ってインターネットアクセスをさせる。
  • 各VPCで立ち上げているNat Gatewayのコストを削減できる。
  • 共通用のNat Gatewayから集約アクセスさせるため、特定のIPからのアクセスで管理がしやすい。
  • Network Firewallで集約してトラフィック制御したい場合も同様のアーキテクチャで構成できる。
  • Route53 Resolverも共通化できる。
  • ※ただし通信量が多い場合、Transit Gatewayの通信量のほうが高くなるケースもあるのでご注意ください。

EIPの解放

• 不要なEIPが残っている場合は解放しましょう。2024年2月から使っているEIPも課金されるようになりましたので極力使わない、使用しないEIPは解放するようにしましょう。

AZ間通信料の削減

• 意外と高いのがAZ間通信料金です。USD 0.01/GBかかるので通信量が多いシステムの場合、コストが肥大化します。
  • EC2→RDSなどデータベースの書き込みが多い場合、ライターインスタンスをEC2と同じAZに合わせる。
  • 3AZ使っている場合、可用性の要件で3AZ指定がない場合は2AZなどにする。
  • EKSなどAZ間通信量が多いシステムはistioやAWS Load Balancer Controllerなどで同じAZ間で通信させるようにチューニングする。

コスト管理について

コスト通知設定など

日々のコスト発生などを管理するために毎日チェックする工数は取れないと思いますので以下のような設定をしてコストの異常値や指定した予算超過などをいち早く察知することができます。

Cost Anomaly Detection

[請求とコスト管理]→[コスト異常検出]を選択し、Cost Anomaly Detectionを有効化しておくと普段利用されていないサービスが利用されている、過去の利用平均金額から一脱するようなコストが発生していることに気づく事ができます。
定量的な金額や変動%数などで通知設定ができるため、適意チューニングする必要があります。

予算設定を行う

[請求とコスト管理]→[予算]内で予算設定を行い、80%などで通知するなどアラート設定をしておく。

CloudWatchで[EstimatedCharges]のメトリクス通知でアラーム設定をして指定した料金を超えると通知なども可能です。

コスト分析のための準備

どのシステムがどれくらいコストが発生しているかなど収支分析やコスト分析をするために以下の設定を行うことをおすすめします。

コストタグ設定

Cost ExplorerでフィルターができるようにKeyに[cost]Valueに[app名]などを入れてフィルターができるようにしましょう。

ECS/EKSのコスト配分データ分割

[請求とコスト管理]→[コスト管理の設定]で有効化できます。コンテナ、Pod単位でのコスト内訳が詳細に分析可能です。

予期しないコストが発生していることに気づいて冷や汗が止まらないことになる前に事前のコスト通知や日頃からのコスト管理をおすすめします！
ただ注意点としてCost Explorerへの表示が2日後とかになるのでリアルタイムでのコスト状況は確認できないためご注意ください。