「AWS Cost Explorer」と「AWS Budgets」でインフラのコストを管理しよう

はじめに

前回(第22回)では、Container Insightsダッシュボードを活用した監視のベストプラクティスを学びました。ノードのメモリやディスク使用率、Podの再起動回数、CPUスロットリングなど、Kubernetes特有の問題を早期に検知する方法を解説しました。

これまでの回で、EKSクラスターの構築から監視体制まで一通り整備できました。しかし、運用フェーズでは監視と並んで重要な課題があります。それが「コスト管理」です。

構築したEKSクラスターやその他のAWSリソースは、稼働している限りコストが発生します。そのため、予想外のコスト増加を早期に検知し、無駄なリソースを削減する仕組みが必要です。特に開発環境と本番環境を分けている場合、例えば以下のような問題の発生が考えられます。

• 開発環境で試験的に作成したリソースを削除し忘れてコストが増加
• インスタンスタイプが過剰で、無駄なコストが発生
• 予算を超過したことに気づかず、月末に請求書を見て驚く

本記事では「AWS Cost Explorer(以下、Cost Explorer)」と「AWS Budgets」を使った基本的なコスト管理の方法を解説します。Cost Explorerでコストを可視化し、環境ごとのコスト内訳を分析して予算アラートを設定することで、コストの透明性を確保できるようになります。

Cost Explorerとは

Cost ExplorerはAWSの利用コストを可視化し、分析するためのツールです。過去のコストデータを確認したり、将来のコストを予測したり、予算を設定してアラートを受け取ったりできます。

Cost Explorerを使うと、以下のような情報を簡単に確認できます。

• 先月のAWS利用料はいくらだったか
• どのサービスにコストがかかっているか
• このまま利用を続けると来月いくらになるか
• 環境(dev/prod)ごとのコスト内訳はどうなっているか
• 特定のタグを持つリソースのコストはいくらか

運用フェーズになると、これらの情報が非常に重要になります。予算計画、コスト最適化、経営層への報告など、さまざまな場面でCost Explorerのデータを活用できます。

Cost Explorerは初回利用時に有効化する必要があります。有効化の手順は後述しますが、有効化後にデータが表示されるまで24時間程度かかる場合があります。なお、Cost Explorerのコンソール利用自体は無料ですが、APIを使ってデータを取得する場合は1リクエストあたり$0.01の料金が発生します。

Cost Explorerの基本的な使い方

コストダッシュボードへのアクセス

1. AWSマネジメントコンソールにログインし、右上のアカウント名をクリックして「請求とコスト管理」を選択します。左側のメニューから「Cost Explorer」をクリックします。
2. 初回アクセス時は「Cost Explorerの起動」ボタンが表示されます。ボタンをクリックして有効化すると過去のコストデータの集計が開始され、24時間程度でダッシュボードにデータが表示されるようになります。
3. 有効化が完了すると、初期状態では過去6か月間のコストが月ごとにグラフ表示されます。グラフの下にはサービスごとのコスト内訳が表示されます。
   

サービスごとのコスト内訳

第15回〜第18回で構築した環境では、以下のようなサービスにコストがかかっているはずです。

• Amazon Elastic Kubernetes Service (EKS): EKSクラスター自体のコスト(1クラスターあたり$0.10/時間)
• Amazon EC2: EKSノードグループのインスタンスコスト(第16回ではt3.smallを使用)
• Amazon Virtual Private Cloud (VPC): NAT Gatewayのコスト(時間単位 + データ転送料。料金はリージョンによって異なる)
• Amazon Simple Storage Service (S3): Terraformの状態ファイル用バケットとECRのイメージストレージ
• Amazon Elastic Container Registry (ECR): コンテナイメージの保存コスト

Cost Explorerで「グループ化」を「サービス」に設定すると、サービスごとのコストが棒グラフで表示されます。通常、EKSとEC2が最も高コストになります。

期間とグラフのカスタマイズ

Cost Explorerでは、表示期間やグラフの種類をカスタマイズできます。

• 期間の変更:「日次」「月次」を選択して、より細かい粒度でコストを確認
• グラフタイプ: 棒グラフ、折れ線グラフ、スタックグラフから選択
• グループ化: サービス、タグ、リージョン、使用タイプなど、さまざまな軸でグループ化

例えば、日次グラフに切り替えると、特定の日にコストが急増したことを発見できます。この場合、その日に何が起きたかを調査することで原因を特定できます。

リソースタグによるコスト分析

第16回で各環境のリソースに付けたEnvironmentタグ(dev、prod)を活用すると、環境ごとのコストをCost Explorerで分析できます。タグでグループ化することで、開発環境と本番環境それぞれにかかっているコストを一目で把握できます。

例えば、開発環境が本番環境よりコストがかかっている場合、以下のような気づきが得られます。

• 開発環境のノード数が本番環境より多い
• 開発環境でテスト用のリソースが削除されていない
• 開発環境のインスタンスタイプが本番環境と同じ(オーバースペック)

