¿Cuál es la mejor práctica para la comunicación entre instancias de Amazon EC2?

Question

He estado configurando instancias de Amazon EC2 para un próximo proyecto. Son todas microinstancias que ejecutan Ubuntu Server 64bit. Esto es lo que he configurar hasta ahora:

• servidor Web - Apache
• servidor de bases de - MySQL
• servidor de desarrollo de - Apache MySQL &
• servidor de archivos - SVN & Bacula (las copias de seguridad se realizan a los segmentos S3)

Actualmente, solo hay un servidor web, pero con el tiempo habrá más.

Mi primera pregunta es, ¿cuál es la forma más segura mejor, para Amazon EC2 casos se comuniquen entre cada otra? Actualmente estoy usando SSH, ¿es el mejor método?

De acuerdo con Amazon, las instancias que se comuniquen entre sí utilizando sus direcciones de IP elásticas serán cargadas con tarifas de transferencia de datos. Sin embargo, las instancias que se comunican usando sus direcciones IP privadas pueden hacerlo de forma gratuita. Desafortunadamente, parece que las IP privadas cambian si la instancia se detiene y se reinicia.

Así que esa es mi segunda pregunta, ¿cómo hacer uso de IPs privadas instancias de Amazon si no son estáticas?

Sé que las instancias probablemente no se detengan y se inicien con mucha frecuencia, pero aun así, si la dirección IP está en varios archivos de configuración, sería una molestia tener que revisarlas todas y cambiarlas .

Me preocupan principalmente los servidores web, que necesitarán acceso al servidor de la base de datos y al servidor de archivos, que necesitarán acceso a todas las instancias cuando realicen copias de seguridad.

Nota: Nunca he usado Bacula antes y todavía no lo tengo configurado, pero supongo que necesitará las direcciones IP de los clientes para realizar una copia de seguridad.

¿Sería ServerFault un lugar mejor para hacer esta pregunta?

Answer 1

Probablemente sea más un tema de ServerFault, pero lo responderé de todos modos.

La forma más sencilla de superar el dinamismo de las direcciones IP internas es ejecutar un servidor DNS privado en su clúster. Mi propiedad utiliza máquinas virtuales de Windows, por lo que tenemos un par de AD configurado para proporcionar servicios DNS (así como, por cierto, autenticación de inicio de sesión VM centralizada). Con cada máquina como miembro del dominio y con sus punteros DNS configurados para cada una de las unidades AD (primaria y de respaldo), la IP interna dinámica se registra automáticamente con el servicio DNS cada vez que cambia, por lo tanto, en lugar de referirse a otra VMs por su IP pública (p. Ej. 79.125.xx) que incurre en costos de transferencia de datos, o por IP interna (ej. 10.44.xx) que puede cambiar al reiniciarse, usan un nombre DNS (ej. Mydomain.dbserver01) que es persistente.

Utilizamos comunicaciones cifradas para intercambios de datos internos y externos; recuerde, las VM en la nube son, por definición, inherentemente menos seguras que cualquier cosa dentro de su cortafuegos corporativo, por lo que debe invertir más en su configuración de seguridad. Nuestra política es que una VM en la nube se configure de manera tal que sea más segura que una VM equivalente dentro de nuestra intranet.