Yes, you can, if you set up the entire site to run behind CloudFront. You can then configure the default back-end origin service for the site, and carve out an exception to take a different path for /blog.
Configure a new CloudFront distribution. Use the main site's ELB or EB hostname as the origin. Configure the site's domain name as an alternate domain name in CloudFront.
Next, add a second origin, with the destination being the hostname where the WP deployment can be reached. Create a behavior with a path pattern that matches /blog*
and uses the second origin.
(If /blog* matches anything else is in the root of the site... unlikely but say you had another page in the root called /blogosphere, this would incorrectly be matched, so you'd actually need to create two patterns, /blog and /blog/*).
Gotcha: Note that when creating an origin, there is a box for origin path. This probably does not do what you expect. Leave it blank if unsure.
The origin path is a prefix that you want Cloudfront to prepend to the request it sends to the origin, even though it is not visible in the URL. So, if you set this to /test and the request from the browser was for /blog, the back-end server would see the request arrive for /test/blog.
Origin path allows you to prepend to the path that is going to be requested, otherwise the incoming path is sent through as received from the browser. This means on your WP install, the root of the content needs to be at /blog
when you connect directly to the WP server, not at /
. CloudFront does not currently provide any mechanism to remove components from the path.
Remember also to enable query string and cookie forwarding to the WordPress back-end to whatever extent is necessary for WordPress to work as needed. The same is true for your main site, of course.
You may need to whitelist the Host:
header if your server expects it. Possibly others, depending on what headers the servers need to see, but as a rule, the more headers you forward, the less caching CloudFront can do, because if it forwards a header to the origin, it must assume that any subsequent request where that header varies might receive a different response from the server, so the request can't be served from cache unless all the forwarded headers match.
Ultimately, then, after configuration and testing, you'd point your hostname to the CloudFront endpoint and you'd be live.
Best Answer
If you only want
/
redirected to/blog
you can do a simpleindex.html
based redirect. Lambda@Edge is a very powerful mechanism but very much an overkill for your usecase.To use
index.html
for the redirect do this:Configure the S3 bucket for website hosting, that will also make sure that a request to
/
will serve the contents of/index.html
.Create and upload the
/index.html
file with a content like this:Now every time a request is made to
http://rootdomain.com/
the browser will receive the above HTML file and follow the refresh/redirect tohttp://rootdomain.com/blog
.Hope that helps :)