Tunnel a un RDS privado sin bastion.

La respuesta clásica a "¿cómo corro una migración contra un RDS privado desde mi laptop?" es levantar un bastion EC2, abrir el puerto 22 a tu IP, pushear una key SSH y tunnelear:

ssh -N -L 5433:<rds-endpoint>:5432 bastion-prod

Funciona. También es desperdicio: una EC2 expuesta públicamente que mantenés viva para siempre para migraciones que ocurren una vez por trimestre, más las keys SSH y reglas de security group que vienen con ella.

Si tu cuenta tiene AWS Systems Manager (SSM) y al menos una EC2 con el agent SSM en la misma VPC que el RDS, no necesitás un bastion. SSM Session Manager tiene un modo de port forwarding que tunneliza TCP a través de esa EC2 en un comando.

El comando

aws ssm start-session \
  --target <ec2-instance-id> \
  --document-name AWS-StartPortForwardingSessionToRemoteHost \
  --parameters '{
    "host": ["<rds-endpoint>"],
    "portNumber": ["5432"],
    "localPortNumber": ["5433"]
  }'

--target es cualquier EC2 en la VPC que ya tenga alcance de red a la base. host es el endpoint del RDS. La sesión abre un tunnel TCP desde localhost:5433 en tu máquina hacia ese endpoint, ruteado por la red de la EC2. La EC2 es solo un hop, ve la conexión pero no toca el protocolo.

Corré la sesión, dejala abierta en una terminal, y desde otra terminal apuntá tu tooling a localhost:5433. El connection string: cambiá host y puerto, mantené user, password y nombre de base. Corré tu migración, tu psql, tu dump, lo que sea.

Cuando hacés Ctrl-C en la sesión, el tunnel se cierra. Sin cleanup, sin reglas huérfanas.

Lo que necesitás del lado AWS

Tres cosas, todas estándar:

1. La EC2 target tiene el SSM agent corriendo. En Amazon Linux 2 / AL2023 / Ubuntu viene instalado por default hace rato; en AMIs más viejas lo instalás una vez.
2. El instance role de la EC2 target incluye AmazonSSMManagedInstanceCore (o el subset de permisos que otorga).
3. Tu principal IAM (el que tu CLI aws autentica) tiene ssm:StartSession sobre ese target.

Eso es todo. Sin IP pública en la EC2, sin puerto inbound abierto, sin key SSH.

Lo que el approach SSH-bastion esconde y dejás de pagar

1. Una EC2 bastion con exposición pública. SSM no tiene. La sesión arranca desde tu máquina local, la API de AWS hace el routing.
2. Keys SSH para administrar y rotar. El auth de SSM se monta sobre tu identidad IAM existente. Sin keys para pushear, perder o auditar.
3. Una regla de firewall que sobrevive a la migración. El tunnel SSM se cierra cuando termina la sesión. No hay ventana donde el path queda abierto después de que dejaste de usarlo.

Audit trail

Cada llamada start-session se loguea en CloudTrail con el principal IAM, la instancia target, el session ID y la duración. Conseguís un paper trail por default que el modelo SSH-bastion no te da limpio. Si tu equipo alguna vez necesita responder "¿quién se conectó al RDS de prod el martes pasado?", CloudTrail tiene la respuesta en una query.

Cuándo SSM es la herramienta equivocada

Algunos casos donde el modelo bastion sigue teniendo sentido:

• Tu cuenta no corre ninguna EC2 con el agent SSM. Setups puramente Lambda o puramente Fargate no van a tener un target. (Fargate puede correr con el agent SSM también, pero es menos común.)
• Necesitás tunnels long-running medidos en horas, no minutos. Los timeouts de sesión SSM defaultean a 20 minutos idle; configurables pero no ilimitados.
• Necesitás identidad no-IAM para el operador (por ejemplo, contratistas sin acceso AWS). Un bastion con keys SSH a veces es más simple que provisionar IAM.

Para todo el resto, el patrón SSM tunnel es más corto, más seguro, y auditado por default.

La forma que sobrevive

El reflejo cuando no podés alcanzar un recurso privado es sumar infraestructura. El default mejor, cuando ya estás en AWS, es preguntar si SSM puede rutear la conexión sin sumar nada. La mayoría de las veces puede.

Un comando, una EC2 ya corriendo, una entrada en CloudTrail por sesión. El bastion que no tenés es el bastion que no necesitás operar.