Tackling latency, availability, and security with AWS’s CloudFront and Certificate Manager
In my previous post, I discussed how one could use GitLab’s pipelines to enable continuous delivery of your web-app to Amazon’s S3 buckets. However, this is only the first step to achieving a production-ready environment. You want to keep your web-app secure, right? What about delivering it to your users with low-latency and high availability? That’s where CloudFront and Certificate Manager (ACM) come into play.
Let’s review: We have a web-app deployed to an S3 bucket that has web-hosting enabled, but we have no sort of CDN or cloud caching and certainly, no security (SSL certificates). Your application flow may look something like this:
This means that all requests coming from your users are going to directly access that S3 bucket, regardless of geolocation or amount of requests it is receiving; that is obviously not efficient and not necessarily secure. Enter CloudFront.
As you can see in the image above, CloudFront has the idea of a “global network”.
Amazon CloudFront uses a global network of 166 Points of Presence (155 Edge Locations and 11 Regional Edge Caches) in 65 cities across 29 countries.
In essence, the way that this works and achieves efficiency is by having the DNS route traffic through CloudFront, which determines the best Edge Location that can serve the request — generally the closest location in terms of latency. Each Edge Location internally determines if it has the desired file in its cache. If it has a cached copy of the requested file it will return it, else it will go fetch it from the connected S3 bucket, cache it, and then return it.
(1) A user pings your website
(2) A request is made to the nearest Edge Location
(3) If file is cached, return to user
(3a) If file is not cached, fetch from Amazon S3 bucket
(3b) Return file from S3 and store in Edge Location
(3c) Return file to user
Now that we have a good grip on how CloudFront works, let’s start implementing it. First things first, we will need to create our SSL certificate with ACM that we can consume when setting up our CloudFront Distribution.
Head over to ACM and ensure that you are in US-East-1 (N. Virginia) region. For some reason, only certificates issued from this region are accepted by CloudFront.
Click the “Request a certificate” in the upper left-hand corner and then choose “Request a public certificate” on the following page. Enter the domain that you want to secure like so:
The next step is verification. You may choose either email or DNS validation. Either is acceptable, and you may choose whichever is best suited for your situation. After the verification process has been completed, you should see an “Issued” certificate in your ACM dashboard.
Back to CloudFront!
Navigate to your CloudFront dashboard and click “Create Distribution”. Do not worry about the region, since CloudFront is by definition “everywhere” 😊.
Now we need to configure CloudFront’s properties. When you click on the “Origin Domain Name” text-field you should see a drop-down of your S3 buckets; go ahead and select the S3 bucket you want to have CloudFront manage.
Additionally, insert the following configurations:
- Viewer Protocol Policy: “Redirect HTTP to HTTPS”
- Object Caching: You may put “0” during development stages so that it always fetches and your changes are immediately reflected. However, you will normally want to set a default TTL (time-to-live) that CloudFront will adhere to.
- SSL Certificate: Select “Custom SSL Certificate” and then choose the one you created in the previous step. We want to be secure! 🔒
- Default Root Object:
Lastly, click “Create Distribution” and wait for it to deploy!
Note: You may change your Price Class when configuring your CloudFront distribution. Obviously, this should be determined by your use case. If you have users who are located all over the world, using all edge locations would be the most performant; however, it would cost more than just US or Canada.
We are all set! Your app is not only secured, but it is highly available with blazing fast latency! Remember, don’t forget to check out part 1 if you would like to see how to deploy your web-app to S3.