When configuring multiple origins in CloudFront, a common pain point emerges: the service forwards the entire request path to the origin server by default. This becomes problematic when you need to:

• Serve content from different origins under specific path prefixes
• Maintain clean URL structures without exposing internal routing
• Prevent 404s from origin servers that don't expect the full path

Consider this common architecture:

CloudFront Distribution
├── Origin 1: example-bucket.s3.amazonaws.com (/*)
└── Origin 2: api.seconddomain.com (/subfolder*)

Without path modification, requesting example.com/subfolder/resource would hit api.seconddomain.com/subfolder/resource, when you actually want it to hit api.seconddomain.com/resource.

Here's how to configure it properly:

1. Navigate to your CloudFront distribution in AWS Console
2. Select the "Origins" tab
3. Edit your secondary origin (Origin 2 in our case)
4. Set the "Origin Path" field to /subfolder
5. Update your behavior to use path pattern /subfolder/*

For more complex scenarios, you might need Lambda@Edge:

exports.handler = (event) => {
  const request = event.Records[0].cf.request;
  
  // Strip /subfolder prefix
  if (request.uri.startsWith('/subfolder/')) {
    request.uri = request.uri.replace(/^\/subfolder/, '');
  }
  
  return request;
};

• Caching Implications: Different path modifications create separate cache entries
• SSL Certificates: Ensure your alternate domain has valid SSL
• Header Forwarding: Configure "Cache Based on Selected Request Headers" as needed

If it's not working:

1. Check CloudFront logs for x-forwarded-host values
2. Verify the origin responds to the modified path
3. Clear CloudFront cache between configuration changes

When setting up multiple origins in Amazon CloudFront, you might encounter a situation where the path prefix gets unintentionally forwarded to your secondary origin. For example:

Current behavior:
example.com/subfolder → second.com/subfolder

Desired behavior:
example.com/subfolder → second.com/

The root cause lies in how CloudFront processes path patterns. When you create a behavior for /subfolder*, CloudFront forwards the entire path including the prefix to your origin.

The correct approach is to use the Origin Path field in your origin configuration:

1. Go to your CloudFront distribution
2. Select the origin configuration for second.com
3. Set "Origin Path" to "/subfolder"
4. In the behavior configuration, keep the path pattern as "/subfolder*"

This tells CloudFront to:

• Match requests for /subfolder*
• Strip the /subfolder prefix when forwarding to second.com
• Append the remaining path components

Here's how to implement this in infrastructure-as-code:

resource "aws_cloudfront_distribution" "example" {
  origin {
    domain_name = "second.com"
    origin_id   = "secondary-origin"
    origin_path = "/subfolder"
    # other origin config...
  }

  ordered_cache_behavior {
    path_pattern = "/subfolder*"
    target_origin_id = "secondary-origin"
    # other behavior config...
  }
}

After deploying changes, verify with curl:

curl -v http://example.com/subfolder/style.css

Should request from second.com/style.css, not second.com/subfolder/style.css

Remember these key points:

• Origin Path requires leading slash but not trailing slash
• The behavior pattern must still match the full path including prefix
• Cache invalidation may be needed after configuration changes