基于AWS无服务器栈实现URL重定向并保留原始域名的需求

First, let’s clarify: what you need isn’t a traditional redirect (which changes the address bar), but a reverse proxy setup. This way, users visit example.com or example1.com, their address bar stays on that domain, and all content is served from your mysite.com serverless backend. Here’s how to implement this with AWS Lambda, API Gateway, and S3:

Step 1: Point Custom Domains to API Gateway via Route 53 #

• For each custom domain (example.com, example1.com), use Route 53 (or your domain registrar’s DNS) to create an Alias A/AAAA record pointing to an API Gateway endpoint.
• If you don’t have an API Gateway yet, we’ll set that up next—you can come back to this step once your proxy API is live.
• Ensure you have a valid SSL certificate for each custom domain (or a multi-domain/wildcard cert) in AWS Certificate Manager (ACM) for the region where your API Gateway is hosted.

Step 2: Configure API Gateway as a Reverse Proxy #

Your API Gateway will act as the middleman, forwarding all requests from custom domains to your mysite.com backend while preserving the original domain in the address bar:

1. Create a Proxy API:
   • In API Gateway, create a new API, then add a proxy resource (use /{proxy+} as the path) to catch all incoming requests.
2. Set Up HTTP Proxy Integration:
   • For the proxy resource, set the integration type to HTTP Proxy.
   • Enter the endpoint URL of your mysite.com backend:
     • For dynamic Lambda-powered content: Use your existing mysite.com API Gateway endpoint (e.g., https://abc123.execute-api.us-east-1.amazonaws.com/prod/{proxy+})
     • For static S3 content: Use your S3 bucket’s website endpoint (e.g., https://mysite-bucket.s3-website-us-east-1.amazonaws.com/{proxy+})
3. Configure Headers:
   • Enable passthrough of all request headers (including Host, Cookie, and Authorization) so your backend receives the original user context.
   • Ensure response headers from your backend (like Content-Type, Cache-Control) are passed back to the client.
4. Attach Custom Domains:
   • In API Gateway’s "Custom Domain Names" section, add each of your custom domains. Associate the corresponding ACM certificate, then map the domain to your proxy API’s stage.

Step 3: Update Lambda Functions to Use Dynamic Domains #

If your mysite.com uses Lambda for dynamic content, avoid hardcoding mysite.com in responses. Instead, pull the original domain from the request headers:

// Example Node.js Lambda handler
exports.handler = async (event) => {
  const originalDomain = event.headers.Host; // Will be example.com or example1.com
  return {
    statusCode: 200,
    headers: { 'Content-Type': 'text/html' },
    body: `<h1>Welcome to ${originalDomain}</h1>
           <p>This content comes from mysite.com's backend!</p>`,
  };
};

This ensures any generated links or redirects use the user’s original domain, keeping the address bar consistent.

Step 4: Adjust S3 CORS and Proxy Settings #

For static content stored in S3:

• Update your bucket’s CORS policy to allow requests from your custom domains:

  <CORSConfiguration>
    <CORSRule>
      <AllowedOrigin>https://example.com</AllowedOrigin>
      <AllowedOrigin>https://example1.com</AllowedOrigin>
      <AllowedMethod>GET</AllowedMethod>
      <AllowedHeader>*</AllowedHeader>
    </CORSRule>
  </CORSConfiguration>
  

• If serving S3 content via API Gateway proxy, verify the integration correctly forwards request paths and returns proper content headers (API Gateway sometimes needs explicit mapping for S3 objects).

Step 5: Test the Setup #

• Visit example.com in your browser—your address bar should stay on example.com, but content should match mysite.com.
• Test dynamic content: Confirm Lambda-generated links use the original domain.
• Check static assets: Ensure images, CSS, and JS load without CORS errors.

Key Pitfalls to Avoid #

• Hardcoded URLs: Never hardcode mysite.com in frontend code or Lambda responses. Use relative paths or dynamic domain values from request headers.
• SSL Certificates: ACM certificates must be in the same region as your API Gateway. For global coverage, consider using CloudFront (though it’s optional for serverless setups).
• API Gateway Throttling: Adjust throttling limits in API Gateway if you expect high traffic from custom domains.

内容的提问来源于stack exchange，提问作者dataguy20182019