Live data from Hacker News

CloudFront vs. Cloudflare, and how to reduce response times for both (2021)

foxy.io

51–57 of 57 posts

Re: CloudFront vs. Cloudflare, and how to reduce response times for both (2021)

#51
post #12
post #5

Earlier quoted context omitted.

Price is the main difference between AWS CloudFront/Fastly and CF. In most cases, CF prices are fixed, like $200 for business or $20 for the pro plan. If you like fixed prices VMs from Linode or DO, chances are high that you will like Cloudflare too. Of course, advanced addons features like CF Argo and CF Bot management cost more money at Cloudflare too.

While that lasts, you can't be charging a flat $200 in a world where the other players are charging 5-10¢/GB of egress.

Erm... why not? Everyone knows cloud providers are gouging customers on egress bandwidth fees, it's great that someone bucks the trend and calls them out on it.

Re: CloudFront vs. Cloudflare, and how to reduce response times for both (2021)

#52

Earlier quoted context omitted.

Out of curiosity, what makes Clousflare's WAF so much better?

CF have more options, filters, settings, realtime reports, rules and statistics.. Additionally CF ofers a good set of system managed WAF rules that you can simply active and CF will manage it for you. With AWS you're basically on your own. More or less is a bare bones WAF tool.

This isn't accurate. AWS added Managed Rulesets several years ago: https://aws.amazon.com/marketplace/solutions/security/waf-ma...

Re: CloudFront vs. Cloudflare, and how to reduce response times for both (2021)

#53
post #48

IMO Perfomance wise CloudFront and Cloudfront are quite similar. I've migrated from CloudFront+AWS WAF to just CloudFlare given Cloudflare's superior (100x better) WAF/Firewall/DDOS protection at a lower cost

> IMO Perfomance wise CloudFront and Cloudfront are quite similar. Yes I don't think the capitalization has too much impact.

No post body was provided.

Re: CloudFront vs. Cloudflare, and how to reduce response times for both (2021)

#54
post #15

TLDR, adding an "edge" in front of your application incurs a connection setup cost which can be 2-3x RTT and is especially noticeable when you don't have a large QPS and are in a region like APAC where geographically close networks often have high latencies between each other. Both Argo and OriginShield seem to pool more aggressively, often going cross-datacenter to avoid hitting origin which sometimes saves this set…

depending on your origin and your users, having TLS terminate / be negotiated at the edge should _reduce_ your connection setup cost, by reducing RTT time for the handshake to the end user (typically the slowest bit / longest tail).

If you have 1 origin region/server and globally distributed users, in the data shown the RTT from Sydney could be 1000ms, so TLS negotiation of 3 roundtrips could be 3000ms. If you terminate TLS at the edge that could be order of magnitude less.. not more? depends on your setup though.

Re: CloudFront vs. Cloudflare, and how to reduce response times for both (2021)

#55
post #26

Anybody using Cloudflare to cache an API that serves JSON? Thinking about setting that up.

We managed to get it working for analytical SQL queries [1] for our database. It's kind of questionable whether this is an intended use of Cloudflare, but it feels like it, since we use it for query results, which are essentially a static asset in our use case (dashboards and visualizations).

[1] https://www.splitgraph.com/blog/seafowl-sql-cdn

Re: CloudFront vs. Cloudflare, and how to reduce response times for both (2021)

#57
post #15

TLDR, adding an "edge" in front of your application incurs a connection setup cost which can be 2-3x RTT and is especially noticeable when you don't have a large QPS and are in a region like APAC where geographically close networks often have high latencies between each other. Both Argo and OriginShield seem to pool more aggressively, often going cross-datacenter to avoid hitting origin which sometimes saves this set…

depending on your origin and your users, having TLS terminate / be negotiated at the edge should _reduce_ your connection setup cost, by reducing RTT time for the handshake to the end user (typically the slowest bit / longest tail). If you have 1 origin region/server and globally distributed users, in the data shown the RTT from Sydney could be 1000ms, so TLS negotiation of 3 roundtrips could be 3000ms. If you termin…

This is true, on average having an edge will be faster, but it is not a panacea for latency, especially if you don't move non-trivial QPS from every region.
Post reply on HN