AWS S3 CloudFront Static Website

Amazon Web Services (AWS) S3 with CloudFront CDN for a Static Website

A recent requirement to host a simple one page site I looked into what AWS had to offer in this realm. My requirements for hosting included:

1. A simple hosting solution, not complex multiple Virtual Servers.
2. Inexpensive.
3. Content Delivery Network (CDN) for speed.
4. The ability to use my own DNS provider to setup a sub-domain for this site.
5. Explore possible SSL options.

After some research I found Hosting a Static Website on Amazon Web Services page, this ticked most of my boxes. Below is my journey to set this awesomeness up!

Create a S3 Bucket

1. Assuming you have already signed up to AWS, then login to your AWS Console
2. Select S3, then click the blue Create Bucket button top left.
3. Enter your Bucket Name, in my example I'm using a sub-domain test.example.co.uk. Then the Region you would like the site to be served from.

Configure the S3 Bucket

Now that the bucket is created we need to tweak the configuration of the bucket to turn it into a static web hosted site.

Permissions

1. Click Properties (top right) button, click the Permissions tab. Here we need to allow access to the files within the S3 bucket to the public. For this we will set-up a bucket policy.
2. Click Edit bucket policy button. Below is an example of a bucket policy which allows all users get permissions to the particular bucket.
3. To help you can use the AWS Policy Generator or Sample Bucket Policies links.

Static Web Hosting

1. Under the Static Web Hosting tab click Enable Website Hosting.
2. Next enter the file name your homepage, e.g. Index Document: index.html
3. Note the Endpoint for further use, this will be the url you can use to test the site works.

Deploy your Site to S3 Bucket

1. To deploy your site, simple click the Upload button and select the required files. I uploaded a simple index.html page.
2. Now using the Endpoint from above we can test to see if the site works. e.g. go to http://test.example.co.uk.s3-website-eu-west-1.amazonaws.com

BOOM! You now have a hosted site! Well not quite, but almost.

At this point you can skip the CloudFront CDN set-up, if that's not required, and go straight to the DNS setup. Otherwise please continue reading.

Create CloudFront CDN for Bucket

If you don't mind a small additional cost then I would recommend also setting up CloudFront to act as a CDN for your site. Essentially this delivers your site from the nearest Amazon Region for each specific web user according to their location. Therefore increasing site delivery speed to your users and also distributing traffic to separate regions easing the load. E.g A visitor from the UK will be delivered the site from the AWS Europe region, US to US region, etc.

Sounds good? Then lets set this up!

1. Click Create Distribution button, then for Select a delivery method for your content choose Web.
2. Next complete the Create Distribution form with the following fields:
   
   
   1. Origin Domain Name: enter your sites endpoint test.example.co.uk.s3-website-eu-west-1.amazonaws.com, NOT the Amazon S3 Bucket select option value!
   2. Minimum TTL: set time to life to 360 seconds (5 minutes)
   3. Price Class: Choose the Edge Location option to best suites your performance needs and costs. Options range from Only US & Europe, Only US, Europe & Asia & All Edge Locations (Best Performance). I went down the middle of the line and chose Only US, Europe & Asia.
   4. Alternate Domain Names (CNAMEs): Set the alternate domain names for your site. In my case the sub-domain test.example.co.uk.
   5. Default Root Object: Specify the homepage for your site, e.g. index.html.

Give AWS time (5-10 minutes) to set-up your CloudFront distribution. Once this has complete you can test it's working by going to your generated CloudFront domain name. It will be something like http://e1zchjugikb91z.cloudfront.net. Your homepage should now be displayed, hurray!!

Third Party DNS Set-Up (not using Amazon Route 53)

The final piece in the puzzle is configuring your DNS so that you can see a nice domain name instead of Amazon's ugly URLs. As I already had a DNS provider and didn't require to use Amazon's Route 53 service, all that was required was to add a new CNAME to your existing domain. For example:

Sub-Domain: test.example.co.uk
Type: CNAME
Target: e1zchjugikb91z.cloudfront.net.

Or if you didn't set-up the CloudFront CDN then use the sites endpoint as your target instead, test.example.co.uk.s3-website-eu-west-1.amazonaws.com.

Once the DNS change has propagated you should be able to hit your site http://test.example.co.uk, CHAMPION!

CloudFront SSL? SNI Custom SSL or Dedicated IP Custom SSL

