3 ms·
Certainly if you are charging for internet egress. Like, charging for requests or internal data processing, sure okay. But this is a charge specifically for t
by paulddraper 3y ago
Certainly 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 3y 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 3y agoSure. In this case specifically AWS is attempting to transfer 70Gbps through a 1Gbps pipe. Not a rounding error.
- deleted 3y ago[deleted]
- klabb3 3y 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.