"ブラックボックス"なクラウドコストに終止符を。〜Looker Studioで全社クラウドコスト可視化基盤を構築した話〜

技術本部で商用インフラ全般を担当しているインフラエンジニアの小林です。

今回は、「誰が何にいくら使っているか」がわからない"明細のない電気代"のような状態だったクラウドコストを、インフラ担当者の立場から全社課題として捉え、Looker Studioで可視化した基盤を構築した話を紹介します。

背景・きっかけ
システム概要
工夫した点
苦労した点
導入効果
まとめ・今後

背景・きっかけ

これまでAWSやGCPのコストを確認するには、各クラウドのコンソールへのログインが必要でした。担当者以外はコスト感を把握しにくく、「明細のない電気代」のような"ブラックボックス"な状態でした。全社的にクラウドコストの削減が求められる中、誰がどのリソースにいくら使っているかを可視化する必要がありました。

AWSのコスト確認にはAWSへのログインが必要
QuickSightはViewerライセンスが必要でコストがかかる
50個以上のアカウントが存在し、全体把握が困難

さらに、サービス側のバグでGCPのコストが大量に発生するインシデントが起き、異常コストを素早く検知できる仕組みの必要性も痛感しました。

そこで、AWSアカウントを持たない人でも閲覧できるクラウドコスト可視化基盤の構築に着手しました。あわせて、異常コストをSlackに即時通知するAWS Cost Anomaly DetectionのPoCも別プロジェクトとして立ち上げました。

システム概要

AWS コスト可視化構成図

GCP コスト可視化構成図

構成の概要：

データソース: AWS Data Export (S3) / GCP Billing Export (BigQuery)
データ基盤: BigQuery
可視化: Looker Studio（adwaysのGoogleアカウントで誰でも閲覧可能）
アラート: AWS Cost Anomaly Detection → Slack通知（別プロジェクトとして推進）

Looker Studioを選定した理由は以下の通りです。

追加コストゼロ: QuickSightはViewerライセンスが必要なのに対し、Looker StudioはGWS（Google Workspace）のアカウントがあれば閲覧・編集ともに無料
社内に馴染みがある: すでにGWSを利用しており、Looker Studioも社内で使われていたため導入障壁が低かった
BigQueryとの親和性が高い: 同じGoogle Cloud製品同士のため、BigQueryをデータソースとして追加設定なしで接続でき、クエリ結果をそのまま可視化できる
リアルタイム反映: BigQueryへの直接接続のため、データが更新されれば自動的にダッシュボードに反映される

作成したダッシュボードは2種類です：

コスト可視化ダッシュボード: AWS/GCPの実績コストをサービス・プロジェクト単位で確認できる
コスト最適化ダッシュボード: AWS Cost Optimization HubやGCPの推奨事項を活用し、未使用リソースなど「節約できるポイント」を自動検知して提示する

コスト可視化ダッシュボード（サンプル）

工夫した点

運用コストゼロの設計

Looker Studioはadwaysのアカウントさえあれば追加ライセンス費用ゼロで全社展開できます。また、データパイプラインの仕組みとして：

AWSはData Export機能でS3に自動出力し、BigQuery Data Transfer Serviceで定期転送
GCPはBilling Exportで直接BigQueryにエクスポート

いずれもフルマネージドサービスを組み合わせているため、サーバーの管理・運用が不要です。

さらに、毎月3日にインフラのSlackチャンネルへレポート確認依頼を自動通知する仕組みを構築しました。これにより、ダッシュボードを作って終わりにならず、定期的な確認と最適化を行う運用サイクルを定着させることができました。

実績値とコスト削減ポテンシャルの両方を可視化

実績コストだけでなく、「どれだけ削減できるか」もダッシュボードで確認できるようにしました。各プロジェクト単位での削減余地が一目でわかります。

AWSデータのBigQuery連携

