网络课程笔记

00:00 So CloudFront has more capability

00:02 than just a CDN.

00:03 It is allowing you to run custom code at the edge

00:06 to do some customization.

00:08 So the idea is that you want to execute edge functions

00:11 as close as possible to users to make sure

00:14 that you're verifying some early logic, some early behavior,

00:17 or normalizing some cache keys.

00:19 So an edge function is a code that you write

00:19 and that you attach to your CloudFront distribution,

00:19 and it will run very, very close to your users

00:19 in order to minimize the latency

00:27 of whatever you're trying to do.

00:29 It doesn't have any cache behavior.

00:30 It is just here to change the request

00:32 and the response sent by the users and back to the users.

00:36 Now, CloudFront has two different logic for edge functions.

00:40 It has the CloudFront functions and Lambda@Edge.

00:43 We'll see them both in this lecture.

00:45 So the use cases for customization at the end is to,

00:48 at the edge is to manipulate HTTP request and responses.

00:52 Is to implement request filtering

00:53 before reaching your application.

00:54 Is to verify user authentication and authorization.

00:58 Is to also maybe generate HTTP responses

01:00 directly at the edge

01:02 or do A/B testing by separating users into two groups,

01:05 or for example, doing bot mitigation at the edge.

01:08 The idea is that using edge functions,

01:10 so either CloudFront functions or Lambda@Edge,

01:12 you do not have to manage any servers.

01:14 Everything is deployed globally and it is serverless.

01:14 So if we look at a traditional architecture of CloudFront,

01:21 we have our clients talking to our edge locations,

01:23 talking to original edge cache, talking to our origin.

01:26 Now, Lambda@Edge functions are going to be deployed

01:29 at the regional edge cache level,

01:31 whereas CloudFront functions are going to be deployed

01:31 on the edge location.

01:34 So as you can see, two different level for deployment

01:37 of these functions, and that will impact your choice

01:37 between CloudFront functions and Lambda@Edge functions.

01:42 So if we look at CloudFront functions,

01:44 they will interact with the viewer request

01:47 and the viewer response.

01:48 These are the request and response

01:50 that happen between the client and CloudFront.

01:52 It does not modify origin request or origin response.

01:55 So these are lightweight functions returning JavaScript,

01:58 and they're meant to do high scale latency sensitive

02:00 CDN customizations.

02:02 So it is a sub-millisecond startup time,

02:04 so it's very, very quick to start and it can handle

02:06 millions of requests per second.

02:09 So we run at edge locations

02:10 and it's process-based isolation.

02:13 So you want to change the viewer request and responses

02:15 as I said.

02:16 So what is the viewer request?

02:17 Well, it's after CloudFront receives a request

02:19 from a viewer, and your response is before CloudFront

02:22 forwards the response to the viewer.

02:24 So the idea is that it's a native feature of CloudFront.

02:26 You manage the code directly from within CloudFront,

02:29 and this allows you to do some very quick

02:32 time sensitive transformations in CloudFront.

02:34 Okay?

02:35 The idea is that you cannot call external services

02:38 from the CloudFront functions.

02:39 You just want to perform some transformations,

02:41 some computations or some normalizations

02:44 in a very, very quick fashion.

02:46 Now, Lambda@Edge is a different mindset.

02:49 So these were first what CloudFront was offering

02:52 as a feature.

02:53 CloudFront functions are new,

02:53 but Lambda@Edge has been existing for a long time,

02:56 and the idea was this is that you have Lambda functions

02:58 that are in either NodeJS or Python,

02:58 and you can scale to thousands of requests per second.

03:04 So less scale than your CloudFront functions for sure.

03:04 And they run on the nearest regional edge cache.

03:12 They're VM-based isolation,

03:14 and they're used to change both

03:14 CloudFront requests and responses.

03:18 So we can change the viewer request, the origin request,

03:20 which is the request that CloudFront sends to your origin.

