What caused the reduction in your hosting bill? Was it Amazon's supposedly-poor cache hit ratio, or a CloudFlare-specific feature? Have you tried negotiating with a larger CDN?
CloudFlare typically reduces bandwidth usage and load by about 70%. That can translate into cost savings if your host (e.g., AWS) charges you for bandwidth.
> CloudFlare typically reduces bandwidth usage and load by about 70%.
How does it do this? I'm going to be flipping our content-service from IIS to CloudFront soon so I'm familiar with CloudFront on a theoretical level. Not clear on what you mean.
One big thing they do is cache static assets for you at their edge locations. The majority of the bandwidth costs imposed by static images, CSS and JavaScript (assuming appropriate cache settings) should be offloaded onto CloudFlare once you set it up.
This is what any CDN does, including CloudFront (although supposedly CloudFront's cache hit ration is fairly low). The specific issue at hand is in what way CloudFlare (a CDN) saved more money than CloudFront (another CDN): neither "it typically saves money" (eastdakota's answer) nor "it is a CDN" (effectively your answer) answer that question: these are both nothing more than tautologies restated from the initial question, and do not help someone attempting to compare these two services. (Personally, I use CDNetworks, after having used EdgeCast for a while and evaluating Akamai for my use case; I personally see no reason why I would use CloudFlare, but am always curious.) (Is the issue simply that CloudFront is so expensive that you don't feel you are saving much money? Hence my question then about negotiating with a larger CDN, such as any of the ones I was working with.)
Well, yeah, but my point is that CloudFront does this too. The quote I selected made it sound like CloudFlare reduces bandwidth usage by 70% in comparison to CloudFront. So I'm curious how that works.
$3k/mo buys you a lot of bandwidth, though; even at CloudFront's somewhat-high-for-a-CDN pricing, that's 30TB of bandwidth; to see a 95% reduction in your hosting costs over CloudFront with $3k/mo unmetered bandwidth you'd have to be pushing 1.8PB of data. (edit: I originally said 600TB, but I had done the math wrong for the later discount brackets.)
Even if you were down at the $200/mo plan, that's 45TB/mo before you get to the "95% less expensive" point; I have tens of millions of users worldwide downloading megabytes of packages from me (while the Cydia ecosystem has tons of things much larger, I don't host those: I just have the core package), and I don't often go above 45TB/mo.
Is the idea here that CloudFlare is seriously giving you ludicrously unlimited amounts of bandwidth (and will not give you any crap about it) with a high cache-hit ratio even at their $20/mo plan? If so, I'm going to have to run some insane experiments with their service ;P. (Part of me isn't certain that I want them to hate me that much, though ;P.)
(edit:) Ok, I looked into this some, and this argument ("they don't charge for bandwidth") is just as false as one would expect given that it isn't feasible of them to price that way ;P. Their terms of service makes it very clear that they are only designed for HTML, and that "caching of a disproportionate percentage of pictures, movies, audio files, or other non-HTML content, is prohibited" <- yes, even "pictures".
With this glaring restriction, there is really no way I can imagine any reasonably-normal company getting a 95% reduction in hosting costs over another CDN, even CloudFront: if you are pushing tens of terabytes of mostly-HTML content a month, you are doing something insanely awesome (and we've probably all heard of you ;P).
If it's web content, go right ahead. We have many very large sites using the free plan. From your use, it sounds like you're using a CDN for file distribution (i.e., sending out large package files), not traditional web content. CloudFlare isn't designed for that use case. We're also not setup for streaming content (e.g., if you're running a streaming server for video). In both those cases, you're likely better with a traditional CDN. However, if you're using us for traditional web content, there are no bandwidth caps even on the free plan.
We're running some e-commerce sites with 8-20k items through the $20/month plans and have never heard a complaint from Cloudflare. That said, any sites we 'care' about are running on their business or enterprise levels which are much higher than $20/month :P.
Probably you won't see this reply, but if you do... we move a decent amount, but not a crazy amount. In the last 30 days it was around 3TB total (through Cloudflare... we only saw about 2/3 of that).
Can you elaborate on CloudFronts "poor cache hit ratio"? Wouldn't this just be up to the origins use of cache headers (cache-control, expires, etc)? I suppose cold content could be LRUd out, but the CloudFront docs advertise advertise 1 day last I looked. PS CloudFront customer access logs include cache result (hit/miss/error) so you can see for yourself.
One of the main ways that CDNs compare with each other is how well they manage to actually cache content and not have to go back through to your origin server; I see a lot of developers go the path you are, saying "well, that's fixed, isn't it?", but if you think about the architecture of how you build a CDN, you rapidly see that that doesn't really make sense.
Yes: if you had a single server somewhere out in the cloud that was sitting in front of yours as a cache (which is how most developers seem to conceptualize this: such as running a copy of Varnish), it is easy to say "ok, I'll cache this for a day"; however, you first are going to run into limits on what can be stored on that box: there is only so much RAM, and it doesn't even make sense to cache everything anyway.
You can spill the content to disk, but now it might actually be slower than just asking my server for the content, as my content might have it in RAM. This is a major differentiating factor, and some CDNs will charge more to get guaranteed access to RAM for either certain files or in certain regions or for certain amounts of data, as opposed to getting spilled off to some slower disk. However, there is also only so much disk.
Even with an infinitely large and very fast disk, though, you don't have one server: in an ideal situation (Akamai), you have tens of thousands of servers at thousands of locations all over the world, and customers are going to hit the location closest to them to get the file. Now: what happens if that server doesn't have the file in question? That is where the architecture of how you build your CDN really starts to become important.
In the most naive case, you simply have your server contact back to the origin; but, that means as you add servers to your CDN, you will require more and more places that will need a copy to get cached. This isn't, in essence, a very scalable solution. Instead, you want to figure out a way to pool your cached storage among a bunch of servers... and somehow not make that so slow that you are better off asking my server for the original copy.
You then end up having bigger servers in each region that a front-line server can fall back on to get the cached copy, but that server is now going to become more and more of a centralized bottleneck, as more and more traffic will have to flow through it (as a ton of stuff always ends up not being currently warm in cache). It also eventually looks more and more like the centralized server straining for storage, and will have to evict items more often.
Some places might spend more time trying to specialize specific front-line servers for specific customers (some kind of hashing scheme), but then the CNAME'd DNS gets more complex and is less likely to be cached in whatever ISP this is, or you can attempt to distribute routing tables between your own servers for where to find content, etc.; this simply isn't a simple problem, and certainly doesn't come down to something as simple as "well, I told them to cache it, so they did: read my Cache-Control headers".
In some cases, you might even "well ahead of time" go ahead and download a file that you think might be valuable to other regions; you might also attempt to optimize for latency, and do prophylactic requests for things that clients haven't even asked for yet, so you can get them cached and ready for when they do (CDNetworks, for example, normally re-request files that are actively used when they are still 20% away from expiring, to make certain that the file never expires in their cache, which would cause a latency spike for the poor user who first requests it afterwards).
> ... Cotendo pre-fetches content into all of its POPs and keeps it there regardless of whether or not it’s been accessed recently. Akamai flushes objects out of cache if they haven’t been accessed recently. This means that you may see Akamai cache hit ratios that are only in the 70%-80% range, especially in trial evaluations, which is obviously going to have a big impact on performance. Akamai cache tuning can help some of those customers substantially drive up cache hits (for better performance, lower origin costs, etc.), although not necessarily enough; cache hit ratios have always been a competitive point that other rivals, like Mirror Image, have hammered on. It has always been a trade-off in CDN design — if you have a lot more POPs you get better edge performance, but now you also have a much more distributed cache and therefore lower likelihood of content being fresh in a particular POP.
Given all of this, what I've heard from people using CacheFront that have shopped around and know enough to pay attention to this kind of metric is that their cache-hit ratio is somewhat poor in comparison to other CDNs you might use. I am thereby curious if that's one of the things that is causing CloudFlare to come up much better than CloudFront, if it is a specific feature from CloudFlare that is helping, or if it is just that CloudFront is so expensive in general (bandwidth from CloudFront is ludicrously bad: even Akamai tends to hit you with initial quotes that are better than what CloudFront offers; but 95% reduction in price seems "unbelievable").
