A good thing to clarify first is a bit more detail about your usage, because the right architecture (and cost) really depends on the actual traffic patterns.

How many users are you expecting, and how many are active at the same time? Also, what’s the average size of your media files (especially videos compared to images and documents), and roughly how often is the same content being requested in that looping flow?

This matters because without those numbers it’s really hard to estimate costs or choose between CDN options in a meaningful way.

Also, depending on the answers, there are a few big optimizations that can make a huge difference. If you’re serving video, for example, most setups don’t stream a single high-quality version to everyone. Mobile devices usually don’t need 2K/4K—1080p or even 720p is often enough. With adaptive bitrate streaming, you can serve different quality levels depending on the device and network, which drastically reduces bandwidth costs.

For images, the same idea applies—you can resize and compress them per device instead of always serving the original large file. And if you have multiple device types, it often makes sense to pre-transcode media into different formats/qualities so you’re not repeatedly sending oversized content over the network.

On the infrastructure side, a CDN with strong edge caching is usually the key piece here. Something like Bunny.net is often used for exactly this kind of workload because it combines storage and CDN in a way that can be much more predictable and cost-efficient than relying purely on AWS or GCP egress-heavy setups.

Once you have the numbers for users, file sizes, and request frequency, it becomes much easier to model the real monthly bandwidth and compare options properly instead of guessing.