The Secret Life of AWS: Edge Compute (CloudFront Functions & Lambda@Edge)

How to execute code at the global network perimeter

#AWS #CloudFront #EdgeCompute #Serverless

---

Edge Compute

Timothy was reviewing a new compliance requirement from the security team. They mandated that every HTTP response leaving the application must include strict security headers, specifically Strict-Transport-Security (HSTS) and a Content-Security-Policy.

"I am planning to update the backend," Timothy explained to Margaret, drawing on the whiteboard. "I will modify our core API Gateway and our backend Lambda functions in Virginia to append these security headers to every single response payload."

Margaret looked at the architecture diagram and specifically pointed to the Amazon CloudFront distribution they had built the previous week.

"That will work for your dynamic API calls," Margaret said kindly. "But what about the static assets? What about the product images and the frontend JavaScript files that CloudFront is caching in Tokyo and London?"

Timothy paused. "If a user in Tokyo requests a product image, and CloudFront has a Cache Hit, the Edge Location serves the file directly. The request never reaches the backend in Virginia."

"Exactly," Margaret nodded. "Your backend Lambda functions will never execute. The security headers will be missing from all cached content. If you force CloudFront to forward every request to the backend just to attach a header, you defeat the entire purpose of the Content Delivery Network. We need to execute compute logic directly at the Edge Location."

The Execution Triggers

Margaret opened the AWS Console and navigated to the CloudFront distribution settings.

"CloudFront allows us to intercept HTTP traffic at four distinct points in the request lifecycle," she explained. "When the user sends a request, that is the Viewer Request. When CloudFront forwards a Cache Miss to your backend, that is the Origin Request. When your backend replies, that is the Origin Response. And finally, when CloudFront replies to the user, that is the Viewer Response."

"To ensure every single file gets a security header, even on a Cache Hit, we need to run a piece of code exactly at the Viewer Response trigger," Margaret said. "We have two tools for this: Lambda@Edge and CloudFront Functions."

Lambda@Edge vs. CloudFront Functions

Timothy looked at the console. "We already use AWS Lambda for our backend microservices. Can we just deploy those same functions to the Edge Locations?"

"We can use Lambda@Edge," Margaret replied. "Lambda@Edge allows you to run Node.js or Python code in AWS Regional Edge Caches. It is powerful. It has network access, meaning it can make external API calls, authenticate users against a database, or render dynamic HTML before sending it to the user. However, because it is a full virtual machine environment, it takes a few milliseconds to execute and costs slightly more."

"For simply injecting an HTTP header," Margaret continued, "we do not need network access or heavy compute. We need absolute speed. We will use CloudFront Functions."

She opened the Functions tab in the CloudFront console.

"CloudFront Functions run directly inside the physical Edge Locations, right next to the cache," she explained. "They only run JavaScript, they have no network or file system access, and they must execute in under one millisecond. Because they are so lightweight, they cost significantly less per invocation than Lambda@Edge. They run on every single request—even Cache Hits—modifying the response right after it is pulled from the cache, without invalidating the stored object itself."

Writing the Edge Logic

Margaret handed the keyboard to Timothy. He created a new CloudFront Function and wrote a few lines of JavaScript:

function handler(event) {
    var response = event.response;
    var headers = response.headers;

    headers['strict-transport-security'] = { value: 'max-age=63072000; includeSubdomains; preload'};
    headers['content-security-policy'] = { value: "default-src 'self';" };

    return response;
}

"That is the entire codebase," Timothy noted. "It simply intercepts the response object, injects the two dictionary keys, and returns the object."

"Now, we attach this function to our CloudFront distribution's Viewer Response trigger," Margaret said. "And because we configure these at the Cache Behavior level, you can associate different functions with different routes. You can use CloudFront Functions to inject headers on your static images, and later, if we need to personalize content—like dynamically rendering different products based on a user's geographic location—we can attach Lambda@Edge to the API routes. But that is an architecture for another day."

Timothy saved the function and published it to the live distribution. He opened his browser's developer tools and requested a cached product image from the Tokyo Edge Location. The image loaded in twelve milliseconds. He inspected the network response. The HSTS and Content-Security-Policy headers were perfectly appended.

"The code executed in a fraction of a millisecond in Tokyo," Timothy realized. "It never touched Virginia. We manipulated the traffic at the perimeter."

"You have mastered global delivery, global security, and now, global compute," Margaret smiled.

---

Key Concepts

Edge Compute refers to the architectural practice of running code at physical data centers located as close to the end user as possible, rather than at a centralized, distant origin server. This minimizes network latency, offloads compute pressure from backend infrastructure, and allows for real-time manipulation of HTTP requests and responses at the network perimeter. In AWS, this is handled natively within the Amazon CloudFront service by intercepting traffic at specific trigger points: Viewer Requests, Origin Requests, Origin Responses, and Viewer Responses. Functions can be assigned to specific Cache Behaviors, allowing architects to mix and match edge compute tools based on the specific route.

CloudFront Functions is a serverless edge compute feature ideal for lightweight, high-volume HTTP manipulations. These functions are written in JavaScript, run directly within CloudFront Edge Locations, and are restricted to sub-millisecond execution times. They do not have network or file system access, making them highly secure, incredibly fast, and highly cost-effective. They run on every request—including Cache Hits—without invalidating the underlying cached objects, making them the architectural standard for tasks like URL rewrites, cache key normalization, and injecting security headers.

Lambda@Edge is a more robust serverless edge compute feature that deploys Node.js or Python code to AWS Regional Edge Caches. Unlike CloudFront Functions, Lambda@Edge functions possess network access and allow for longer execution times, enabling complex operations. This service is utilized for compute-heavy edge tasks, such as making external third-party API calls, dynamically rendering web pages based on user location, or inspecting authentication tokens against a database before allowing a request to reach the origin server.

---

Aaron Rose is a software engineer and technology writer at tech-reader.blog. For explainer videos and podcasts, check out Tech-Reader YouTube channel.