[__roland__]

Sorry for not having this made clearer (we'll fix this part of the post): the gotcha is not that AWS does not honor range requests, it's that canceling those will still add the full range of bytes to your egress bill (and this can add up quickly) although no bytes (or much fewer) have been transferred.

[alchemist1e9]

On the other hand you did ask for them so what does it mean “canceling”? Just playing devil’s advocate that they did likely start getting the data for you and that takes resources. Otherwise they would be open to a DOS attack that initiates many requests and then cancels them.

[__roland__]

Sure, that's true. The thing is: this was the same requested (and cancelled) range on the same file(s), over and over (it was a bug). Looking at this from the outside, even some internal S3 caching should have had many cache hits and not have to re-download the requested ranges internally all the time (there were dozens of identical requests per second, immediately being cancelled).

On top of this, S3 already bills (separately) for any request against a bucket (see the other current issue with the invalid PUT requests against a secured bucket, which still got billed to the bucket owner; https://news.ycombinator.com/item?id=40203126). So I'd say both the requests and the cancellations were already paid for; the surprise was the 'egress' cost on top, of data that was not actually leaving the AWS network.

Still, you are right that this still consumes some additional AWS resources, and it is probably a non-trivial issue to fix in the 'billing system'.