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'.
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.
I can assure you this was not AI-generated, apart from the 'symbolic image' (which should be fairly obvious :).
Maybe that's just our non-native English shining through. In any case, as a small European company in the healthcare space, we are quite used to having to explain "the cloud" (with all potential and pitfalls) to our customers. They are also (part of) the target audience for this post, hence the additional explanations.
(Not OP and not author of the article, but was involved in the write-up.)
You are right, this is about canceling range requests and still getting billed, not about requesting ranges and getting billed for the complete file egress. Sorry; we'll make the post clearer.
Sorry, I think that part of our write-up is misleading (I was involved in analyzing the issue described here). To our best understanding, what happens is the following:
- A client sends range requests and cancels them quickly.
- The full range request data will be billed (NOT the whole file), so I think this should read that the entire requested range gets billed, even if it never gets transferred (the explanation we received for this is that it's due to some internal buffering S3 is doing, and they do count this as egress).
In any case, if you send and cancel such requests quickly (which is easy enough, this was not even an adversarial situation, just a bug in some client API code) the egress cost is many times higher than your theoretical bandwidth (and about 80x higher than in the AWS documentation, hence the blogpost).
You are right: the horizontal scroll only appears if you scroll down to the bottom of the page. But there is also a (more sensibly layouted) program shown on each streaming page (e.g. https://streaming.media.ccc.de/rc3/two, "Fahrplan" tab)
Just as an anecdotal counterpoint to all the negative reviews here: I have a 2015 Tuxedo notebook that is still going strong, and never had any issue with it. There is quite a bit of fan noise, which I don't hear as I'm typically using a noise-cancelling headset anyway. The keyboard is rather flimsy and the build quality is definitely not on par with Dell XPS or a T-series Lenovo, at least for this model: in my use case (using external keyboard and monitor 99% of the time) this is not an issue, so I'm (still) quite happy with it. As others have already said, the pricing is hard to beat and its Ubuntu setups are well configured.
I also had very positive interactions with their support staff; very friendly and knowledgeable. I have yet to see a piece of Tuxedo hardware fail, and know several people who are using their hardware (both laptops and workstations, which are even nicer and have a much better build quality IMO).
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'.