[text]
This Guidance helps media publishers who are facing two conflicting requirements when it comes to serving content: deliver content quickly by using a Content Delivery Network (CDN) and protect and monetize content using a paywall. The conflict arises because CDNs operate at the network edge, while paywall logic is usually available only at the originating website. Because the CDN does not know whether to serve content from its cache, requests must go to the origin. With this Guidance, publishers can combine their CDN and paywall in a single system. Amazon CloudFront makes this possible by invoking a compute resource at the network edge using Amazon Web Services (AWS) Lambda@Edge functions. Paywall logic can be applied immediately to provide a fast user experience.
Please note: [Disclaimer]
Architecture Diagram
[text]
Step 1
Client authenticates using an Amazon Cognito user pool (or another identity provider).
Step 2
During authentication, the pre-token generation process for Cognito invokes an AWS Lambda function.
Step 3
Lambda function looks up the user’s subscription information in Amazon DynamoDB and adds it to the JSON Web Token (JWT) as a custom claim.
Step 4
Cognito returns JWT to the Client, which stores it in a cookie to authorize content requests.
Step 5
Client initiates a request for content, such as a news article, served by Amazon CloudFront. To authorize the request, the client includes the JWT in a cookie.
Step 6
CloudFront invokes a Lambda@Edge function to update the viewer request headers based on whether the user is authorized to view the content.
Step 7
Lambda@Edge validates the JWT and adds a custom header to the request indicating whether user has access to the content based on subscription’s data in the JWT.
Step 8
CloudFront creates a cache key based on the custom header added in Step 7. If content is not found in cache, it sends an origin request to Amazon API Gateway; otherwise, it skips to Step 12.
Step 9
API Gateway invokes a Lambda function to retrieve content.
Step 10
Lambda function examines the request header, added in Step 7, to determine if the user has a subscription. If the user has a subscription, it retrieves content from Amazon Simple Storage Service (Amazon S3) or DynamoDB based on an identity provided in the request URL. If the user does not have a subscription, the function returns a message that the user is not authorized to view the content.
Step 11
API Gateway returns the response generated by the Lambda function, which will either be the full content or a message saying that the user is not authorized to access the item.
Step 12
After serving content to the client, CloudFront caches it using a key that includes the custom header added in Step 7, thus enabling different versions of the content to be cached for subscribers and non-subscribers.
Step 1
Client authenticates using an Amazon Cognito user pool (or another identity provider).
Step 2
During authentication, the pre-token generation process for Cognito invokes an AWS Lambda function.
Step 3
Lambda function looks up the user’s subscription information in Amazon DynamoDB and adds it to the JSON Web Token (JWT) as a custom claim.
Step 4
Cognito returns JWT to the Client, which stores it in a cookie to authorize content requests.
Step 5
Client initiates a request for content, such as a news article, served by Amazon CloudFront. To authorize the request, the client includes the JWT in a cookie.
Step 6
CloudFront invokes a Lambda@Edge function to update the viewer request headers based on whether the user is authorized to view the content.
Step 7
Lambda@Edge validates the JWT and adds a custom header to the request indicating whether user has access to the content based on subscription’s data in the JWT.
Step 8
CloudFront creates a cache key based on the custom header added in Step 7. If content is not found in cache, it sends an origin request to Amazon API Gateway; otherwise, it skips to Step 12.
Step 9
API Gateway invokes a Lambda function to retrieve content.
Step 10
Lambda function examines the request header, added in Step 7, to determine if the user has a subscription. If the user has a subscription, it retrieves content from Amazon Simple Storage Service (Amazon S3) or DynamoDB based on an identity provided in the request URL. If the user does not have a subscription, the function returns a message that the user is not authorized to view the content.
Step 11
API Gateway returns the response generated by the Lambda function, which will either be the full content or a message saying that the user is not authorized to access the item.
Step 12
After serving content to the client, CloudFront caches it using a key that includes the custom header added in Step 7, thus enabling different versions of the content to be cached for subscribers and non-subscribers.
Well-Architected Pillars
The AWS Well-Architected Framework helps you understand the pros and cons of the decisions you make when building systems in the cloud. The six pillars of the Framework allow you to learn architectural best practices for designing and operating reliable, secure, efficient, cost-effective, and sustainable systems. Using the AWS Well-Architected Tool, available at no charge in the AWS Management Console, you can review your workloads against these best practices by answering a set of questions for each pillar.
The architecture diagram above is an example of a Solution created with Well-Architected best practices in mind. To be fully Well-Architected, you should follow as many Well-Architected best practices as possible.
-
Operational ExcellenceRead the Operational Excellence whitepaper
API Gateway, CloudFront, DynamoDB, Amazon S3, and Lambda are services purpose-built to enhance your operational excellence framework when deploying this Guidance. These services allow for publishing new versions and configurations through an automated pipeline, such as AWS CloudFormation. These services also provide Amazon CloudWatch metrics, or can be configured to send events to CloudWatch logs, which can be used to monitor individual components of the Guidance.
-
SecurityRead the Security whitepaper
Cognito and API Gateway are two services deployed in this Guidance to enhance the security of your workloads. Cognito provides an authentication framework that issues digitally signed JSON Web Tokens (JWTs ). API Gateway can be configured to require an API key. Cognito provides a secure, tamperproof mechanism for listing user subscriptions in a JWT, which can then be used to authorize requests for content. A Lambda@Edge function uses the JWT on each request and sets a request header showing that the request has been authorized. By configuring the API Gateway to require an API key, you can ensure that the authorization header was set by your own CloudFront distribution.
-
ReliabilityRead the Reliability whitepaper
Lambda, DynamoDB, Amazon S3, Cognito, API Gateway, CloudFront, and Lambda@Edge are highly available at a Regional or global level. Each AWS Region is fully isolated and consists of multiple Availability Zones, which are also isolated in the infrastructure. This helps you deploy this Guidance with high resiliency and protect your workloads from issues such as outages and failures.
-
Performance EfficiencyRead the Performance Efficiency whitepaper
CloudFront and Lambda@Edge can enhance the performance efficiency of your workloads, as they both handle requests at the network edge. This reduces network latency, helping you deliver content as quickly as possible.
-
Cost OptimizationRead the Cost Optimization whitepaper
Lambda and Lambda@Edge are serverless architectures that run and scale on demand, helping to ensure that your workloads are able to continually match the demand with only the minimum resources required. By using these services, you do not pay for compute instances that are not being used.
-
SustainabilityRead the Sustainability whitepaper
Lambda, API Gateway, Cognito, and DynamoDB are serverless architectures, which means these services minimize resource consumption, scale on demand, and include patterns for maintaining consistent high utilization of deployed resources. This helps to ensure you meet the needs of your present workloads without compromising the ability of future generations to meet theirs.
Implementation Resources
A detailed guide is provided to experiment and use within your AWS account. Each stage of building the Guidance, including deployment, usage, and cleanup, is examined to prepare it for deployment.
Disclaimer
The sample code; software libraries; command line tools; proofs of concept; templates; or other related technology (including any of the foregoing that are provided by our personnel) is provided to you as AWS Content under the AWS Customer Agreement, or the relevant written agreement between you and AWS (whichever applies). You should not use this AWS Content in your production accounts, or on production or other critical data. You are responsible for testing, securing, and optimizing the AWS Content, such as sample code, as appropriate for production grade use based on your specific quality control practices and standards. Deploying AWS Content may incur AWS charges for creating or using AWS chargeable resources, such as running Amazon EC2 instances or using Amazon S3 storage.
References to third-party services or organizations in this Guidance do not imply an endorsement, sponsorship, or affiliation between Amazon or AWS and the third party. Guidance from AWS is a technical starting point, and you can customize your integration with third-party services when you deploy the architecture.