AWSの請求は、予期せぬコストが手遅れになるまで見過ごされがちで、エンジニアリングチームにとって驚きや不満の原因となることがあります。一般的なシナリオとして、エンジニアが概念実証のためにインスタンスを起動し、それをオフにするのを忘れてしまい、継続的な請求が発生するというものがあります。AWSが提供するツールであるCost Explorerは、請求データのトレンドや異常を特定するのに役立ちますが、どの特定のインスタンスがどのエンジニアやチームに属しているかを示すことができないなどの制限があります。このツールは請求レコード上で動作し、サービス、リージョン、アカウント、タグごとに集計できますが、実行中のインスタンスとアイドル状態のインスタンスを区別することはできません。リソースのタグ付けは帰属を改善できますが、リソースが積極的に使用されているか、アイドル状態にあるかを判断できないなどのギャップがあります。アイドルリソースの問題は、特に開発およびステージング環境で蔓延しており、リソースが継続的に実行されたままになり、かなりのアイドル時間が発生することがよくあります。この問題を解決するには、アクティビティシグナルとアイドルコストの可視性を備えたリソースごとの帰属という2つのレイヤーでのインストルメンテーションが必要です。アクティビティシグナルは、リソースが実際に使用されているかどうかを判断することを含み、リソースごとの帰属は、アイドルリソースのコスト結果を表面化することを含みます。EC2開発ボックス、RDSステージングデータベース、ECSサービスなどの異なるリソースタイプは、さまざまなアイドルコストパターンを持っています。アイドルコストの可視性がないことの結果は、コスト最適化が鈍い手段となり、いつ作業が行われるかについての仮定に依存することです。より正確なアプローチは、所有権の帰属とともに、リソースレベルでアイドルコストを可視化し、最適化の決定に情報を提供することです。アイドルコストがどこに蓄積しているかのより明確な全体像を把握するために、チームはインスタンスの稼働時間とCloudWatchアクティビティの比較、週末のRDS接続数の確認、ECS最小タスク数のレビュー、および実行中のインスタンスに対するタグコンプライアンス監査の実行から始めることができます。最終的に、アイドルコストの問題に対処するには、アクティビティを認識した自動化を備え、特定のエンジニア、チーム、または環境へのアイドルコストの帰属を中心に構築されたTrigopsのようなツールを使用するなど、体系的なアプローチが必要です。