Cloud Front - Content Distribution mgmt Platform

What is Cloud Front

Cloud Front is used to manage the content delivery in AWS. It is deployed in all edge locations and provide very low latency content delivery to consumers. 

CloudFront is able to deliver high performance read and write operations over a standard HTTP/HTTTPS interface.

It also have the programmable API, that allow us to control the behavior of the caching environment and deliver the services. With the help of these API, we can configure our CloudFront distribution which can tune the feature and performance of our application.

Below are HTTP methods supported when creating our CloudFront Distribution

HTTP GET & HEAD Method

Using these methods, we can cache the READ operations in CloudFront. Once it receives the request, it performs a cache lookup and if the cache does not contain the object, then the service will forward the request to the backend and get the request complete.

HTTP GET, HEAD & OPTIONS method

Whenever there is HTTP request for OPTIONS, GET & HEAD allows caching service to respond. Each OPTIONS response will be cached so that, when the backend service options change, we need to force an update of the cache or expire the OPTIONS response.

Full Set of HTTP methods

We can also configure CloudFront to respond to GET, HEAD, OPTIONS , PUT, PATCH, POST & DELETE method. In not only cache the READ operations, the service will respond to any WRITE and DELETE HTTP request. It terminates the session at Edge location and provide the end user with faster response for READ & WRITE Operations.

When Ever we change the content on origin Server, we still see that CloudFront distribution still serves the cache content. To serve the latest content, we must manage the TTL of our Cache in the CloudFront Environment. We can control, how long we want content to be served for and when to retire or we can also force the CloudFront distribution to frequently refresh the content on origin and update its cache if necessary.

CloudFront provides us following options to control TTL.

Minimum TTL

It is the Minimum time till then our content will exist in CloudFront cache. This setting is only required when we configure all HTTP method for our distribution. Once this TTL expires, Cloud Front Will automatically refresh the content from origin.

Default TTL

When we don’t want to enforce the TTL to origin, Default TTL is applied. When the Minimum TTL is applied at origin, default TTL needs to be longer.

Maximum TTL

It is the Longest TTL time for caching and this option can be set when the origin does have the caching configuration and is designed to override any defaults from Origin, so that Content are present in Cache for longer time.  

Cloud Front also help us saving cost, as any data which are being transferred between AWS Service and CloudFront does not fall under data transfer cost. Due to which CloudFront can deliver the content faster with lower latency and better delivering rate.

How to Secure Content Delivery

There are requirements to deliver the content in very secure manner and its should be also delivered to intended audience. For this type of requirement, we can use CloudFront, which help us to control access to our application content with Signed URLs or Cookies.

Below figure describes, how signed URL can be used with CloudFront.

• User signs into the Application
• Once Authentication is done, Applications sends the Signed URL to user.
• Signed URL points to CloudFront
• The CloudFront distribution verifies the signature against the policy and returns the content.

With the Cloud Front, we can also control the access to S3 bucket by using Origin Access Identity (OAI) Feature. In which User will also be required to connect to CloudFront to access content and if request to access files goes directly to S3, those requests will be denied.

Below figure describes OAI feature of CloudFront

• User Connects to CloudFront
• CloudFront distribution OAI is allowed to access the content and respond with the content.
• CloudFront distribution can also offload the SSL encryption, or it may connect to backend server with encrypted protocol also.

Encryption

With the help of CloudFront, We can also encrypt the data in transit between our client and CloudFront distribution via SSL/TLS.

In this we can also use AWS Certificate Manager (ACM) with CloudFront. The ACM allows us to create free SSL Certificate for our domain and attach it to our distribution. With the help of ACM, Certificates are automatically updated, renewed.

Below Figure describes the ACM Workflow

• ACM Automatically deploy the certificate to CloudFront Distribution
• User who connects to CloudFront, establish the Secure Session
• CloudFront Distribution can either offload the SSL encryption or connect via encrypted protocol to backend.

AWS has recently launched, Field Level Encryption on CloudFront. In this We can ensure which portion of the content needs to be protected. In Field Level Encryption we can specify up to 10 fields in POST request , that needs to be encrypted. In this encrypted is done by Public keys and its respected Private key will be there in origin Server. In this way we can offload all of the HTTP traffic to CloudFront but still Encrypting Sensitive Data between CloudFront and Origin Server using Field Level Encryption.

Below Figure describes the Filed Level Encryption Method.

DDoS Mitigation

CloudFront is resilient to DDoS Attack, as it is already integrated with AWS Shield Standard. It Not only protect our application, but also provide an extra layer of defense from attacks. AWS Shield Standard protect CloudFront from Layer 3 and Layer 4 network DDoS attacks, but if we want higher Security, we can use AWS Shield Advance, Which can provide higher level of security , higher level of attack mitigation , real-time visibility of traffic events in to Cloud Distribution.

In order to enhance Security to layer 7, We can also integrate the AWS Shield Advance with AWS Web Application Firewall (WAF) Service, the WAF rules can be run directly on CloudFront distribution.