Redirects and rewrites

The terms “redirect” and “rewrite” refer to different ways of handling HTTP requests, and they serve distinct purposes in web development.

CloudFront Lambda@Edge

For patterns that use CloudFront distributions (such as CDK-SPA), redirects and rewrites are implemented using AWS Lambda@Edge functions that execute at CloudFront edge locations. This provides low-latency routing decisions across a global network of edge servers, allowing you to:

• Process requests without additional server round-trips
• Implement intelligent routing based on request properties
• Serve dynamic content patterns with minimal latency
• Scale globally without infrastructure management

This feature is available for static site hosting patterns that leverage CloudFront. Other hosting patterns may have different routing capabilities.

Redirect

A redirect is an HTTP response that instructs the client’s browser to make a new request to a different URL. When implemented through Lambda@Edge at CloudFront, redirects happen at edge locations without requiring requests to reach your origin server.

HTTP Status Codes: Commonly uses status codes like 301 (Moved Permanently) or 302 (Found/Temporary Redirect). See HTTP Status Codes in the CloudFront documentation for more details.

Client-Side Action: The browser updates the URL in the address bar to the new location specified in the Location header of the response.

Use Cases:

• Moving content to a new URL to avoid a broken link when the address of a page changes.
• To avoid a broken link when a user makes a predictable typo in an address.

SEO Impact: A 301 redirect passes most of the SEO value from the old URL to the new one, while a 302 redirect does not.

Rewrite

A rewrite (also called a 200 Redirect) modifies the URL path internally on the server without changing the URL in the client’s browser. When implemented through Lambda@Edge at CloudFront, rewrites are processed at edge locations, allowing CloudFront to serve the rewritten content without client awareness or additional requests.

No HTTP Status Code: Since the rewrite is internal, it doesn’t involve sending a new HTTP status code to the client.

Server-Side Action: The server processes the request as if it was made to the rewritten URL.

Use Cases:

• Serving a single-page application (SPA) by rewriting all paths to index.html.
• Handling legacy URLs without changing the visible URL structure.

SEO Impact: Since the URL in the browser doesn’t change, rewrites don’t directly impact SEO.

Pattern

Configure redirects and rewrites for CloudFront-based deployments using pattern matching. Patterns support static paths, wildcards, and placeholders to handle various URL transformation scenarios.

Using static paths:

Source	Destination
/home	/

Using wildcards:

Source	Destination	Example Effect
/guide/*	/blog/*	/guide/path1 → /blog/path1
/cms/*	/*	/cms/path1 → /path1

Using placeholders:

Source	Destination	Example Effect
/docs/:any	/:any	/docs/introduction → /introduction
/blog/posts/:postid	/blog/:postid	/blog/posts/123 → /blog/123
/updates/:year/:month	/changelog/:year/:month	/updates/2023/10 → /changelog/2023/10