S3: punto de enlace de puerta de enlace o de interfaz para el acceso desde la red local

Dos tipos de punto de enlace S3 parecen intercambiables en una revisión de diseño y se comportan de forma totalmente distinta en cuanto el cliente queda fuera de la sede. Un punto de enlace de puerta de enlace es una integración con la tabla de rutas dentro de una VPC, así que una solicitud desde una VPN de sede nunca llega a él como destino privado. Un punto de enlace de interfaz coloca direcciones privadas en interfaces de red, algo que una ruta híbrida sí puede alcanzar. Todo lo que sigue depende de cuál de los dos haya elegido.

Decida por la entrada de red, no por el nombre del servicio

Empiece por donde se origina el tráfico, porque esa es la pregunta que responde el tipo de punto de enlace. Una carga de trabajo en un contexto de VPC compatible puede usar un punto de enlace de puerta de enlace y nunca necesita una dirección privada propia. Una carga de trabajo en la sede necesita una dirección privada a la que pueda enrutar, y eso es lo que proporciona un punto de enlace de interfaz. Si un diseño mezcla ambos, los dos tipos de punto de enlace pueden coexistir en una misma VPC, y eso es una disposición normal y no una duplicación.

Mezclarlos no es el problema. Suponer que un tipo cubre al otro sí lo es.

Clasifique al cliente antes de elegir nada. Un espacio de trabajo dentro de la VPC, un contenedor detrás de una puerta de enlace NAT y una aplicación en una oficina de sucursal son tres orígenes distintos, y solo el último obliga a la entrada híbrida. Escriba esa clasificación junto al inventario de puntos de enlace para que el siguiente revisor vea por qué existe cada punto de enlace.

Qué exige la ruta de interfaz de extremo a extremo

Un punto de enlace de interfaz otorga accesibilidad a direcciones privadas, y la accesibilidad es solo uno de cuatro requisitos. La red local necesita una ruta hacia esas direcciones, el lado de la VPC necesita una ruta de retorno, el grupo de seguridad del punto de enlace debe admitir el rango de origen, y cualquier dispositivo de inspección entre ambos debe permitir el flujo. Una ruta hacia cualquier instancia de la VPC no demuestra ninguno de los cuatro.

Trabaje desde el extremo lejano hacia atrás. Confirme que las interfaces de red del punto de enlace existen en las subredes que espera y luego confirme que su grupo de seguridad admite el rango local real y no un marcador de posición. Después compruebe si el túnel o el circuito transporta la ruta de retorno en la misma dirección. La inspección es el paso que la gente omite, porque un dispositivo intermedio que permite la conexión aún puede descartar un cuerpo de respuesta mayor, y eso parece un problema de rendimiento y no de política.

Pruebe con la operación autorizada más pequeña disponible en lugar de una descarga grande. El fallo aparece antes y con menos tráfico que justificar.

El DNS sigue al origen de la consulta, no a la VPC

Un punto de enlace que existe no redirige nada por sí solo. La aplicación recibe el nombre que devolvió su resolutor, y el resolutor responde según la vista que se le permite ver. Una instancia dentro de la VPC y un portátil en la oficina hacen dos preguntas distintas y ambos pueden obtener respuestas correctas y diferentes. Verificar una y concluir sobre la otra es la forma en que una prueba superada se convierte en un despliegue fallido.

Lea la configuración de DNS privado del punto de enlace como parte del diseño, no como una casilla que se activa después de la puesta en marcha.

Si el resolutor de la oficina tiene que ver la vista de la VPC, esa ruta debe construirse a propósito, normalmente mediante un punto de enlace de entrada de resolutor. Consulte desde el propio contexto de la aplicación y anote qué resolutor respondió. Un resultado recogido en un host bastión dentro de la VPC describe la vista del bastión y nada más.

El permiso está separado de la accesibilidad

Un punto de enlace accesible devuelve errores para las solicitudes que el principal no tiene permitido hacer, y ese error significa que el sistema funciona según lo diseñado. La política de identidad, la política del bucket y cualquier política del punto de enlace se evalúan en sus propias capas. El acceso de red nunca ha otorgado un permiso.

Acepte el diseño con dos resultados: una llamada autorizada inofensiva que tiene éxito y una denegación esperada para una identidad o un bucket excluido.

aws ec2 describe-vpc-endpoints --filters Name=vpc-id,Values=vpc-0123456789abcdef0
dig +short s3.us-west-2.amazonaws.com @10.0.0.2

Registre el nombre del punto de enlace, el destino resuelto y el contexto de política junto a cada resultado, porque un cambio posterior de DNS puede invalidar toda la conclusión. Compare el coste actual y el peso operativo de ambos tipos de punto de enlace antes de aprovisionar nada. Un punto de enlace de interfaz compra una entrada privada híbrida, no es un requisito universal, y la ruta de puerta de enlace a menudo sigue siendo la mejor respuesta para cargas de trabajo dentro de la VPC. La elección es por cliente y sigue siendo revisable.