‫So let's talk about
‫Customization At The Edge.
‫So what does it mean?
‫Well we know we deploy our functions
‫and our applications in a specific region,
‫but sometimes using, for example, CloudFront,
‫we have the Edge locations are distributing our content.
‫And sometimes the modern applications require
‫to execute some form of logic at the Edge
‫before reaching the application itself.
‫So these are called Edge Functions,
‫and this is a piece of code that you write
‫and that you will attach to your CloudFront distributions.
‫The idea is that you want to run these functions
‫close to users in order to minimize latency in some cases.
‫So CloudFront has two kinds of functions,
‫you have the CloudFront Functions and Lambda@Edge.
‫The idea will be to be able to understand
‫when they are required and their differences,
‫and will do this in this lecture.
‫But using the Edge Functions,
‫you don't have to manage any servers,
‫these Edge Functions are deployed globally.
‫And the use cases of them,
‫for example, would be to customize the CDN content
‫coming out of CloudFront.
‫Also, you only pay for what you use,
‫and it is fully serverless.
‫So now let's have a deeper look
‫into these things, the use cases.
‫The first one is around website security and privacy,
‫then we have dynamic web applications at the Edge,
‫we can do search engine optimization, SEO,
‫we can do intelligent routing across
‫Origins and data center,
‫Bot mitigation at the Edge,
‫real-time image transformation at the Edge,
‫A/B testing, user authentication and authorization,
‫user prioritization, user tracking and analytics, and so on.
‫So this is a lot of different customizations
‫we can have using CloudFront Functions and Lambda@Edge.
‫So now let's discuss what CloudFront Functions
‫are used for and how they work.
‫So this is what a typical request
‫into CloudFront looks like.
‫So the client will do a request into CloudFront,
‫and this is called a viewer request,
‫because the client views it.
‫Then CloudFront will do an origin request
‫into your origin server,
‫the server will reply to CloudFront,
‫so we have an origin response,
‫and finally CloudFront sends that response to the client,
‫so we have a viewer response.
‫Now CloudFront Functions are lightweight functions
‫written in JavaScript,
‫and they modified the viewer request and response.
‫They're used for high-scale,
‫latency-sensitive CDN customizations,
‫which gives you sub-millisecond startup times,
‫and a scale of millions of requests per second.
‫As I said, they're used to change viewer request
‫and responses only,
‫so the view request is after CloudFront
‫receives a request from a viewer, we can modify this,
‫or the viewer response is to
‫before CloudFront forwards the response back to the viewer.
‫It's a native feature of CloudFront,
‫and the entire code is managed
‫from within CloudFront directly.
‫Remember, CloudFront Functions high performance,
‫high scale only for the viewer request and response.
‫Now Lambda@Edge is a bit more,
‫so you can modify all of them.
‫So these are functions returned in NodeJS or Python,
‫and you scale to 1000s of requests per second,
‫and it's used to change CloudFront request
‫and response, multiple ones, so all of them actually,
‫the viewer request and the origin request,
‫which is before CloudFront forwards a request to the origin.
‫You also have the origin response,
‫which is after CloudFront receives the response
‫from the origin, and the viewer response,
‫which is before CloudFront forwards
‫the response back to the viewer.
‫You author your function in one region,
‫which is us-east-1, which is the same region
‫where you manage your CloudFront distributions,
‫and then CloudFront is going to replicate this function
‫to all of its locations.
‫So we have a table here to differentiate
‫between CloudFront Functions and Lambda@Edge.
‫So one notable difference is the runtime support,
‫of course JavaScript only for CloudFront Functions,
‫and then NodeJS and Python for Lambda@Edge.
‫The scale is really, really high scale
‫for CloudFront Functions, we're talking about
‫millions of requests per second,
‫versus thousands for Lambda@Edge.
‫Now where the trigger is happening is a big difference.
‫So Lambda@Edge has impact on both
‫the viewer request and the origin,
‫whereas the CloudFront Functions is only on the viewer.
‫And very important, the max execution time
‫is less than one millisecond for CloudFront Functions,
‫so they're very, very quick and simple functions.
‫Whereas for Lambda@Edge you can get
‫up to 5 to 10 seconds,
‫so you can perform a lot of logic in these functions.
‫The rest, you can have a look, okay?
‫Now in terms of use cases,
‫CloudFront Functions is going to be for
‫cache key normalization,
‫so to transform, for example the request attributes
‫to create an optimal cache key.
‫Header manipulation to insert, modify, or delete
‫HTTP headers in the request or response,
‫or to do URL rewrites or redirects,
‫or to request of an authorization
‫to create and validate JWT tokens to allow or deny request.
‫So all these things can be executed
‫in less than one millisecond,
‫whereas Lambda@Edge has a longer execution time,
‫it could be up to 10 seconds, for example.
‫You have adjustable CPU and memory,
‫so you can load a lot of libraries,
‫and your code can depend therefore,
‫on third party libraries, such as the SDK
‫if you wanted to access other AWS services.
‫You also have network access to external services
‫for processing the data,
‫so you can really perform some big integrations.
‫And Lambd@Edge gives you file system access,
‫or access to the body itself of the HTTP request,
‫so you can do some more customizations.
‫So hopefully that helps you.
‫I hope you liked this lecture,
‫and I will see you in the next lecture.