また、Project(プロジェクト名)、Team(チーム名)、CostCenter(経理部門への報告用)といったタグを追加することで、より詳細なコスト分析も可能になります。

ただし、タグをCost Explorerで使用するには事前の設定が必要です。TerraformでAWSリソースに付けたタグは、そのままではCost Explorerで選択できません。コスト配分タグとして有効化する必要があります。さらにAWS Organizationsを使用している場合は管理アカウント(支払いアカウント)でのみ設定できるため、メンバーアカウントを使っている場合は管理アカウントの管理者に依頼が必要です。

タグを使ったコスト分析が難しい環境の場合は、サービスごとのグループ化を代替手段として活用できます。Cost Explorerで「グループ化」を「サービス」に設定し、EKSやEC2などサービス単位でコストを確認することで、どのサービスがコストを押し上げているかを把握できます。

AWS Budgetsで予算アラートを設定

AWS Budgetsとは

コストの監視を自動化するためにAWS Budgetsで予算を設定し、予算を超えそうになったらアラートを受け取るようにしましょう。

AWS Budgetsは月次予算、四半期予算、年次予算など、さまざまな予算タイプに対応しています。予算額に対する実績額の割合を監視し、設定したしきい値を超えたときに通知を送信します。

予算の作成手順

「請求とコスト管理」ダッシュボードの左側メニューから「予算」を選択し、「予算の作成」をクリックします。

ステップ1: 予算の設定方法を選択
最初に「テンプレートを使用する(シンプル)」と「カスタマイズ(詳細)」のどちらかを選びます。

テンプレートには以下の種類があります。

• ゼロ支出予算: 費用が1セントでも発生したらアラートを送信。予期せずリソースが作成された場合などに気づける
• 月次コスト予算: 月次予算を設定し実績が85%と予測が100%を超えたらアラートを送信。しきい値はテンプレートで固定され、変更は不可

今回はタグでフィルターをかけて開発環境のコストだけを監視したいため、「カスタマイズ(詳細)」を選択します。

ステップ2: 予算タイプの選択
「コスト予算」を選択します。他にも「使用量予算」(特定のサービスの使用量を監視)や「リザベーション予算」(リザーブドインスタンスの使用率を監視)がありますが、今回はコストを監視します。

ステップ3: 予算の詳細設定
以下の項目を設定します。

• 予算名: monthly-budget(アカウント全体)
• 期間: 月次
• 予算更新タイプ: 定期予算
• 予算設定方法: 固定(毎月同じ予算額)
• 予算額: 例えば$100(実際の環境に応じて調整)

「予算設定方法」について補足します。「自動調整」は過去の支出パターンから予算を自動計算してくれる便利な機能ですが、インフラを構築したばかりで支出パターンが安定していない時期には精度が低くなります。まずは固定額で運用し、コストの傾向をつかんでから切り替えを検討すると良いでしょう。

本来であれば、フィルターでタグEnvironment = devを指定することで開発環境のリソースのコストだけを監視できます。ただし、前述の通りコスト配分タグの有効化には管理アカウントの権限が必要です。タグが使えない場合はフィルターを設定せず、アカウント全体のコストを監視する形で運用します。

ステップ4: アラートと通知先の設定
予算額に対するしきい値と通知先を設定します。複数のしきい値を設定できるため、段階的にアラートを受け取れます。

例として、以下のような設定が考えられます。

• アラート1: 予算の50%($50)を超えたとき
  　通知先： メールアドレス
• アラート2: 予算の80%($80)を超えたとき
  　通知先： メールアドレス
• アラート3: 予算の100%($100)を超えたとき
  　通知先： メールアドレス

通知先にはメールアドレスを指定します。複数のメールアドレスを指定できます。また、Amazon SNSトピックを指定するとSlackやチャットツールへのSNS連携も可能になります(SNSとSlackの連携については次回(第24回)で解説します)。

ステップ5: 予算の確認と作成
設定内容を確認し「予算の作成」をクリックします。予算が作成されると、Cost Explorerのデータと連動してリアルタイムでコストが監視されます。

コスト最適化のベストプラクティス

Cost Explorerで高コストのリソースを特定したら、以下のようなコスト最適化を検討します。

適切なインスタンスサイジング

EKSノードのCPU使用率が常に20%以下の場合、インスタンスタイプの過剰スペックが疑われます。より小さいインスタンスタイプへ変更することでコストを削減できます。

例えば、第16回ではt3.small(2 vCPU、2 GiBメモリ)を使用しましたが、CPU使用率が低い場合はt3.micro(2 vCPU、1 GiBメモリ)へ変更を検討します。

# terraform/modules/eks/main.tf
instance_types = ["t3.micro"]  # t3.smallから変更

ただし、本番環境では余裕を持たせることが重要なので、開発環境でのみサイズダウンを検討します。

