brief introduction
This article is for users who want to use Amazon CloudFront Lambda@Edge to improve Amazon CloudFront's edge computing capabilities, and aims to help you better develop, debug, test, and deploy CloudFront Lambda@Edge.
First, we will give a brief introduction to CloudFront Lambda@Edge, and then tell you how to create a test environment with CloudFront Lambda@Edge processing capabilities in seven steps, and carry out some related debugging work.
Step 1: Prepare the overall architecture based on the deployment guide (2)
Step 2: Create a Lambda function
Step 3: Add a CloudFront trigger to run the function
Step 4: CloudFront Lambda@Edge log output and query
Step 5: Use Response Header to improve debugging efficiency
Step 6: View Lambda@Edge resource utilization
Step 7: CFF Application in CloudFront Extension
Through this guide, you will learn how to use CloudFront to quickly build a content distribution network and demonstrate the distribution effect.
CloudFront Function
A brief introduction to Lambda@Edge
With Amazon CloudFront, you write your own code to handle HTTP requests and responses. Code runs close to your users to minimize latency, and you don't have to manage servers or other infrastructure. You can write code to manipulate requests and responses flowing through CloudFront, perform basic authentication and authorization, generate HTTP responses at the edge, and more. The code that you write and attach to your CloudFront distribution is called an edge function. CloudFront currently offers two methods for authoring and managing edge functions:
CloudFront Functions – With CloudFront Functions, you can write lightweight functions in JavaScript for large-scale, latency-sensitive CDN custom processing. The CloudFront Functions runtime environment provides sub-millisecond startup times, scales instantly to handle millions of requests per second, and is highly secure. CloudFront Functions are native to CloudFront, which means you can build, test, and deploy your code entirely within CloudFront.
Lambda@Edge – Lambda@Edge is an extension of Amazon Lambda that provides powerful and flexible computing for complex functions and complete application logic, closer to your viewers, and highly secure. Lambda@Edge functions run in js or Python runtime environment. You publish them to a single Amazon region, but when you associate a function with a CloudFront distribution, Lambda@Edge automatically replicates your code globally.
The differences and choices between CloudFront Functions and Lambda@Edge can be found in the CloudFront documentation.
This article will be dedicated to introducing CloudFront Lambda@Edge, about
For a detailed introduction to CloudFront Functions, please refer to Amazon CloudFront Deployment Guide (4) - CloudFront Function Basics and Diagnosis .
As shown in the figure below, Lambda@Edge can be placed in both the Viewer stage and the Origin stage. Lambda@Edge is ideal for the following scenarios:
Functions that take milliseconds or more to complete.
Functions that require CPU or memory scaling.
Functions that depend on third-party libraries, including the Amazon SDK for integration with other Amazon services.
Functions that require network access to use external services for processing.
Functions that require file system access or access to the body of an HTTP request.
how to start
Development of CloudFront Lambda@Edge
CloudFront Lambda@Edge is an extension of Lambda. In actual use, the development, testing, and deployment of Lambda are completed first, and then associated with the CloudFront distribution. CloudFront will distribute Lambda to edge sites, and intercept requests and responses in edge sites. Processing can significantly reduce latency and improve user experience.
Different from Lambda, Lambda@Edge only supports Node.js and Python as development languages, and must be created in the US East (N. Virginia) region, and it will be automatically distributed to each edge site for execution. For more restrictions on Lambda@Edge, please refer to the developer guide.
Below we set out to build a minimal CloudFront Lambda@Edge environment.
step one:
Prepare the overall architecture based on the deployment guide (2) to demonstrate the deployment process
First, let's build a CloudFront environment that accelerates dynamic and static websites based on the CloudFront deployment guide (2) . In this article, we will mainly use the part of the dynamic website in this environment to complete the debugging.
During the debugging process, we will mainly use /api, the Behavior path that disables caching, for debugging. Use Echo-Sever to observe changes in web requests brought by CloudFront Lambda@Edge.
Step two:
Create a Lambda function
You can refer to the third step of the official document to quickly create a sample function that modifies the response header by using the blueprint. Use the following code to test, the following code increases the output of the AWS_REGION environment variable, and returns it to the client together with the custom function-version in the header.
The third step of the official document: https://docs.aws.amazon.com/zh_cn/AmazonCloudFront/latest/DeveloperGuide/lambda-edge-how-it-works-tutorial.html#lambda-edge-how-it-works- tutorial-create-function
If you want to know more about environment variables, you can refer to the official documentation to retrieve environment variables.
*Note that the function to modify the response header needs to be associated with CloudFront's Viewer Response or Origin Response (Origin Response) event, and modify the CloudFront's response event data structure. This data structure is not available in Viewer Request and Origin Request events.
'use strict';
exports.handler = (event, context, callback) => {
//Get contents of response
const response = event.Records[0].cf.response;
const headers = response.headers;
let region = process.env.AWS_REGION;
console.log("region: ", region);
//Set new headers
headers['strict-transport-security'] = [{key: 'Strict-Transport-Security', value: 'max-age= 63072000; includeSubdomains; preload'}];
headers['content-security-policy'] = [{key: 'Content-Security-Policy', value: "default-src 'none'; img-src 'self'; script-src 'self'; style-src 'self'; object-src 'none'"}];
headers['x-content-type-options'] = [{key: 'X-Content-Type-Options', value: 'nosniff'}];
headers['x-frame-options'] = [{key: 'X-Frame-Options', value: 'DENY'}];
headers['x-xss-protection'] = [{key: 'X-XSS-Protection', value: '1; mode=block'}];
headers['referrer-policy'] = [{key: 'Referrer-Policy', value: 'same-origin'}];
headers['function-version'] = [{key: 'Function-Version', value: 'V01'}];
headers['function-region'] = [{key: 'Function-Region', value: region}];
//Return modified response
callback(null, response);
};Swipe left to see more
Step three:
Add a CloudFront trigger to run the function
You can refer to step 4 of the official document to configure a CloudFront trigger for the Lambda function to run your function. Here you can select the CloudFront distribution created in advance in step 1, and select /api/* for the cache behavior. This time, we select Origin Response for the CloudFront event type , check Confirm to deploy to Lambda@Edge, and click Deploy.
The fourth step of the official document: https://docs.aws.amazon.com/zh_cn/AmazonCloudFront/latest/DeveloperGuide/lambda-edge-how-it-works-tutorial.html#lambda-edge-how-it-works- tutorial-add-trigger
After the deployment is complete, you can test it through the curl command, and we can see that the header information added in Lambda has been included in the response header.
Note: The deployment of Lambda@Edge takes some time. You can enter the general page in the CloudFront distribution to check the last modification time and confirm the deployment progress.
curl -i http://xxxx.cloudfront.net/api/testSwipe left to see more
Update the Lambda@Edge function
Method 1: Republish on the Lambda console
For functions that have been deployed to Lambda@Edge, if you modify the code in Lambda, you need to click the Deploy button first to save the modified code. Then repeat step three to deploy the modified function to Lambda@Edge.
Method 2: After a new version is released, update CloudFront
After deployment (Deploy) , switch to the Version tab, click Publish New Version to publish, and you will get a new version number after publishing, then go to the CloudFront console to select the target distribution to be deployed, and select the corresponding one in Behavior Click the Edit button, update the function ARN/name in the function association at the bottom to the version number just generated, and click Save Changes .
For scenarios where the source request and source response need to be updated at the same time , method 2 can be adopted to change the versions of the source request and source response at the same time , so that CloudFront can update the two functions at the same time during deployment.
Step four:
CloudFront Lambda@Edge log output and query
Use Console.log for log output, and Lambda@Edge will automatically send logs to the CloudWatch log group, and create a log stream in the Amazon region where the function runs. The format of the log group name is
/aws/lambda/us-east-1.function-name ，
where function-name is the name you gave the function when you created it, and us-east-1 is the region code for the Amazon region in which the function is running.
The logs of Lambda@Edge are stored in the area where the function is actually executed, not the area where the function is deployed ( us-east-1 ), so when debugging, you need to first determine the area where the function is executed, and switch to the corresponding area in the CloudWatch console , search function-name to enter the log group to view the latest log. In the case of uncertain execution areas, if you keep switching between areas to find log information, it will be extremely time-consuming. Moreover, due to the delay in the log, there will be cases where the correct area is obviously found, but the log is missed due to the delay, and then the search is kept in the wrong area, which wastes precious time.
The way mentioned in the official document is to view the index chart of the corresponding function on the CloudFront console. Since it is statistical information, it may be applicable when there are very few requests. If there are a certain number of requests in multiple regions, it is more difficult to judge .
Through the X-Amz-Cf-Pop value in the Header, you can get the edge location number corresponding to the current request, and you can find the corresponding country and city through the Amazon CloudFront CDN Edge Locations website, and you can find logs in its adjacent regions .
Here is a method to quickly and accurately obtain the region where the function is executed each time, which is to obtain the AWS_REGION environment variable and return it in the Response Header. Here AWS_REGION refers to the Amazon region where the Lambda function is executed.
Method to realize:
If you have already created Lambda code for Origin Response , add the following line of code before returning the modified response in the code:
event.Records[0].cf.response.headers['execution-region'] = [{key: 'Execution-Region', value: process.env.AWS_REGION}];Swipe left to see more
If you have only created a Lambda code for Origin Request , it is recommended that you use the following code to create a Lambda code for Origin Response and deploy it to Lambda@Edge.
'use strict';
exports.handler = (event, context, callback) => {
event.Records[0].cf.response.headers['execution-region'] = [{key: 'Execution-Region', value: process.env.AWS_REGION}];
callback(null, response);
};Swipe left to see more
The following is an example of the response result. As long as the response can be obtained, the region where the function is executed can be known through the response header, and then you can switch to the region in the CloudWatch console and wait for the logs to appear.
Note: When publishing to a production environment, it is recommended to delete unnecessary log output to save costs. If desired, you can also disable Lambda's permission to CloudWatch log output to eliminate any logs by removing Allow:logs:PutLogEvents from the execution role .
Step five:
Using Response Header to Improve Debugging Efficiency
In the case of online debugging, you can determine which version of the code the current request uses by adding a version header to the Response Header. Every time you update the code, you need to use a new version number, you can refer to the Function-Version in the above code.
When debugging, if you want to print and view the value of a certain variable, you can convert the variable to string type and put it in the Response Header for output. In this way, the value can be checked after the response result is obtained, without having to check it in the console, which greatly improves efficiency.
This method is described in detail in Amazon CloudFront Deployment Guide (4) - CloudFront Function Basics and Diagnosis . The ideas and methods are very similar, so you can refer to it.
When using the response header output information for debugging, you need to follow the response header specification, the value must be of string type, and only when the CloudFront Function executes normally and returns the response completely to the client can you see the relevant information. If the code execution is abnormal or interrupted, a normal response cannot be obtained. At this time, the debugging information cannot be viewed through the response header. In this case, console.log() can print out the logs before the abnormal interruption. We can use it in conjunction with actual development and testing.
Step six:
View Lambda@Edge resource utilization
We can check the execution time of the function and the memory information used by CloudWatch Logs. It is recommended to test with Lambda Power Tuning to obtain the optimal memory configuration before releasing to the production environment.
Step seven:
Lambda@Edge Application in CloudFront Extension
The whole process of development and debugging of CloudFront Lambda@Edge is introduced above with the case of modifying HTTP Response. There are also many code cases in the CloudFront Extension project maintained by Amazon Solutions Team (CSDC), which can be used for your reference and study. The Github link for the CloudFront Extension is here: aws-cloudfront-extensions.
Summarize
With this article, you should have a hands-on understanding of CloudFront Lambda@Edge. You now have a small and practical CloudFront Lambda@Edge debugging environment, in which you can use CloudFront Lambda@Edge code to modify web requests according to your needs, and observe their operation through Echo-Server, CloudWatch indicators and logs In addition, you can instantly know the area where the function is executed and the running status of the program through the log header written in the Response Header.
Amazon Cloud Technology CloudFront Deployment Small Guide Series Articles
Click on the title to view previous articles:
Amazon CloudFront Deployment Guide (1) - Quickly Build CDN Content Distribution
Amazon CloudFront Deployment Guide (2) - Advanced Deployment
Amazon CloudFront Deployment Guide (3) - Continuous Deployment
Amazon CloudFront Deployment Guide (4) - CloudFront Function Basics and Diagnosis
The author of this article
Zhu Jinsong
Amazon cloud technology solution architect, responsible for solution consulting and design based on Amazon cloud platform, has more than 10 years of working experience in the IT industry, has served as system architect, big data director, CTO and other positions, in edge computing, serverless, big data Has rich practical experience.
Cui Junjie
Senior Product Solution Architect of Amazon Cloud Technology, responsible for cloud edge security related service products of Amazon Cloud Technology. Provide Amazon cloud users with product consultation related to DDoS defense/website front-end security defense/domain name security. Have an in-depth understanding of Cloudfront, Shield, WAF, Route53, Global Accelerator and other cloud edge security related products. Years of working experience in computer security, data centers and networking.
I heard, click the 4 buttons below
You will not encounter bugs!
