Exam AWS Certified Solutions Architect - Professional SAP-C02 topic 1 question 5 discussion

A. The only difference between A and D is CloudFront function vs Lambda@Edge. In this case the CloudFront function can remove the response header based on request header and much faster/light-weight.

I think this is answer D: Lambda@Edge can modify headers https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/lambda-examples.html

The correct answer is D. Here’s why: Requirement: The solution must: Use serverless technologies. Retain the ability to support older devices by removing problematic headers based on the User-Agent header. Analysis of the options: A. CloudFront with an ALB and a CloudFront function: CloudFront functions can modify headers, but they are limited to request handling and cannot modify response headers. This does not fully meet the requirement to remove response headers based on the User-Agent header.

Option A as per https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/edge-functions-choosing.html -- seems lambda@edge is not needed as cloudfront function can be quick for modifying the response headers and handles higher request rates

It's A. Cloudfront funtions are faster and cheaper than Lambda@Edge. The use case in the question (add headers if missing from old devices) is documented on the AWS samples https://github.com/aws-samples/amazon-cloudfront-functions/tree/main/add-origin-header

Option A or D are viable. I went with D because Lambda@Edge offers better performance since it runs closer to the end-users, reducing latency. Lambda@Edge can also handle more complex logic and is always more suitable for modifying headers based on User-Agent. While A could work, D offers a more robust and scalable solution that better aligns with the company's requirements to support older devices and leverage serverless technologies effectively.

CloudFront lets you choose whether you want CloudFront to forward headers to your origin and to cache separate versions of a specified object based on the header values in viewer requests. This allows you to serve different versions of your content based on the device the user is using, the location of the viewer, the language the viewer is using, and a variety of other criteria.

Removing User-Agent headers is generally a lightweight task. Since it involves simple string manipulation to detect and remove headers based on predefined conditions, CloudFront Functions (Option A) are perfectly suited for this purpose. They provide fast, low-latency execution, making them ideal for straightforward operations like header manipulation.

It says a serverless solution. ALBs are not serverless.

Lambda@Edge is integrated with CloudFront and allows you to manipulate requests and responses closer to the user, such as removing unsupported headers. This is ideal for addressing the issue with older devices by inspecting the User-Agent header and removing the problematic HTTP headers.

A, because it's faster. CloudFront Functions vs. Lambda@Edge use cases * CF Functions: * cache key normalization: transform request attributes (headers, cookies, query string, URL) to create an optimal Cache Key * header manipulation: insert/modify/delete HTTP headers in the request or response * URL rewrites or redirects * request authentication & authorization: create and validate user-generated tokens (e. g. JWT) to allow/deny requests * Lambda@Edge: * longer execution time (several ms) * adjustable CPU or memory * 3rd party dependencies (like AWS SDK) * network access to use external services for processing * file system access or access to the body of HTTP requests

Lambda@Edge lets you run Lambda functions to customize the content that CloudFront delivers, executing the functions in AWS locations closer to the viewer. The functions run in response to CloudFront events, without provisioning or managing servers. You can use Lambda functions to change CloudFront requests and responses at the following points: - After CloudFront receives a request from a viewer (viewer request) - Before CloudFront forwards the request to the origin (origin request) - After CloudFront receives the response from the origin (origin response) - Before CloudFront forwards the response to the viewer (viewer response)

D: This solution involves creating an Amazon CloudFront distribution for the metadata service and configuring it to forward requests to the Application Load Balancer (ALB), which is used to invoke the correct Lambda function for each type of request. A Lambda@Edge function should be created that will remove the problematic headers in response to viewer requests based on the value of the User-Agent header. This approach allows the company to remove the problematic headers while supporting older devices and using serverless technologies.

D is correct This solution uses Amazon CloudFront with an Application Load Balancer (ALB) and AWS Lambda@Edge to remove problematic headers based on the User-Agent header. CloudFront can be used as a content delivery network (CDN) to deliver the metadata service to consumer devices while the ALB is used to invoke the correct Lambda function for each type of request. Lambda@Edge is used to modify the response headers in real-time based on the User-Agent header. This solution addresses the requirement to support older devices that do not support certain HTTP headers by removing problematic headers based on the value of the User-Agent header. It also leverages serverless technologies such as AWS Lambda and Lambda@Edge for scalability and cost-effectiveness.

In this solution, you use CloudFront, ALB, Lambda@Edge, and Lambda functions to achieve the desired outcome. Create an Amazon CloudFront distribution: CloudFront acts as a content delivery network (CDN) and allows you to distribute your metadata service globally. You can configure it to handle incoming requests and route them to the appropriate backend. Create an Application Load Balancer (ALB): ALB is used as a target for CloudFront to forward requests. It provides advanced routing capabilities and can invoke the correct Lambda function based on the type of request. Create a Lambda@Edge function: Lambda@Edge allows you to run Lambda functions at the CloudFront edge locations, closer to your users. Create a Lambda@Edge function that examines the User-Agent header of incoming requests and removes the problematic headers from the response when necessary. This ensures compatibility with older devices.

I think thre are two problems in this situation: 1- "Many older devices do not support certain HTTP headers and exhibit errors when these headers are present in responses." 2- "The company has already migrated the applications into a set of AWS Lambda functions" Those two problems are addressed by using an API Gateway which 'selects the appropriate function for each type of request' and a mapping template which 'removes the unsupported headers'.

This is really challenging for me. Here is my reasoning: i) user-agent header is stored in request and not in answer ii) based on i) we need a mechanism to map sessionid to user-agent in requests and access this mapping when processing answers Not .A as CF Functions do not interact with other AWS services, they can use key value pairs but in read-only mode. https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/functions-tutorial-kvs.html Not B. as gateway responses only works with "supported response type" listed here https://docs.aws.amazon.com/apigateway/latest/developerguide/supported-gateway-response-types.html (plese note the question mention errors, but they occur on devices) Not C. as response mapping template do not interact with other AWS services D. is correct as Lambda@Edge can access other AWS services (e.g. in this case a DynamoDB for sessionid user-agent mapping)