Live data from Hacker News

How an empty S3 bucket can make your AWS bill explode

medium.com

61–70 of 118 posts

Re: How an empty S3 bucket can make your AWS bill explode

#61
post #2

I don't use S3, but it's kind of insane that unauthorized requests contribute to your bill... couldn't a bored/malicious actor with a botnet just spam common bucket names?

>kind of insane that unauthorized requests contribute to your bill

Abandoned GCP API gateway because of this...best as I can tell even with a rate limit the calls for the gateway get charged. I guess if it helps if the thing behind it is computationally expensive but still feels a bit silly

Re: How an empty S3 bucket can make your AWS bill explode

#63

Quite terrifying. Anyone know if competitors also bill requests which result in a "permission denied"? GCP, Azure, Backblaze B2, etc.?

90% sure GCP charges for rate limited API gateway. i.e. doesn't matter if it is above rate limit. Never got 100% confirmation either way though - their documentation on pricing is too vague

Re: How an empty S3 bucket can make your AWS bill explode

#64
post #40

I wonder why does not Amazon be responsible and lock these accounts clearly attempting abuse? Logically either they are compromised or malicious. At least after certain number of failed request. And thus should be treated as such.

One problem here is that you can execute these unauthorized S3 requests without having an AWS account at all.

Re: How an empty S3 bucket can make your AWS bill explode

#65

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…

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...

Re: How an empty S3 bucket can make your AWS bill explode

#67

Today I was hit by a surprise 500$ bill by using byte range request within zip files without an upper bound, but not consuming the whole stream. I tested for about 45 min at about 1gbps. My ISP meter says I downloaded 300gb which lines up with physics, but AWS says it was 6000gb. My first thought is that can be abused to multiply the damage if you want to engage in some cost based denial of service. About every other…

To preface this comment, I'm not super familiar with range GETs or the library you're using. Are you saying that the library was performing range GET requests but instead of sending a byte range, it was only sending a starting byte number?

> Today I was hit by a surprise 500$ bill by using byte range request within zip files without an upper bound, but not consuming the whole stream. I tested for about 45 min at about 1gbps. My ISP meter says I downloaded 300gb which lines up with physics, but AWS says it was 6000gb.

Re the bill itself - You may be able to get the surprise bill waived by AWS with a support request, especially if you haven't had to do that before.

Re the metered billing - This isn't super clear anywhere I could find in the AWS docs, but I think from AWS's perspective your network data transfer out from S3 is the amount of data you requested + initiated, not what your app ultimately happened to consume from the stream. They really do not make this clear though, which might help your case.

FWIW, it sounds like AWS's implementation is behaving consistently about "range specifiers" with the RFC they link to in the S3 docs.

https://www.rfc-editor.org/rfc/rfc9110.html#section-14.1.1-4

Sidebar, but: If it works for your setup, I think putting a CloudFront distribution in front of the bucket and accessing that way would mitigate the damage by caching the whole object after the first request. I've used a setup like this for streaming very large files to many viewers before.

https://docs.aws.amazon.com/AmazonCloudFront/latest/Develope...

Re: How an empty S3 bucket can make your AWS bill explode

#68
post #51
post #49

Earlier quoted context omitted.

Shield Advanced claims cost protection, although as always, the devil is in the details... - https://aws.amazon.com/shield/features/ "AWS Shield Advanced comes with DDoS cost protection to safeguard against scaling charges resulting from DDoS-related usage spikes on protected EC2, ELB, CloudFront, Global Accelerator, and Route 53 resources. If any of these protected resources scale up in response to a DDoS attack, yo…

Shield Advanced is $3000 per month with a 1 year commitment, plus extra bandwidth fees on top of your existing bandwidth fees, I somehow doubt that many of the users who would be impacted the most by an unexpectedly large bill (individuals and smaller businesses) are proactively paying that much for DDoS insurance just in case.

I think CloudWatch billing alarms [1] are the only viable "solution" for an average joe here. Of course, they do not actually stop the usage, but at least they bring automated awareness.

Even with that, there's no easy way to rename an S3 bucket [2], plus doing so would commonly require updating config + re-deploying any apps using the bucket too...

All of this to say, the customer level really feels like the wrong layer of abstraction to solve this problem.

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

[2]: https://stackoverflow.com/questions/41511034/how-to-rename-a...

Re: How an empty S3 bucket can make your AWS bill explode

#69
post #9

Earlier quoted context omitted.

That doesn't work, the standard endpoint always remains available.

I assume random names are the only way forward. Unfortunately a bucket name can’t be longer than 63 characters.

You can stuff >256 bits into 56 BASE32 digits. The 63 character limit seems like it would only be constraining if humans want meaningful bucket names.

Re: How an empty S3 bucket can make your AWS bill explode

#70
post #51

Earlier quoted context omitted.

Shield Advanced is $3000 per month with a 1 year commitment, plus extra bandwidth fees on top of your existing bandwidth fees, I somehow doubt that many of the users who would be impacted the most by an unexpectedly large bill (individuals and smaller businesses) are proactively paying that much for DDoS insurance just in case.

I think CloudWatch billing alarms [1] are the only viable "solution" for an average joe here. Of course, they do not actually stop the usage, but at least they bring automated awareness. Even with that, there's no easy way to rename an S3 bucket [2], plus doing so would commonly require updating config + re-deploying any apps using the bucket too... All of this to say, the customer level really feels like the wrong l…

[deleted]
Post reply on HN