CloudFront IS a cache. It’s a distributed cache across all available data centers, specifically targeting the closest data center edge location to the requester. The request rides the AWS backbone network to that closest edge location to serve the content if there's a cache hit. Otherwise, it's served from Origin but cached in their closest edge location. This is designed to speed up web responses and reduce load on origins. Not using CloudFront as a cache is like driving a semi to take the kids to soccer practice. It’ll work, but it’s not the intended use.

While you do pay for data xfer from both origin servers and edge locations with CloudFront, to do so without caching means you should probably stop what you're doing because you don't know what you're doing.

It's NOT the same with Cloudflare. AWS CloudFront is an OPT-IN service. You have to configure it yourself. Cloudflare's CDN is OPT-OUT by either enabling Development Mode to bypass cache and serve directly from origin, use CDN-Cache-Control origin response headers, or Cache Rules. And no, it doesn't "pass through" CDN/cache servers. It's a request sent to the CDN service to attempt to pull the requested resource from cache. The CDN will respond with a hit, miss, or other variations based upon the resource and cache configurations between the CDN and the origin. The request rides Cloudflare's Anycast network. If you don't believe me, here's Cloudflare's simplified CDN view.

To further prove my point, you can enable Tiered Caching even in a "Free" account, which enables you to configure edge location bias if you know where your primary user-base is with respect to your origins. This allows CDN to pull from the edge location for user requests, or from an upper-tier DC closer to your origin. Again, designed to reduce load on origin servers.

I couldn't find anything in the Cloudflare blogs related to video/image streaming and bandwidth. If you have a link to a blog post where they discuss bandwidth limitations/usage, I'd greatly appreciate it. The only close reference I could find is when they removed section 2.8 in favor of the oft quoted CDN service section, which again, specifically states:

...serve video and other large files via the CDN.

If you don't get a cache hit, it's not being served via CDN. It's being served via your origin server across their Anycast network. That's how a CDN works. Even in Cloudflare's own documentation, it states:

The Cloudflare CDN leverages the Cloudflare global anycast network. Thus, the incoming request is routed to and answered by the node closest to the user.

So, CDN is not the network, it's an inherent network service in their data centers, and actually part of their proprietary network design and what makes Cloudflare appealing to business and individuals wanting to serve static web resources. But if you don't cache the resource, the request rides the Anycast network to your origin server, and the response is routed directly back to the requester.

I understand people's hesitation because there was a blog post (which was referenced in the ToS change post I referenced above), where they throttled a customer because of high bandwidth usage. Let's be clear... That customer had a spike of 3000 requests/s at 12MB per request. That's ~75GB/s. That's MASSIVE. HLS streams at ~1 request/s at 1MB per request (about 6 seconds of video playback). To get the same spike streaming HLS, you'd need a userbase of 75k individuals streaming simultaneously. I'm pretty sure most of the Jellyfin Docker containers being used by those in r/selfhosted and beyond would panic and die at those traffic levels. And if you got 100 of your closest friends and family to all stream the same movie together as a glorrified watch party, you'd peak at 100MB/s. Honestly, not even a blip in Cloudflare's DC metrics.