3

PLEASE NOTE: port 22 is just an example port there will be instances when it is not port 22 I am trying to deal with.

Security Groups

"server-1" has a security group "group-1"
"server-2" has a security group "group-2"
"server-1" has an elastic ip address assigned to it i.e 111.222.333.444

and

"group-2" is allowed to connect to "group-1" via port 22

So if I ssh from server-2 to server-1 via the following command

ssh -iKEY.pem root@ec2-111.222.333.444.eu-west-1.compute.amazonaws.com

the connection is fine, works as expected.

If however I try and connect via this command.

ssh -iKEY.pem root@111.222.333.444

It does not work for what I assume are obvious reasons

I have left the aws network in order to connect to the server-1 and therefore aws sees the connection from server-2 as an external resource and no longer an aws instance. This means it will not use the Security group that says: 

"group-2" is allowed to connect to "group-1" via port 22

Actual Problem

I want to connect to server-1 via the ElasticIP address so I can happily reboot server-1 and/or server-2 and not have to worry that the aws instance name/ip address has changed i.e the domain name in the first ssh example will change on a reboot/new instance taking over.

So my question really is what is the best practice way to do this. The options I can see at the moment are:

  1. Do a reverse dns look up of the ElasticIP address and connect using this domain name form server-2 to server-1 i.e the Elastic ip address is 111.222.333.444 and the reverse look up will return me

    ec2-111-222-333-444.eu-west-1.compute.amazonaws.com

    I cannot relay on building this manually as I also need to know what availability zone the instance is in in order to do that (I would like very much not to care about where it is).

  2. I would assume there is a aws api call I can do to grab the current instance name that is attached to the ElasticIP address. Iam not overly kean on the application knowing it is on an aws server and would like to keep away form the api.

  3. Use vpc instances within aws. This way I can always attach the same private ip address to server-1 and connect to it reliably even after a reboot of either server. This however appears to come with a lot of configuration and maintenance.

  4. I could manually update any config settings pointing to the server-1 after a reboot (this is not a series suggestion).

  5. Open server-1 port 22 to the world (NOTE: I want to open other ports as well not just 22) and worry about the application doing the authentication. (again not really a sensible option as if I want to open port 80 to server-2 then have to use .htaccess or alike to authenticate the connection, therefore just moving this issue and not really solving it).

The problem I have with options 1 and 2 are that I have to always do these lookups which produces massive over head on an application or I cache it and have to live with the fact that if the instance of server-1 changes i.e a reboot occurs then there is a time when server-2 will will not be able to connect to server-1 till it de-caches the instance name.

Option 3 is probably the best solution however it comes with configuration and maintenance that is time consuming and needs extra knowledge within our company.

Does anyone have an other suggestion that will work?

Flimzy
  • 2,454
  • 18
  • 26
Alistair Prestidge
  • 806
  • 1
  • 7
  • 19

2 Answers2

2

Given your requirements, I would agree that using a VPC is the most optimal solution. Since it sounds like you've done your research, you know that a VPC allows much finer-grained control over subnet and host addressing. To answer your question, that is the "best practices" approach.

What I would do is create two private subnets, one in each AZ, and place an Elastic Network Interface with a static, private IP address in each subnet. Then you can attach/detach the ENI to the appropriate instance at will. This allows some cool stuff and functions like hot-swapping a NIC between servers while traffic is still flowing through it. Yes, there is a significant learning curve with setting up a VPC, but the tradeoff is greatly increased security and flexibility when using multiple EC2 instances that need to talk to each other.

It's worth noting that utilizing the AWS API (as you also mentioned) is also a viable solution for your immediate needs. But the further you go down this path of writing a custom solution, the more time consuming it becomes to maintain as your needs grow.

jamieb
  • 3,427
  • 4
  • 25
  • 36
  • Thanks that is exactly the answer I was expecting. I just wanted to make sure before I dive into VPC and find it was a waste of time. Thanks – Alistair Prestidge Jan 15 '13 at 14:36
0

The AWS api method to look up the instance's public dns is this:

http://169.254.169.254/latest/meta-data/public-hostname

(It's an AWS internal ip, not an external service.)

But as for the root of the issue, the public DNS for an Elastic IP is supposed to be permanently associated with that Elastic IP, regardless of reboots/new instances that it points to. All my Elastic IP public DNS look like ec2-11-22-33-44.compute-1.amazonaws.com. How come you have a region in the public DNS? What does it return with the api above?

wisbucky
  • 1,069
  • 10
  • 9