amazon-ec2 - services - vpn site to site aws

ELB de Amazon en VPC

Question

Estamos utilizando Amazon EC2, y queremos poner un ELB (equilibrador de carga) en 2 instancias en una subred privada. Si simplemente agregamos la subred privada al ELB, no obtendrá ninguna conexión, si conectamos ambas subredes al ELB, entonces puede acceder a las instancias, pero a menudo obtendrá tiempos de espera. ¿Alguien ha implementado con éxito un ELB dentro de la subred privada de su VPC? Si es así, ¿podría explicarme el procedimiento?

Gracias

Answer 1

Debe agregar las siguientes configuraciones.

1. Zona de subred pública b = NAT de servidor
2. Zona de subred privada c = Web del servidor
3. Zona de subred pública c = ELB

El truco es el enrutamiento:

1. El enrutador a NAT se conecta con la puerta de enlace A.
2. El enrutador al servidor web está conectado a NAT.
3. El enrutador a la subred pública se conecta con la puerta de enlace A.

Detalles de ELB:

1. Zona: zona de subred pública c 2.Instancia: Web del servidor 3. Grupos de seguridad: habilitar puertos

http://docs.amazonaws.cn/en_us/ElasticLoadBalancing/latest/DeveloperGuide/UserScenariosForVPC.html

Answer 2

Hemos implementado ELB en una subred privada, por lo que la afirmación de que todos los ELB deben ser públicos no es completamente cierta. Usted necesita un NAT. Cree una subred privada para los ELB privados, active VPC DNS y luego asegúrese de que la tabla de enrutamiento privada esté configurada para pasar por NAT. Los grupos de seguridad de la subred también deben configurarse para permitir el tráfico entre ELB y la aplicación, y las subredes de la aplicación a la base de datos.

Los cheques de salud de Beanstalk no funcionarán porque no pueden llegar al equilibrador de carga, pero para los servicios que necesitan estar fuera del alcance público, este es un buen compromiso.

Lectura sugerida para iniciar su arquitectura de VPC: http://blog.controlgroup.com/2013/10/14/guided-creation-of-cloudformation-templates-for-vpc/ .

Answer 3

La clave aquí es entender que no está "Agregar subredes / zonas de disponibilidad" a ELB, sino más bien especificar en qué subredes poner instancias ELB.

Sí, ELB es un equilibrador de carga de software y cuando crea un objeto ELB, se coloca una instancia EC2 de equilibrio de carga personalizada en todas las subredes que ha especificado. Entonces, para que el ELB (sus instancias) sea accesible, debe colocarse en las subredes que tienen la ruta predeterminada configurada a través de IGW (lo más probable es que haya clasificado estas subredes como públicas).

Como ya se respondió anteriormente, debe especificar redes "públicas" para ELB, y esas redes deben ser de los AZ donde se ejecutan las instancias de EC2. En este caso, las instancias ELB podrán llegar a sus instancias EC2 (siempre que los grupos de seguridad estén configurados correctamente)

Answer 4

Mi compañero de equipo y yo solo hemos implementado ELB en una VPC con 2 subredes privadas en diferentes zonas de disponibilidad. La razón por la que obtiene tiempos de espera es que por cada subred que agrega al equilibrador de carga, obtiene una dirección IP externa. (prueba ''dig elb-dns-name-here'' y verás varias direcciones IP). Si una de estas direcciones IP asigna una subred privada, se agotó el tiempo de espera. La IP que se mapea en su subred pública funcionará. Debido a que DNS puede darle cualquiera de las direcciones IP, a veces funciona, a veces agota el tiempo.

Después de algunos vaivenes con Amazon, descubrimos que el ELB solo debe colocarse en subredes ''públicas'', es decir, subredes que tienen una ruta hacia la puerta de enlace de Internet. Queríamos mantener nuestros servidores web en nuestras subredes privadas, pero permitimos que ELB les hable. Para resolver esto, tuvimos que asegurarnos de tener una subred pública correspondiente para cada zona de disponibilidad en la que teníamos subredes privadas. Luego agregamos al ELB, las subredes públicas para cada zona de disponibilidad.

Al principio, esto no pareció funcionar, pero después de probar todo, recreamos el ELB y todo funcionó como debería. Creo que esto es un error, o que el ELB estaba en un estado extraño debido a tantos cambios.

Aquí está más o menos lo que hicimos:

1. WebServer-1 se está ejecutando en PrivateSubnet-1 en la zona de disponibilidad us-east-1b con un grupo de seguridad llamado web-server.
2. WebServer-2 se está ejecutando en PrivateSubnet-2 en la zona de disponibilidad us-east-1c con un grupo de seguridad llamado web-server.
3. Creó una subred pública en la zona us-east-1b, la llamaremos PublicSubnet-1. Nos aseguramos de asociar la tabla de enrutamiento que incluye la ruta a Internet Gateway (ig-xxxxx) con esta nueva subred. (Si usó el asistente para crear una VPC pública / privada, esta ruta ya existe).
4. Creó una subred pública en la zona us-east-1c, la llamaremos PublicSubnet-2. Nos aseguramos de asociar la tabla de enrutamiento que incluye la ruta a Internet Gateway (ig-xxxxx) con esta nueva subred. (Si usó el asistente para crear una VPC pública / privada, esta ruta ya existe).
5. Creó un nuevo ELB, añadiéndole PublicSubnet-1 y PublicSubnet-2 (no PrivateSubnet-X). Además, eligió las instancias para ejecutar en el ELB, en este caso WebServer-1 y WebServer-2. Se aseguró de asignar un grupo de seguridad que permite el puerto entrante 80 y 443. Llamemos a este grupo elb-group.
6. En el grupo del servidor web, permita el tráfico desde el puerto 80 y 443 desde el grupo elb.

¡Espero que eso ayude!