4 ms·
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
by fabian2k 2y ago
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.
- paulddraper 2y agoCertainly if you are charging for internet egress. Like, charging for requests or internal data processing, sure okay. But this is a charge specifically for the data transferred from AWS to the internet. So if you're not transferring data to the internet....
- fabian2k 2y agoThe part where I think there is some flexibility is about the difference between "bytes attempted to transfer" and "bytes actually transferred". I think it is pretty fair to bill for the former, as long as you abort requests in a reasonable way. So I don't expect it to be billed exactly by the transferred byte, but I do expect it to not go above that higher than whatever the chunk size for transferring is.
- paulddraper 2y agoSure. In this case specifically AWS is attempting to transfer 70Gbps through a 1Gbps pipe. Not a rounding error.
- deleted 2y ago[deleted]
- klabb3 2y agoThat’s an orthogonal issue. There’s no interpretation of “egress” that means “stuff we do internally before leaving aws data centers”. If the tcp conn is reset only a few MB would leave aws frontend servers. Instead, it appears they’ve been basing the number off the range in the request and/or whatever internal caching/loading they’re doing within S3, which again has nothing to do with egress. I mean, we already know egress is short for egregious. It’s an incredibly bad look to be overestimating the “fuck you” part of the bill.