CloudFront
- CloudFront is a fully managed, fast content delivery network (CDN) service that speeds up the distribution of static, dynamic web or streaming content to end-users.
- CloudFront delivers content through a worldwide network of data centers called edge locations or Point of Presence (POP).
- CloudFront securely delivers data, videos, applications, and APIs to customers globally with low latency, high transfer speeds, all within a developer-friendly environment.
- CloudFront gives businesses and web application developers an easy and cost-effective way to distribute content with low latency and high data transfer speeds.
- CloudFront speeds up the distribution of the content by routing the user to the edge location that best serves the content thus providing the lowest latency (time delay).
- CloudFront uses the AWS backbone network that dramatically reduces the number of network hops that users' requests must pass through and improves performance, providing lower latency and higher data transfer rates.
- CloudFront is a good choice for distribution of frequently accessed static content that benefits from edge delivery - like popular website images, videos, media files, or software downloads
CloudFront Benefits
- CloudFront eliminates the expense and complexity of operating a network of cache servers across multiple sites across the Internet and eliminates the need for over-provisioning capabilities in order to serve potential spikes in traffic.
- CloudFront also provides increased reliability and availability as copies of objects are held in multiple edge locations around the world.
- CloudFront keeps persistent connections with the source servers so that those files can be fetched from the source servers as quickly as possible.
- CloudFront also uses techniques such as collapsing simultaneous viewer requests at an edge location for the same file in a single request.
- CloudFront offers the most advanced security capabilities, including field-level encryption and HTTPS support.
- CloudFront seamlessly integrates with AWS Shield, AWS Web Application Firewall - WAF, and Route 53 to protect against multiple types of attacks including network and application layer DDoS attacks.
Edge Locations & Regional Edge Caches
CloudFront Edge Locations or POPs make sure popular content can be served to viewers quickly.
CloudFront also has regional Edge Caches that help bring more content closer to the viewers, even when the content is not popular enough to stay at a POP, to help improve that content.
Regional Edge Caches are deployed globally, close to the viewer, and are located between the source servers and the Edge Locations.
Regional edge caches support multiple Edge Locations and support a larger cache size so objects remain in the cache longer at the nearest regional edge cache location.
Regional edge caches help with all types of content, especially content that tends to become less popular over time.
Configuration & Content Delivery
CloudFront Configuration and Content Delivery
Configuration
Original servers need to be configured to get the files for distribution. An origin server stores the original, definitive version of the objects and can be used for an AWS hosted service e.g. S3, EC2, or an on-premise server
Files or objects can be added / uploaded to the Origin Servers for public read permissions or permissions restricted to the Original Access Identity (OAI).
Create a CloudFront distribution, which says CloudFront, which generates files from the source servers when users request the files.
CloudFront sends distribution to all the edge locations.
This website can be used with the CloudFront provided domain name or a custom alternate domain name.
An origin server can be configured to limit access to protocols, caching behavior, add headers to the files to TTL, or the expiration time.
Content delivery to Users
When a user accesses a website, file, or object - the DNS routes the request to the CloudFront edge location that can best serve the user's request with the lowest latency.
CloudFront returns the object immediately if the requested object is currently in the cache at the Edge location
If the requested object does not exist in the cache at the edge location, the POP typically goes to the nearest regional edge cache to fetch it.
If the object is in the regional edge cache, CloudFront forwards it to the POP that requested it.
For objects not cached at either the POP or the regional edge cache location, CloudFront requests the object from the origin server and returns it to the user via the regional edge cache and POP.
CloudFront begins to forward the object to the user as soon as the first byte arrives from the regional edge cache location.
CloudFront also adds an object to the cache in the regional edge cache location in addition to the POP for the next time a viewer requests it.
When the object reacts its expiration time, for any new request CloudFront checks with the latest server for any latest versions, if it has the latest it uses the same object. If the original server has the latest version of the same is retrieved, served to the user, and cached as well
CloudFront Origins
Each origin is either an S3 bucket, a MediaStore container, a MediaPackage channel, or a custom origin like an EC2 instance or an HTTP server
For the S3 bucket, use the bucket URL or the static website endpoint URL, and the files will either be publicly readable or secured using OAI.
Original restrict access, for S3 only, can be configured using Direct Access Identity to prevent direct access to the S3 objects.
For the HTTP server as its origin, the domain name of the resource needs to be mapped and the files must be publicly readable.
Distribution can have multiple origins for each bucket with one or more cache behaviors that route requests to each source. Path pattern contains a cache behavior determines which requests are routed to the origin (S3 bucket) that is associated with that cache behavior
Origin groups can be used to specify two origins to configure origin failover for high availability. Origin failover can be used to designate a primary source plus a second source that CloudFront switches to when the primary origin returns specific HTTP status code failure responses.
CloudFront Delivery Methods
Web distributions
supports both static and dynamic content e.g. Using HTML, CSS, js, images, etc. HTTP or HTTPS.
supports multimedia content on-demand using progressive download and Apple HTTP Live Streaming (HLS).
Supports a live event, such as a meeting, conference, or concert, in real-time. For live streaming, distribution can be created using an AWS CloudFormation stack.
Source servers can be either an S3 bucket or an HTTP server, for example, a web server or an AWS ELB, etc.
RMTP distributions (Support Discontinued)
supports streaming media files using Adobe Media Server and the Adobe Real-Time Messaging Protocol (RTMP).
must use an S3 bucket as its origin.
To stream media files using CloudFront, two types of files are required
Media files
Media player for e.g. JW Player, Flowplayer, or Adobe Flash
End-users view media files using the media player that is provided; Not locally installed on the computer of the device
When an end-user streams the media file, the media player starts playing the file content while the file is still being downloaded from CloudFront.
The media file is not stored locally on the end user's system.
Two CloudFront distributions are required, web distribution for media player and RMTP distribution for media files
Media player and media files can be stored in the same-origin S3 bucket or different buckets
Cache Behavior Settings
Path Patterns
Path Patterns help define which path the Cache behavior will apply to.
A default (*) pattern is created and multiple cache distributions can be added to the pattern to take precedence over the default path
Viewer Protocol Policy
The Viewer Protocol policy can be configured to define the allowed access protocol.
Between CloudFront & Viewers, cache distribution can be configured to either allow
HTTPS only - supports HTTPS only
HTTP and HTTPS - support both
HTTP redirected to HTTPS - HTTP is redirected to HTTPS
Origin Protocol Policy
Between CloudFront & Origin, cache distribution can be configured with
HTTP only (for S3 static website)
HTTPS only - CloudFront fetches objects from the origin of using HTTPS
Match Viewer - CloudFront uses the protocol that the viewer uses to request the objects.
For S3 as origin,
For this website, the protocol for HTTP as HTTPS is not supported
For the S3 bucket, the default original protocol policy is Match Viewer and cannot be changed. So when CloudFront is configured to require HTTPS between the viewer and CloudFront, it uses HTTPS to communicate with S3.
HTTPS Connection
CloudFront can also be configured to work with HTTPS for alternate domain names using: -
Serving HTTPS Requests Using Dedicated IP Addresses
CloudFront associates the alternate domain name with a dedicated IP address, and the certificate is associated with the IP address. When a request is received from a DNS server for the IP address,
CloudFront uses the IP address of the distribution and the SSL / TLS certificate returned to the viewer
This method works for every HTTPS request, regardless of the browser or other viewer that the user is using.
An additional monthly charge (of about $ 600 / month) is incurred for using a dedicated IP address
Serving HTTPS Requests Using Server Name Indication - SNI
SNI Custom SSL relies on the SNI extension of the TLS protocol, which allows multiple domains to be served over the same IP address, including the hostname, viewers are trying to connect.
With the SNI method, CloudFront associates an IP address with the alternate domain name, but the IP address is not dedicated
CloudFront is not determine, based on the IP address, which is the domain request for this IP address is not dedicated
Browsers that support SNI receive the domain name from the request URL & add it to a new field in the request header.
When CloudFront receives an HTTPS request from a browser that supports SNI, it finds the domain name in the request header and responds to the request with an applicable SSL / TLS certificate.
Viewer and CloudFront perform SSL negotiation, and CloudFront returns the requested content to the viewer.
Older browsers do not support SNI.
SNI Custom SSL is available at no additional cost beyond standard CloudFront data transfer and request fees
For End-to-End HTTPS connections certificate requirements apply to both the Viewers and CloudFront & CloudFront and Origin, with the following requirements
HTTPS between viewers and CloudFront
A certificate that has been issued by a trusted certificate authority (CA) such as Comodo, DigiCert, or Symantec;
Certificate provided by AWS Certificate Manager (ACM);
Self-signed certificate.
HTTPS between CloudFront and a custom origin
If the origin is not an ELB load balancer, the certificate must be issued by a trusted CA such as Comodo, DigiCert, or Symantec.
For load balancer, a certificate provided by ACM can be used
Self-signed certificate CAN NOT be used.
To use an ACM certificate with CloudFront, it must be requested or imported into the US East (N. Virginia) region. ACM certificates in this region that are associated with a CloudFront distribution are distributed to all geographic locations configured for that distribution.
Allowed HTTP methods
CloudFront supports GET, HEAD, OPTIONS, PUT, POST, PATCH, DELETE to get, add, update, and delete objects, and get object headers.
GET, HEAD methods to use to get objects, object headers
GET, HEAD, OPTIONS methods to use to get objects, object headers or retrieve a list of the options supported from the source.
GET, HEAD, OPTIONS, PUT, POST, PATCH, DELETE operations can also be performed for e.g. Submitting data from a web form, which is directly proxied back to the original server
CloudFront only caches responses to GET and HEAD requests and, optionally, OPTIONS requests. CloudFront does not cache responses to PUT, POST, PATCH, DELETE request methods and these requests are directed to the origin.
PUT, POST HTTP methods also help to accelerate content uploads, as these operations will be sent to the origin e.g. S3 through the CloudFront edge location, improving efficiency, reducing latency, and allowing the application to benefit from monitored, persistent connections that CloudFront maintains from the edge locations to the source servers.
CloudFront Edge Caches
Control the cache max-age
To increase the cache hit ratio, the origin of it can be configured to add a Cache-Control: max-age directive to the objects.
Longer the interval less frequently it would be retrieved from the origin
Caching Based on Query String Parameters
CloudFront can be configured to cache based on the query parameters
None (Improves Caching) - If the origin returns an object of the same version regardless of the value of the query string parameters.
Forward all, cache based on whitelist - if the origin server returns different versions of the objects based on one or more query string parameters. Then specify the parameters that you want CloudFront to use as a basis for caching in the Query String Whitelist field.
Forward all, cache based on all - if the origin server returns different versions of the objects for all query string parameters.
Caching performance can be improved by
Configure CloudFront to forward only the query strings for which the origin will return unique objects.
Using the same case for the parameters' values for e.g. The parameter value A or A, CloudFront would cache the same request twice even if the response or object is returned the same
Using the same parameter order for e.g. For request a = x & b = y and b = y & a = x, CloudFront would cache the same request twice even though the response or object is returned the same.
For RTMP distributions, when CloudFront requests an object from the origin server, it removes any query string parameters.
Caching Based on Cookie Values
CloudFront can be configured to cache based on cookie values.
By default, it considers cookies while caching on edge locations
Caching performance can be improved by
Configure CloudFront for forwarding cookies only If the request has 2 cookies with 3 possible values, CloudFront will cache all possible combinations even if the response takes into account a single cookie.
Cookie names and values are both case sensitive so better to stick with the same case
Create separate cache behaviors for static and dynamic content, and configure CloudFront to forward cookies only for dynamic content e.g. For CSS files, the cookies do not make sense as the object does not change with the cookie value
If possible, create separate cache behaviors for dynamic content that are unique to each user (such as a user ID) and dynamic content that varies based on a small number of unique values reducing the number of combinations.
For RTMP distributions, CloudFront cannot be configured to process
cookies When CloudFront requests an object from the origin server, it removes any cookies before forwarding the request to your origin. If your origin returns any cookies along with the object, CloudFront
removes them before returning the object to the viewer.
Caching Based on Request Headers
CloudFront can be configured to cache based on request headers
By default, CloudFront will consider headers when caching the objects in edge locations.
CloudFront caches based on request headers, does not change the headers that CloudFront forwards, only CloudFront caches objects based on the header values.
Caching performance can be improved by
Configure CloudFront to forward and cache based only on specified headers instead of forwarding and caching based on all headers.
Try to avoid caching based on request headers that have large numbers of unique values.
CloudFront is configured to forward all headers to its origin, CloudFront has a cache associated with this cache behavior. Instead, it sends every request to the origin
CloudFront caches based on header values, it considers the case of the header name but considers the case of the header value
For RTMP distributions, CloudFront cannot be configured to cache based on header values.
Object Caching & Expiration
Object expiration determines how long the objects stay in a CloudFront cache before it fetches it again from the origin
Low expiration time helps serve materials that change frequently and high expiration time helps improve performance and reduce the source load.
By default, each object expires after 24 hours
After expiration time, CloudFront checks if it is still the latest version
If the cache is already the latest version, the originator returns a 304 status code (Not Modified).
If the CloudFront cache does not have the latest version, the originator returns a 200 status code (OK), and the latest version of the object
If an object in an edge location is frequently requested, CloudFront may evict the object, remove the object before its expiration date, to make room for objects that have been requested more recently.
For Web distributions, the default behavior can be changed by
For the entire path pattern, cache behavior can be configured by the setting Minimum TTL, Maximum TTL, and default TTL values.
For individual objects, the origin can be configured to add a Cache-Control max-age or Cache-Control s-maxage directive, or an Expires header field to the object.
AWS recommends using Cache-Control max-age directive over Expires header to control object caching behavior
CloudFront uses only the value of Cache-Control max-age, if both the Cache-Control max-age directive and the Expires header are specified.
HTTP Cache-Control or Pragma header fields include a GET request from a viewer used to force CloudFront to go back to the source server for the object.
By default, when the originator returns an HTTP 4xx or 5xx status code, CloudFront caches these error responses for five minutes and then submits the next request for the object to be viewed.
The requested object is available and the problem has been resolved
For RTMP distributions
Cache-Control or Expires headers can be added to change the amount of time that CloudFront keeps objects in edge caches before it forwards to another request.
The minimum duration is 3600 seconds (one hour). If you specify a lower value, CloudFront uses 3600 seconds.
Serving Compressed Files
CloudFront can configure certain types of compressed files and serve compressed files when viewer requests include Accept-Encoding in the request header
Compressing content, downloads are faster because the files are smaller as well as less expensive as the cost of CloudFront data transfer is based on the total amount of data served.
CloudFront can compress objects using the Gzip and Brotli compression formats.
If serving from a custom origin, it can be used to
Configure compress files with or without CloudFront compression
compress file types that CloudFront is compressing.
If the originator returns a compressed file, CloudFront detects compression by the Content-Encoding header value and compresses the file again.
CloudFront serves content using compression as below
CloudFront distribution is created and configured to compress content.
A viewer requests a compressed file by adding the Accept-Encoding header with gzip, br, or both to the request.
At the edge location, CloudFront checks the cache for a compressed version of the file that is referenced in the request.
If the compressed file is already in the cache, CloudFront returnss the file to the viewer and skips the remaining steps.
If the compressed file is not in the cache, CloudFront forwards the request to the origin server (S3 bucket or a custom origin).
Even if CloudFront has an uncompressed version of the file in the cache, it is still forwards to a request.
The original server returns an uncompressed version of the requested file
CloudFront determines whether the file is compressible:
The file must be one of the types that CloudFront compresses.
File size must be between 1,000 and 10,000,000 bytes.
The response must include a Content-Length header to determine the valid compression limits within the size. If the Content-Length header is missing, CloudFront is currently compressing the file.
The value of the Content-Encoding header on the file must not be gzip. The origin of the file is already compressed.
The response should be a body
The response HTTP status code should be 200, 403, or 404
If the file is compressible, CloudFront compresses it, returns the compressed file to the viewer, and adds it to the cache.
The viewer uncompresses the file.
Distribution Details
Price Class
CloudFront has edge locations all over the world and costs for each edge location varies and the price charged for serving requests also varies.
CloudFront edge locations are grouped into geographic regions, and regions are grouped into price classes
Price Class - includes all the regions
Another price class includes most regions (the United States; Europe; Hong Kong, Korea, and Singapore; Japan; and India regions) but excludes the most expensive regions.
Price Class 200 - Includes all regions except South America and Australia and New Zealand.
Price Class 100 - A third price class includes only the least-expensive regions (North America and Europe regions)
Price class can be selected at lower cost but this will only come at the expense of performance (higher latency), as CloudFront will serve requests only from selected price class edge locations.
CloudFront may, at times, request service from a region not included within the price class, however, you will be charged for the least-expensive region in your selected price class.
WAF Web ACL
AWS WAF can be used to allow or block requests based on the criteria specified, choose the web ACL to associate with this distribution.
Alternate Domain Names (CNAMEs)
CloudFront by default assigns a domain name for the distribution e.g. d111111abcdef8.cloudfront.net
An alternative domain name, also known as a CNAME, can be used to link your custom domain name to objects
Both web and RTMP distributions support alternative domain names.
CloudFront supports * wildcard at the beginning of a domain name instead of specifying subdomains individually.
However, a wildcard cannot replace a subdomain name for e.g. * domain.example.com, or cannot replace a subdomain in the middle of a domain name for e.g. subdomain. *. example.com.
Distribution State
Distribution state indicates whether you want the distribution to be enabled or disabled once deployed.
Geo-Restriction - Geoblocking
Geo restriction can help or prevent users from accessing the content in selected countries,
CloudFront distribution can be configured either to allow users in
The whitelist of the country specified is the access to the content or
Deny users a blacklist of countries
Geo restriction can be used to restrict access to all the files that are
associated with distribution and restrict access at the country level
CloudFront responds to a request from a viewer in a restricted country with an HTTP status code 403 (Forbidden)
Use a third-party geolocation service, if access is restricted to a subset of files that are associated with a distribution or restrict access at a finer granularity than at the country level.
CloudFront Edge Functions
Refer blog post @ CloudFront Edge Functions
CloudFront with S3
CloudFront Security
CloudFront provides encryption in transit and can be configured to require viewers to use HTTPS to request files so that connections are encrypted when CloudFront communicates with viewers.
CloudFront provides Encryption at Rest
uses SSDs that are encrypted for edge location points (POPs), and encrypted EBS volumes for Regional Edge Caches (RECs).
Function code and configuration are always stored in an encrypted format on the encrypted SSDs at the edge location POPs, and in other storage locations used by CloudFront.
Restricting access to content
Configure HTTPS connections
Use signed URLs or cookies for restrict access for selected users
Restrict access to content in S3 buckets using source access identity - OAI, to prevent users from using the direct URL of the file.
Set up field-level encryption for specific content fields
Use AWS WAF Web ACLs to create a web access control list (web ACL) to restrict access to your content.
Use geo-restriction, also known as geoblocking, to prevent users in specific geographiesAccessing content from ic locations is served by a CloudFront distribution.
Access Logs
CloudFront can be configured to create log files that contain detailed information about every user request that CloudFront receives.
Access logs are available for both web and RTMP distributions.
With logging enabled, an S3 bucket can be specified where CloudFront will save the files
CloudFront delivers access logs for a distribution periodically, up to several times an hour
CloudFront usually delivers the log file for that time period to the 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
CloudFront Cost
CloudFront charges are based on actual usage of the service in four areas:
Data Transfer Out to the Internet
Charges are applied for the volume data transferred out of the CloudFront edge locations, measured in GB
Data transfer out of AWS origin (eg, S3, EC2, etc.) to CloudFront is no longer charged. This applies to data transfer from all AWS regions to all global CloudFront edge locations
HTTP / HTTPS Requests
Number of HTTP / HTTPS requests made for the content
Invalidation Requests
Invalid request in the path
A path listed in the invalidation request represents the URL (or multiple URLs if the path contains a wildcard character) of the object you want to invalidate from the CloudFront cache.
Dedicated IP Custom SSL certificates associated with a CloudFront distribution
$ 600 per month for custom SSL certificate associated with one or more CloudFront distributions using the Dedicated IP version of custom SSL certificate support, pro-rated by the hour
AWS Certification Exam Practice Questions
Questions are collected from the Internet and the answers are marked as per my knowledge and understanding (which may differ with yours).
AWS services are updated everyday and both the answers and questions may be outdated soon, so research accordingly.
AWS exam questions are not updated to keep pace with AWS updates, so even if the underlying feature has changed the question may not be updated.
Open to further feedback, discussion and correction.
Your company is moving towards tracking web page users with a small tracking image loaded on each page you are currently serving out of US-East, but starting to get concerned about the time it takes to load the image for users on the west. coast. What are the two best ways to speed up this image? Choose 2 answers
Use Route 53's Latency Based Routing and serve the image out of US-West-2 as well as US-East-1
Serve the image out through CloudFront
Serve the image out of S3 so that it is being served of your web application tier
Use EBS PIOPs to serve the image faster out of your EC2 instances
You deployed your company website using Elastic Beanstalk and you enabled log file rotation to S3. An Elastic Map Reduce job is periodically analyzing the logs on S3 to build a usage dashboard that you share with your CIO. You recently improved the overall performance of the website using Cloud Front for dynamic content delivery and your website as its origin. After this architectural change, the usage dashboard shows that the traffic on your website is dropped by an order of magnitude. How do you fix your usage dashboard? [PROFESSIONAL]
Enable CloudFront to deliver access logs to S3 and use them as input of the Elastic Map Reduce job
Turn on Cloud Trail and use trail log tiles on S3 as input of the Elastic Map Reduce job
Change your log collection process to use Cloud Watch ELB metrics as input of the Elastic Map Reduce job
Use Elastic Beanstalk "Rebuild Environment" option to update log delivery to the Elastic Map Reduce job.
Use Elastic Beanstalk 'Restart App server (s) "option to update log delivery to the Elastic Map Reduce job.
An AWS customer runs a public blogging website. The site users upload over two million blog entries a month. The average blog entry size is 200 KB. The access rate to blog entries drops to negligible 6 months after publication and users rarely access a blog entry 1 year after publication. Additionally, blog entries have a high update rate during the first 3 months following publication; This drops to no updates after 6 months. The customer wants to use CloudFront to improve his user's load times. Which of the following recommendations would you make to a customer? [PROFESSIONAL]
Duplicate entries create two separate buckets and create two separate CloudFront distributions where S3 access is restricted to Cloud Front identity only
Create a CloudFront distribution with the "US & Europe" price class for US / Europe users and a different CloudFront distribution with all Edge Locations for the remaining users.
Create a CloudFront distribution with S3 access restricted only to the CloudFront identity and partition of the blog entry's location in S3 according to the month it was uploaded to CloudFront behaviorors
Create a CloudFront distribution with Restrict Viewer Access Forward Query string set to true and minimum TTL of 0.
Your company has an on-premises multi-tier PHP web application, which recently experienced downtime due to a large burst of web traffic due to a company announcement. Over the coming days, you are expecting similar announcements to drive similar unpredictable bursts, and are looking for ways to quickly improve your infrastructure's ability to handle unexpected increases in traffic. The application currently contains 2 tiers of a web tier, which contains a load balancer, and several Linux Apache web servers as well as a database tier that hosts a Linux server hosting a MySQL database. Which scenario below will provide full site functionality, while helping to improve the ability of your application in the short timeframe required? [PROFESSIONAL]
Setup a CloudFront distribution and configure CloudFront to cache objects from a custom origin.
Migrate to AWS Use VM Import / Export to quickly convert an on-premises web server to an AMI create an auto scaling group, which uses the imported AMI to scale web based on incoming traffic on an RDS read replica and setup replication. RDS instance and on-premises migrate the database to MySQL server.
Failover Environment: Create an S3 bucket and configure it tor website hosting Migrate your DNS to Route53 using zone (import and leverage Route53 DNS failover to failover to the S3 hosted website.
Hybrid environment Create an AMI that can be used to launch web serfers in EC2 Create an auto scaling group that uses * AMI to scale web based on incoming traffic leverage Balancing Balancing traffic between on-premises web servers and those hosted. in AWS.
You are building a system to distribute confidential training videos to employees. Using CloudFront, what method could be used to serve content that is stored in S3, but not publically accessible from S3 directly?
Create an Original Access Identity (OAI) for CloudFront and grant access to the objects in your S3 bucket to that OAI.
Add the CloudFront account security group "amazon-cf / amazon-cf-sg" to the appropriate S3 bucket policy.
Create an Identity and Access Management (IAM) user for CloudFront and grant access to the objects in your S3 bucket to that IAM user.
Create a S3 bucket policy that lists the CloudFront distribution ID as the Principal and the target bucket as the Amazon Resource Name (ARN).
A media production company wants to deliver high-definition raw video for preproduction and dubbing to customers all around the world. They would like to use Amazon CloudFront for their scenario, and they may need 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 Compute Cloud (EC2) / Amazon RDS first, which is responsible for restricting the number of downloads. Content is stored in S3 and is configured to be accessible only via CloudFront. What else needs to be done to achieve an architecture that meets the requirements? Choose 2 answers [PROFESSIONAL]
Enable URL parameter forwarding, let the authentication backend count the number of downloads per customer in RDS, and return the content S3 URL unless the download limit is reached.
Enable CloudFront logging into an S3 bucket, leverage EMR to analyze CloudFront logs to the number of downloads per customer, and return the content S3 URL unless the download limit has been reached. (CloudFront logs are logged periodically and EMR not being real time, therefore not suitable)
Enable URL parameter forwarding, let the authentication backend count the number of downloads per customer in the RDS, and invalidate the CloudFront distribution as soon as the download limit is reached. (Distribution not invalidated but Objects)
Enable CloudFront logging into the S3 bucket, let the authentication backend determine the number of downloads per customer parsing those logs, and return the content S3 URL unless the download limit has been reached. (CloudFront logs are logged periodically and EMR not being real time, therefore not suitable)
Configure a list of trusted signers, let the authentication backend count the number of download requests per customer in the RDS, and return a dynamically signed URL unless the download limit has been reached.
Your customer is implementing a video on-demand streaming platform on AWS. The requirements are to support multiple devices such as iOS, Android, and PC, using a standard client player, using streaming technology (not download) and scalable architecture with cost effectiveness [PROFESSIONAL]
Store the video contents of Amazon Simple Storage Service (S3) as an origin server. Configure the Amazon CloudFront distribution with a streaming option to stream the video contents
Store the video contents to Amazon S3 as an origin server. Configure the Amazon CloudFront distribution with a download option to stream the video contents (Refer link)
Launch a streaming server on Amazon Elastic Compute Cloud (EC2) (for example, Adobe Media Server), and store the video contents as an origin server. Configure the Amazon CloudFront distribution with a download option to stream the video contents
Launch a streaming server on Amazon Elastic Compute Cloud (EC2) (for example, Adobe Media Server), and store the video contents as an origin server. Launch and configure the required amount of streaming servers on Amazon EC2 as an edge server to stream the video contents
You are an architect for a news-sharing mobile application. Anywhere in the world, your users can see local news on topics they choose. They can post pictures and videos from within the application. Since the application is being used on a mobile phone, connection stability is required for uploading content, and delivery should be quick. Content is accessed a lot in the first minutes after it has been posted, but is quickly replaced by new content before disappearing. The local nature of the news means that 90 percent of the uploaded content is then read locally (at least a hundred kilometers from where it was posted). What solution will optimize the user experience when users upload and view content (by minimizing page load times and minimizing upload times)? [PROFESSIONAL]
Upload and store the content in a central Amazon Simple Storage Service (S3) bucket, and use an Amazon Cloud Front distribution for content delivery.
Upload and store content in an Amazon Simple Storage Service (S3) bucket in the region closest to the user, and use multiple Amazon Cloud Front distributions for content delivery.
Upload the content to an Amazon Elastic Compute Cloud (EC2) instance in the region closest to the user, send the content to a central Amazon Simple Storage Service (S3) bucket, and use an Amazon Cloud Front distribution for content delivery.
Use an Amazon Cloud Front distribution for uploading the content to a central Amazon Simple Storage Service (S3) bucket and for content delivery.
To enable end-to-end HTTPS connections from the user`s browser originating through CloudFront, which of the following options are valid? Choose 2 answers [PROFESSIONAL]
Use self signed certificate in origin and CloudFront default certificate in CloudFront. (Origin cannot be self signed)
Use the CloudFront default certificate in both origin and CloudFront (CloudFront cert cannot be applied to source).
Use 3rd-party CA certificate in origin and CloudFront default certificate in CloudFront
Use 3rd-party CA certificate in both Origin and CloudFront
Use a self signed certificate in both origin and CloudFront (original cannot be self signed)
Your application comprises 10% of writes and 90% of reads. You currently service all requests through a Route53 Alias record directed to an AWS ELB, which sits in the front of an EC2 Auto Scaling Group. Your system is getting very expensive when there are large traffic spikes during certain news events, during which many more people request to read similar data all at the same time. What is the simplest and cheapest way to reduce costs and scale with spikes like this? [PROFESSIONAL]
Create an S3 bucket and asynchronously replicate common requests in response to S3 objects. When a request comes in for a precomputed response, redirect to AWS S3
Create another ELB and Auto Scaling Group layer mounted on top of the other system, adding a tier to the system. Serve most read requests out of the top layer
Create a CloudFront Distribution and direct Route53 to the Distribution. Use the ELB as an origin and specify Cache Behavior to proxy cache requests, which can be served late. (CloudFront can request server cache and multiple cache behavior can be defined based on rules for a given URL pattern based on file extensions, file names, or any part of a URL. Each cache behavior can include CloudFront configuration values: origin server name , viewer connection protocol, minimum expiration period, query string parameters, cookies, and trusted signers for private content.)
Create a Memcached cluster in AWS ElastiCache. Create cache logic to serve requests, which can be served late from the in-memory cache for increased performance.
You are designing a service that aggregates clickstream data into batch and delivers reports to subscribers via email only once per week. Data is extremely spikey, geographically distributed, high-scale, and unpredictable. How should you design this system?
Use a large RedShift cluster to perform the analysis, and a fleet of Lambdas to perform record inserts into the RedShift tables. Lambda will scale quickly enough for the traffic spikes.
Use a CloudFront distribution with accessog delivery to S3. Clicks should be recorded as query string GETs for distribution. Reports are built and sent periodically running EMR jobs on the access logs in S3. (CloudFront is a Gigabit-Scale HTTP (S) global request distribution service and works fine with peaks higher than 10 Gbps or 15,000 RPS. It can handle scale, geo-spread, spikes, and unpredictability. Access logs will contain GET data and Work just fine for batch analysis and email using EMR. Other streaming options are expensive as not required as needed for batch analysis)
Use the API Gateway invoking Lambdas which spins PutRecords into Kinesis, and EMR running Spark performing GetRecords on Kinesis to scale. Spark on EMR outputs the analysis to S3, which is sent out via email.
Use the AWS Elasticsearch service and EC2 Auto Scaling groups. The Autoscaling groups scale based on click throughput and stream into the Elasticsearch domain, which is also scalable. Use Kibana to generate reports periodically.
Your website is serving on-demand training videos to your workforce. Videos are uploaded monthly in high resolution MP4 format. Your workforce is distributed globally on the move and using company-provided tablets that require a HTTP Live Streaming (HLS) protocol to watch a video. Your company has no video transcoding expertise and it may require you to pay for a consultant. How do you implement the most cost-efficient architecture without compromising high availability and quality of video delivery? [PROFESSIONAL]
Elastic Transcoder to transcode original high-resolution MP4 videos to HLS. S3 to host videos with lifecycle management to archive original flies to Glacier in a few days. CloudFront to serve HLS transcoded videos from S3
Running a video transcoding pipeline on EC2 using SQS to distribute tasks and auto scaling to adjust the number or nodes depending on the length of queue S3 to host videos from archive All files to Glacier CloudFront to serve HLS transcoding a few days later. videos from Glacier
Elastic Transcoder to transcode original high-resolution MP4 videos to HLS EBS volumes to host videos and EBS snapshots incrementally backup original rues within a few days. CloudFront to serve HLS transcoded videos from EC2.
Running a video transcoding pipeline on EC2 using SQS to distribute tasks and auto scaling adjust the number of nodes depending on the length of the queue. EBS volumes to host videos and EBS snapshots incrementally backup original files in a few days. CloudFront to serve HLS transcoded videos from EC2
References
AWS_CloudFront_Developer_Guide