RDS privado desde EC2: ¿misma VPC, peering o algo más?

El portátil del desarrollador llega a la instancia privada de RDS a través de la VPN del personal, pero la aplicación en EC2 no puede conectarse en absoluto. Eso no es un despliegue roto. El portátil tiene un túnel que la instancia de EC2 nunca hereda, y «privado» en RDS significa que la base de datos no tiene un punto de conexión público, no que los usuarios humanos de la VPN sean los únicos llamantes permitidos. La aplicación necesita su propia ruta autorizada, su propia relación con el grupo de seguridad y su propia identidad de base de datos, y el orden en que elige esas tres cosas ahorra la mayor parte de la depuración. Decida la ruta primero, luego los permisos y, por último, verifique desde el entorno desplegado en lugar de desde su escritorio.

La VPN del portátil no es la ruta de la aplicación

Haga lo que haga la VPN del personal para las personas, no hace nada por una instancia a menos que esa instancia forme parte explícita de la misma ruta de red. Una instancia de EC2 en una subred privada llega a RDS mediante el enrutamiento de VPC, los grupos de seguridad y las ACL de red. No hereda el túnel de una persona, la sesión de una persona ni las credenciales de una persona, y no debería: la conectividad de aplicaciones sin supervisión y el acceso remoto del personal deben poder operarse de forma independiente.

Esa independencia es una ventaja. Cuando la VPN falla, la aplicación sigue funcionando. Cuando la aplicación se comporta mal, nadie pierde su acceso remoto. Los diseños que fusionan ambas cosas en una sola ruta suelen descubrirse durante un incidente, en el peor momento posible.

Decisión 1: misma VPC, ruta directa

Cuando la aplicación y la base de datos están en la misma VPC con enrutamiento directo y sin ningún dispositivo intermedio de inspección entre ellas, la ruta es sencilla y la referencia al grupo de seguridad es la herramienta más potente disponible. Dé a la aplicación su propio grupo y luego permita el puerto de la base de datos desde ese grupo en lugar de desde un rango de direcciones:

aws ec2 authorize-security-group-ingress --group-id sg-0db123   --protocol tcp --port 5432 --source-group sg-0app456

aws rds describe-db-instances --db-instance-identifier prod-db   --query 'DBInstances[0].{Endpoint:Endpoint.Address,Port:Endpoint.Port,Public:PubliclyAccessible,Groups:VpcSecurityGroups}'

El puerto es ilustrativo y debe coincidir con el motor. Una referencia de grupo autoriza el tráfico desde las instancias de la aplicación; no copia sus reglas ni crea un inicio de sesión en la base de datos. Dos problemas separados, dos soluciones separadas.

Después revise el resto de la ruta en lugar de detenerse en la regla que acaba de añadir. La política de salida de la aplicación, el conjunto completo de grupos adjuntos a la base de datos, las tablas de rutas de la subred y cualquier ACL de red deben coincidir. Las reglas de los grupos de seguridad tienen estado, mientras que una ACL de red personalizada debe permitir la petición y el tráfico de retorno en reglas separadas, incluidos los puertos efímeros. Una regla nueva y estrecha para la base de datos tampoco cancela una autorización amplia anterior que ya estaba adjunta.

Decisión 2: otra VPC u otra cuenta

Si la aplicación está en otra VPC, los propietarios de la red eligen una interconexión privada compatible: peering, un diseño de tránsito o un acuerdo de VPC compartida. Entonces deben existir ambas direcciones de enrutamiento, la resolución de nombres debe funcionar para el punto de conexión de RDS, y el origen que evalúa la política de la base de datos debe coincidir con lo que llega realmente. Los nombres de cuenta coincidentes o una relación de facturación compartida no aportan nada de eso.

La referencia al grupo de seguridad es la parte que varía. Funciona en varios diseños de interconexión privada, pero deja de funcionar en el momento en que un dispositivo intermedio reescribe el origen o termina la conexión, porque entonces la base de datos ve el dispositivo intermedio en lugar de su grupo de aplicación. Los escenarios de VPC de RDS separan el acceso dentro de la misma VPC de los demás arreglos, y vale la pena comprobar su topología concreta con ellos antes de suponer que un estilo de regla se traslada.

No resuelva una ruta que falta haciendo que la base de datos sea accesible públicamente. Esa es otra decisión de exposición con otro propietario, y normalmente la propone quien está más lejos de la consecuencia.

Decisión 3: qué identidad acepta la base de datos

El acceso de red y la autenticación de la base de datos son capas separadas, y confundirlas produce los errores más engañosos. El rol de la instancia es una identidad de AWS para llamar a las API de AWS. No es un usuario de base de datos. La autenticación de base de datos con IAM es una función compatible donde el motor y la configuración lo permiten, y sigue siendo una asignación a un usuario de base de datos, no un sustituto.

Utilice el nombre del punto de conexión de RDS en la configuración de la aplicación en lugar de una dirección capturada de una sola consulta. La conmutación por error de Multi-AZ cambia la dirección detrás de ese nombre, y una aplicación fijada a una IP fallará exactamente en el momento en que se necesite. Mantenga activada la verificación TLS del motor en lugar de desactivarla para hacer desaparecer un error, porque un fallo de verificación le dice algo sobre el punto de conexión al que llegó.

Luego conceda a la cuenta de base de datos el mínimo que la aplicación necesita, en el esquema que realmente utiliza. Ese trabajo es aburrido, es auditable y es la parte que preguntará una revisión de incidente.

Verifique desde el entorno desplegado

Pruebe desde la instancia o desde una tarea que se ejecute con el mismo grupo, subred y rol. Cuatro fallos parecen iguales desde un portátil y se distinguen con facilidad desde allí: un nombre que no se resuelve, una conexión que expira, un fallo de validación TLS y un inicio de sesión rechazado en la base de datos. Cada uno apunta a un límite diferente, y cambiar la exposición de la base de datos antes de saber cuál tiene es adivinar.

psql "host=prod-db.abc123.eu-west-1.rds.amazonaws.com port=5432 dbname=app sslmode=verify-full" -c 'select 1'

Si la conexión funciona desde la instancia y falla desde su escritorio, la ruta de la aplicación está bien y su acceso es lo que hay que arreglar. Si falla desde ambos, empiece por las comprobaciones de grupo y ruta anteriores y no por las credenciales. Esa única comparación evita la mayor parte del ruido que generan estos tickets.