14 Nov 2012

Tough Varnish - Secure cloud caching for safe & speedy sites

This week we've been helping a client with some Varnish caching. Aside from being a fun project it was a welcome reminder of how easy webserver security can be. Through simple implementation of a remote Varnish cache box not only can your website become lightning fast, it can also become super secure and a breeze to re-instate should the worst happen.
Let's take a look at a basic remote Varnish cache setup on AWS EC2 and run through the simple whys and hows.

Varnish (to quote from their website) "....is a web application accelerator  You install it in front of your website and it will speed it up significantly", and it does, exactly as it says on the tin, and very efficiently. 

A common use case for Varnish is to install it on the same box as your web server (Apache or Nginx) and let it handle traffic requests accordingly, thus alleviating load from the (web) server itself and negating a need for upgraded resource to handle escalating traffic, however as a remote cache (server) it brings into play a whole new level of security and/or load balancing options to multiple backends. 

The following AWS schematic shows an entry level x2 EC2 instance setup with secure lockdown :


What we have here is a (very) simple x2 server (EC2 instance) setup, the Nginx webserver is protected by an AWS security group (SG) with IP, SG and port lockdown between it and the Varnish cache box (also SG protected). There is no access to the Nginx box from the WWW as all DNS (via AWS Route 53) points to the Varnish EC2, which in turn pulls (caches) the website(s) from the backend (or backends) and serves them up accordingly to (web) client requests. Anyone trying to hack into your 'actual' web content won't be able to as it's held securely elsewhere, you can selectively choose what to cache and by selecting appropriate TTL and/or cache time you can ensure 'freshness' of content.

And there's more, you don't even need to use EC2 for your web box, depending on site specifics and content dynamics you could host it virtually (or physically) anywhere. For example, I run a Dell Mini 9 NetBook server at home for various bits and bobs of development (and just because I enjoy doing so) and there's no reason why I couldn't host my website there and have the EC2 Varnish box securely target it via SG based IP lockdown (to) & related router port forwarding (through) the perimeter of my home network. In fact if you hold mostly static content you could even just pull from AWS S3 as Varnish offers flexible config for added /index.html (or w.h.y) to specified retrieval strings through its concise configuration language (VCL). For info, the VCL is based mostly around regular expressions and if you're in any way familiar with either C or Perl based regex you'll most likely be up to speed from the word go.

So, there you have it, the above base platform can be upgraded and adapted (expanded) for scaling and/or self repair (such is the nature of AWS), and there could also be considerations for spot scaling based on instance store EC2s (as oppose to EBS backed), bootstrapped (either manually or using something like http://scalarium.com) to pull in the Varnish VCL from GIT (something definitely worth looking at for 'stateless' boxes such as these).

If you are interested in Varnish caching and think it might be something you might like to implement but aren't sure where to begin, or if you would like assistance with any other AWS related projects, our main website is HERE, it has more information on what we do and there's a contact form and/or direct phone number for you to get in touch.

(Varnish website - https://www.varnish-cache.org/)

No comments:

Post a Comment