【ITニュース解説】The $10,000 Label: How We Used Go, Clean Architecture, and AWS to Build a FinOps-Driven Cloud Tagging Engine 🏷️

クラウド環境を大規模に利用する企業にとって、コスト管理は非常に重要な課題である。まるで会社の経費報告書が巨大になるように、クラウドサービスの利用料も膨大になる。このとき、もし適切な「タグ付け」、つまり「project: crm-migration」や「owner: finance-team」のようなシンプルなキーと値のラベルがなければ、毎月数千ドルもの費用が単に「サーバー」とだけ記された項目に費やされ、その内訳が不明瞭な状態となる。これは単なる会計上の問題にとどまらず、コスト管理やセキュリティに対し直接的な脅威となる。例えば、誰も管理していない放置されたAWSリソース（シャドウITと呼ばれる）は、知らず知らずのうちに費用を発生させ続ける。また、財務チームは費用の正確な帰属を特定できず、請求に関する摩擦や遅延が生じることもある。さらに、管理されていないリソースは、セキュリティポリシーやパッチ適用サイクルから外れ、セキュリティリスクを高める可能性もある。

このような課題を解決するため、「sys-tag-manager」という自動化された強力なシステムが開発された。これはGo言語で構築され、まるで「クラウド用ラベルプリンター」のように機能し、すべてのAWSリソースが適切に管理され、コンプライアンスに準拠し、コスト追跡が可能であることを保証する。

ここで言う「タグ付け戦略」とは、クラウド上のリソースにメタデータ（タグ）を体系的に適用する手法のことである。タグは、「owner: finance-team」、「project: crm-migration」、「environment: production」のような単純なキーと値のペアで構成される。一つ一つのタグは単純に見えるが、クラウド環境全体にわたって一貫して適用されることで、組織、ガバナンス、コスト管理の根幹をなすものとなる。タグ付け戦略では、どのようなタグが必要か（例：owner、project、environment）、タグの形式（命名規則、小文字かキャメルケースか、区切り文字）、いつタグを適用するか（作成時か自動修正か）、そして誰がタグの維持管理に責任を持つか、といった点が定義される。

このシステムの技術的基盤は、Go言語、クリーンアーキテクチャ、そしてAWSのコスト削減という3つの要素によって支えられている。プロトタイプ開発にはPythonが手軽だが、システムの中心となるミッションクリティカルなツールには、高いパフォーマンスと信頼性が求められる。そのため、sys-tag-managerにはGo言語が選択された。Go言語はメモリ使用量が少なく、起動が非常に高速であるため、AWS Lambda関数やKubernetes CronJobとして実行する際に、AWSのコンピューティングコストを直接削減できる。これは、リソースを多く消費する他の言語と比較して、より少ない課金時間で実行できることを意味する。また、Go言語の静的型付けと堅牢な並行処理機能は、急増するAWS API呼び出しを効率的に処理し、システムが失敗することなく100%のコンプライアンスをカバーすることを保証する。

さらに、システムの保守性を確保し、クラウド資産が拡大しても対応できるように、「クリーンアーキテクチャ」という設計パターンが採用された。これは、論理をAWS SDKから分離するための戦略的なアプローチであり、長期的な技術的負債の削減に貢献する。クリーンアーキテクチャでは、システムのロジックが以下の3つの層に分けられる。まず「ドメイン層」には、純粋で独立したビジネスルール（例：「リソースは、必要なタグ owner と project を持っていれば準拠している」）が含まれる。この層はAWSの知識を持たず、テストが容易である。次に「ユースケース層」は、アプリケーションの「何をすべきか」（例：「コンプライアンスをチェックし、タグを適用する」）を定義する。そして「アダプター層」は、特定のAWS SDKサービス（EC2Tagger、RDSTaggerなど）と直接やり取りするロジックを分離する。これにより、特定のベンダーに依存する状態（ベンダーロックイン）を防ぎ、S3やLambdaなどの新しいサービスを追加する際にも、中心となるビジネスルールに影響を与えることなく拡張できる。

sys-tag-managerが未タグ付けのリソースを修正する前に、それらをアカウントやリージョンを横断して効率的に見つける必要がある。この「ディスカバリ層」にはAWS Resource Explorerが活用された。複雑なAPI呼び出しを多数記述して、あらゆる種類のリソースを各リージョンからリストアップする代わりに、sys-tag-managerはResource Explorerの統合された検索機能を利用する。

