Home / server / Questions / 729697
Accepted
Sam McAfee
Asked: 2015-10-18 11:19:23 +0800 CST

Can I use CloudFront to serve a WordPress blog from the same domain, but a different server?

  • 772

We have a website that we serve from Elastic Beanstalk (AWS), and it all works great. We use the built-in load balancer to serve our site over HTTPS, etc. Our database is separated through the RDS service, not on the same EC2 instances as our web servers. We are happy with the set up so far.

Now, we would like to set up a WordPress blog under '/blog' on our site's domain (not a separate or subdomain, for SEO reasons). Our site is a custom-built PHP application (using the Laravel framework) and I would rather not host both the WP application and our site from the same place.

I believe that we can use CloudFront (Amazon's CDN) to serve just the /blog part of our site, and route those requests to a separate WP install on different EC2 instances. I have used CloudFront to do regular CDN kind of stuff (static assets) but I am kind of lost as to how to set up this particular kind of configuration.

First, is this a crazy idea, or does it sound OK? Second, if it's reasonable, what are the things I need to know to set this up?

wordpress

1 Answers

  1. Best Answer

    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.

    • 7