Show HN: Tagging Assistant – add AWS cost allocation tags in your dev pipeline(cloudthread.io)
cloudthread.io
Show HN: Tagging Assistant – add AWS cost allocation tags in your dev pipeline
https://www.cloudthread.io/product/cost-savings-insights
14 comments
Excited to see this! Cost attribution is a tricky problem, especially for larger orgs that use shared AWS accounts across a engineering teams. It's too easy to default to manual workarounds that are are only best-effort attempts at the real breakdown. Better tooling here is much needed.
Nice work team Cloudthread! A tagging assistant can be one of the first features for organizations to understand their costs better by product lines, teams, cost centers, etc. Looking forward to using it! :)
Awesome tool, I can see this having some security/compliance applications as well.
Yeah, we are thinking of potential features on that side as well!
Interesting. How does it differ from setting up a CloudTrail and then a Lambda function which would do it automatically on every new resource creation?
CloudTrail + Lambda is a good way to create automations in AWS! Great idea for a future setup option, especially for companies that don't use GitHub.
Here are some reasons we think GitHub + Terraform IaaC is a good approach:
1. One benefit of doing tagging in the infrastructure as code is that it creates visibility for engineering teams that use the IaaC as source of truth.
2. In our experience GitHub provides a natural segmentation for how resources could be tagged - it creates an efficient mapping of your tagging to resources based on being part of different GitHub repos.
3. CloudTrail is AWS specific. In the future we plan on expanding integration to Azure and GCP which would allow consistent tagging across all clouds from this centralized Catalog. We created a developer API to fetch the tagging which could be referenced in the Lambda you're referencing.
Here are some reasons we think GitHub + Terraform IaaC is a good approach:
1. One benefit of doing tagging in the infrastructure as code is that it creates visibility for engineering teams that use the IaaC as source of truth.
2. In our experience GitHub provides a natural segmentation for how resources could be tagged - it creates an efficient mapping of your tagging to resources based on being part of different GitHub repos.
3. CloudTrail is AWS specific. In the future we plan on expanding integration to Azure and GCP which would allow consistent tagging across all clouds from this centralized Catalog. We created a developer API to fetch the tagging which could be referenced in the Lambda you're referencing.
Really great question btw!
How does the integration work? It seems like a lot of security access is required.
Integration with the AWS environment is limited to allows us to 1) see existing tagging structure and 2) to show analytics on tag coverage.
The GitHub integration is done through the Actions API and does not require a GitHub app.
The GitHub integration is done through the Actions API and does not require a GitHub app.
At my company we do all cost segmentation by account, why would we need this?
Daniele here from Cloudthread. Doing cost attribution by account is a great way to segment costs in AWS. If it currently solves all your cost allocation needs, then you can possibly get away without using tagging. At scale many organizations need to either:
1) attribute costs within an account
2) create cost segments across accounts.
That’s when tagging becomes essential.
1) attribute costs within an account
2) create cost segments across accounts.
That’s when tagging becomes essential.
Creative use of tags to determine where eng resources are going to!
What’s the value?
Major use case is a unified Catalog for your entire environment and the ability to change tagging at scale through the Catalog without going into individual Terraform files to make tagging changes. This helps with consistency as engineers only need to remember the catalog key without needing to remember any particular tagging.
AWS Cost Allocation Tags are labels on resources that attribute and track cloud costs. Tagging is a prerequisite to assigning cost ownership (e.g. by team/app/cost center) and creating cloud cost accountability.
Tagging AWS resources is a manual process that’s done either when a resource is spun up or during a cost firefighting initiative to understand cost ownership. We figured there had to be a better way and set out to make tagging a seamless part of development pipelines that use GitHub and Terraform.
Once set up, the Tagging Assistant GitHub action will allow you to continuously enforce and maintain your AWS tagging strategy within your Terraform projects. Each GitHub repository can be associated with a catalog key that maps to tag key-value pairs within the Tag Catalog on the Cloudthread App. Adding or changing tag key-value pairs in a Cloudthread’s Tag Catalog entry will generate a tagging update Pull Request each time the action runs, and fail if the appropriate tagging is not in place. An example of such an update is `.tf` build file getting `(locals {tags = …}})` added.
All resources defined via Terraform in the repository will receive the same tags defined via the Tag Catalog.
This is just the start – in the future we’ll create more tagging granularity so that it is possible to tag different provider aliases differently within a single project.
A graphic showing how this works is here:
https://www.cloudthread.io/product/tagging-assistant
Tagging Assistant is free to use and instructions to set it up are in our docs below.
https://docs.cloudthread.io/guides/setting-up-tag-catalog
By installing Tagging Assistant you’ll get access to the free version of Cloudthread’s cost visibility, savings insights, and unit economics features.
Very excited to get feedback! Try it out, let us know what you think, and feel free to reach out directly to [email protected] or by using the chat icon bottom right on the Cloudthread app.