Section 15: CloudFront

Question 1

T/F
* A) CloudFront is a Contend Delivery Network (CDN)
* B) improves read/write performance/user experience by caching content at the endge
* C) 216 point of presence globally (edge locaitons)
* D) DDOS protection (because worldword), integration with Shield, AWS Web App FIrewall

Answer 1

B is false. It’s just read performance/user experience

Question 2

T/F
CloudFront origins
* A) S3 bucket: distributing files and caching them at the edge; enchanced security with CloudFront Origin Access Control; OAC is replacing Origin Access Identity (OAI); CloudFront can be used as an ingress (to upload files to S3)
* B) Custom Origin (HTTP): App Load balancer; ec2 instance; s3 website (must first enable bucket as static s3 website); any http backend you want

Answer 2

T

Question 3

hey, random, but I just realized that I think you can host dynamic sites on static s3 sites. idk. check this out https://aws.amazon.com/blogs/architecture/create-dynamic-contact-forms-for-s3-static-websites-using-aws-lambda-amazon-api-gateway-and-amazon-ses/.

Question 4

T/F
* when client does an http request into your edge location, then edge location will see if it has your results in the cache. If it doesn’t, it’ll store results in the cache.

Answer 4

T

Question 5

T/F

CloudFront - S3 as an origin

• so if I have one s3 bucket and it uses an Origin Access Control + S3 bucket policy to handle what accesses are and aren’t allowed then people from all over the world will first go through their nearest edge location and if the info is cached then the edge location won’t bother the s3 bucket at all. If the requested info isn’t already cached, your edge location will get the info rom your s3 bucket and then send it off to users with public internet access and then cache that info.

Answer 5

T

Question 6

Which describes CloudFront and which describes Cross Region Replication? (add any important things to remember when answering)

• A) files cached for TTL (maybe a day); great for static content that must be available everywhere
• B) files updated near real-time; read only; great for dynamic content that needs to be available at low-latency in certain places

Answer 6

• A) Cloudfront: Global edge network; files cached for TTL (maybe a day); great for static content that must be available everywhere
• B) s3 cross region replication: must be set up for each region you want replication to happen; files updated near real-time; read only; great for dynamic content that needs to be available at low-latency in a few regionsT

Question 7

you created a cloudfront distribution for your s3 bucket s3”//somebucketsnacks, but when you go to the index.html (not the public one, the one you see when you click the ‘Open’ button you forget about all the time), you still don’t see the beach.jpg that the code says should be there. What’s up?

Answer 7

Probably you forgot to update the bucket policy. Here’s the note you see when you selected somebucketsnacks on the cloudfront distribution form:

You must update the S3 bucket policy
CloudFront will provide you with the policy statement after creating the distribution.

Question 8

hey what’s a good default root object for your cloudfront distrubution (idk why they call it a distribution, basically it just looks like a configuration form).

Answer 8

good old index.html

Question 9

Hey, i know we had another card that said something else, but in this thing that I just copied from aws, note that neither Resource nor Action needed the brackets to indiciate list items. Maybe now you don’t need brackets unless you’re actually making a whole list?

