SAP-C02 Practice Question 27: Edge Function Cost and Latency
AWS Certified Solutions Architect – Professional (SAP-C02) · Test 3 · question 7 of 10
A news publisher serves 2.5 million requests per second at peak through Amazon CloudFront. A Lambda@Edge function on the viewer request event does two things: it rewrites legacy article paths to the current URL scheme, and it strips a dozen marketing query-string parameters so that requests for the same article share one cache entry.
Two problems have appeared. Costs for the edge function now rival the CloudFront delivery bill, and during traffic spikes the function is throttled and viewers receive errors. The rewrite and the query-string normalization must both still happen before CloudFront computes the cache key, the logic is about 40 lines of string manipulation with no calls to other services and no need to read the request body, and the team wants the change to reduce both per-request cost and added latency.
What should the solutions architect do?
Show answer and explanation
Answer:
CloudFront Functions is purpose-built for this workload. AWS lists cache key normalization and URL rewrites as its headline use cases, it runs at viewer request and viewer response, its function duration is submillisecond, and it scales to millions of requests per second, against Lambda@Edge's limit of 10,000 requests per second per Region, which is what is throttling the publisher today. The constraints in the stem match the restrictions of CloudFront Functions exactly: pure string manipulation, no network access, and no access to the request body. It is also dramatically cheaper per invocation than Lambda@Edge, which addresses the cost problem directly.
Option B would cut invocations, but it breaks the requirement. The origin request event fires only after CloudFront has already computed the cache key and missed, so normalizing the query string there cannot consolidate cache entries, and the path rewrite would no longer influence what is cached.
Option C moves the logic behind the cache entirely. CloudFront would keep a separate cache entry per marketing parameter, so the cache hit ratio collapses and every variant reaches the origin, the opposite of the goal.
Option D treats a scaling ceiling as a tuning problem. More memory does not raise Lambda@Edge's per-Region request rate, and keeping a Lambda@Edge invocation on every one of 2.5 million requests per second leaves the cost problem exactly where it is.
Reference: Differences between CloudFront Functions and Lambda@Edge