CloudFront

Question 1

CloudFront

Answer 1

content delivery network or CDN

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,
about 216 globally

the idea is that with the more users you have in a region, the more they will want to do the same kind of reads. And they will all have content served directly from their region, even if S3 bucket is in a totally different region, because it will be fetched once into your region and then served from there so cached locally.

Question 2

on top of this caching at the edge CloudFront gives you

Answer 2

DDoS protection (distributed denial of service)

gives you integration with a shield and also a web application firewall.

it’s a good way to front your applications when you deploy them globally

Question 3

CloudFront allows you to expose

Answer 3

HTTPS endpoint by loading the certificates and also talk internally in HTTPS to your applications if you need to encrypt that traffic as well.

Question 4

CloudFront allows you to distribute

Answer 4

your reads all around the world based on these different edge locations. We improve latency
and reduce the load on your main S3 buckets.

Question 5

what are the different CloudFront origins?

Answer 5

1. using CloudFront in front of S3
2. use CloudFront as an ingress, to upload files into S3 from anywhere in the world.
3. use custom origin and there must be an HTTP endpoints, anything that respects the HTTP protocol: Application load balancer, an EC2 instance, an S3 website, any HTTP backend you want, for example, if it was on your own premises infrastructure.

Question 6

using CloudFront in front of S3

Answer 6

is a very common pattern to distribute your files globally and cache them at the edge. You also get enhanced security between CloudFront and your S3 buckets using your CloudFront OAI or origin access identity. This allows your S3 bucket to only allow communication from CloudFront and from nowhere else.

Question 7

how does it work

Answer 7

We have a bunch of edge locations all around the globe. And they’re connected to the origin we defined,

It could be an S3 buckets or it could be any HTTP endpoints.

1. Our clients will send an HTTP request directly into CloudFront.
2. The edge location will forward the request to your origin.
3. Then your origin responds to the edge location.
4. The edge location will cache the response based on the cache settings we’ve defined and return the response back to our clients.
5. the next time another client makes a similar request,
   the edge location will first look into the cache before forwarding the request to the origin.

That is the whole purpose of having a CDN.

Question 8

S3 buckets as an origin

Answer 8

for example, you have an edge location in Los Angeles
and some users want to read some data from there.

So your edge location is going to fetch the data
from your S3 buckets over the private AWS network
and give you the results from that edge location.

For the edge location of CloudFront to access your S3 buckets it is going to use an OAI or an origin access identity, it is IAM role for your CloudFront origin.

And using that role is going to access your S3 buckets
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 for example, in Sao Paulo in Brazil, or Mumbai, or Melbourne. And so all around the world, your edge locations are going to serve cached content

Question 9

EC2 as an origin

Answer 9

our EC2 instances must be public because they must be publicly accessible from HTTP standpoint

Our users all around the world will access our edge location and our edge location will access our EC2 instance and it traverses the security group.

So the security group must allow the IPs of CloudFront edge locations into the EC2 instance. There is a list of public IP for edge locations that you can get on this website.

Security group must allow all these public IP of edge locations to allow CloudFront to fetch content from your EC2 instances.

Question 10

Load Balancer as an origin

Answer 10

we have a security group for the an LB and the LB must be public to be accessible by CloudFront. But the backend EC2 instances now can be private.
security group for your ALB

must allow the public IP of the edge locations

Question 11

geo restriction

Answer 11

you can restrict who can access your distribution. So you can provide a white list. We’re saying, okay, only
users from this list of approved countries can go to a CloudFront.

Or we can say blacklist: the users from these countries
are not allowed to access our distribution.

The country is determined using a third party Geo-IP database where the incoming IP is matched against it to figure out the country.

Question 12

use case for geo restriction

Answer 12

when you have copyright laws to prevent access to your content. And you want to prove to regulators
that you are indeed restricting content access from,
say, France if you have content in America.

Question 13

CloudFront vs S3 cross region replication

Answer 13

CloudFront 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. And maybe you are okay if that content is outdated a little bit.

S3 cross region replication, it must be set up for each region in which you want to have replication to happen. And the files will be updated in near real time,
it’s going to be read only so is going to help you with read performance. So S3 cross region replication will be great if you have dynamic content that needs to be available at low latency in a few regions.

CloudFront is for catching globally and S3 cross region replication for replication into select regions.

Question 14

CloudFront signed URL and cookies

Answer 14

want to make CloudFront distribution private and you want to give access to people to premium paid shared content all over the world, but you want to be able to see and know who has access to what on your CloudFront distribution.

Question 15

CloudFront signed URL and cookies HOW

Answer 15

when we create a URL and a cookie, you need to attach a policy and you need to tell

• when the URL or the cookie expires
• what IP ranges can access this data from,

so if you know the target IP of your client’s, then you should definitely use that and the trusted signers.

• which AWS account can create signed URLs for your users.

Question 16

what’s the difference between a URL and a cookie?

Answer 16

A signed URL gives access to individual files so you get one URL per file

if you have a signed cookie then you get access to multiple files and the cookie can be reused so this time you have one signed cookie for many files.

Question 17

CloudFront signed URL example

Answer 17

Our CloudFront distribution has a bunch of edge locations and clients can access our S3 bucket through OAI, so Origin Access Identity for full security.

the objects in our S3 bucket cannot be accessed by anything else, but CloudFront, but we still want to be able to give people access to their objects through CloudFronts.

And our application code will use the AWS SDK to generate a signed URL directly from CloudFront. It will return the signed URL to the clients and then the client will be able to use that signed URL to get the data and files and objects or whatever he needs directly from CloudFront.

this also works for signed cookie

Question 18

should I use a CloudFront signed URL or an S3 pre-signed URL?

Answer 18

CloudFront signed URL is to allow access to a path no matter the origin, so signed URL works not just for S3 as an origin, but whatever you want. It’s an account wide-key-pair, so only the root can manage it, and you can filter by IP, path, date, and expiration, and you can leverage all the caching features out of CloudFront.

for S3 pre-signed URL the idea is that if I sign the URL
with my own IAM principal and then use my IAM key
to sign this, then the person who has that URL has the same rights as me.

if you want people to have access to your CloudFront distribution and it’s in front of S3, you have to use a signed URL because you cannot access your S3 bucket as you should because there is a bucket policy restricting it to the OAI, but if your users are using directly against S3 and you want to distribute a file directly without using CloudFront, then pre-signed URL would be a great use case for it.

Question 19

Which features allows us to distribute paid content from S3 securely, globally, if the S3 bucket is secured to only exchange data with CloudFront?

Answer 19

CloudFront Signed URL are commonly used to distribute paid content through dynamic CloudFront Signed URL generation.

Question 20

You are hosting highly dynamic content in Amazon S3 in us-east-1. Recently, there has been a need to make that data available with low latency in Singapore. What do you recommend using?

Answer 20

S3 CRR allows you to replicate the data from one bucket in a region to another bucket in another region

Question 21

How can you ensure that only users who access our website through Canada are authorized in CloudFront?

Answer 21

use CloudFront Geo Restriction

Question 22

You would like to provide your users access to hundreds of private files in your CloudFront distribution, which is fronting an HTTP web server behind an application load balancer. What should you use?

Answer 22

CloudFront Signed Cookies (not URL - it allows access to only one file)

Question 23

You are creating an application that is going to expose an HTTP REST API. There is a need to provide request routing rules at the HTTP level. Due to security requirements, your application can only be exposed through the use of two static IPs. How can you create a solution that validates these requirements?

Answer 23

Global Accelerator will provide us with the two static IP, and the ALB will provide us with the HTTP routing rules