¿Puerta de enlace de S3 o punto de enlace de interfaz para un cliente local?

Llegar a S3 desde una red de oficina por una VPN de sitio no es un problema de enrutamiento que una ruta estática pueda resolver por sí sola. Un punto de enlace de puerta se adjunta a las tablas de rutas y atiende las peticiones que se originan dentro de la VPC. Un punto de enlace de interfaz coloca interfaces de red elásticas con direcciones privadas en tus subredes, y esas direcciones son accesibles desde las instalaciones a través de VPN o Direct Connect. Dónde empieza la petición decide cuál de los dos necesitas en realidad, y el trabajo de DNS, grupo de seguridad y política se deriva de esa respuesta.

Separa los tipos de punto de enlace por dónde empieza la petición

Un punto de enlace de puerta aparece como una entrada en la tabla de rutas que apunta a una lista de prefijos gestionada. No tiene interfaz de red, ni grupo de seguridad, ni dirección privada propia, y es exactamente por eso que un host local no puede enrutar hacia él: al otro lado no hay nada hacia lo que enrutar. El tráfico desde dentro de la VPC llega a S3 porque la tabla de rutas de la subred envía ese prefijo al punto de enlace. El tráfico desde cualquier otro lugar no tiene esa entrada que seguir.

Un punto de enlace de interfaz es un conjunto de interfaces de red en las subredes que elijas, cada una con una dirección privada de esa subred y un grupo de seguridad adjunto. Esa es la forma que puede usar un cliente híbrido, porque es un destino ordinario al que tu túnel puede llevar paquetes. También significa que el punto de enlace consume direcciones de la subred y puede quedarse sin ellas.

aws ec2 describe-vpc-endpoints --query "VpcEndpoints[].{Id:VpcEndpointId,Type:VpcEndpointType,Service:ServiceName,State:State}" --output table

Lee la columna Type en lugar del nombre. Una sola VPC suele contener ambos tipos para el mismo servicio, y la entrada que necesita tu aplicación local es la de interfaz.

Construye la ruta hasta la dirección de interfaz antes de probar S3

Tres cosas tienen que ser ciertas a la vez: el enrutador local tiene una ruta a la subred del punto de enlace, la ruta de vuelta desde esa subred llega a la red del cliente, y el grupo de seguridad del punto de enlace admite el rango de origen del cliente. La ACL de red de la subred todavía puede descartar el paquete después de que las tres se cumplan, así que revísala como cuarto elemento y no como idea tardía.

Una ruta que funciona hacia alguna instancia EC2 dentro de la VPC no demuestra nada de esto. Solo muestra que el túnel está levantado, que es la única parte del camino que ya sabías. Demuestra la dirección del punto de enlace por separado y luego demuestra que el nombre se resuelve en ella.

ip route get 10.60.4.37
nc -vz 10.60.4.37 443
openssl s_client -connect 10.60.4.37:443 -servername bucket.vpce-0123456789abcdef0-abc123.s3.us-east-1.vpce.amazonaws.com </dev/null

El primer comando muestra qué interfaz usaría el cliente. El segundo demuestra un apretón de manos TCP. El tercero demuestra que TLS se completa con un certificado válido para el nombre del punto de enlace, y esa es la comprobación que atrapa una dirección equivocada antes de culpar a los permisos.

Decide qué respuesta DNS recibe la aplicación

Que exista un punto de enlace de interfaz en la VPC no redirige un SDK local por sí solo. El cliente usa o bien el nombre específico del punto de enlace que AWS publica para ese punto, o bien una zona alojada privada que hayas hecho resoluble desde la oficina a propósito.

Para la resolución híbrida, el resolutor local necesita una ruta soportada hacia la vista DNS de la VPC, normalmente a través de un punto de enlace de entrada de Resolver. Activar el DNS privado sin entender qué fuentes de consulta afecta es como una búsqueda empieza a devolver una dirección que la oficina no puede alcanzar. El ajuste cambia las respuestas de las consultas que llegan por el resolutor de la VPC, no las de todos los clientes en todas partes.

dig +short bucket.vpce-0123456789abcdef0-abc123.s3.us-east-1.vpce.amazonaws.com
aws s3api head-bucket --bucket example-artifacts --endpoint-url https://bucket.vpce-0123456789abcdef0-abc123.s3.us-east-1.vpce.amazonaws.com

Ejecuta ambos comandos en el host de la aplicación, no en una máquina de salto dentro de la VPC. El resolutor que responde allí es el que usa tu carga de trabajo, y una respuesta distinta desde otro host es la fuente de confusión más habitual en este diseño.

La accesibilidad no es autorización

Una petición que llega al punto de enlace todavía necesita un principal autorizado y un permiso de bucket aplicable. Una política de punto de enlace puede restringir lo que el punto permite, y una política de bucket puede restringirlo aún más. Llegar a la interfaz no dice nada sobre qué objetos puede leer el llamador.

Prueba ambas direcciones: una llamada autorizada e inofensiva contra el bucket previsto, y una llamada que se espera denegada para una identidad o un recurso fuera de la política. Guarda el nombre del punto de enlace, la dirección resuelta y el contexto de política junto con el resultado para que la siguiente persona pueda reproducirlo. Una denegación que nombra el tipo de política ahorra una hora de conjeturas.

Por último, valora el precio de las dos opciones antes de aprovisionar. Un punto de enlace de interfaz factura por hora de interfaz y por gigabyte, mientras que uno de puerta no, y esa diferencia decide la cuestión para muchas cargas de bajo volumen que solo necesitan acceso desde el lado de la VPC.