-1

We have some EC2 instances running NGINX that will be accessed via a loadbalancer that can be reached via www.example.com. The loadbalancer redirects the traffic to the appropriate EC2 servers. This works fine, but sometimes we want to bypass the loadbalancer (to save money and increase data throughput). We connect on ip12-23-34-45.ec2.aws.amazon.com (example) and retrieve the information directly.

This works fine, but now we started to migrate to SSL for all our services. We have a domain certificate for the example.com domain and it works fine if we connect throught the load-balancer. When we connect to the EC2 servers directly, then it doesn't work because we present a certificate for our domain instead of the Amazon domain.

We can control the hostname where we want to redirect to, so I could choose to redirect to ec2.example.com instead of ec2.aws.amazon.com. So instead of redirecting to ip12-23-34-45.ec2.aws.amazon.com we would redirect to ip12-23-34-45.ec2.example.com. This presents the example.com certificate which should be fine.

The problem is that these hostnames cannot be resolved. Our servers are created dynamically and changing the Route53 DNS to modify the aliases over and over again seems a bit cumbersome. I would rather create a DNS rule in Route53 to map everything to .ec2.example.com to .ec2.aws.amazon.com.

Is it possible to create a rule that maps an entire subdomain to another subdomain in Route53? Or is there an other solution that we could use to bypass the load-balancer and still use SSL?

  • 2
    Please [avoid using other people's domain names and IP addresses](http://meta.serverfault.com/q/963/126632) for obfuscation. – Michael Hampton Sep 04 '14 at 12:12
  • The myamazingservice.com domain is not in use... – Ramon de Klein Sep 04 '14 at 13:53
  • 1
    What if I just bought it? – Daniel Scott Sep 08 '14 at 12:44
  • I will congratulate you with your purchase ;) But I have updated my post, so it uses the example.com domain instead. Hopefully, now someone could answer my question instead of being annoyed of using the wrong domain. – Ramon de Klein Sep 08 '14 at 19:44
  • Is your cert for example.com, example.com and www.example.com, *.example.com, or what? ie. you might need an additional cert depending on the SANs included in your current cert. – Joe Sniderman Sep 08 '14 at 20:03
  • You say your servers are created dynamically. When you create a server, you could also create a Route53 DNS entry under your domain e.g. server1.example.com => ip12-23-34-45.ec2.aws.amazon.com - then, your wildcard certificate will match. – Daniel Scott Sep 08 '14 at 21:29
  • We have a *.example.com domain certificate, so that shouldn't be an issue. Of course, we cannot include *.amazon.com in our certificate. – Ramon de Klein Sep 09 '14 at 09:55

1 Answers1

0

There is no 'wildcard' DNS that can map a whole domain.

I would suggest that you use whatever software automatically creates your servers to also create DNS entries. You can have a single domain name map to multiple servers - each time you lookup the domain name, it will give you the next server in the list (round robin DNS).

So, you could have server.example.com => ip12-23-34-45.ec2.aws.amazon.com. Then, when you create another server, add its hostname into the list, so that server.example.com resolves to ip12-23-34-45.ec2.aws.amazon.com AND ip45-67-89-10.ec2.aws.amazon.com.

Then, when you connect to server.example.com, you will connect to one of the two servers.

Alternatively, if you need to know specifically which server you're connecting to, then maintain a count, and assign server1... server2... etc.

Daniel Scott
  • 430
  • 3
  • 11
  • This is a solution that I proposed in my question, but it requires a bit more work. I am also worried about replication delays. Suppose we start a new server instance, then this instance would register itself in Route53, but when somebody asks for it, then it might not have been replicated yet. Removing instances might also be an issue, but I guess we get a signal before the instance is terminated. – Ramon de Klein Sep 09 '14 at 09:53