The course is part of these learning paths
Amazon CloudFront is a content delivery web service which integrates with other Amazon Web Services products to give you an easy way to distribute content to end users with low latency, high data transfer speeds, and no minimum usage commitments.
During this course we will cover a range of topics from an introduction to what CloudFront is, to architectural considerations, to pricing and reports. We will then do a walkthrough of creating a Web Distribution, during which we will consider security and best practices. After the creation of the Web Distribution we will start monitoring CloudFront with CloudWatch to ensure that our setup is suitable for our needs and to gather valuable information about our distribution. At the very end of this course we will provide an overview of general best practices.
In order to keep up with this course you should be familiar with the core services that AWS provides and best practices for working with the platform. If you need to get up to speed on this, you can start with the AWS Fundamentals series. This is an intermediate level course, and it is recommended that you also have some basic knowledge about CloudFront prior to start, but we will present a general overview as we get started.
If you have thoughts or suggestions for this course, please contact Cloud Academy at firstname.lastname@example.org.
To finish the course, we are going to cover some best practices for the delivery of static and dynamic content, as well as streaming media. We will then look at the architectural considerations for CloudFront.
Let's start with static assets, objects such as images, CSS, fonts, and even software that doesn't change frequently, and which can be distributed to more than one user. Best practices for static content are, one, use Amazon S3 for static assets, as transferring data between S3 and CloudFront is free. It can decrease the load on your web server.
Two, control access to content on S3 by using Origin Access Identity, which means that content can only be accessed by CloudFront. This is beneficial as it prevents content leakage as S3 URLs are not being used.
Three, control access to content on CloudFront to private content, for example, paid subscribers, premium customers. You should use signed URLs or signed cookies.
Four, edge caching setting high TTLs, and do not forward headers, query strings, or cookies unless absolutely required are the default settings for CloudFront.
Five, versioning will result in each object being treated as unique, and allows for easy updates and rollbacks as you use the file name or query string to version.
Dynamic content is content that changes frequently. This could be unique to every request or unique content that changes frequently, but is not unique to every request, for example, weather updates or content that changes based on the end user request. I know that at this point you are probably thinking, "If the content is changing so frequently, why would I cache it?"
One, cache everything. CloudFront does support TTL as low as zero seconds, and even no-cache, no-store. But most content can benefit from being cached, even for a few seconds since CloudFront supports If-Modified-Since and If-None-Match when the object in the cache has expired. To help you identify content that is dynamic and could benefit from caching, use the CloudFront Popular Objects Report.
Two, use multiple cache behaviors and only forward required headers, avoid forwarding all cookies, and also avoid forwarding the User-Agent header, and instead use Is-Mobile-Viewer, Is-Tablet-Viewer, etc. to differentiate between device types.
Streaming media is becoming more popular with live and on-demand streaming for video and audio, and with that it typically consists of the manifest file, media files, and the player. One, setting the right TTLs is important. Typically, you would set a low TTL for the manifest file, high TTL for media files and for the media player. Two, use HTTP-based streaming protocols and distribute via web distributions to deliver multi-bitrate streaming using fragmented streaming formats, such as Smooth Streaming, which has native support in CloudFront.
No discussion on architectural considerations would be complete without talking about availability. The key principle here is design for failure. When we are looking at CloudFront, the key question to ask is, "What if the origin fails or fails to respond to CloudFront?" To help with this, you can take advantage of other AWS services, such as Route 53 which can conduct health checks, and then take the necessary action in the event of a failure being detected. You should also take advantage of CloudWatch for alarms and notifications.
We've mentioned the importance of caching everything before, but more caching equals higher availability, as when the origin server is unavailable CloudFront will automatically serve the stale object if it's in its cache for the duration of the error caching minimum TTL. From a security perspective, you should enable end to end HTTPS. You can configure HTTP to HTTPS Redirect for each cache behavior. Additionally, you should take advantage of IAM users to control access to CloudFront, and use CloudTrail to record API calls history for security analysis, resource change tracking, and auditing purposes.
During this course, we have been introduced to CloudFront. We set up our first web distribution, looked at the reports which we get natively, and then covered best practices for static, dynamic content, and web streaming. As well as architectural considerations, which have provided you with the skills you'll need to go out and create your own distribution.
David's acknowledged hands on experience in the IT industry has seen him speak at international conferences, operate in presales environments and conduct actual design and delivery services.
David also has extensive experience in delivery operations. David has worked in the financial, mining, state government, federal government and public sectors across Asia Pacific and the US