https://news.ycombinator.com/item?id=40203126 https://news.ycombinator.com/item?id=40221108
Those are about a different issue - not a great time for S3 billing!
The AWS S3 Denial of Wallet Amplification Attack
11–20 of 97 posts
Re: The AWS S3 Denial of Wallet Amplification Attack
#12https://news.ycombinator.com/item?id=40203126 https://news.ycombinator.com/item?id=40221108
Those are about a different issue - not a great time for S3 billing!
Correct. Its a like a game of negative chess. Wins who racks the biggest bill, in the shortest amount of time, with the least amount of activity :-)
Re: The AWS S3 Denial of Wallet Amplification Attack
#13Earlier quoted context omitted.
That sounds egregious enough that I have trouble believing this can be correct. My understanding is that AWS bills for egress for every service, parts of the file that aren't transferred are not part of this so can't be billed. There could certainly be S3-specific charges that affect cases like this, no idea. But if AWS bills the full egress traffic costs for a range request I'd consider that essentially fraud.
https://github.com/ZJONSSON/node-unzipper/issues/308
tl;dr
AWS user believes that testing on a 1Gbps connection for 45 min can't be more than $10 of egress.
Gets a $500 bill instead.
Note: This user specified a lower range but not an upper range on the request (and closed the connection prematurely). Essentially read() with an offset, for a ZIP tool.
Re: The AWS S3 Denial of Wallet Amplification Attack
#14> Potential remedies - Stop using S3 and other AWS (perhaps it stands for Amazon Web Scams?) things already and switch to Cloudflare R2...
CIAWS
Re: The AWS S3 Denial of Wallet Amplification Attack
#15Earlier quoted context omitted.
https://github.com/ZJONSSON/node-unzipper/issues/308
tl;dr AWS user believes that testing on a 1Gbps connection for 45 min can't be more than $10 of egress. Gets a $500 bill instead. Note: This user specified a lower range but not an upper range on the request (and closed the connection prematurely). Essentially read() with an offset, for a ZIP tool. See also: https://news.ycombinator.com/item?id=40205213
So I guess the attack of the OP is a case AWS calculate price based on the unbounded request header and not on the actual egress
Re: The AWS S3 Denial of Wallet Amplification Attack
#16Earlier quoted context omitted.
https://github.com/ZJONSSON/node-unzipper/issues/308
tl;dr AWS user believes that testing on a 1Gbps connection for 45 min can't be more than $10 of egress. Gets a $500 bill instead. Note: This user specified a lower range but not an upper range on the request (and closed the connection prematurely). Essentially read() with an offset, for a ZIP tool. See also: https://news.ycombinator.com/item?id=40205213
There is probably a small area where it's difficult to measure, so I would not expect billing to be exact to the byte here. But billing for the requested range if not the entire range was actually transferred is just not correct and not acceptable.
Re: The AWS S3 Denial of Wallet Amplification Attack
#17Why is anyone using S3 when Cloudflare R2 is free?
Re: The AWS S3 Denial of Wallet Amplification Attack
#18Hate that it's essentially half ChatGPT generated. Especially given the huge explanation of AWS.
Re: The AWS S3 Denial of Wallet Amplification Attack
#19Earlier quoted context omitted.
tl;dr AWS user believes that testing on a 1Gbps connection for 45 min can't be more than $10 of egress. Gets a $500 bill instead. Note: This user specified a lower range but not an upper range on the request (and closed the connection prematurely). Essentially read() with an offset, for a ZIP tool. See also: https://news.ycombinator.com/item?id=40205213
So I guess the attack of the OP is a case AWS calculate price based on the unbounded request header and not on the actual egress
More or less. The article quotes AWS as saying the following:
> Amazon S3 attempts to stop the streaming of data, but it does not happen instantaneously.
...which doesn't really explain it. It shouldn't send more than a TCP window after the connection is closed, and TCP windows are at most 1 GiB [1], usually much less, so this completely fails to explain the article's observed 3 TB sent vs 130 TB billed.
The article goes on to say:
> Okay, this is half the explanation. AWS customers are not billed for the data actually transferred to the Internet but instead for some amount of data that is cached internally.
In other words, how much they bill really isn't bounded by how much is sent at all. This is unacceptable.
Re: The AWS S3 Denial of Wallet Amplification Attack
#20"Denial of Wallet" seems a misnomer--it makes it sound like source of payment is being blocked. They should really use the same term cellular systems have been for decades to describe this kind of threat, namely an "overbilling attack".