Amazon Cloud Front

In most common scenario the company wants to reduce the cost & complexity by having their solutions deployed & served from cloud technologies instead of data centers. Amazon cloud is most preferred, highly scalable, high availability time with less maintenance cost as compare to data centers.

Amazon cloud has all the features like server, app server, database, content repositories & their CDN network. Let’s go through the Amazon CDN (Cloud Front) benefits & features.

Cloud Front is CDN service and it integrates with other Amazon products to give easy way to distribute content to end users with low latency, high data transfer speeds, and no minimum usage commitments.

Cloud Front distributes the contents (static, dynamic) from their data centers called Edge locations. When a request comes to cloud front it will server from their Edge locations and if the content is not available in the edge location then it will go to S3 repository or http server to serve. The Cloud front delivers the content with lowest latency and with better performance.

Below is the amazon architecture diagram for cloud front:-

 

 Amazon Cloud Front

 

 

We can access the cloud front objects by 2 types of URL’s – Public URL & Signed URL

Public URL’s – User can access the objects which has no restrictions, open to public & does not required signed URL’s.

          Format of public URL –

 http://<CloudFront domain name>/<object name in Amazon S3 bucket>

 For Ex: - http://riiteshbhachawat.cloudfront.net/resume

Signed URL’s – User can access the only objects which serves private content and this URL contain extra information to verify users.

 

In Cloud Front we can display the custom error page based on 2 below scenarios:-

1)   If the object is not available

2)   Time out settings (it means object will not available after XX minutes)

 

The request goes to Cloud front to serve the object and first it looks in to the edge locations with minimal latency and serve the object. If the object does not found on edge locations then it goes to S3 repositories to serve. If the object is not available in S3 also then it can display the error codes to the user. Cloud front first validates the cache to serve the object and if not there in cache then it goes to edge locations or S3 repository.

The object which we are serving does not available in cloud front due to time out /object is moved / deleted then in this scenario we can configure our custom message in cloud front.

The cloud front displays errors based on the unavailability of the object and we can configure custom error messages based on 2 different categories:-

1)   Client Error - problem with request i.e. time out, object is not available then 400 status code will be sent as response.

2)   Server Error – problem with server i.e. server is busy or unavailable then it sends 500 status code will be sent as response.

In our scenario it will always be the client error and we can configure the custom error messages to display to the user.

There are 2 ways to store the custom error pages –1) Amazon S3 bucket 2) HTTP server. If you can create the page in the HTTP server then we need to make sure that cloud front has READ permission to that page.

Store the pages and note down the below information in order to configure the cloud front error response: -

Response page path – path of the custom error page from amazon s3 bucket or from http server.

Error code – HTTP status code for which you want to display the custom error page.

Response code –HTTP status code for which we want cloud front to return to the user with custom error page.

 

Below are the steps to configure the cloud front error response: -

1)   SIGN IN to AWS console and go to cloud front console.

2)   Select distribution and then select error tab.

3)   Select Create custom error response

  1. Enter HTTP Error code, Response Page path, HTTP Response code, Error Cache, Select YES in custom error response.

4)   Make sure about the Response Page Path and the cloud front should have permission for that page.

 

 

Note: - We can  configure the cloud front cache for custom errors message beco’z it cache the error message for minimum of 5 minutes and after that it will go to edge locations / S3 repository.