Point one Amazon EC2 folder to another instance

Question

I don’t know if this is the right place to ask this. But I have a web app running on an Amazon EC2 instance on AWS. We want to launch a WordPress blog that will be placed at www.myapp.com/blog.

I don’t want them to be in the same Amazon EC2 instance, so I’ve created another instance and set up my WordPress environment. It's up an running.

What I need to do now, is to point this folder /blog to this instance. I suppose we have to do that using Amazon Route 53? I even tried to do that, but apparently I could create a CNAME to blog.myapp.com and not a folder /blog. And we really want it to be at www.myapp.com/blog. Should I use something like .htaccess?

Answer 1

What I need to do now, is to point this folder /blog to this instance. I suppose we have to do that using Amazon Route 53? I even tried to do that, but apparently I could create a CNAME to blog.myapp.com and not a folder /blog. And we really want it to be at www.myapp.com/blog. Should I use something like .htaccess?

Short answer.

In short, what you are describing—as you are describing it—can’t work. While blog/ is a directory/folder/path on the main www.myapp.com Amazon EC2 instance, you are mixing up the concept of servers and web URL paths; aka: directories, folders and paths.

If you are spinning up a new Amazon EC2 instance, you are setting up a whole new server. And two servers with the same base hostname of www.myapp.com but only one has the valid path of /blog just can’t happen.

Your best bet if you want to split this site across servers is to setup the new Amazon EC2 instance with the subdomain of blog.myapp.com and just redirect all traffic from the first instance on www.myapp.com/blog to that new subdomain/host.

More details below.

Longer answer.

So you have two Amazon EC2 instances:

• EC2 Instance 1: Is hosting www.myapp.com.
• EC2 Instance 2: You want to host www.myapp.com/blog.

First, this has 100% nothing to do with Amazon Route 53 which is Amazon’s DNS service. All Amazon Route 53 does is manage the DNS entries for things like hostnames and destination IP addresses. An easy way to understand this is anything to the left of the first path (/) in a URL is a hostname. So in your example:

www.myapp.com/blog

The hostname in question is www.myapp.com.

So attempting to “redirect” www.myapp.com/blog from EC2 Instance 1 to EC2 Instance 2 via a CNAME would never happen. It’s technically not possible and here’s why:

• First, the DNS entry could never be set for path data to the right of the / in the URL.
• Second, you would basically be stating you want EC2 Instance 1 and EC2 Instance 2 to have the same exact hostname of www.myapp.com while only the EC2 Instance 2 would have blog/ which is technically not possible in the way your question implies.

A more realistic solution would be to setup a new subdomain via Amazon Route 53 so the new Amazon EC2 instance setup would be like this:

• EC2 Instance 1: Is hosting www.myapp.com.
• EC2 Instance 2: Will host blog.myapp.com.

In a case like that you could then setup an Apache rewrite rule to force all traffic requests made to www.myapp.com/blog to go to blog.myapp.com. Very viable and easy to do with an .htaccess command like this:

RewriteEngine On
RewriteRule     ^blog(/.*)?$    http://www.newdomain.com/ [R=301]

You would simply place that in the .htaccess file located on the root of www.myapp.com and that will redirect all traffic from EC2 Instance 1 going to blog/ to blog.myapp.com.

One more thing: Pros/Cons of Using an Apache Reverse Proxy.

So all of the above said a commenter does bring up the potential use of setting up and Apache Reverse Proxy to pipe in requests going to www.myapp.com/blog on EC2 Instance 1 to blog.myapp.com on EC2 Instance 2. Yes, this would technically achieve the goals the original question outlines, but it opens up a potential can of worms:

• Complexity of Setting up the Apache Reverse Proxy: Now I am not saying the concept of a reverse proxy is so complex an average user cannot learn how to use it. It’s actually a tad simple to understand once you get the hang of it. But the complexity comes from having to adjust the Apache configs and manage those configs over the lifetime of the setup. For example in some web development shops, this would be considered a DevOps task. And some developers might not want to deal with a non-common DevOps task like this.
• Reverse Proxy Means Both Servers Get Traffic: Since a reverse proxy is basically a “pipe” that routes traffic from one server to another, traffic destined for EC2 Instance 2 will still have to pass through EC2 Instance 1. If the goal of setting up separate Amazon EC2 instances is to make sure one server does not affect the other, a reverse proxy can be problematic. Let’s say tons of traffic—from real users or an attack—goes to www.myapp.com/blog, what happens? The main server on EC2 Instance 1 gets that traffic as well as EC2 Instance 2; so both servers are potentially vulnerable. In contrast a simple RewriteRule to bounce traffic to a subdomain is lightweight/negligible load-wise and since most users will hit the blog on the subdomain of blog.myapp.com anyway, both servers are isolated/separated from the traffic each gets.
• Both Servers Are Inaccessible of the Main Server Goes Down: Very simple to understand. If EC2 Instance 1 is managing traffic for www.myapp.com/blog as well as core content at www.myapp.com, if that server goes down, both sites are inaccessible. By having a subdomain like blog.myapp.com means that even if the main server at www.myapp.com goes down, blog.myapp.com is still accessible.

That said if you want to explore using an Apache Reverse Proxy setup, I have two answers on Server Fault—this one and this one—that explain the basic configuration and setup.

Note that those posts focus on Solr and other Java/Tomcat apps that use port 8080 and how I use Apache Reverse Proxy to make my life easier since Tomcat is a pain in the butt to configure/manage in my humble opinion. Apache Reverse Proxying allows me to use relatively easier to understand Apache configs to manage a site’s front-facing web access instead of dealing with Tomcat’s quirks. But the overall concepts can easily be adapted from use in an Apache-to-Apache Reverse Proxy setup.