What happens if your tracking doesn't end up matching the actual bill?

Vantage integrates at an AWS account level through a mechanism called a Cross account IAM role which allows us to ingest and process the raw data that AWS uses for its own billing systems (Cost and Usage Reports, Service APIs and Cost Explorer)

We haven't seen a single case where we don't end up matching the actual AWS bill. In fact, with a release currently in BETA and rolling out in a week or two, we'll be providing richer data faster than AWS Cost Explorer provides.

You can see a demo of that here (designs still need to be implemented) https://www.loom.com/share/dcb72a921f134e59b19a0dd3d3ab0e2f

Yeah but do you guarantee that you will cover any real billing differences, or you’re not sure enough to put your money where your mouth is?

Having seen firsthand the kind of devious folks who are out there constantly trying to do fraudulent activity on AWS, I don't think any small startup like Vantage would ever want to offer a bill insurance scheme. It would be ripe for exploitation, such as someone trying to spin up 1000 instances in the last couple minutes of the month and then say "Gotcha, your bill prediction didn't match up with the real bill after all!"

At a more general level this may also be one of the most entitled asks I've ever seen in the 12+ years I've been on HN.

StratusBen, this is where you could charge an incredible premium for your service.

If you could underwrite price guarantees and show an insurance company or lender that your figures are right in most cases and that you've never lost over a certain amount, you could really hike the cost of your service and provide an incredible utility across the board.

If you have spare bandwidth and can reliably do this, try building this.

I think you are on to something.

The real opportunity here is to start an AWS insurance business.

Where you provide accident insurance for clients by charging 10% of <some estimate of expected monthly running cost>.

And spread the cost of mishaps over the clients you charge.

The trick is to define that estimate of normal cost. And also to certify that clients meet some minimum expectation of clumsiness.

This is crazy. You suggest that if AWS changes billing somehow, his startup should shoulder the cost? If you don't trust it don't use it.

This is important, and will show confidence in your product.

The requirement is insurance against not exceeding a hard limit. We're talking about a rare event, so the offering (vantage.sh) is not good for this specific usecase if it isn't absolutely foolproof.

This would convert his business to fighting fraud 24/7 practically overnight.

While building CloudAlarm [0] (supports Azure as of now), we found that the usage data on Azure wasn't available for at least a day – in fact, they keep adding the data to it during the next day so technically two days would have passed when the actual usage data is available. I haven't gone deeper in AWS but they also gradually make the data available as per I've read. SO instantly alert we thought cannot be possible with usage and hence we chose a novel route – of 'New Resource' alarm – wherein you can get alerted for all resources created or for anything expensive than the tier you choose. The resources in your Azure subscription are available almost instantly via the API, so this was something a nice workaround we thought.

0: https://cloudalarm.in/