{
“Version”: “2008-10-17”,
“Id”: “PolicyForCloudFrontPrivateContent”,
“Statement”: [
{
“Sid”: “AllowCloudFrontServicePrincipal”,
“Effect”: “Allow”,
“Principal”: {
“Service”: “cloudfront.amazonaws.com”
},
“Action”: “s3:GetObject”,
“Resource”: “arn:aws:s3:::somebucketsnacks/*”,
“Condition”: {
“StringEquals”: {
“AWS:SourceArn”: “arn:aws:cloudfront::781742995911:distribution/E2R2JSCYSROKEG”
}
}
}
]
}

Answer 9

T

Question 10

If you set up cloud front to work with an S3 bucket, does the public use the s3 bucket’s url or your cloudfront distributions Distribution Domain Name?

Answer 10

Public uses your cloudfront distribution’s distrubution domain name

Question 11

Which of the following, if any, is false (and what is the true version)?

Caching
* A) Cache lives at each CloudFront Edge Location
* B) CloudFront identifies each object in the cache using the Cache Lock
* C) Cache expires based on TTL
* D) you want to maximize cache hit ratio to minimize requests to the origin (requests to your s3 bucket or main whatever)
* E) you can invalidate part of the cache using the CreateInvalidation API

Answer 11

B is false. True version is:
* B) CloudFront identifies each object in the cache using the Cache Key

CloudFront Caching & Caching Policies

Question 12

T/F
CloudFront Cache Key:
* by default, consists of hostname + resource portion of the url. hostname ex: mywebsite.com; resource portion of ex: “/content/stories/example-story.html” in content/stories/example-story.html?ref=123&whatever=something

Answer 12

T

Question 13

How might you use S3, CloudFront edge locations, and CloudFront caching, and what does this picture have to do with it?

Answer 13

Question 14

If I set up CloudFront and S3 together, which does a user reach first when trying to get to my website?

Answer 14

Question 15

How does CloudFront identify objects in the cache?

Answer 15

Using the Cache Key

Question 16

Do you want ot maximize or minimize the cache hit ratio, and why? (hint, to ____ requests to the origin)

Answer 16

Maximize, because you want to minimize requests to the origin

Question 17

T/F
You can invalidate part of the cache using the CreateInvalidation API

Answer 17

True

Question 18

T/F
CloudFront Cache Key is a unique identifier for every object in the cache.

Answer 18

True

Question 19

T/F
* you can add other elements to the cache key using CloudFront Cache Policies (HTTP headers, cookies, query strings)

Answer 19

T

Question 20

How might you use EC2, CloudFront Edge Locations, and CloudFront Caching together?

Answer 20

Question 21

Describe this.

Answer 21

You have an app (UI and a backend) you’re serving on an EC2 instance. Sam is trying to some data to show up in the UI. Sam ends up first going to the nearest (depending on how you set things up) CloudFront (without them knowing, of course) Edge Location. Then the Edge Location checks out it’s (perhaps each Edge Location gets it’s own Cache? Things are getting fuzzy here) cache to see if the desired data is there. If it is, that’s a cache hit and the data goes back to fill in the user’s UI. If the desired data isn’t in the edge location cache, that’s a cache miss. The edge location reaches out to your Ec2 instance, gets the data, sticks a copy in the cache and returns a copy to Sam.

Update: I didn’t look at this any kind of thoroughly, but it does seem like each CF EL has it’s own cache.

update update: Cache lives at each CloudFront Edge Location <- from lectures

Question 22

Does each CloudFront Edge Location have it’s own cache?

Answer 22

Yes

Question 23

What’s an origin request header?

Answer 23

The Origin request header indicates the origin (scheme, hostname, and port) that caused the request. For example, if a user agent needs to request resources included in a page, or fetched by scripts that it executes, then the origin of the page may be included in the request.

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Origin

Question 24

T/F

Cached based on
* HTTP headers: None, Whitelist
* Cookies: None, Whitelist, Include All-Except, All
* Query Strings: None, Whitelist, Include All-Except, All

Control the TTL (0 sec to 1 year using Cache-Control header, Expires header etc)

Create your own policy or use Predefined Managed Policies

All HTTP headers, cookies, and query strings that you include in teh cache key are automatically included in origin requests

Answer 24

T

Question 25

Does Cache Policy value of ‘None’ for HTTP headers, Cookies and Query Strings give you the best caching performance? Would a cache policy value of ‘All’ for those things give you the worst caching performance?

Answer 25

Yes.

Question 26

Is Language: fr-fr (for French-French, but focus on the header key ‘Language’, not the value associated with it (fr-fr)) a good example of a header to Whitelist if you think your blog is going to be read by people who speak a variety of languages?

Answer 26

yes

Question 27

T/F, when you’re talking CloudFront, there are two important policies to keep in mind: Cache Policy and Origin Request Policies

Answer 27

T

Question 28

what is a domain name again? (examples)

Answer 28

examples.com, anna.com, lovm.com.

In the http headers, this is referred to as the ‘host’. -_-.

Question 29

T/F

Include in the Origin Request Policy stuff you don’t defined as wanting to be cached in the cache policy (though honestly it seems like in an example me mentions Header Authorization as being cached and part of the origin request policy.)

Answer 29

True

https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/controlling-origin-requests.html

Question 30

T

User (viewer?) request comes with cookies, request headers, query strings and we cache based on cache policy.

but your origin may need more than that to properly serve data. It may need new headers, like ‘User Agent’, a new session_id cookie, and a certain query string value. That’s the stuff that goes in your origin request policy.

Answer 30

T

Question 31

Talk about this.

Answer 31

Legolas wants to get their data to show up in the UI they’re looking at.
Their request (along with various headers) goes to the nearest (or appropriate) CloudFront Edge Location. If there’s already a data match for the host/subdomains/path as well as what I’m assuming is a valid authorization header, the authorization header, that’s a cache hit and the data goes back to the UI, Legolas can look at pics of Fangorn Forest. I’m not sure what happens if the data for the host/subdomains/path (say like a get request) is there but the authorization key doesn’t match. Maybe the auth key gets validated and added to the apprioriate cache record? Maybe that’s not possible so it counts as a cache miss? Probably beyond the scope of this test.

Okay, Say you got a cache miss. Then the request is forwarded to the origin (an ec2 instance in this example) along with the appropriate headers (the headers whitelisted in the Origin Request Policy) and if your app likes what it sees it’ll return the data back to Legolas and send a copy back to the edge location cache, and maybe that’s when the new cache record gets stored.

yea that seems good, so the cache record doesn’t get created till you have data Legolas requested from the app (connected to the db somewhere) on the ec2 instance.

Question 32

Fill in the question marks so you can explain this

Answer 32

Question 33

1. Is the system described in this flowchart possible?
2. Is the default Cache Behavior first or last to be processed?
3. T/F the Default cache behavior is always assocaited with “/*”

Answer 33

1. Yes. They call them CloudFront Cache Behaviors, though I think they get defined through your CloudFront Distributions (which is just a fancy word for a CloudFront definition/setup/description)
2. last. Specific cache behaviors will be processed first.
3. True

Question 34

Number these and talk about what’s going on

Answer 34

numbers shown follow the process of Cloud Front Cache Behaviors can be used as a user goes to the /login page and gets a signed cookie from the ec2 instance. Then that cookie goes all the way back the user, then gets sent with the request for data to the s3 bucket, and then the data is able to get back to the users (the flowchart includes some stuff i missed, like where the cloud front distribution fits into all of that, but that’s the general idea) (f)

Question 35

Can you use to CloudFront to separate static (ex: s3) and dynamic (ex: alb + ec2) distributions? If yes, draw it out.

Answer 35

Question 36

T/F

1. If you’re going from an edge location to an ec2 instance, the ec2 instance must be public and you set up your cloudfront distribution to allow public IP of edge locations (the only words i’m not sure about there are “set up your cloudfront distribution”)
2. If you have edge locations reaching out to ALB which then goes to an EC2 instance, your Application Load Balance MUST be public and (or is it to?) allow the public ip of the edge locations. Then you can make your EC2 instance private if you and then on your ec2 instance you setup probably inbound and outbound traffic to allow the security group of the load balancer (only words i’m not sure about are “setup probably inbound and outbound traffic to”)

Answer 36

T

ALB as Origin

Question 37

About Geo Restriction:

T/F. You can set up an allowlist or a blocklist. The country is determined using a 3rd party geo-ip database. use case: copying laws to control access to content.

Answer 37

T. It’s super easy, it’s just a tab on your cloud front distribution and you just create a list.

Geo Restriction

Question 38

I can think of about one reason you’d want to use an s3 presigned url instead of a cloudfront signed url. What might that be?

Answer 38

You only have the s3 bucket, no cloudfront anything. You block all public access to your s3 bucket and want to give one person (or like at most a family-number group of people) who you have a relevant amount of trust in access to your s3 bucket, and you dont mind that if you create a presigned url, those people you share the presigned url with are going to be using thte IAM key of the signing IAM principal (i think that’s you, in this situation).

Question 39

T/

T/F

CloudFront Signed URL
* allow access to a path, no matter the origin
* account wide key pair, only root can manage
* can filter by IP, path, date, expiration
* can leverage caching features

S3 Presigned URL
* issues request as person who presigned url
* uses IAM key of signing iam principlal
* limited lifetime

Question 40

T/F use a trusted key group to create a cloudfont signed url so you can leverage api’s to create and rotate keys (and IAM for API security)

Answer 40

T

Question 41

T/F
* For Cloudfront signed urls, you generate your own public/private key.
* private key is used by your apps (ex: ec2) to sign urls
* public key (uploaded) is used by cloudfront to verify utls

Question 42

Cloudfront Pricing
* cost of data out per edge location varies (mex/us/can costs different than south america)
*

can come up in exam

Question 43

T/F

you can reduce number of edge locations for cost reductions. Three price classes:
* Price Classs All - best performance, most expensive
* Price Class 200 - everywhere except South America, Australia and New Zealand (au and nz are one group)
* Price class 100: only US, Mex and Can (that’s all one group) and Europe and Israel (those two are another grou)

Answer 43

T

Question 44

T/F
Cloud Front Origin Group

• increase high availability and do failover
• origin group: one primary (ex an ec2 instance) and one secondary origin (another ec2 instance in the same origin group)
• if cloudfront tries to get data from the primary and fails with some error (not like a permissions error but a more serious one), the second origin is used

Question 45

Can you setup failover system to make the apps served by your cloudfront distrubtion more available?

Answer 45

Yes, using CloudFront Origin Group

Cloud Front Origin Group

• increase high availability and do failover
• origin group: one primary (ex an ec2 instance) and one secondary origin (another ec2 instance in the same origin group)
• if cloudfront tries to get data from the primary and fails with some error (not like a permissions error but a more serious one), the second origin is used

Question 46

Cloud Front Field LEvel Encryption

• protet user sensitive info through app stack
• adds additional layer of security along with https
• sensitive info encrypted at edge closest to user
• uses asymmetric encryption

Answer 46

T

Question 47

T/F CloudFront Field LEvel Encryption Uses
* specify a set of fields in POST request that you want to be encrypted (up to 10 fields)
* specify public key to encrypt them

Answer 47

T

Question 48

So this one flowchart makes it look like requests go from a client to an edge location, not necessarily the cloudfront distribution, but i think that’s just how this one chart looks, cuz really edge locations are part of cloudfront and which edge locations you can get to depends on your cloudfront distribution etc. Anyway

You can tell CloudFront that you want your edge locations to do field level encyrption and encrypt credit card data (using some public key whatever) and then after that the credit card data is at least encrypted as the request goes through the rest of cloudfront to an ALB and to your web servers. The web server will have access to the private key that it needs to decrypt the encrypted credit card info.

Answer 48

T

Question 49

Cloud Front Real Time logs. Get real time requests received by CloudFront sent to Kinesis Data Streams so you can monitor, analyze, take action etc.

T/F

near real-time processing
* users -> cloudfront -> logs go to kinesis data streams -> records go to Lambda

real-time processing
* users -> cloudfront -> logs go to kinesis data streams -> records go to Kinesis Data Firehose

Answer 49

False!
here’s the true version

real-time processing
* users -> cloudfront -> logs go to kinesis data streams -> records go to Lambda

near real-time processing
* users -> cloudfront -> logs go to kinesis data streams -> records go to Kinesis Data Firehose

Question 50

Answer 50

Correct answer is C. “CloudFront Signed URLs are commonly used to distribute paid content through dynamically generated signed URLs.”

no incorrect answers have notes

Question 51

Answer 51

B. CloudFront Geo Restriction. No answer choices have notes.

Question 52

Answer 52

Correct answer is A. Origin Answer Control. no answer choices have notes.

Question 53

Answer 53

Correct answer is D. “Signed Cookies are useful when you want to access multiple files.”

Did not check incorrect answer notes.

Question 54

Answer 54

Correct answer is B. Only allow S3 bucket content to be accessed from CloudFront distribution. No notes for any answer choices.

Question 55

Answer 55

Correct answer is A: Use CloudFront invalidation. No answer choices have notes.

Question 56

Answer 56

Correct answer is B. “S3 Cross-Region Replication allows you to replicate the data from one S3 bucket in an AWS region to another S3 bucket in another AWS region.”

Did not check answer choice A for notes.

Question 57

Answer 57

Correct answer choice is D. HTTP Methods. no answer choices have notes.

Question 58

Answer 58

Correct answer choice is A. Trusted Key Group, CloudFront Key Pair. No notes on this answer.