What stands in the front of the cloud to take the traffic. Yes, it is the CloudFront.
Let’s say you have built an awesome application and you are running it from your home country, but now people from all around the world are a big fan of your app and they want to access it from the different corners of the world, but your server resides in your home country.
We want people to be able to access this application of yours with high transfer speed and very low latency, but in the world of internet, it has to go through a very long path.
EDGE LOCATIONS:
So how do we reduce this latency. Here CloudFront comes to our rescue. AWS has a network of more than 200 edge locations. What are these edge locations??? They are locations where AWS cashes your data. No, no, no, edge locations are not for you to access but it is a location where the AWS caches the data to be served in a faster way.
REGIONAL EDGE CACHE:
Well, there is another thing called Regional edge cache for things which are not much frequently accessed, but they are required to be cashed and one Regional Edge Cache supports a number of Edge locations in that geographical area.
Regional cash is not supported by S3 origin it is only supported by custom origin (on prem servers, EC2, S3 website ..)
So the story goes like this--- User A asks for your application's content and the edge location is checked for the content. If the edge location does not have it, it's called a cache miss :( Now the edge location asks the regional cash "Do you have this content?" The Regional Edge Cache says "Oh, I don’t have this". Then there is an origin fetch which happens, the Regional Edge Cache goes to the origin, gets the content, stores it and also distributes it to the Edge location. User B comes and asks for the same content now and the edge location is checked for the content. Now the edge location has it, it's called a cache hit :) So, without any latency the content is served and any other future customers asking for this content are served almost immediately without having to go all the way to the other side of the world to fetch this content. This is the magic of CloudFront.
TTL:
When we create a CloudFront distribution, we also define a TTL(Time to live) for that object in the Edge Location. When this time to live is reached then --does the Edge location completely removes the object from it? No, now what it does is, it goes back and asks the origin "Is there is any change in the object" and if there is no change in the object and the Edge location can continue caching it, then the origin returns at 304 Not Modified code and if there is some change then the origin returns a 200 okay code, so that means it has been modified and the Edge Location fetches the object again from the origin.
INVALIDATIONS:
Imagine that one of the pictures in your content is faulty. It is not the picture you meant to be in the content.
Now when the User A comes and asks for the picture the faulty picture is served to them through the edge location after cashing it in the edge location but, now you realize that the picture is faulty so, you immediately go to your origin and you change the image and change it into the correct one. Now the User B comes and asks for the same image. Guess which picture is served to User B. Again the faulty picture is given user because that is the one which is cashed in the edge location.
So even though you have changed it in the origin, it does not reflect in the edge location because, according to cloud front it has some time to live(TTL) in the edge location. Now if you want to remove it from the edge locations you will perform an action called the invalidation. Yes, thankfully there is a process called invalidation which can help us immediately to remove the content from the edge location but mind you this will cost you.
CERTIFICATES:
For a website to be viewed as a secure website, you have to pick a name for it and generate a certificate or have one generated for it.
The certificate is signed and it is used to prove the identity of the website. So the DNS name is attached with the certificate.
When you set up a CloudFront distribution you will get a default a domain name. This default domain name does not make much sense. It starts with the random name and ends in cloudfront.net, but the good thing is this can enable HTTPS access to your distribution by default. So this means that you have enabled HTTPS without any additional requirements. CloudFront distribution is supplied with a default CloudFront certificate. But you would like to use your own domain name with the CloudFront. Won’t you??? You wouldn’t want to use this random name.
And if you want to your domain name then you have to have a certificate matching this domain name. You can generate your own certificate or import a certificate using ACM. Remember that CloudFront is a global service in AWS and the certificate has to be generated in the north Virginia region only.
SNI:
In 2003 and additional extension was added to the TLS protocol and it was called SNI(Server name indication). This will let the client tell the server which domain name it wants to access and all this happens during network TLS handshake itself. So even before reaching the HTTPS layer, in the network layer itself the host is being mentioned. So now a server has a capability to host many HTTPS websites with a single IP address. But if the clients don't support SNI this capability is of no use. If you’re dealing with browsers which do not support SNI you will have to have a dedicated IP at the age location and this will cost money.
Happy Learning Guys!!!!
Oldest comments (0)