If you want are to set-up SSL for your S3 CloudFront static site you will have to think about the costs and possible drawbacks of the particular SSL setup. The 2 options are:

1. Server Name Indication (SNI) Custom SSL: Free, however it won't work for very old browsers (see Amazon CloudFront Announces SNI Custom SSL)
2. Dedicated IP Custom SSL: Which costs $600 per month and in my opinion very expensive.

Further reading on SSL from Amazon:

• Amazon CloudFront Custom SSL
• Set-up CloudFront to Serve HTTPS Requests

Impersonate a Web User from a Different Country

Recently I was in a situation where I needed to be able to test some geo-specific functionality on a website. The visiting web users IP would be recognised as coming from a specific country and a different action would occur (i.e. different view, redirect, etc).

After some Googling I managed to find a handy Chrome extension called GeoProxy. This allows you to set Chrome's proxy from a list of proxies (generated based on country) you choose. Proxies are listed in the order of latency.

GeoProxy:

https://chrome.google.com/webstore/detail/geoproxy/pooljnboifbodgifngpppfklhifechoe?hl=en

Agilaterfall: When Agile becomes Waterfall

Agile when it's adhered to correctly can be very satisfying to a developer due to its productive nature. Constantly delivering working software in small iterations, what's there not to like? However when agile isn't understood and enforced by both the product owner and stakeholders, it can also mean going back to the days of waterfall. To help demonstrate my point lets take a look at the Agile Manifesto (in steps wiki):

• Individuals and interactions – in agile development, self-organization and motivation are important, as are interactions like co-location and pair programming.
• Working software – working software will be more useful and welcome than just presenting documents to clients in meetings.
• Customer collaboration – requirements cannot be fully collected at the beginning of the software development cycle, therefore continuous customer or stakeholder involvement is very important.
• Responding to change – agile development is focused on quick responses to change and continuous development.

The first two points, "Individuals and Interactions" and "Working Software" can be controlled and implemented by the product owner and development team. The final two points, "Customer collaboration" and "Responding to change", if not done correctly is where waterfall can creep in. I fully agree that not all requirements can be fully collected at the beginning of a project and not always at the start of the sprint during sprint planning. The acceptance criteria on user stories is not always going to be the complete picture and that's where the responding to changes will cater for this.

However in order to respond to changes you firstly need to know what the changes are, and requires the stakeholder to raise these changes after a sprint. These can then be built into the next sprint and burn down charts recalculated. Giving a more accurate reflection on where the project is in its development life-cycle.

A stakeholder without the understanding of agile and the purpose of using such a software development methodology can be potentially damaging to the project. If these changes are not raised in the first instant and left to the end of the project, then you are essentially adhering to waterfall. You are then in the situation of adding unplanned time to the end of the project due to the stakeholders new requirements.

Conclusion

The two main points to take away from this:

1. Have good user experience (UX) and business analysts to ensure acceptance criteria is as complete as possible.
2. Ensuring the stakeholder fully embraces the nature of agile and reports changes or issues during sprints. Not at the end of the project and therefore reverting to a waterfall approach.

Multiple IIS websites running HTTPS with one Self-Signed Certificate

This is my first post and a little 101 however useful nonetheless. During development there comes a time when you have more than one website running in IIS that requires a Secure Sockets Layer (SSL). This would seem fairly trivial, no? However there's a distinct lack of material out there documenting the steps to achieve the holy grail of HTTPS secureness in a local set-up. You may have come across the following error during attempts to set this up:

"At least one other site is using the same HTTPS binding and the binding is configured with a different certificate. Are you sure you want to reuse this HTTPS binding and and reassign the other site or sites to use the new certificate?"

With help from a fellow work colleague the configuration was found. I thought I would share this to hopefully aid others in their search. Right, down to the goodness!

1. Open up IIS and click the IIS server node and select Server Certificates.
   
   
2. Create Self-Signed Certificate... and name it starting with a wildcard (*) and then followed by the domain name. E.g. *.local
   
   
   
   
3. Now to secure your website. Select your website and select Bindings. Click Add..., select Type as https and choose the newly created wildcard SSL certificate you created above e.g. *.local. Finally enter the Host name of your website which in my case is project1.local.
   
   
   
   
4. Now you only need to repeat step 3 to add more IIS websites that require a SSL. Remember to change the Host name accordingly for each new website.