そのワークフローは以下の通りである。まず、「ディスカバリ」フェーズでは、sys-tag-managerはResource Explorer APIを使用して、必要なタグ（例：tag:ownerが欠落しているリソース）が不足しているリソースをクラウド全体から検索する。次に「検証」フェーズで、発見された各未タグ付けリソースのメタデータが、AWS SSM Parameter Storeに保存されている一元化された正確なルールと照合される。最後に「修正」フェーズで、システムは適切なタグを適用し、リソースを正しい所有者やプロジェクトに割り当て、即座にコンプライアンスを確保する。この設計により、タグ付けの中核ループが大幅に効率化され、タグの適用（Go言語）だけでなく、タグの発見（Resource Explorer）も効率的に行われ、API呼び出しコストとレイテンシの削減に繋がっている。

また、一部のリソース、例えばコアとなるネットワークコンポーネントや中央集中型のセキュリティグループのような「共有インフラストラクチャ」は、単一の所有者に属さない。これに対処することも重要な設計課題であった。このシステムではスマートなフォールバックメカニズムが導入されている。タグ付けエンジンはまず、リソース固有の必要なタグをチェックする。タグが欠落している場合、次に共有インフラストラクチャとして指定されたAWS ARN（Amazon Resource Names）の事前定義リストをチェックする。もしARNが一致すれば、システムは非準拠と判定する代わりに、汎用的な共有タグセット（例：owner: platform-team, charge-code: shared-infra）を適用する。これにより、誤検知を防ぎ、共通リソースのコスト帰属を正確にする。

sys-tag-managerの真の力は、TerraformとSSM Parameter Storeの連携により、一元化され監査可能なメタデータに基づいてタグ付けルールを動的に適用できる点にある。AWS Systems Manager (SSM) Parameter Storeは、必要なタグキー、値、コンプライアンスルールを保存するための中央集中型ルールソースとして利用される。そして、TerraformがこれらのSSM内のコンプライアンスルールを排他的に管理する「単一の真実の源」となる。これは、すべてのルール変更がGitOpsワークフローを通じて追跡、レビュー、デプロイされる「不変性」を意味する。また、Terraformで新しいプロジェクトが作成されると、そのプロジェクトに必要なタグ値がSSMに自動的にプッシュされ、タグマネージャーによるチェックで即座にそのタグが有効となる「自動化」も実現する。この統合により、FinOpsルールは常にデプロイされたインフラストラクチャの定義と一致し、明確で追跡可能なメタデータループが形成される。

このシステムへの投資は、FinOpsに対し具体的な成果をもたらした。例えば、コンプライアンスにかかる時間は、以前の手動監査では数週間を要していたが、自動修正によって数分に短縮された。これにより、コスト割り当てが高速化され、リスクが軽減された。また、放置されたリソース（孤立リソース）の割合は、以前の推定約12%から1%未満に大幅に減少し、無駄なAWS支出から直接的な節約が生まれた。FinOpsの精度に関しても、以前は摩擦や紛争が多かったが、今では高い信頼性と自動化されたショーバック（部門へのコスト提示）が可能となり、正確で自動化されたチャージバック（費用請求）を実現する。

このシステムを導入することで、受動的なタグ監査から、積極的で自動化されたコンプライアンス適用へと根本的に変化した。これはエンジニアの工数を削減するだけでなく、財務チームがAWSコストと使用状況レポート（CUR）を自信を持って利用し、正確なショーバックとチャージバックを可能にし、クラウド運用の全体的な説明責任と財務効率を向上させている。

結論として、sys-tag-managerは単なる自動化スクリプト以上の存在であり、FinOpsとセキュリティポリシーを実施するための強制レイヤーである。これにより、クラウド環境は自己修復的で、財務的に説明責任を果たせるものとなる。Go言語をパフォーマンスのために、クリーンアーキテクチャを保守性のために、そしてTerraformとSSMの連携を一元化されたメタデータ管理のために採用することで、タグ付けは手動の負担から、自動化されたコスト削減資産へと変貌した。この変化により、AWSに費やされるすべてのドルが追跡可能で、監査可能であり、ビジネスオーナーまたはプロジェクトに直接帰属するという確信が得られた。その結果、エンジニアは機能開発に集中でき、基本的なガバナンスであるタグ付けはsys-tag-managerによって自動的かつ効率的に処理されるという、「Compliance as Code」の文化が生まれたのである。