My company has a running business web service on AWS which uses a wildcard SSL certificate (works for *.example.com). Multiple partners have subdomains and need SSL (https://partner1.example.com, https://partner2.example.com, etc.) and we serve either HTML or JSON responses to them.
Our production site has a web-facing ELB that has our SSL certificate installed. THe ELB balances and terminates SSL to a cluster of production server instances within our VPC. Our web app knows how to serve the correct partner HTML/JSON based on the sub-domain name.
I want to replicate this for our test environments (e.g. QA, Staging, Demo) as simply as possible. But test and production environments can't be the same server instances; I need to know that I won't kill production if I mess up on our test environment.
Ideally, the same ELB that handles production traffic could somehow route traffic to my test servers, perhaps if they used a known IP address or DNS subdomain? Am I correct that this isn't possible?
I suppose I could set up an ELB with the SSL cert for each test environment, each "balancing" to one server, but this seems overly complicated, and I would guess expensive too.
All instances, production and test, run within our VPC. But currently only the production cluster has SSL set up on the ELB (which terminates SSL) and passes along straight HTTP requests to the instances themselves.
The test servers accept HTTP. I have public elastic IPs and DNS names set up (staging.example.com, qa.example.com, demo.example.com) ... but they are not protected by SSL.
There's almost no critical or customer data on test server instances, and they are secured and patched properly as any web-facing server should be (I hope!!). Still, I would like SSL not only for additional security, but also to have my test environment match my production environment as closely as possible.
In all but the case of our staging server, the other environments are supported by a single instance (e.g. demo and qa both on the same server) with Apache named virtual host configurations. So, for test, lots of sites, but only a few servers.
Is there a way that I can still have my wildcard SSL certificate installed only on my load balancer (or perhaps one more), or some other configuration that allows me to detect and route the HTTP request to the right test server, based on IP or domain name (or even an HTTP header)?
I know this is a complicated question. I understand AWS, security, and networking pretty well, but I am still trying to figure out routing and even internal DNS within the VPC environment, so may be ignorant of my options.
Answer
Honestly? I'd say you're overthinking this. Just use multiple ELBs and put the *.example.com certs on all of them. This isn't really cost prohibitive. In your entire stack, the ELB is probably going to be one of the cheapest components. This also allows you to spin up stacks from the same CloudFormation template or provisioning system. You can use the cert on as many ELBs as you'd like.
We faced a problem very similar to yours and decided to do exactly what I describe above. We ended up saving money because the ELB just isn't a significant predictor of our monthly cost, and it'd have taken far more time in salary to hack up a solution, even if one was possible. With ELBs you only pay for what you use traffic-wise, so QA and demo environments just aren't going to be anywhere near the cost of production load. In the example described in that link, 100GB of traffic in a month is $18. That's like three Starbucks coffees.
One added benefit: It's also way easier to debug. No need to worry about weird trafficking rules or the like.
No comments:
Post a Comment