The simplest option if you are concerned about billing is to use prepaid credits:
So e.g buy $10 of credit.
You can greatly limit even the potential for costs by not using e.g auto-scaling. With Fly, by default that is turned off. So if you only create e.g 1 vm, that is all the compute capacity you can be billed for. If it were to get a billion requests, it will simply not be able to respond. Your site/app would be down as a result, but you would not be billed for more compute than that 1 vm. As that is all you have 
.
Since one of the things that causes large AWS bills is using their auto-scaling options which happily increase compute based on load (whether using EC2 instances, or serverless Lambda). As they provide you basically infinite computing power (which some large companies need) and the only way you can really know about it is with billing alerts. By which time it is too late. And yes, there have been some horror stories!
The other potential for a big surprise bill is bandwidth. The good news is that Fly’s bandwidth is much cheaper than AWS’s bandwidth. So the cost risk is lower already. But as you mention media files, that would be my concern. Since if you are serving e.g video files and know they are big, if they get linked somewhere popular, that could easily result in a large bandwidth bill. I don’t know what setup you have (such as whether the media files are cached from S3, streamed etc) but I’d focus on that. Optimise cache headers, maybe use a free CDN such as Cloudflare to offload requests (they don’t allow streamed video … not sure what Fly’s policy is regarding that). What you would want to be avoiding is lots of requests being served from S3. Because you pay per request and also per GB and that can certainly get expensive, fast. I read a horror story recently about AWS Cloudfront (the AWS CDN in front of S3). In that case, AWS were good enough to refund the user for the enormous cost but you can’t rely on that.