A media production company wants to deliver high definition raw video material for pre-production and dubbing to customer all around the world. They would like to use Amazon CloudFront for their scenario, and they require the ability to limit downloads per customer and video file to a configurable number. A CloudFront download distribution with TTL = 0 was already setup to make sure all client HTTP requests hit an authentication backend on Amazon Elastic Cloud Compute (EC2)/Amazon Relational Database Service (RDS) first, which is responsible for restricting the number of downloads. Content is stored in Amazon Simple Storage Service (S3) and configured to be accessible only via CloudFront. What else needs to be done to achieve and architecture that meets the requirements? (Choose 2)
a. Enable URL parameter forwarding, let the authentication backend count the number of downloads per customer in Amazon RDS, and invalidate the CloudFront distribution as soon as the download limit is reached.
b. Configure a list of trusted signers, let the authentication backend count the number of download requests per customer in Amazon RDS, and then return a dynamically signed URL unless the download limit is reached.
c. Enable CloudFront logging into an Amazon S3 bucket, let the authentication backend determine the number of downloads per customer by parsing those logs, and return the content S3 URL unless the download limit is reached.
d. Enable URL parameter forwarding, let the authentication backend count the number of downloads per customer in Amazon RDS, and return the content S3 URL unless the download limit is reached.
e. Enable CloudFront logging into an Amazon S3 bucket, leverage Amazon Elastic Map Reduce (EMR) to analyse CloudFront logs to determine the number of downloads per customer, and return the content S3 URL unless the download limit is reached.
This question is testing your understanding of CloudFront and how to secure the Origin which in this case is an S3 Bucket. I would strongly recommend watching the AWS re:Invent Video Introduction to Amazon CloudFront (CTD205) as this will cover some of the fundamental pieces that is being asked within the Question.
There are number of components that form the CloudFront Service however I’m just going to refer to two of them distributions and origins.
- Essentially is a pointer to the original content that you’re hosting in an AWS Origin or in your own Custom Origin that is located in your corporate data center.
- Every CloudFront distribution has its own unique domain assigned to it so that you can reference objects that you’re going to cache.
- e.g. abc123.cloudfront.net
- The Origins need to be specified within the distribution as well. CloudFront needs to know when a request comes in and the content isn’t stored in the cache, it needs to know where to obtain the original content.
- e.g. origin.mysite.com
- CloudFront can be communicated with by both HTTP or HTTPS.
- You can also configure specific Tags, change the different types of Origins, have different behaviors, and have more fine grained cache control.
- Essentially this is where CloudFront is going to get its content from.
- It’s any publicly accessible web server. This could be an S3 bucket, an EC2 instance, an EC2 instance behind an Elastic Load Balancer or a web server that is hosted within your own data center.
- In order to maintain security and to make sure that your Origin is delivering content to CloudFront there are a couple of things that you can configure.
- Origin Access Identity for S3 (OAI) – Restrict Access to an S3 Bucket to just CloudFront. Any other request that comes in that isn’t from CloudFront will just be denied
- Signed URL (Tokenised URL) – CloudFront can then use that to access the Origin and the Origin will only respond with the content if the signed URL is valid.
- To make sure that the performance is in place there are persistent connections. The connection is persisted using TCP between the CloudFront Edge Cache and the Origin. This help to speed up content delivery when the item isn’t in the cache or for dynamic content to keep the dynamic content channel open to reduce the chatter between the Edge and the Origin.
- The ability to encrypt the connection via SSL
- Full bridge – End-client all the way to the Origin
- Half bridge – End-client to just the CloudFront Edge
- CloudFront can be used to proxy connections as not all content is cacheable.
- CloudFront is optimised for use with other AWS resources such as S3, ELB etc…
So now that I’ve covered off the above bits of information lets start with ruling out the obvious wrong answers.
“Answer C” is incorrect. The solution is recommending using CloudFront logging. The issue with this is that the timing of the log delivery isn’t instant. If you read the CloudFront Access Logs Documentation it states the following:
“CloudFront usually delivers the log file for that time period to your Amazon S3 bucket within an hour of the events that appear in the log. Note, however, that some or all log file entries for a time period can sometimes be delayed by up to 24 hours.”
In addition reading what has already been implemented within the question, Origin Access Identity has been configured to only allow access to the S3 bucket from CloudFront, therefore if you return the S3 URL back to the Client they will simply get an access denied.
“Answer D” and “Answer E” are also both incorrect for the above reason. They both suggest returning the S3 Content URL’s back to the Client directly. As the OAI has already been configured the Client would also get an access denied.
“Answer B” is correct. Given that within the Solution that has already been implemented they have already implemented a very low TTL which is typically used for dynamic content, this is forcing the HTTP requests to hit the authentication backend whereby they can count the number of requests within a Database (in this case RDS). The authentication server can then return a Signed URL to the end client to enable access to the content via CloudFront Edge Cache and then utilise some additional CloudFront behaviors to reject access when it hits a download limit.
“Answer A” is also correct as it is still allowing the authentication backend to handle the download count but it’s in effect utilising the query string to forward parameters that would then be stored in cookies. CloudFront is then able to vary the response to the Client based on what the query string and cookie values are.
That is all for now.