Access bastion host via elb

[robinbowes]

This change adds a classic ELB in front of the instance, which makes it possible to assign a Route53 alias record.

[antonbabenko]

I see a bit too many problems with such implementation (and using ELB for doing SSH), but to be short I wonder what will happen when there are several servers behind ELB? Do you propose to use sticky-sessions (hmm)?

And in the first place, what was the problem you wanted to solve with this code?

[robinbowes]

ELB classic works fine for ssh using a TCP connection. There will only ever be one bastion host so multiple servers is not a problem.

The problem I wanted to solve was to be able to create a Route53 Alias record for our bastion hosts., rather than managing an EIP association. With my approach, there is nothing to manage as AWS makes sure the Alias record always points to the DNS name of the ELB.

[antonbabenko]

I honestly see very little benefits of supporting ELB in favor of using Alias records with Route53. There are 3 main issues:

• Pricing of ELB vs pricing of EIP. ELB costs $18/month, EIP is likely to be zero. Multiple that by a number of bastion hosts (people sometimes run one per AWS account or one per environment).
• Overall architecture is getting more complex than it can be.
• Keep-alive settings on ELB should be very high to keep connection open. How high?

If you could rework the code to make creation of ELB conditional (using variable like ${var.use_eip}) and describe in a README file how to make it to work with ELB and EIP that would be nice and we can definitelly merge it. Make creation of EIP by default to prevent BC for the users.

[robinbowes]

Actually, I think a better approach would be to manage the ELB outside the module and pass it in to optionally attach it to the ASG.

I'll look into refactoring and try that approach.