Using Load Balancer Instead of Proxy Server

4
votes

I am planning on running both a Java web app (www.example.com) and a wordpress blog (www.example.com/blog) on the same domain.

Tomcat server serves my Java web app content and Apache server serves the WordPress content.

Originally, I was going to use a proxy server to route all blog request to the Apache server and all other requests to Tomcat (http://tomcat.apache.org/tomcat-8.0-doc/proxy-howto.html) (I'm not sure exactly how I would implement since I haven't done it yet).

However, I was recently made aware of AWS Application Load Balancer. Using the LB I can route requests to specific ports based on the url path and thus I can use it to route all www.example.com/blog requests to the Apache Server (on port 80) and all www.example.com requests to the Tomcat server (port 8080).

Is there any reason why I shouldn't do this? Since Application Load Balancer is a relatively new product, most of the documentation recommends the proxy server solution, but I see no reason why not to use the Application Load Balancer solution instead.

Thank you.

1
amazon-web-servicestomcatproxyreverse-proxy
There is no reason and Issue that will not make this work suing Application Loadbalancer. So instead of proxy server use ALB that is a good solution. - error2007s
One drawback is that you cannot test your site on a local environment if you're using the Load Balancer option. - theyuv

1 Answers

9
votes

While the Application Load Balancer is a great addition to the AWS product suite, there are some things (currently) you can do with a reverse proxy that you can't with an ALB - your choice will depend on what your situation requires.

Generally speaking, ALB will be fine for simpler configurations, but the proxy gives you more control and flexibility if you have more complex rules/needs.

Things you can do with a Proxy you can't with an ALB

  • Built in caching of backend responses respecting HTTP standard cache control headers and/or custom caching rules
    • ALB routes requests without caching
    • (The AWS-native solution if you need caching is Cloudfront)
  • Complex backend routing decisions
    • e.g. using nginx you can select the backend based on pretty much any aspect of the request - with ALB (so far) it's based on the path only (with up to 10 rules at launch) - although they promise more are coming
  • Arbitrary backends
    • proxies will generally allow you to proxy to any http/s backend (e.g. an S3 bucket, some other website, etc.)
    • ALB at this point only appears to offer target groups which contain EC2 instances or EC2 Containers
  • Many proxies (e.g. nginx) offer a range of modules any one of which might be helpful/useful for you
  • Custom extensibility - nginx lua module gives massive flexibility to behavior of the proxy

Things that are easier with ALB over a Proxy

  • Much simpler configuration
  • High availability out of the box
    • If you ran a proxy, you'd need to put the proxy in it's own scaling group and run a two layers of traditional ELBs - one in front of the proxy's ASG, and one in front of each backend's ASGs (e.g. search for Service Segmentation Using a Proxy Layer on that page
  • API based provisioning and configuration - better for devops workflows and CI/CD pipelines if you want to spin up new environments on the fly

Other References

Nginx has published a comparison here - the list above was based on my opinion of the important points - Nginx obviously has their own biases, but it is worth reviewing.