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

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.