Cloudflare + Backblaze B2 (or Wasabi) beats this hard. They are Bandwidth Alliance partners, so you won't incur egress traffic cost in B2 side. Cloudflare's Free plan is more than enough in most cases. Also B2 gives you free 10 GB storage when you sign up.
79 cents cheaper = "beats this hard" with no analysis of the performance or reliability differences? Or even time to set up? B2 is still missing basic website functionality that you have to code and test yourself. [1]
Cloudflare has way more points of presence than AWS Cloudfront even inside US and Europe, set aside countries like Russia or Australia. There's no point using Cloudfront unless you deeply integrated into AWS or negotiated serious price discount.
I have some clients that use Cloudflare, and others that use CloudFront. All of the CloudFront sites perform far better than all of the Cloudflare sites.
I don't care how many points of presence Cloudflare has if the performance is worse.
As I stated, they are client websites, which I don't particularly feel like disclosing. It's trivially easy to find benchmarks. [1] is old, but it gives you an idea of the stark differences that I have seen in practice.
Cloudflare blocks Tor users unless they solve a Google CAPTCHA and
accept cookies. By saving money you limit your audience and make
the world a worse place.
Have you tried visiting a Cloudflare-protected site using the TBB recently? (as in within the last few years?). We don't block Tor users. I use TBB to browse and don't see this problem.
> Users are either blocked outright with CAPTCHA server failure messages, or prevented from reaching websites with a long (and sometimes endless) loop of CAPTCHAs, many of which require the user to understand English in order to solve correctly. For users in developing nations who pay for Internet service by the minute, the problem is even worse as the CAPTCHAs load slowly and users may have to solve dozens each day with no guarantee of reaching a particular site. Rather than waste their limited Internet time, such users will either navigate away, or choose not to use Tor and put themselves at risk.
So, if we don't make our websites available in languages used by oppressed peoples, if we don't make sure it's very low latency, and if we try to filter out abusive users, we're making the world a worse place. Not just leaving the world in a bad state, but actively increasing the harm done to the world, just by making a website that not everyone can or wants to use.
Not only do I not buy this argument, it makes me want to support Tor less, if for no other reason than blatantly ignoring why the captchas were put up in the first place.
TOR and most e-commerce aren’t compatible anyhow proper opsec on any anonymizing Network is to not de-anonymize yourself by tying your activity to your identity.
If you use TOR to access services that can be directly correlated to your identity you are simply using a slow VPN at that point.
I am in New Zealand and a company I worked for used Cloudflare and we found out that our site was being served from Japan most of the time (8800 km away). This meant a request would go: Auckland -> Japan -> Sydney (our data center)
The fix was to upgrade to their $200/mo plan and we found we would be served from AKL or SYD most of the time, occasionally still Japan.
This is often an internet routing issue. Also their Argo product can sometimes have bad routes chosen. Did you try their support? As a CDN, they’re very interested in fixing any performance problems quickly.
The two biggest telcos in NZ won't peer freely. At least for the biggest (Spark) Cloudflare delivers from far away.
Also Cloudflare "protected" 8chan during the Christchurch terrorist shooting last year which makes them unpopular in some quarters. I have heard that given as a reason our largest telco won't peer with them.
funny, I have distaste for cloudflare because the ceo “woke up one morning in a bad mood” and decided to boot the daily stormer. Censorship without due process. not trying to debate that decision here, but it seems they got the worst of both worlds.
The Daily Stormer shot themselves in the foot by libeling Cloudflare. Before that CF was perfectly willing to give them service, in the interests of being content-neutral provider, despite believing that the site itself was vile.
CF themselves have raised similar concerns about due process in the way they handled this particular case, but I can understand why they dropped a customer against whom they had a pretty strong case for suing.
You do know The Daily Stormer is a far-right neo-Nazi, white supremacist, and Holocaust denial commentary and message board website that advocates for the genocide of Jews, right?
There's a certain subset of the tech community that entirely doesn't get that words result in real-world harm. It isn't just bytes in a database we can be indifferent to because it doesn't affect anything.
There's a certain subset of the tech community that doesn't get that speech and action are different things, and that either all speech is protected or none is.
Government is different from the private sector but as we rapidly move towards a future ruled by megacorporations, the application of rules and laws becomes ever more important.
> doesn't get that speech and action are different things, and that either all speech is protected or none is.
That only covers how government is supposed to act, right? I mean, a hosting company is free to pick how their service is used. If a client insists in abusing and breaking the law by, say, repeatedly publishing hate speech, doesn't the company has the right to act? I mean, just the reputation hit makes this a business liability.
I covered that in the 2nd paragraph. Publishing hate speech is not against the law, it's not even a real definition. The greater point is that the company can do what it wants but we should be wary as companies turn into major oligopolies/monopolies with arbitrary unaccountable policies. See Youtube and Facebook for the current crisis.
Censorship is something done by the government. Daily Stormer could have easily moved to another provider. Just because Nazis are being kicked off of private platforms doesn't mean "censorship" is being done. I'm kind of taken aback at how you think "due process" which is a legal term would be implemented by a private entity.
That simply isn't true. You can use our free service to run a business and many small businesses do. Larger businesses typically want things we only provide on the pay plans and therefore pay for the service.
That's good to know. The description of the free tier is a bit misleading:
Free
Cloudflare for Individuals is built on our global network.
This package is ideal for people with personal or hobby projects that aren’t business-critical.
Eh, seems like expectations management to me, i.e. "don't blame us if you do something business-critical on the free tier and it goes wrong and you didn't pay for support to get you out of it".
Why do we need to make everything so complicated and fancy? I am not trying to be rude but I hate this trend of everything needs to be hosted on AWS and pay hundreds of dollars.
Why not dump these static files into a shared hosting? It shouldn't cost you more than couple of bucks a month.
You get SSL, Email, sub-domains, SSL, logs and much more for couple of bucks a month.
The article explains how to do it without complicating it with shared hosting, and it only cost $.8/mo for 100k visits.
Not knowing something doesn't mean its complicated, it just means it is unfamiliar, for you. Once you did this several dozen times, its the simplest thing ever.
With AWS, your costs are unpredictable. You could be spammed or some search bots decide to go haywire and you will incur hundreds of dollars.
The second thing is AWS is very expensive for what it does.
Do you need to add DNS records? There is Route 53 which costs extra.
Do you need emails? There is AWS Simple Email which costs extra.
Do you need logs? The storage cost (although little) is added to your bill.
Do you need databases? Do you need support?
All I am saying is that shared hosting should be first considered for static websites.
Flip it around. AWS let's you not pay for things you don't need. Then, if there's a biz requirement for something else, you make that _investment_.
Of course there are alternatives. But shared hosting is a roll of the dice. For a hobby project or POC? Sure, start with shared. But if you're certain shared is not a semi-longer term option don't wasteyour time. Shared is cheap for a reason. Saving a couple dollars will dry up quickly in downtime and headache time.
All of those things cost money and effort to maintain. Im not a super AWS fanboy but each IaaS component is a feature that's easy-ish to do on your own with a server and some software. When you go server less or cloud native you have to really think about the bits of tech that bring real value.
If you look at the free tier limits, and monthly costs. Putting a simple rest app behind API gateway with a few buckets and a little lambda gives you a whole lot of bang for very little cost.
If you're a person in a region and your website is going to get bursty use by people in your region then it's a pretty cheap deal.
Monthly costs < 1 coffee for a blog or some non trivial page.
What you are considering a disadvantage is seen as a strength by others (myself included): you pay only for what you use. No cross-subsidization to services you don’t need!
I see your point, but shared hosting is not a reliable solution. It fails pretty often (for a very short time) because it’s shared. You need a CDN. There are a lot of cheap options.
You can put CloudFlare in front and turn on forced caching for all content. I checked multiple times with @jgrahamc and he assured me (and other people) that the free tier is really free and force caching static files for website (so not massive media hosting) is allowed and OK. You can set edge cache TTL to a month and have CloudFlare keep your site appearing "up" even if the backend server is down completely.
I'm hosting a photo sharing SPA on S3/Cloudfront/Lambda with a robust user system including email verification, and a few GB of image files, and I pay $0.25/month at most. Yeah, it's a personal/friends-only site so it doesn't see much traffic, but that was kind of the point - I wanted to pay next to nothing for this site if nobody visits it, and it is working well for that. $3.00/year is pretty cheap.
You provide a valid point, but where's the hacker factor in choosing something readily available? 100k views for under $1 seems like the true hacker spirit, utilizing whatever AWS offers without breaking the bank.
One point mentioned in the article is the caching for global users and shared hosting does not give you that. At most you can replace S3 with shared hosting, not CDN part.
I have shared + Cloudflare for Spain and Latin America audiences and it works pretty well. IDK AWS is for other purposes, for simple apps it's not worth it IMO.
For the past several years I've been running a 100% static web application that serves rain radar images. It also updates itself periodically using serverless functions currently running on AWS Lambda, but can easily run anywhere else.
This is a very stable architecture for such websites and it's great to see it being widely adopted.
Thanks! The only other costs are the storage of the radar images themselves on S3, last time I checked I store around $1.5's worth of images per month.
No real reason to archive them in the long term, but one day I might start training some neural network on those images :)
My bad for not giving a more appropriate title for the post. You re right this setup does not take the backend APIs into account. In our case we use Lambda for the backend APIs so that is also serverless but I failed to mention it in the post.
Hi, also curious how you integrated WhatsApp messages to user for confirmation? Is it business api and is the pricing an issue? (I’m in India too and think WhatsApp api is a bit expensive especially for a use case where I initiated the messaging like in your case)
Could you elaborate on what part of the maintenance would be messy? I was under the impression that maintaining this would be quite easy because there is no physical server present anywhere in this setup.
Not OP, but I think you should be fine. It can get messy if you're using it as a backend for an application that may at some point have different versions in the field (or dev/testing/staging) so you need to support multiple versions of your APIs. It's not impossible, but it can get messy. If anybody has some good rules/frameworks to organize that kind of thing, I'd appreciate a reply.
I did find one catch with the S3/CloudFront approach, relating to default document, when I was looking at hosting a static Hugo site a few months ago. With S3 web hosting, you can specify a default object which also works for subdirectories (e.g. so http://www.example.com returns http://www.example.com/index.html and http://www.example.com/foo returns http://www.example.com/foo/index.html). With Cloudfront, the default document doesn't apply to subdirectories, which would have broken my site.
(For the author of this article, it looks like the combination of CLoudFront's default document and custom error handling did the job for their site - just flagging this as something to look out for in cases where it doesn't work :-) )
AWS suggest a workaround using Lambda@Edge (https://aws.amazon.com/blogs/compute/implementing-default-di...) to rewrite the requests at the CloudFront layer - but at that point I decided that actually getting the site published was more important than adding more to the technology stack, so it's now happily hosted on Netlify's free tier.
there's a better and simpler workaround; there are two ways of setting up CloudFront->S3 origin. One is to use the S3 as file storage, the other is to use the S3 web site endpoint as a HTTP origin. With the second option, index documents work with directories, as well as S3 redirect rules etc. CloudFront sends S3 a http request as if it were an external web site, but it's all inside AWS so in effect your costs are the same in both options.
Thanks for that - I certainly agree that's simpler than Lambda@Edge, and option well worth considering.
I looked at that approach at the time but didn't go down that route because, as far as I understood (unless I missed something), that would involve having the S3 bucket directly publicly accessible over HTTP (not HTTPS) with the S3-style URLs, including public access. And my main motivation for adding CloudFront to the mix was to support/enforce TLS - I certainly didn't have traffic levels requiring it!
(But, pragmatically, the key risks of someone going to the effort of finding and using the unpublished S3 URL would seem to be be that (a) the site could stop working if I change the hosting and (b) they, through their own choice, aren't using TLS - which, for a static, low-traffic, personal blog, could be considered pretty low.)
Thanks for the information. I guess we never encountered this because our application is in react js framework, so once the build is done it creates just one index.html file and there are no subdirectories.
Yes, plus Cloudflare is free for unlimited traffic. I use it in front of App Engine, and I've served 1m pages in a day for $0 because I don't even hit the App Engine free tier limits after Cloudflare's cache takes the traffic.
Matthew Prince is on-record that Cloudflare Workers are an exception to (unspecified) bandwidth limits in that you're free to use a very large amount of it without having to pay for their Enterprise / Pro / Business plans.
I’d highly recommend looking into Amplify Console for hosting static sites on AWS.
Behind the scenes you’re still running on s3/cloudfront so you don’t need to worry about scalability, but you’ll get automatic https, build and deploy pipeline hooked into your github repo, per branch environments, etc.
I have similar setup but fully automated with GitHub an travis. I use cloudflare instead of cloudfront to reduce cost as well - https://reisinger.co.uk/posts/s3_hosting/
For anyone thinking to simply host assets in S3 (i.e. skip the Cloudfront part), please do not. I'm not sure if it's my ISP throttling it, or the routing, but from where I am in Europe, accessing a file from an S3 bucket in us-east often results in speeds less than 100kbit/s. The same files served from Cloudfront will saturate my connection (gigabit).
Am I missing something? This is not "your entire web application" - this is the static piece of it, it still requires an application server doing the dynamic stuff via XHR.
Bad title. Should say "how to host the frontend to your SPA for pennies on CloudFront + S3"
You should take a look at Amplify (https://aws.amazon.com/amplify/), it will make the whole process considerably less painful, allow you to easily access AppSync (graphql) and Lambda with your code all in one place, then also trigger rebuilds on git commits.
A practical example that happened to my employer recently : we migrated to Microsoft Azure when they opened two datacenters in our country. We didn't have to change any code because we don't use vendor locked solutions.
Any time you want to leave that vendor. If they up their prices greatly, reduce service levels, refuse to give attention to improving service levels.. break a clause in the contract... an so on.
While this is true in theory, I don't recall a single instance of AWS increasing pricing or reducing service levels - not saying that is impossible, but it hasn't happened so far (at least that I remember)
I think hosting files in a S3 bucket with a CDN in front is easy to replace. You can do the same with two Docker containers or host it the same way in many other clouds.
Deploying is also easily scripted using the aws-sdk package, see the docs for .S3 and .Cloudfront. Be aware though that if you have a large amount of files the the cost of invalidations at cloudfront will add up quickly, but you can how ever cherry pick files to invalidate.
Yes but each order has a unique ID which only the customer who placed that order will have access to. If that customer decides to share that URL on his own discretion that is fine by us
CSRF is only needed when you have a dynamic website, when someone can potentially make a request on behalf of someone else (and thus make some malicious changes). If your website is 100% static, there's nothing to change.