未使用リソースの削除

テスト用に作成したリソースは、テストが終わったら速やかに削除します。Terraformを使っている場合、以下のコマンドで環境全体を削除できます。

$ cd terraform/environments/dev
$ terraform destroy

ただし、terraform destroyは環境全体を削除するため、実行前に必ず内容を確認してください。特定のリソースだけを削除する場合はTerraformのコードから該当リソースの定義を削除し、terraform applyを実行します。

開発環境のスケジュール運用

開発環境は業務時間外(夜間や週末)に稼働させる必要のないケースが多いです。Auto Scalingグループのスケジュールアクションを使って業務時間外は自動的にノード数を0にすることで、コストを大幅に削減できます。

例えば、平日の9:00にノード数を2に、19:00にノード数を0にするスケジュールを設定します。これにより、1日あたり10時間、週末を含めると約70%のコストを削減できます。

ただし、スケジュール運用は導入前にチームの実態を確認することが重要です。例えば、業務時間外に環境を使用する必要が生じた場合、環境を管理しているエンジニアに連絡して起動してもらう必要が出てきます。そのエンジニアの人的コストは節約できるインスタンス代を上回る可能性があります。業務時間外に誰も環境を使わないことを確実に保証できるチームでなければ、コスト削減を上回る運用負荷を招くリスクがあります。

Auto Scalingの活用

負荷に応じてノード数を自動調整するAuto Scalingを活用することで無駄なリソースを削減できます。第16回で設定したdesired_size、min_size、max_sizeを見直し、最小ノード数を減らすことを検討します。

# terraform/modules/eks/main.tf
scaling_config {
  desired_size = 1  # 2から1に変更
  min_size     = 1  # 2から1に変更
  max_size     = 3
}

ただし、本番環境では可用性を優先するため、最小ノード数は2以上に保つことをお勧めします。

リザーブドインスタンスとSavings Plans

長期的に使用するリソース(特に本番環境)には、リザーブドインスタンスやSavings Plansを活用することで最大72%のコスト削減が可能です。

• リザーブドインスタンス: 1年または3年契約で、特定のインスタンスタイプを割引価格で使用
• Savings Plans: より柔軟な1年または3年契約で、一定の使用量をコミットすることで割引を受ける

ただし、長期契約となるためリソースの使用パターンが安定してから導入を検討します。変更頻度が高い開発環境のリソースには向きません。

Cost Explorerの高度な機能

コスト予測

Cost Explorerには、過去の使用パターンから将来のコストを予測する機能があります。レポートの表示期間に将来の日付を含めると、グラフ上に予測コストが自動的に表示されます。折れ線グラフでは予測範囲が線で、棒グラフでは棒の上部に2本の線で示されます。

この予測を基に、予算を超過する可能性がある場合は早めにコスト最適化の対策を実施できます。

レポートの保存

Cost Explorerで作成したグラフやフィルター設定はレポートとして保存できます。「レポートを保存」をクリックしてレポート名を入力すると、後で同じ設定を簡単に呼び出せます。

CSVエクスポート

Cost ExplorerのデータはCSV形式でエクスポート)できます。「ダウンロード」をクリックすると、グラフのデータがCSVファイルとしてダウンロードされます。

このデータをExcelやGoogle Spreadsheetsで分析したり、独自のレポートを作成したりできます。

おわりに

今回は、Terraformで構築したAWSインフラのコスト管理について学びました。Cost Explorerを使ってコストを可視化し、サービスごと、環境ごとの内訳を確認しました。リソースタグを活用することで、より詳細なコスト分析が可能になることも学びました。

AWS Budgetsで予算アラートを設定することで、予想外のコスト増加を早期検知できるようになりました。複数のしきい値を設定することで段階的に対応を検討できます。

また、コスト最適化のベストプラクティスとして適切なインスタンスサイジング、未使用リソースの削除、開発環境のスケジュール運用、Auto Scalingの活用を紹介しました。加えて、リザーブドインスタンスとSavings Plansの利用についても解説しました。

これらのコスト管理手法により、以下が実現できます。

• コストの透明性確保: どのリソースにコストがかかっているかを正確に把握
• 予算管理の自動化: 予算超過を早期に検知し、迅速に対応
• コスト最適化: 無駄なリソースを削減し、適切なサイジングを実現
• 経営層への報告: CSVエクスポートやレポート機能を活用して、定期的にコストを報告

コスト管理は一度設定して終わりではなく、定期的な見直しが重要です。週次または月次でCost Explorerのダッシュボードを確認し、コストトレンドを分析することをお勧めします。特に、新しいリソースを追加したときやトラフィックが増加したときは、コストへの影響を注視しましょう。小規模なうちから監視体制を整えておくことで、スケールアップ時にもスムーズにコスト管理を継続できます。

次回(第24回)は、Amazon SNSとSlackを連携させて、AWS Budgetsのアラートをチャットツールに通知する仕組みについて解説します。