A company uses CloudFront for a global web application. Over time performance has degraded and the CloudFront cache hit ratio has steadily declined. Metrics show that some URLs include query strings whose parameters are inconsistently ordered and sometimes use mixed-case letters versus lowercase, reducing cache hits. What actions should a solutions architect take to increase cache hit ratio as quickly as possible?

The correct solution is to deploy a Lambda@Edge function that sorts query-string parameters by name and converts them to lowercase, attaching it to the CloudFront viewer request event. This approach normalizes the incoming requests before CloudFront processes them for caching, ensuring that identical requests with different parameter order or casing are treated as the same, thereby increasing the cache hit ratio. This is a quick and effective way to address the issue without modifying the origin application. Disabling caching based on query string parameters would likely decrease performance further, as many dynamic requests would bypass the cache entirely. Deploying a reverse proxy after the load balancer is a more complex and time-consuming solution, requiring infrastructure changes and potentially introducing new points of failure, and it doesn't address the issue at the CloudFront edge. CloudFront does not natively support case-insensitive query string processing or query string parameter sorting within its distribution settings.