Para que una instancia de RDS en VPC sea accesible "públicamente" (Internet), todas las subredes a las que está conectada deben ser subredes "públicas", en lugar de "privadas".
Una subred pública se define esencialmente como una subred que tiene el objeto Puerta de enlace de Internet (igw-xxxxxxxx) como su ruta a "Internet", o al menos a cualquier destino de Internet al que necesite acceder. Por lo general, esta es una dirección de destino de 0.0.0.0/0
. Las subredes públicas deben usarse para instancias (incluyendo RDS) que tendrán una dirección IP pública asociada, y no deben usarse para instancias que no tendrán direcciones IP públicas, ya que las direcciones privadas no funcionan en Internet sin traducción.
Una subred privada, por el contrario, tiene su tabla de enrutamiento configurada para llegar a destinos de Internet a través de otra instancia EC2, generalmente una instancia NAT. Esto se muestra en la tabla de rutas VPC asociada con esa subred como i-xxxxxxxx, en lugar de "igw". Esa máquina (que, en sí misma, estará en una subred diferente de la que actúa como destino de ruta) sirve como traductor, permitiendo que las instancias privadas de IP solo realicen de manera transparente las solicitudes salientes de Internet utilizando el público de la máquina NAT. IP para sus necesidades de Internet. Las instancias con una dirección IP pública no pueden interactuar adecuadamente con Internet si están conectadas a una subred privada.
En el caso específico, aquí, las subredes asociadas con la instancia de RDS no se configuraron realmente como algo que podría clasificarse simplemente como una subred privada o pública, porque la subred no tenía ninguna ruta predeterminada. Agregar una ruta predeterminada a través del objeto "igw" o, como lo hizo OP, agregar una ruta estática a la dirección IP de Internet donde se necesitaba conectividad, en la tabla de rutas VPC para las subredes soluciona el problema de conectividad.
Sin embargo ... Si experimenta un problema similar, no puede simplemente cambiar la tabla de ruta o construir nuevas tablas de ruta y asociar las subredes con ellas, a menos que ya no tenga nada más funcionando correctamente en las subredes, porque el cambio podría razonablemente ser Se espera que rompa la conectividad existente. El curso correcto, en ese caso, sería aprovisionar las instancias en diferentes subredes con las entradas correctas de la tabla de rutas en su lugar.
Al configurar una VPC, es ideal definir claramente los roles de subred y aprovisionar completamente las rutas necesarias cuando se comisiona la VPC por primera vez. También es importante recordar que toda la "LAN" de VPC es una red definida por software. A diferencia de una red física, donde el enrutador puede convertirse en un cuello de botella y, a menudo, es razonable colocar máquinas con mucho tráfico entre ellas en la misma subred ... el tráfico que cruza las subredes no tiene ninguna desventaja de rendimiento en VPC. Las máquinas deben colocarse en subredes que sean apropiadas para las necesidades de direccionamiento IP de la máquina: dirección pública, subred pública; sin dirección pública, subred privada.
Puede encontrar más información sobre la logística de las subredes privadas / públicas en VPC en Por qué necesitamos una subred privada en VPC (en Stack Overflow).
(110)
mensaje de error en el mensaje significa "conexión agotada", por lo que definitivamente se trata de un problema de conectividad IP. Su instancia de RDS muestra que está asociada con dos subredes. En la consola VPC, ¿cuál es la ruta predeterminada de esas dos subredes? ¿Es un "igw-xxxxxxxx" o es un "i-xxxxxxxx"?