AWS Cloud : CloudFront Limitations , AMI Cloning and Global Accelerator

Hello readers , this article explains some of the limitations o the AWS CloudFront , explains how we can create our own AMI and what is the need to do it , and introduces to a very recent service started by AWS for the content delivery known as Global accelerator . In order to understand some basic details covered in this article , first go and read the previous article on AWS CloudFront service.

CloudFront Limitations

Let us continue right from the previous blog where we understood about the working of CloudFront . We took an example of a company running a webserver in Mumbai region from where a website is running and the client is in US . So , the edge network is being used through the cloudfront service where the edge keeps a cache of the requested content by the client for sometime (assigned TTL) to avoid high latency . But after the TTL is completed , the cache is cleared and when the customer requests again , then for the first time , high latency is countered .

Now , the problem with CloudFront is that for the whole TTL time of the Edge , if some changes in the website are done at the Origin (Mumbai region) , then that would not get reflected in the Edge till the TTL completes and client will get the old content only . Solution of this can be that we decrease the TTL upto like every 4-5 hours or for much frequent content change , 30-60 seconds so that after TTL ends , the cache gets cleared and Edge again download the new content from Origin when Client requests . But this solution completely becomes a failure of the most important goal of CloudFront i.e. decreasing the Latency . Hence , CloudFront service is not better for the frequently changing website content .

AMI Cloning

Amazon Machine Image (AMI) is a service of AWS Cloud that provides images of instances that we can launch and run our programs there like running a webserver . However , this launching of the instance is a regional service i.e if we launch a webserver from Mumbai region , then we cannot operate it in any other region .

Let us take an example of a webserver of a company running in Mumbai region . Now the company wants to start the similar 10 webservers in different regions and operate them instead of using the CloudFront because of its limitations and also the limitation of number of customers each webserver can accomodate . So , one way can be to again start the instance , configure the webserver and launch the website in each region everytime . But this is a very time consuming process . Hence , the solution to this is to clone the same instance and launch it in different regions . Let us see how this can be done ...

You can see that i have an instance running in Mumbai region in which my webserver is running .

Let us take this is my website .

Now , this instance is fully configured with all data to run my website . In order to clone this AMI , i have to first clone the EBS connected to this Instance . Go to Volumes>>Selectthe EBS volume >>Actions>>Create Snapshot .

Give some name and tag and click "Create snapshot" . The snapshot will be created .

Now go to Snapshots>>Select the cloned EBS >>Actions>>Create Image .

See the details , give a name and click "Create" .

Go to Images>>AMIs , you can see the Image is successfully cloned.

You can now launch the instances by going to Instances>>Launch Instances>>My AMIs .

But , this image can launch instances only in the Mumbai region . If we want to launch the same image in any other regions , we have to copy this image in that region . Let us see how we can do this ...

Go to images >>AMIs>>Select you image>>Actions>>Copy AMI .

Select the region in which you want to start the instance . I have selected US West . Click Copy AMI .

The copied AMI is not visible in Mumbai region .

But when i switched to US west(N.California) , i can see my image there .

Now i can launch the same instance in US west and Operate it and provide services to my client from from that website . Since this instance is only a copy of our Origin instance , therefore there is no need to provide an ssh connection while launching the instance . We need ssh for management or doing changes in the webserver , but here we don't want to do so . Hence , we will only give the HTTP inbound rule while launching an instance so that client can connect to the webserver . If we want that there should be some addition in the webserver , then we can give ssh inbound rule .

However , there are again problems with this type of implementation . As the ip address of each of the webserver would be different , therefore we have to give different ip addresses to different people or clients to see our website . But this is not a feasible action . The company must have a single url for each website .

---------------------------------------------------------------------------------------------------------------In order to solve the Cloudfront problem of high latency explained above and the problem of multiple webservers with same url , AWS has a solution in the form of a service called as Global Accelerator .

Global Accelerator

Global Accelerator is a recent service of AWS Cloud that solves the problems of CloudFront and the multiple webservers ip addresses in one go . Let us see the working of Global Accelerator to solve these two problems .

Multiple Webservers - Same URL

Let us consider a company whose same webservers are running in different regions broadcasting the same website in Internet . Now , what the company can do is that it can connect all the webservers with the Global Accelerator and create a single url for all the different ip addresses of the webservers .

Fault Tolerance With Security and Reliablility

Now , you must be thinking that how the global accelerator works and decides which client to connect to which webserver and how this connection is implemented . So here is the answer !!!

AWS has one more functionality of its Edges . These Edges are connected to each other by making their own private network for transmission of data just like internet . This private network is a very high speed network with a constant connectivity throughout the globe where the edges are present . Global Accelerator is implemented on this private network of AWS .

So , whenever a client request for the website through the url , the request goeas to the Edge and it connects to the nearest webserver and completes the request of client fastly with least latency . However , if the nearest webserver is not able to provide the service due to an reasons , the connection request is forwarded to the next nearest webserver through the edge network . This is known as fault tolerance .

This edge network is also very fast , secure and reliable as compared to the public internet . The public internet is mostly unreliable because of the different ISP servers accross the globe . For example , if the client in California is to connect to the Mumbai webserver , then first the request has to go through the ISP of California , then get forwarded to any other ISP , then it will come to the ISP in Mumbai and connect to the webserver . This can be a problem if any of the ISP is not constant or any other failure . Also , the public internet is not secure as the public ISP can easily track and read the network packets sent to the client . Thus the the private network of the AWS edges gives a guarantee of high speed (approx 40% faster than the public internet) connectivity and security at the same time which makes it reliable .

---------------------------------------------------------------------------------------------------------------

That is all about this article . Hope it was an informative one for you. Thank you for reading...!!!