How to serve an AWS EC2 instance from S3 subdirectory

问题

I have a website hosted on AWS S3, served over Cloudfront. www.mysite.com

I am hosting a blog on an EC2 instance.

I would like to have this blog served from www.mysite.com/blog

For SEO purposes I do not want it to be www.blog.mysite.com

Is it possible to achieve this with only S3 and Couldfront?

I have played around with S3 redirects and Lambda@edge but the documentation on these is not great. In the case of Lambda@edge I want to avoid further complexity if I can. S3 redirects work but the user is no longer under the mysite domain.

S3 Redirect example

<RoutingRules>
  <RoutingRule>
    <Condition>
      <KeyPrefixEquals>blog/</KeyPrefixEquals>
    </Condition>
    <Redirect>
      <HostName>${EC2_Public_DNS}</HostName>
    </Redirect>
  </RoutingRule>
</RoutingRules>

Other articles I have read involve using apache or nginx servers handling the redirect. I would rather not have to add one of these.

回答1:

Since a redirect is an instruction for the browser, telling it to look elsewhere for the requested resource, CloudFront isn't designed to follow redirects itself -- it returns the redirect to the browser.

What you want, instead, is a new CloudFront Cache Behavior, and a new CloudFront Origin server declaration, configured in the existing CloudFront distribution that's handling your site.

In CloudFront, add a new Origin, setting the Origin Domain Name to the hostname pointing to the EC2 instance (or to the load balancer in front of the instance, if there is one). You'll notice a field called "Origin Path" which you might be tempted to set to "/blog/" or something similar, but that is incorrect. Leave "origin Path" blank.

Then add a new Cache Behavior matching the Path Pattern /blog/* and pointing it to the new origin.

That, in a nutshell, is what you are looking for, but there are several other factors that will require appropriate settings and configuration.

You'll need a TLS certificate on your origin server, unless you set the Origin Protocol Policy to HTTP Only, in which case you're running unencrypted traffic between CloudFront and EC2. CloudFront has specific requirements for correctly configuring TLS on your origin server and most misconfigurations related to TLS will result in a 502 Bad Gateway error though of course there can be other causes for that error code.

Your blog software might require query string parameters and/or cookies, which CloudFront, by default, strips from all requests (because they interfere with caching). These are two of the Cache Behavior settings that commonly require customization, since the defaults are based on appropriate settings for typical static content.

You will also need to configure your blog software to expect the incoming requests to include the path prefix "/blog/" because CloudFront does not remove path components. The only way to present the path to the origin server with one or more elements stripped from it is to use Lambda@Edge to rewrite the path -- as I explained here.

If you are now mentally protesting the path being set to "/blog/" instead of "/blog", the problem to keep in mind is that this path needs correct anchoring -- HTTP semantics assume directory levels end with "/" while files and other resources don't, so you're likely to encounter difficulties if you try to put the blog at a path that doesn't end with /... but for the benefit of users who shouldn't be expected to type the trailing /, you still do need to configure a redirect in S3 -- but only in order to send requests for /blog right back to /blog/.

<RoutingRules>
  <RoutingRule>
    <Condition>
      <KeyEquals>blog</KeyEquals>
    </Condition>
    <Redirect>
      <ReplaceKeyWith>blog/</ReplaceKeyWith>
      <HostName>${main_site_hostname}</HostName>
      <Protocol>https</Protocol>
    </Redirect>
  </RoutingRule>
</RoutingRules>

When testing, you may also want to set your Error Caching Minimum TTL to 0 so that you don't fix a problem and keep seeing cached errors returned for the next 5 minutes, even though the error has been resolved by a change you made. CloudFront does this to help avoid overloading an origin server that might already be experiencing problems (as evidenced by the fact that it's returning errors), but it catches some users off guard.

来源：https://stackoverflow.com/questions/60474201/how-to-serve-an-aws-ec2-instance-from-s3-subdirectory