Cloudfront - multiple origins on same distribution

Question

I'm having trouble making cloudfront work with multiple origins.

I have two origins:

ORIGIN 1

Path: Default (*)

Origin: Custom-example1.com/p

ORIGIN 2

Path: ns/

Origin: Custom-example2.com/Produtos

I can access the original and default origin, but not the second.

I have e.g an image from the second origin I want to access:

http://example2.com/Produtos/06/D12-1365-006/D12-1365-006_detalhe1.jpg

How do I access the image via the second origin?

My site is cdn.mysite.com.

Answer 1

CloudFront provides two mechanisms related to the url-path.

One is the cache behavior path pattern that defines which paths are routed to which origins.

The path pattern /foo/* will send all requests matching /foo/* to the specified origin, using the path in the original request, so GET /foo/bar on the incoming request will be sent as-is, GET /foo/bar on the outgoing request to the origin

...unless... the path is modified by the origin path, which adds a prefix to the beginning of every outgoing request to the origin.

If the origin, above, had an origin path of /baz, then the outgoing request to the origin would be GET /baz/foo/bar.

There is, then, no mechanism for removing path components -- only for adding them.

No configuration options can remove components of the path prior to forwarding the request to the origin. If GET /foo/bar should be forwarded to the origin as GET /bar... CloudFront does not currently have that capability.

CloudFront, by itself, does not have the ability to remove or otherwise rewrite the path that will be sent to the origin, but Lambda@Edge does. Lambda@Edge is a CloudFront feature that allows you to configure triggers that fire at 4 distinct points during request processing, and modify portions of the request (including the path and headers) or the response (headers), using code written in Node.js.

CloudFront creates a data structure representing the request attributes and invokes the Lambda function, passing the structure as the event argument. The Lambda function's response modifies the CloudFront behavior accordingly.

There are 4 trigger points. You can use any combination of them on each Cache Behavior.

• Viewer Request triggers are fired after the initial matching of the Cache Behavior Path Pattern matching is done, but before the cache is checked. Here, you can inspect the incoming request from the browser, modify the path, and headers, and even -- depending on the contents of the request -- generate a simple response directly from the Lambda function, which returned to the browser without further processing by CloudFront. Modifying the path here will change the path that CloudFront uses for the cache lookup, but will not result in CloudFront selecting a different Cache Behavior. After the cache is checked, a response may be returned to the viewer in case of a cache hit, or processing may continue inside CloudFront.
• Origin Request triggers fire when CloudFront does not have a cached copy of the object, before the request is sent to the origin. Path and headers can be modified here, and simple responses generated directly without sending the request to the origin if desired. This trigger will not cause the Cache Behavior selection to change, even if you rewrite the path. When path rewrites are needed, this is usually the most cost-effective trigger to use, since it only fires when the object is not already in the cache. (By contrast, the Viewer Request trigger fires for each request.)
• Origin Response triggers fire when the response returns from the origin, before the object is cached and returned to the viewer. Here, you can still inspect the original request, but it's too late to modify it. You can modify the response headers. This is particularly useful for origins that don't set the Cache-Control headers that you want. Setting Cache-Control headers, here, affects both CloudFront and browser cache behavior. This trigger does not fire on errors, only origin responses with HTTP status codes < 400.
• Viewer Response triggers fire before CloudFront returns an object to the viewer, whether it was freshly-fetched from the origin, or served from the cache. Response headers can be modified.

For the application discussed here, the solution requires a Lambda@Edge Origin Request trigger, to remove a known prefix from the request path after the cache is checked, but before the request is sent to the origin server.