03:24 You can change the origin response, so the response

03:26 that CloudFront receives from the origin

03:29 and as well as the viewer response.

03:31 Okay?

03:32 Now, when you want to deploy them,

03:33 that edge functions on CloudFront,

03:35 you need to author your functions in one region,

03:36 which is US East one,

03:38 and then CloudFront will replicate this function

03:40 to all its regional edge caches.

03:43 Now, if we have a look at

03:45 how these things can be used together.

03:46 So we have edge locations and regional edge caches,

03:49 and so the view request goes all the way like this,

03:52 then it goes through the origin,

03:53 and then the origin response goes all the way like this

03:55 to the viewer response.

03:57 Now your CloudFront functions

03:58 are going to run on the edge locations at the viewer request

04:02 and viewer response level,

04:03 whereas your Lambda@Edge functions are going to run

04:06 at the origin request and origin response level.

04:08 This is if you want to use both CloudFront functions

04:11 and Lambda@Edge functions together.

04:13 Okay, so this is one option

04:14 and we can see a clear separation of duties.

04:18 But if you want to just have Lambda@Edge functions,

04:22 then in that case, what's going to happen

04:23 is that the Lambda@Edge functions are going to operate

04:26 on both the viewer requests response

04:28 and the origin request and response,

04:29 but only at the regional edge cache level.

04:32 In this case, we cannot use CloudFront functions

04:34 because we cannot use both Lambda@Edge

04:36 and CloudFront functions

04:37 on the viewer request and responses.

04:40 So this is when you need capabilities of Lambda@Edge

04:43 that are not available with CloudFront functions.

04:44 For example, if you need a longer execution time,

04:44 network access, third party API calls, these kind of things.

04:44 So if we want to compare, you know, on the table,

04:54 the CloudFront functions and Lambda@Edge,

04:56 while the runtime support is different,

04:58 so one is JavaScript, pure JavaScript code,

05:00 the other one is NodeJS and Python,

05:02 where it gets executed is on edge locations

05:05 for CloudFront functions, whereas it's original edge cache

05:05 is for Lambda@Edge.

05:09 The CloudFront triggers is going to be the view request

05:11 and response for functions

05:12 and all of them, for them that edge.

05:15 The isolation is process-based versus VM-based.

05:17 Now, the max execution time

05:19 is what I think is the most important thing.

05:21 You only get one millisecond

05:22 to execute your CloudFront functions

05:24 and therefore they must be very, very quick

05:26 and very, very simple.

05:27 Whereas Lambda@Edge, you get five seconds of runtime

05:31 for viewers triggered and 30 seconds of runtime

05:34 for origin triggers.

05:35 The memory of your CloudFront functions

05:37 is low, two megabytes.

05:38 Whereas for Lambda@Edge, you have more memory,

05:41 128 megabytes or 10 gigabytes.

05:43 The total package size is very, very small

05:45 for CloudFront functions, 10 kilobytes.

05:46 Whereas Lambda@Edge has more space.

05:49 There's no network access, no file system access

05:51 for CloudFront functions,

05:52 whereas you have some for Lambda@Edge.

05:54 You do not have access to the request body

05:57 in CloudFront functions,

05:58 you have access to it in Lambda@Edge.

06:00 So CloudFront functions is really about

06:02 reading headers and so on.

06:04 And the pricing is that there's a free tier

06:06 for CloudFront functions,

06:07 and it's 1/6 of the price of @Edge.

06:09 So if you can move your logic from Lambda@Edge

06:12 to CloudFront functions, you're better off.

06:14 And Lambda@Edge has no free tier

06:15 and you get charged per request and duration.

06:18 So when do you use a CloudFront function

06:20 versus a Lambda@Edge function?

06:22 Well, CloudFront functions are going to be used

06:24 for cache key normalization.

06:25 So you want to transform the request attributes

06:27 such as the headers, cookies, the query string, the URL

