I have a hobby portfolio site on the free tier and really enjoy how easy the platform is to develop on. I’m running Django connected to an S3 bucket for media files, and so far my bill is $0/month and everything just works.
However, there are many stories on sites like Hacker News of people getting burned with huge surprise AWS bills, and similar discussions from those hesitant to try fly.io for the same reason.
These stories have me spooked enough to wonder if I’m one typo away from fly sending me a massive bill. As a non-business, I’d almost rather pay a guaranteed $10/month than $0/month with an unlimited cap.
Are these horror stories common or am I just being paranoid?
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.
Thanks @greg. That’s a nice overview of the gotchas. I have autoscaling off and am only storing small images files in S3. The files themselves are served through Cloudfront. I keep forgetting about the ability to purchase credits and will probably do that for some insurance.
I realize it’s a PaaS trope to worry about the monstrous surprise bill, but as a hobbyist there’s always a non-zero chance of making a dumb misconfiguration somewhere. I became interested in fly because it abstracts away a ton of devops and sysadmin hassle and made deploying a toy site really easy. Autoscaling is of little use to me but also the one thing that makes me nervous.
It’s an entirely reasonable concern. It’s very easy to run up a huge bill with AWS. Weird how they make it so easy to do that!
Image files are less of a worry than videos. However it is worth being aware that AWS Cloudfront charges per request, in addition to bandwidth. It’s not much but those dollars can also add up on a popular site. You could perhaps use a CDN that does not charge per request like Cloudflare or Stackpath, or even move that part inside Fly too (e.g Appkata: MinIO - S3 Compatible Storage · Fly Docs)
@greg mentioned a lot of great things to think about, and it sounds like you’ve set things up to keep costs fairly predictable and contained.
If it’s at all reassuring, we’ve been known to refund the odd surprise bill. It doesn’t happen much, but we’re not really interested in making money from some misconfiguration that accidentally generated a bunch of unexpected usage. If it ever comes up, let us know so we can help you out!
I’ve come to ask basically the same question, but actually I’m wondering if there’s any way to make it so that services will just stop instead of my getting billed beyond a certain point. The dashboard says “Payment Method: Charged automatically” which would seem to imply that there’s a way to make it act differently, but I can’t see how to do that?
no worries-- it can be helpful sometimes to have related questions nearby
If you’re worried about billing and would like to set a spending limit, we can help out with this. You can add some prepaid credit to your organization (prepaid credit can be added in amounts larger than $25). Then, send us an email (billing@fly.io) so that we can set your organization up so that you won’t be charged if you exceed the amount of credit you have loaded.
Being a hobbyist and having no experience with cloud deployment, I would like to protect myself from unexpected costs with a prepaid credit, but I think $25 is too much just to test the platform. If I were to test 4 different platforms in this way I would spend $100 and give away $75 after choosing one of the platforms. So my request is simple: can you lower or rather eliminate the minimum amount of prepaid credit that can be purchased?
We’re not going to lower the minimum prepaid amount.
It’s difficult to have burst usage that grows unexpectedly on Fly.io. With the exception of bandwidth, everything we bill for requires manual provisioning.
We’re comfortable with this setup, and think it’s a good balance between helping you manage your costs and the level of engineering effort on our end. In general, we’re not going to put a lot of time into preventing you from provisioning paid resources. We’d much prefer to refund mistakes after the fact.
@bman wanted to point out that, although you mentioned just small image files, Cloudflare R2, which is mostly S3 compatible, might be a cheaper option than AWS S3, especially as they don’t charge for bandwidth.
Also see: S0 aka AWS Lightsail Object Store which is fully-compatible with S3 and cheaper (but not as cheap as R2, so moving soon to it, anyway). Right now, we front S0 with Lightsail CDN and Cloudflare CDN.
Hi @eli I sent an email to billing@fly.io on 1/4/2023 regarding this issue but I haven’t heard back yet.
My issue was that I added a credit card before I knew you could purchase credits. Then I purchased credits and now I’d like to remove my credit card so that its not charged beyond the $25 credit. Not sure if that is possible?
.
