AWS provides secure cloud based services for applications and data storage. These can be compute resources, databases, static assets like images, videos or audio files that you want your users to access.
The time it takes your web application or website to retrieve data and content is important in providing a good user experience.
CloudFront is a content delivery service that replicates data stored in AWS to other edge locations around the world so it can be served faster when requested by users nearer to that location.
When you create an AWS account, you select a specific region that will host any infrastructure and data you create using your AWS services. The region is effectively geo-specific data centres that contain the physical computer hardware you rent from AWS as part of their Infrastructure as a service (IaaS) or Platform as a service (PaaS)
Each region is named and relates to the main AWS data centre for that geographic area:
For example:
Us-east-1 = US East (N. Virginia)
Us-west-1 = US West (N. California)
Af-south-1 = Africa (Cape Town)
Ap-east-1 = Asia Pacific (Hong Kong)
Ap-southeast-1 = Asia Pacific (Sydney)
The best way to provide faster data access or lower latency is to store your data and applications as close to your users as possible. So if you had an application that serviced users located in California, then hosting the application and data in us-west-1 would provide the fastest response time when content or data needs to be fetched by the application or web service being accessed by the user.
Where AWS CloudFront comes into play is when your users are located nearer to other AWS regions and edge locations than the one you have set up your infrastructure on.
If your primary AWS account infrastructure is set up in us-west-1 (n. California) but a large proportion of users are in Australia then serving data requests from Ap-southeast-1 (Sydney) would make more sense, and that is where the CloudFront CDN becomes invaluable.
When you set up a CloudFront distribution, whenever a user is closer to another AWS region and makes a data request, the data is replicated to the AWS region cache closest to them so it can be served faster. This also means that when other users in the same region request the same data or content, it is already located in the data centre closest to them and can be served much faster than requesting it from the original region where the source application and data was created.
Whether it is static or dynamic content like html, css, javascript or images, CloudFront will cache content locally for faster access. This accelerates static website content delivery and improves the delivery of on-demand or live streaming video for instance.
AWS Global Infrastructure for CloudFront
CloudFront has a network of over 80 edge locations around the world and 10 or more radial edge caches for content delivery. This growing network provides the opportunity to scale out your content delivery at low cost via an easy to use, secure service that has deep integration with many AWS data storage and compute services like AWS Web application firewall, certificate manager, route53 and Amazon S3.
Typical use cases for AWS CloudFront include static asset caching, live video streaming, security and DDoS protection, API acceleration and software distribution.
How to set up AWS CloudFront.
In this example we’ll set up a CloudFront distribution for the content of an S3 Bucket. The bucket is located in us-east-1 and the access requests will be made from Australia and we’ll see if there is any difference in the load speed of a sample image after CloudFront is introduced.
Our bucket is located in n. Virginia
Accessing a 6.5mb image in the bucket without CloudFront consistently returns a 5.8 - 6.2 second response
From the Cloudfront console in AWS you create a new distribution.
On this screen you need to select the origin of the entity you wish to distribute via CloudFront, this can be a domain, webserver, application IP address (even external to AWS) or an AWS service origin like a S3 bucket or a load balancer endpoint.
Once you select an origin, AWS will suggest a name for the origin which you can change if required.
We can set the viewer behaviours at this point, but will leave them at the defaults.
On the settings options you can select a price class. This will decide what areas of the globe CloudFront will cache your content in.
You can also optionally nominate an AWS WAF web ACL, a custom CNAME and a SSL certificate that you have already set up in AWS certificate manager.
Now all you need to do is select “Create Distribution”. AWS will then deploy the distribution to the edge locations you have selected.
The deployment time typically takes 10-15 minutes before the distribution status becomes enabled and is operational.
But has it made a difference?
If we check the same image load speed using the domain name provided by AWS when it set up the CloudFront distribution. This will ensure we are accessing the closest edge location.
With CloudFront active, the load time for our 6.5mb image that is hosted in us-east-1 and requested from Australia is now 1.8 seconds down from 5.8 seconds, a 4 second reduction (68.98%) which is a lifetime in these days of core web vitals and page load speeds being a critical metric on so many levels.
If you have globally distributed clients or users, CloudFront as a method of improving content delivery performance is definitely worth a look.
Also definitely worth a look if you are building or hosting applications and data on AWS are the network topology diagrams automatically generated by Hava. Hands free, no drag and drop, hava.io will produce a set of network topology, security and 3d diagrams when you connect to your AWS, Azure or GCP accounts.
Once created, Hava continuously polls your connected cloud configurations and when changes are detected a new set of diagrams is produced and the superseded diagrams are placed into version history which can be inspected and compared to the current diagram set if you need to identify changes quickly.
You can take Hava for a free trial, learn more here:
