AWS Amazon Cloud Partners: Revealing AWS CloudFront Advanced Play: Using Edge @ Lambda to Achieve Customized Direction at Edge Nodes

Friends who have played cross-border e-commerce, overseas independent stations or large-flow overseas App, right

Amazon CloudFront (global CDN for AWS)

Certainly no stranger. At ordinary times, people use it as a large "static cache shield" to cache pictures, accelerate videos and block malicious DDoS attacks.

But if your understanding of CloudFront only stays in "static cache", it is really a waste of time.

Today, let's talk about advanced hardcore gameplay:

Lambda@Edge

. Simply put, it allows you to "launch" your custom code (Node.js or Python) directly to hundreds of CDN edge nodes on AWS worldwide. Before the request arrives at your origin server, the code has been executed and customized diversion, redirection or content modification has been completed on the CDN node closest to the user.

This can not only help your origin server share 90% of the business logic pressure, but also reduce the response delay of global users to the extreme. Let's not talk nonsense, just open the whole.

Phase 1: Understanding the 4 Triggers of Lambda @ Edge

To play tricks at the edge node, you must first remember to CloudFront the complete request chain. A request from the user's mobile phone to get the data, the total will pass.

4 levels

. You can insert your Lambda code exactly at any level:

Viewer Request: The user just sent a request to the CDN node. At this time, CDN has not checked whether it has cache or not. Code insertion is most suitable here: A/B test diversion, ban specific malicious IP, and redirect old URL.

Origin Request (origin request):CDN node checked and found that there was no cache, so it was ready to go to your origin server to get data. The code inserted here is suitable for: dynamically modify the back-to-source path and forward the request to different source stations according to the user equipment (mobile phone/computer).

Origin Response (origin site response): The origin site server has spit the data to the CDN node and is ready to store it in the cache. The code inserted here is suitable for doing: cleaning or appending specific HTTP response headers, security policy injection.

Viewer Response: The CDN node is ready to send the data back to the user's browser. Code insertion is suitable for doing here: dynamic injection of personalized, fragmented data that is not suitable for caching.

Phase II: Practical Exercise-Using Edge Scripts to Realize Intelligent A/B Test Diversion

Talk is cheap. Let's directly restore an enterprise-level advanced scenario: the company's front-end has released new functions and needs to be done.

A/B testing

. We want users around the world to visit

[ht

tps://yourcompan

y.com/index.html]

ht

tps://yourcompany.com/index.html)

When:

50% of users stay on old pages.

50% of users are quietly drained to the new page index_v2.html.

Hard requirement: the URL of the user's browser address bar cannot be changed in the whole process, and the source server cannot be involved in the judgment. it is all done at the CDN edge.

This requirement is most suitable for welding Lambda in

Viewer Request (Audience Request)

Level.

The first step: in

us-east-1

region to write a Lambda function

Ironlaw Warning: No matter where your business is located in the world, Lambda @ Edge must be created in the "Northern Virginia (us-east-1)" region, otherwise it cannot be deployed to global CDN nodes.

Log in to the AWS console, switch to us-east-1, and create a new Lambda function.

Select Node.js as the running language (edge functions require high execution speed, and Node.js is the first choice).

In terms of permissions, the edgelambda.amazonaws.com service principal must be allowed to call this function in the execution role.

Write the following core magic logic code:

Click Deploy to save.

The third stage: "launch" the code to the global edge node

After the code is written, how can it go to CDN nodes around the world to stand guard?

In the upper-right corner of the Lambda function page, click Actions-> Deploy to Lambda @ Edge ".

Configure deployment parameters: Distribution: Select your existing CloudFront instance ID. Cache Behavior: Select a specific cache behavior (such as default * or for/index.html). CloudFront Event: Select the Viewer Request without hesitation.

Check the confirmation pop-up window and click Deploy.

At this time, AWS will start an automated distribution program in the cloud, and copy and synchronize your dozens of lines of Node.js code to hundreds of CDN edge nodes around the world in a few minutes.

The fourth stage: test verification and the history of avoiding pits and tears in marginal play

After the deployment is complete, you use the world's network to crazy refresh your website. You will find that the address bar is always displayed

index.html

, but the screen switches randomly between the old version and the new version. The log of the source server is clean. It doesn't even know that an A/B test has taken place. All the pressure is resolved by the CDN node at the front end.

But when you're excited about getting ready to put Lambda @ Edge on all your businesses

Before that, we must first understand these cruel restrictions brought about by "edge execution", otherwise we will accidentally crash the entire CDN:

1. Strict "body" and time limit

In order to pursue the ultimate response speed, the edge node is very stingy with the resources left to the code:

If you add code in the Viewer Request / Response phase, your code package size cannot exceed 1MB, the execution timeout cannot exceed 5 seconds, and the usable memory is only 128MB.

Don't expect to write a complex deep learning model at the edge node or connect to a traditional remote high-latency database. The principle of edge code is: as short as it can be, as fast as it can be.

2. Eliminate direct connection to the production database (will drag the network speed)

If your Lambda @ Edge has to connect to a physical MySQL database in Beijing or Oregon to check user data across the country every time a user requests, the acceleration advantage brought by CDN will be completely wiped out by the high network cross-border delay.

The right thing to do: If you must read and write data, use Amazon DynamoDB Global Tables, a globally distributed NoSQL database, or take advantage of a faster CloudFront KeyValueStore (KVS) with limited functionality.

3. Watch your wallet

Lambda @ Edge is calculated by "requests" and "execution time (milliseconds). If your website has hundreds of millions of PV traffic every day, and each traffic has to trigger a complex Viewer Request script, then the Lambda bill at the end of the month may make you painful.

Save money trick: if you just do a simple HTTP redirect, rewrite the path according to the country code, or add a security response header (such as HSTS anti-hijacking), give priority to using CloudFront Functions. It is a low-profile and lightweight version of Lambda @ Edge, with an execution speed of sub-millisecond, a cost only a fraction of Lambda @ Edge, and does not need to be deployed around us-east-1.

Summary

To unveil the advanced gameplay, the essence of Lambda @ Edge is to put"

Computing capacity front

”. By stripping logic such as A/B testing, anti-theft chain checking and signing, and mobile adaptive redirection from the centralized server and placing it on the edge node of global distribution, you not only gain an indestructible and infinitely flexible front-end defense line, but also exchange the lowest architecture cost for a smooth and smooth experience for global users.