-: Now we're getting into content delivery,
and we'll start by CloudFronts.
So CloudFront is a content delivery network,
or CDN,
and what it does is that it improves read performance,
because the content is going to be distributed
and cached at the edge locations,
and edge locations are all around the world,
and there's about 216 points of presences globally,
as I'm recording this lecture,
and they add all the time,
new points of presence.
So it's much more than the 30 something regions
that AWS has.
This is a world wide thing,
and so what does CloudFront give you
on top of this caching at the edge?
Well it gives you DDOS protection.
So to protect against attack
that are distributed denial of service.
It gives you integration with shield,
and also a web application firewall.
See those into the security section of this course,
but the idea is that it's really protected,
and its a good way to front your applications
when you deploy them globally,
and also allow you to expose external HTTPS endpoint
by loading a certificates,
and also talk internally in HTTPS to your applications
if you needed to encrypt the traffic as well.
So lets take a diagram.
So this is a map of the world,
and there are some orange regions,
and they're edge,
everything on this graph is edge,
but as you can see it's all around the globe,
and so for example,
say we have an S3 bucket in Australia,
and some user from America wants to access it,
it's actually going to access an edge location close to it.
So in America.
And that network is going to be transmitted
over the private AWS network,
all the way to the S3 bucket,
and the content is going to be cached.
So the idea is that this American user,
the more users you have in America,
the more they will want to do the same kind of reads,
and they will have content served directly from America.
Not necessarily from Australia
because it will be fetched once into America
and then served from there.
So cached locally.
So another user may be in Asia
will talk to a edge location closer to Asia,
and the edge location again
will forward the traffic to the S3 bucket,
to get the content and then cache it at the edge.
So CloudFronts allows you to really
distribute your reads all around the world,
based on these different edge locations,
and improve latency
and reduce the load on your main S3 buckets.
So I said S3 buckets but what are the origins.
The origins are what CloudFront can source data from.
So it can be an S3 bucket
and this is a very common use case,
is they want to distribute large files
or caching them at the edge.
Physically making sure
that all of the request do not reach your S3 bucket
but can be cached all around the world.
They also give you enhanced security.
So we'll use something called
CloudFront Origin Access Identity or OAI,
to access our S3 bucket securely.
CloudFront can be used also as an ingress.
So it's possible to upload files to S3 through CloudFront,
and that give you some kind of transfer acceleration.
This is a similar concept to S3 transfer acceleration.
We can front on S3 website.
So you first much enable the website at the S3 bucket level.
So its a static S3 website
and then you can have CloudFront in front of it,
and then finally,
you can have CloudFront in front on any custom HTTP origin,
and that origin must be publicly accessible.
So it can be an application load balancer,
or an EC2 instance,
or any HTTP backend you want,
and in that case if it's a publicly accessible HTTP origin,
then the traffic from CloudFront
to your origin goes over the public web.
It does not go over the private web,
but the private AWS network,
but still it will give you
some really nice caching capability as a whole.
So lest look at S3 as a origin in details.
So you the cloud,
and you have your origin which is your S3 bucket,
and for example you have an edge location in Las Angeles,
and some users want to read some data from there.
So your edge location
is going to fetch the data from your S3 bucket
over the private AWS network,
and give you the results from the edge location.
The idea here is that
for the edge location of CloudFronts
to access your S3 bucket is going to use an OAI,
or an Origin Access Identity.
It's a IAM role for your CloudFront origin,
and using that role,
it's going to access your S3 bucket
and the bucket policy is going to say,
yes this role is accessible,
and yes send the file to CloudFront.
So this works as well for other edge locations.
Fro example,
in Sao Paulo in Brazil,
or Mumbai or Melbourne,
and so all around the world.
Your edge locations are going to serve cache content
from your S3 buckets.
And so we can see how CloudFronts can become super helpful
as a CDN.
Now what if we have ALB or EC2 as an origin?
The security changes a little bit.
So we have our EC2 instance or instances,
and they must be public
because they must be publicly accessible
from HTTP standpoint,
and we have our users all around the world.
So they will access our edge location,
and our edge location will access our EC2 instance.
And as you can see it traverses the security group.
So the security group
must allow the IP's of CloudFront edge locations
into the EC2 instance,
and for this there is a list
of public IP for edge locations
that you can get on this website,
and the idea is that
the security group must allow
all these public IP of edge locations to allow CloudFront
to fetch content from your EC2 instances.
So that makes sense.
What if you use an ALB as an origin?
So now we have a security group for the ALB,
and the ALB must be public to be accessible by CloudFront,
but the backend EC2 instances now can be private,
and so in terms of the security group
for the EC2 instances,
it needs to allow the security group of the load balancer.
We've seen this extensively,
and for the edge location,
which are again public locations,
it need to access your ALB through the public network,
and so that means that your security group for your ALB,
must allow the public IP of the edge locations.
The same public IP as we had from before.
So two different architectures.
Same concept,
but we better understand network security for S3,
for ALB or EC2 in front,
behind, I must say CloudFronts.
Now CloudFronts is a CDN,
it also has some really nice features.
One of them is Geo Restriction.
So it can restrict who can access your distribution.
So you can provide a whitelist where saying,
okay users from this list of approved countries
and only this list can go to CloudFront,
or we can say blacklist, where you're saying,
okay the users from these countries
are not allowed to access our distribution,
and the way the country is determined,
is using a third party Geo-IP database,
where the incoming IP is matched against it
to figure out the country.
So the use case for Geo Restriction,
would be when you have copyright laws
to prevent access of your content
and you want to prove to regulators
that you are indeed restricting content access say,
France of you have content in America.
Okay, now you may be asking yourself,
what is really the difference between CloudFront
and something like S3 Cross Region Replication?
So CloudFornt is using a global edge network,
and files are going to be cached for a TTL,
so a Time To Live maybe for a day.
So it's great when you have static content
that must be available everywhere around the world.
Okay, and maybe you are okay
with if that content is out dated a little bit.
Now for S3 Cross Region Replication,
it must be set up for each region
in which you want replication to happen,
and the file will be updated in near real time.
It's going to be read only,
so it's going to help you with read performance.
So S3 Cross Region Replication
would be great if you have dynamic content,
that needs to be available at low latency
in a few amount of regions.
Hope that makes sense.
Hope that's very clear.
CloudFront is for teaching globally,
and S3 Cross Region Replication
for replication-ing into select regions.
All right, so that's it for this lecture.
I will see you in the next lecture for some hands on.