AWS Data Export機能でS3にエクスポートし、BigQuery Data Transfer ServiceでBigQueryへ転送する構成を採用しました。 AWS OrganizationsのManagement Accountを持っており、傘下の全アカウントのData Export設定を一箇所で一元管理できるため、転送設定は最小限の箇所で対応できました。

この構成で詰まりやすい仕様があったため、詳細は「苦労した点」のセクションにまとめています。

GCPデータのBigQuery連携

GCPはプロジェクトごとにビリングアカウントが分かれており、それぞれのBilling ExportデータをLooker Studioのカスタムクエリで UNION ALL して統合する構成にしました。

この際、Looker Studioのクエリ実行の制約上、各プロジェクトのエクスポート先BigQueryデータセットのリージョンをすべて asia-northeast1 に統一する必要がありました。

開発チームへの提案型アプローチ

ダッシュボード設計時、開発チームへのヒアリングでは「何が見たいですか？」と受け身で聞くのではなく、コスト最適化ダッシュボードのデータをもとに「このリソースはこれだけ削減できます」と具体的な施策案を持参する提案型で進めました。

AWS Cost Optimization Hubでは、未使用・過剰スペックのリソースに対する推奨事項が自動的に検知されます。これをダッシュボードに取り込み、各チームに「何が削減できるか」を可視化した状態で提案することで、受け身の情報提供ではなく能動的なコスト削減活動につなげることができました。こうすることで、各チームが「自分ごと」としてコストを意識しはじめ、自律的な削減活動の土台（文化）を作ることができました。

苦労した点

AWSのエクスポート仕様との格闘

AWS Data Exportには特有の仕様があります。Data export overwriting を「既存のファイルを上書き」に設定した場合、その月の1日〜当日分の累積データが毎日同じS3パスに上書き出力されます。

これをそのままBigQuery Data Transfer Serviceで取り込もうとすると、S3上のファイルが更新されても「新しいファイルがない」と判断されてデータが取り込まれませんでした。ドキュメントにも明記されておらず、この仕様に気づくまでに時間がかかりました。

対処として以下の2点を設定することで解決しました。同じ構成を試みる方はこの2点を最初に押さえておくことをおすすめします。

S3の出力先パスを BILLING_PERIOD=*/ のようにBilling Period（月）単位のHiveパーティション形式にする
BigQuery Data Transfer側の Write Disposition を WRITE_APPEND（追記）に設定する

GCPの手動設定の多さ

GCPの標準Billing Export設定にはAPIやCLIが存在せず、プロジェクトごとに手動での設定が必要です。プロジェクトが増えるたびにLooker StudioのUNION ALLクエリを修正しなければならず、新規プロジェクト追加時の運用フロー整備（誰がどのタイミングでクエリを更新するか）に泥臭い苦労がありました。

データセットのリージョン統一

GCPの各プロジェクトのBilling ExportをBigQueryに出力する際、エクスポート先のデータセットのリージョンがバラバラだと、Looker StudioのカスタムクエリでUNION ALLできません。後から気づいたため、一部はデータセットの作り直しが発生しました。リージョン設定は最初に統一しておくことを強くおすすめします。

導入効果

コスト可視化ダッシュボードとAnomaly Detectionが揃ったことで、クラウドコスト管理における「知る・防ぐ・削る」のサイクルが回りはじめました。

知る: 全社員がAWSログイン不要でコスト状況をリアルタイムに確認できるようになった
防ぐ: 別プロジェクトで導入したAWS Cost Anomaly Detectionにより、異常コストをSlackで即時検知できるようになった（GCPも同様に異常検知の仕組みを別途整備済み）
削る: コスト最適化ダッシュボードで削減余地を可視化し、インフラチームから開発チームへ具体的な提案を実施できるようになった

ダッシュボードを活用した提案の結果、以下のような具体的な削減効果が出ています。コスト最適化ダッシュボードにより、長期間放置されていた未使用EBSボリュームの存在や、EC2インスタンスをGravitonアーキテクチャに移行するだけでコストを削減できることが一目でわかるようになりました。