dpackard

Thanks!

Cost Explorer is nice. If you want more granular data (resource level, hourly) then you need to look at your Cost and Usage Report which you can do with Cloudthread or AWS CUDOS dashboards.

Biggest way to save quick with zero engineering effort is through committed use discounts (Savings Plans / Reserved Instances) if an org hasn't done this yet.

Top 3 source of savings for customers from Cloudthread computed opportunities has been RDS/ElastiCache/DynamoDB rightsizing, EBS volumes in standard storage that can be archived, and s3 intelligent tiering implementation.

Typically it's worth doing a round of usage optimization (e.g. rightsizing) so you're not buying committed use discounts on unnecessary/wasted instances :)

Yes, but right now for GCP we're only aggregating cost recommendations from Google Recommender.

For AWS on the other hand we're also computing dozens of our own savings opportunities.

In the coming month we'll be adding more GCP opportunities - would be very excited to hear what you'd want prioritized

Sometimes the difference between a savings opportunity and engineering action is a Jira ticket :)

Thanks Pranav!

Thanks for the input. Definitely tough to balance being opinionated and guiding with best practices vs being flexible for unique company use cases and right now we're trying to "nudge" :)

We particularly wanted the "Easy" savings opportunities to be things a cloud cost owner (Head of Infrastructure or Cloud FinOps) could execute centrally without creating tickets for eng sprints. Quick wins.

Definitions we use when rating savings opportunities are below.

Right now users can’t edit the difficulty but that’s helpful feedback if you think it’s something you’d use!

Would you want the ability to change difficulty to one of our fixed difficulty categories or the ability to add a custom difficulty unique to your org (e.g. custom difficulty based on internal approvals/processes at your company)?

Easy: zero downtime, zero performance risk

Medium: zero downtime, potential performance tradeoffs

Hard: downtime required, potential performance tradeoffs

Yes, for companies using TA these are included in the Opportunities Explorer.

Most of the TA cost optimization recs we replicate and compute ourselves so that companies that don’t pay for TA (lots of $ !!!) can see those opportunities. And if you’re using TA you can toggle between seeing RI/SP recommendations from Cost Explorer or TA.

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.

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.

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.