Comment by nicoburns
5 years ago
I definitely empathise with the difficult in competing with the big cloud providers on price. Your service is inevitably going to end up more expensive. Having said that, I'd be interested to know how you're hosting the content.
When I was looking at setting up a similar service, it seemed like you Backblaze B2+Cloudflare might well be the best combination. B2 will sell you storage at $5/TB, and you can get free bandwidth out to Cloudflare's network. It's against Cloudflare's terms to use free plan for image hosting that isn't just images as part of webpages. However, one of their staff members commented on a thread that they'd likely to be willing to set up a custom plan for a business who wanted to do this. And I'd bet that Cloudflare's bandwidth would be a lot cheaper than B2's.
Pre-signed URLs generated with B2's S3 APIs are incompatible with Cloudflare at the moment. We are working around this by using a Cloudflare Worker to proxy data from B2 to the client. This is currently free if you're on the Bundled plan and Cloudflare's support has promised that when they decide to start charging, they will alert us in advance.
Interestingly, Workers Unbound charges 0.045/GB which is more than B2's 0.01/GB.
A viable long term alternative could be Wasabi that offers free egress in return for a $6/TB plan. But we're waiting to see how things pan out before executing an expensive migration.
When you say incompatible, are you talking about the cache not working or something else? How are you working around this using workers?
B2 documentation suggests that after adding a CNAME (eg. cdn.ente.io) for their bucket endpoint (eg. bucket.s3.eu-central-003.backblazeb2.com), you will be able to replace the latter with the former. This breaks with the native B2 APIs with the following error:
```
{
}
```
The last I checked was a few months ago, not sure if things have been fixed now.
With Workers, we simply fetch the remote resource from B2 and return it back to the client, acting as a thin proxy.