If It's Worth Doing, It's Worth Overdoing - the Story of nitor.fi / Part 2

10.12.2015 klo 11.03

In Part 1 of this blog post I introduced the infrastructure behind Nitor's new website running on Amazon Web Services. I'll dig a little deeper into the details in this Part 2.


(see Part 1 of this blog post)

Configuration Management

All of the infrastructure is defined in two pairs of Cloudformation stacks. There's a dev environment where new features get tested and then the production environment that is the public website. The environments are identical, except for access being more restricted to the dev environment. To us, this is the right amount of environments. Deploying new code is fast enough (code gets updated in 21 seconds) so that we don't need a lighter-weight environment for dev. The stacks are in two parts so that they can be updated independently. The front contains the definitions for CloudFront. That stays pretty stable and we don't generally need to touch it. The backend contains the CMS Elastic Compute Cloud (EC2) instances, Elastic Load Balancers (ELBs), Relational Database Service (RDS) instances and the associated networks.

Site Shield

A customer of mine had a global brand website with Akamai CDN. During my time there we implemented Akamai Site Shield, which is basically just Akamai telling us which IP spaces the traffic comes from and us limiting traffic at the origin to just those spaces. We hoped to bring something like that to our setup. Otherwise it would be easy to knock our site off the internet by overloading the origin as we want to run it in the smallest possible Amazon instance (T2.micro).

Turns out there was nothing like this ready to take into use, but Amazon does publish the CloudFront IP ranges. So I built a script that grabs those ranges and updates a security group to only allow ingress traffic from there. Set that to run every five minutes and we have a poor man's site shield! And it does not cost anything besides the processing power to run the script. The script sends email if the ranges change. The ranges have added one new range since we went live. The script is available here, and we set up a Jenkins job to run that every 5 minutes and send email to our admins in case it returns a failing status. That means either something failed or the IP ranges have changed.

I went to see Amazon's Defending Against DDoS Attacks talk in this year's Amazon re:Invent in Las Vegas, and Amazon really does quite a lot of Distributed Denial of Service (DDoS) attack prevention at CloudFront, so I'd say we have world class security on our tiny little website - I dare you to try and take it offline. Well I know it's possible, but it is no longer cheap and easy. Check out that talk if you are interested in this, it is quite enlightening.


So as mentioned above, in addition to edge caching, CloudFront gives us quite a lot of security. We only allow GET and HEAD requests to most of the site and drop most of the headers and all cookies. This reduces the attack vectors available for many attacks and improves caching.

Caching is essential for the sites performance. We tested our performance with Loader.io and with just about ten simultaneous users the response times start to reach uncomfortable levels. With CloudFront we had no problems with hundreds of users. This is essential, handling the same load with just more and bigger EC2 instaces, the cost would be significantly bigger. CloudFront costs us less than two dollars a month.

SSL Only

Some of our customers have been planning to go SSL only. We did that from the very beginning. All of our alternate domain names redirect to https://www.nitor.fi and all of them have plain http and https listeners with valid certificates to get your request and send you to the right place. All of that costs us nothing besides the effort to set it up. We get certificates free fromStartSSL and the rest is one box doing the redirects and some DNS configuration. CloudFront does it's own redirecting from http to https.


We now have a website that exceeds our needs in quite many ways: we really don't need to handle hundreds of concurrent users or to force SSL on every connection or to protect the site from DDOS attacks. But we did those anyway since they add practically no cost and if it's worth doing, it's worth overdoing.


Pasi Niemi

Pasi Niemi is a Senior Software Architect with Nitor Creations. Pasi has over fifteen years of experience in the software business as a developer, architect and team leader.