Comment by scottlamb | Hacker News Reader

Comment by scottlamb | Hacker News Reader

Looking at AWS's price page for us-east-1 [1]

* PUT, COPY, POST, LIST requests are $0.005 per 1,000 requests

* GET, SELECT, and all other requests are $0.0004 per 1,000 requests

It sounds like these are getting charged at the PUT request pricing. And IIUC, those prices are set because successful write operations seek on multiple HDDs (physically moving the head) to commit the data to multiple machines, or S3 would be unable meet durability goals. Successful read operations are an order of magnitude cheaper because they likely move only one of several heads, sometimes none at all (because they're cacheable).

Authorization failures should never hit an HDD.

Other folks have mentioned that these auth failures are costing AWS something. Sure...but very very little. Far less than the cost of a successful GET, much less a successful PUT. They really shouldn't be charging at all for this, or if they do, it should be like $0.00001 per 1,000 requests (another order of magnitude cheaper than GETs). Not even that really; the actual cost for them to process this request is likely less than they're (over)charging for the bandwidth alone.

[1] https://aws.amazon.com/s3/pricing/

What's crazier is that turning on Requester Pays does not actually mean requester pays when the request is a 403 [1][2].

Essentially every S3 bucket, public or private, whose name is discovered can be DDoSed creating an insane bill...

That's a platform level security issue for AWS to resolve. We do not need another Bucketgate.

[1]: https://twitter.com/Lauramaywendel/status/178507498639629151...

[2]: https://docs.aws.amazon.com/AmazonS3/latest/userguide/Reques...

For me it looks like AWS has mainly different scenarios to handle. First, unauthenticated users are a big security pain for AWS and S3 because S3 is used for everything. But S3 was not designed for "secure" public access. As a result billing attacks are possible (e.g. [1]) and will not be fixed (by design). Second, authenticated AWS users are kind of trustworthy and these are never assumed to do any DDoS stuff or similar. Here, we have even more surface for billing attacks. I am waiting for the moment when this assumption breaks because credit cards do not make users trustworthy.

My personal suggestion is that you should never use S3 for public access. Public buckets are an open gate to your AWS bill. If you have private buckets the attack surface is reduced but even in this situation you cannot prevent billing attacks. Try to reduce the damage by activating Cost Anomaly Detection.

[1] https://blog.limbus-medtec.com/the-aws-s3-denial-of-wallet-a... [2] https://aws.amazon.com/aws-cost-management/aws-cost-anomaly-...

private in the sense that the connection will never make it to the S3 bucket, is that correct?

private in the sense that it is locked down to allowed source IP's or IAM-- then the connection still gets there and AWS incurs a charge for the Access Denied response, etc

Yes, private in the sense of "block public access" (your second point) (https://docs.aws.amazon.com/AmazonS3/latest/userguide/access...)

Sadly, the private in the sense of "never make it to the S3 bucket" is nearly impossible. May this can be achieved by choosing some "secret" S3 bucket name.

> I am waiting for the moment when this assumption breaks because credit cards do not make users trustworthy.

IMO it is already broken, or beginning to crack at least, with the advent of throwaway virtual cards.

> Try to reduce the damage by activating Cost Anomaly Detection.

Yeah, this sounds like it could be a better solution than just using CloudWatch Billing alarms and billing alerts that I mentioned elsewhere. It's hard to tell at-a-glance if Cost Anomaly Detection is built on top of CloudWatch Billing alarms, or if they're just totally separate products. I don't seed the latter mentioned in the docs for the former.

[1]: https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitori....

What is bucketgate? Your comment comes up when searching...

I'm referring to the endless amounts of S3 buckets that ended up inadvertently exposing sensitive data publicly due to how complicated and confusing the various access control methods were / are. And also, Amazon very eventually doing something about, probably a decade after it was needed. [1][2][3]

[1]: https://cloudsecurityalliance.org/blog/2023/04/06/the-data-o...

[2]: https://news.ycombinator.com/item?id=18468753

[3]: https://news.ycombinator.com/item?id=34585670

That's why AWS doesn't allow pentesting of this (S3) service.

> Other folks have mentioned that these auth failures are costing AWS something.

This should be entirely irrelevant, as those same failures were happening even before the bucket existed, they were just hitting a different failure path.

Reply on news.ycombinator.com