Hacker News new | ask | show | jobs
by CSDude 1727 days ago
Tagging is required yes, but its a very simple practice. I worked in both small (3 accounts) and huge (200 accounts) orgs, and tagging, at least by name was never a problem regardless of tens of thousands of resources we manage.

Cost Explorer does all of what you mentioned. UI allows 1 level group by, API does 2. You can filter & group by API Operation (S3 put object), Service (S3), Usage Type (S3 Standard Storage GB/mo), (predefined) Tags and it works brilliantly over even 1 year of data, fast.

I'm really not convinced on what you can do additionally, since you work on the same data exactly (detailed dumps on S3) apart from nicer charts.

1 comments

Just so I understand this correctly....you have individually tagged each individual resource to do this for an AWS org with over 200 member accounts? Then enabled the presumably hundreds of thousands of individual tags for Cost Explorer to pick up?

From what we've heard from our customers no one is doing this (or wants to do this) and would prefer to just a flip a switch and have Vantage handle it on their behalf.

I agree AWS should tag all resources with their names already for them to show up in the Cost Explorer. However, we already tag by cost center or teams to identify costs. It's required as a policy and baked in most of our automations. It's also a best practice recommended by even most basic tutorials. If you have a TAM, they would tell you to do this as well when your finance team or person is asking about why these bills are large.

Also, even if they are untagged, it's not like we need to tag them by hand, AWS Resource Tagging API works nice enough, and not every resource is costly that we need to tag them by resource-level.

I support what you are doing however there are too many companies working CUR data in S3 and none of them is good enough and neccessarily faster or more useful than Cost Explorer. Just wanted to understand what you can add on top of it, apart from automatic tagging? part.

Got it - so what I'm inferring is that for your use-cases you don't need to see per-resource cost granularity out of the box which is completely fair.

We've heard from customers that some top issues they have with cost explorer include (1) lack of visibility into K8S workloads (2) more complex filtering around creating cost reports and (3) more effective tools for chargebacks/showbacks. All of these are on our roadmap - in addition to supporting other clouds (Azure, GCP) and other cloud services.

Out of curiosity, what would you want from a "better cost explorer" service for your organization?

K8s integration sounds useful, there are also many startups in this area, and it's trivial to implement, however please consider that just a workload is requesting 2 CPUs, does not mean you can divide the underlying EC2's price per vCPU or Memory. There is significant overhead running K8s, log collectors, agents, wasted space, and spot instance pricing etc. please be more insightful for that, not just divide by request/limits. Combining these with overall AWS costs would make more sense. However as I said, we tag by service or cost centers, so I would want to associate my Pods and its SQS queue cost together.

Chargebacks in AWS is very complex, i.e in cost explorer net amortized cost vs unblended cost is hard to understand for an average user. It'd be nice if you can have some clarifications on it, what does even amortized mean etc.

We use Cost Explorer API to identify anomalies. Even basic statistics works sometimes. But there is also new native feature that is good enough for us, so we removed that. But it was a very sensitive topic, i.e our S3 usage is steadily increasing %.x per month. Trend & seasonality analysis is a must.

Sorry for my quick and dirty English. This is a hot topic for me and I get excited.