Yes. The case where it's much more useful is traffic going in/out of major CDNs to shared IP addresses. For Netflix or someone else running their own CDN the gains are much smaller.

So ISPs could still impose traffic shaping on Netflix if they wanted to, I take it? I can't see how Netflix could prevent this. Ultimately, their servers ('OCAs') have easily detectable IP addresses, right?

Fast.com probably helps quite a bit. If ISPs throttle Netflix' traffic their fast.com measurements will look bad and customers will complain/sue. (AFAIK there's no way to distinguish between fast.com tests and actual Netflix video consumption since the former's traffic patterns are identical(?) to a Netflix video streaming client's.)

Creating fast.com always seemed like a pretty brilliant move by Netflix to me.

I think that was the whole point of fast.com, right? Speeds to known 'speedtest' servers were manipulated by ISPs, and this was bad for Netflix's business because customers would ostensibly have good speeds yet have slow Netflix, so fast.com was created as a way to measure the 'real' speed to Netflix's servers.

Yeah, that's what I was saying (or at least trying to say).

Good point. Smaller players can't make the same move though.

Both the replies here miss the fact that the relationship between Netflix and ISPs is often pretty cooperative. Specifically, Netflix will provide ISPs with devices to do caching. The ISPs need to install and run these devices, configure the routes to send traffic to them, etc etc. Details: https://openconnect.netflix.com/en/. Because of that (and various other things), it's very easy for ISPs to attribute traffic to Netflix.

IIRC netflix mostly use AWS these days. So checking IPs will just check for anything AWS hosted.

For the web site and UI, yes. But the actual video traffic comes from a private CDN: https://openconnect.netflix.com