4

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?

Improve this question

1 Answer 1

Reset to default
7

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.

Improve this answer
7
  • This is great, and I have come pretty far following your instructions. One thing I am stuck on is HTTPS. No matter what I do, I seem to keep getting "CloudFront wasn't able to connect to the origin". If I browse the EB domain directly, it's fine. If I browse the ELB domain directly, it's fine. But I can't seem to get the CF domain to load over SSL. I have the default origin set to the ELB for my site, and the Match Viewer setting for 80/443. I have the behavior defined for Viewer Protocol Policy set as "HTTP and HTTPS". I am using the default CF cert, btw.
    – Sam McAfee
    Oct 21, 2015 at 19:45
  • Answering my own question, perhaps, I think it's because the Origin has to have the domain in it's certificate that you're calling from, and I have not pushed this to the live domain yet. So, the fetch by CF fails to connect to the Origin properly. Yes?
    – Sam McAfee
    Oct 21, 2015 at 22:37
  • 1
    The origin server needs an SSL certificate to use HTTPS on the back side, and to that extent, my advice to "use the main site's ELB or EB hostname as the origin" may be the wrong thing to do. The cert on the origin almost certainly needs to match the configured origin server hostname.
    – Michael - sqlbot
    Oct 21, 2015 at 23:02
  • A follow up question: If CF is using our SSL certificate for HTTPS, do we need to have our Elastic Beanstalk load balancers also managing SSL, or can we make them just handle port 80? Is that still secure? If we don't have to make the load balancers support 443, it would solve some other deployment automation challenges we have.
    – Sam McAfee
    Feb 22, 2016 at 20:28
  • 1
    Not true with ACM certificates. Create a cert in ACM, and you can use it with both ELB and CloudFront... and if you need http to https redirects, you can configure CloudFront to do it.
    – Michael - sqlbot
    Feb 23, 2016 at 16:11

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .