I first saw Lambda@Edge at re:Invent a couple of years back and wasn’t sure what to make of it. The demo showed how you could manipulate http headers in-flight but the audience was in a post-lunch sugar-crash full of ‘so what?’. It wasn’t the presenter’s fault —some next-level concepts just weren’t landing their punches with the crowd. I mean, who needs to interfere with the CDN, right?
Recently we started a CloudFront-heavy project that performs all sorts of optimization voodoo for webpages. That’s when I remembered back to the Lambda@Edge presentation and a few lightbulbs started to flicker. To test this, we quickly moved some code into functions at The Edge and saw some blistering performance gains. While there was nothing particularly amazing about the code we wrote, getting it working has been a trial like never before. Let’s cover the gotchas before the gold.
Personalizing content helps to drive subscriptions, improve revenue, and increase retention rates by providing a more engaging and responsive customer experience. In this blog post, we’ll show you how to build a serverless subscription service for your website that personalizes and monetizes content by using Amazon CloudFront and AWS Lambda@Edge.
Customers have typically used content delivery networks (CDNs) to reduce latency for global applications by serving content closer to their users. Since we announced Lambda@Edge in December 2016, customers have also started using Lambda functions to shift compute-heavy processing to the edge. By using Lambda@Edge, developers can build and continuously deliver features in edge locations, closer to their users and web consumers. Using CloudFront and Lambda@Edge together helps you to build and provide highly-performant online experiences. Using serverless applications at the edge also helps you avoid managing an extra tier of infrastructure at the origin.
If you’re just learning about Lambda@Edge, we recommend checking out the Get Started section in the documentation first, before you read this article, to get a general understanding about how Lambda@Edge works.
In our example application for personalizing content, users must register first, so that we can show them content that is most relevant to them. We use Lambda@Edge to validate registered users by authenticating them. For simplicity, we haven’t included a customer registration page but it’s straightforward to include one in your web flow. If someone is visiting your site for the first time, you can redirect them to a registration page, and then attach an entitlement to the profile to permit them to perform actions based on the level of their subscription.
There are a number of reasons to use Lambda@Edge when you build a subscription service. For example, you and your customers can gain the following benefits:
- Lambda@Edge is a serverless computing platform, which has several advantages. There’s no infrastructure to manage when you use it. It’s an event-driven system, so you only pay for the service when an event is triggered. It scales automatically based on the demand. And, finally, it’s highly available.
- A Lambda@Edge function runs closer to the viewer, so users have a better experience with faster response times.
- The load on your origin is reduced because you can offload some CPU-intensive applications and processes from your web and app servers. Caching at the edge further reduces the load on your origin.
- You can control your user journey in a more fine-grained manner, so you can, for example, implement micropayments, micro-subscriptions, bots management, and metering content. These features help your website to interact in innovative ways with customers and frequent viewers.
- The AWS ecosystem includes more than 100 managed services that you can integrate with. For example, you can build analytics based on the logs generated on Lambda@Edge, CloudFront, and CloudWatch.
- You can promote advertisements on your articles that align with your brand and opinion by using Lambda@Edge to provide relevant tags to advertising platforms at the Edge, allowing you to further drive revenue based on the viewer’s subscription level.
When you build web applications or expose any data externally, you probably look for a platform where you can build highly scalable, secure, and robust REST APIs. As APIs are publicly exposed, there are a number of best practices for providing a secure mechanism to consumers using your API.
Amazon API Gateway handles all the tasks involved in accepting and processing up to hundreds of thousands of concurrent API calls, including traffic management, authorization and access control, monitoring, and API version management.
In this post, I show you how to take advantage of the regional API endpoint feature in API Gateway, so that you can create your own Amazon CloudFront distribution and secure your API using AWS WAF.
AWS WAF is a web application firewall that helps protect your web applications from common web exploits that could affect application availability, compromise security, or consume excessive resources.
As you make your APIs publicly available, you are exposed to attackers trying to exploit your services in several ways. The AWS security team published a whitepaper solution using AWS WAF, How to Mitigate OWASP’s Top 10 Web Application Vulnerabilities.