06:30 to create an optimal cache key.

06:32 You also want to manipulate your headers,

06:34 so you want to change them.

06:34 So you want to insert, modify, or delete HTTP headers

06:37 in the request or response,

06:39 or you want to do your rewrites or redirects

06:41 or to request authentication

06:43 and authorization directly at the edge.

06:45 So in which you can create

06:46 and validate user generated tokens, for example, JWT,

06:50 to allow or deny request very, very close to your users.

06:54 Whereas Lambda@Edge is going to be giving you

06:56 a much longer execution time, okay?

06:57 Up to five seconds or 30 seconds.

07:00 You get adjustable CPU or memory.

07:01 You get to have code that can depend on

07:04 third party libraries.

07:04 For example, you can use the SDK

07:06 to access other AWS services.

07:08 You can use the network access to use external services

07:11 for processing, and you have file system access

07:13 if you wanted to cache some stuff locally,

07:15 or you can even access the body of the HTTP request

07:18 to manipulate the body itself.

07:20 So hopefully the use cases are clear and well-defined.

07:23 Now, if you wanted to do authorization

07:25 and authentication with CloudFront functions,

07:27 the idea is that at the Edge location

07:29 you would intercept the content

07:30 and you would check the token, the digital JWT token,

07:34 which lives in your headers, and then you can check

07:36 whether or not it is correct.

07:37 And then if it's not correct,

07:38 then the client will get an error message directly

07:41 without having your request go all the way to your origin.

07:44 Whereas your Lambda@Edge function

07:46 will operate on the regional edge cache level.

07:48 It could be intercepted by a Lambda function,

07:50 which can do some custom logic

07:51 and even issue third party API calls

07:54 to check whether or not the authorization

07:56 and authentication is properly well set up.

07:58 Another very common use case for CloudFront functions

07:58 is to load content based on the user agents.

08:04 We have an S3 bucket

08:05 and Amazon CloudFront with original Edge cache

08:07 and we have users accessing it from desktop

08:10 and others just accessing it from mobile.

08:12 Now they both wanna access a cat picture,

08:14 so they do a request for cat picture,

08:16 and the resolution is super high.

08:17 So 1920-1080.

08:23 So it's 1080p and they request it from CloudFront.

08:25 So if the request goes well,

08:27 well the request is passed all the way through

08:29 to the S3 bucket to get that specific image.

08:32 But imagine that the same request is done

08:35 from our mobile device, and this time the user agent

08:37 is not Chrome, it is the iPhone OS Safari.

08:41 Now what we can do is instead of sending this big image

08:45 back to our mobile, which may be very inefficient,

08:48 we can have a CloudFront function

08:50 that will inspect the user agent HTTP header

08:50 and then redirect based on the device type.

08:56 And so there, therefore,

08:58 because our device is a mobile device,

09:00 then the image is going to be asked into our S3 bucket

09:03 is going to be cat 640-320,

09:06 which is a lower resolution for our cat picture.

09:10 And this is the picture that will be returned

09:10 by our S3 bucket into our mobile device.

09:14 So the function was able to modify the request

09:14 to change the target of these requests.

09:21 So the other way you can use Lambda@Edge

09:23 is for a global application, for example,

09:24 your client gets the website from an S3 bucket,

09:24 and then for dynamic API request,

09:29 it sends it into CloudFront to leverage the cache.

09:32 But your Lambda function can also be used, for example,

09:34 to query data into DynamoDB table,

09:36 which gives you a fully global

09:36 and serverless way to do an API in AWS.

09:44 So that's it.

09:44 At the exam level what you need to know

09:47 is understand when you need to use Lambda@Edge

09:47 or CloudFront functions, and that should be good to go.

09:52 But I want to give you a bit more detail

09:53 so you can really understand the use cases behind it.

09:55 So I hope you liked this lecture

09:56 and I will see you in the next lecture.