Eligiendo su estrategia de Endpoints de VPC para Amazon S3

Por Jeff Harman y Gilles-Kuessan Satchivi, Arquitectos Sénior de Soluciones
Esta publicación fue coescrita con Anusha Dharmalingam, ex arquitecto de soluciones de AWS.

¿Su aplicación de Amazon Web Services (AWS) debe conectarse a los buckets de Amazon Simple Storage Service (S3), pero sin atravesar el Internet para llegar a los puntos de conexión públicos? ¿La conexión debe escalar para satisfacer las demandas de ancho de banda? AWS ofrece un mecanismo llamado Endpoints de VPC (VPC Endpoints) para cumplir con estos requisitos. Esta publicación proporciona orientación para seleccionar el tipo de endpoint (punto de enlace o punto de conexión) de VPC adecuado para acceder a Amazon S3. Un endpoint de VPC permite que las cargas de trabajo que se encuentran en una Amazon VPC (Virtual Private Cloud) se conecten a servicios públicos de AWS compatibles o a aplicaciones de terceros a través de la red de AWS. Este enfoque se utiliza para cargas de trabajo que no deben comunicarse a través de redes públicas.

Cuando la arquitectura de una carga de trabajo utiliza endpoints de VPC, la aplicación se beneficia de la escalabilidad, la resiliencia, la seguridad y los controles de acceso nativos de los servicios de AWS. Se puede acceder a Amazon S3 mediante un endpoint de VPC de tipo interfaz con AWS PrivateLink o un endpoint de VPC de tipo gateway (puerta de enlace). Para determinar el tipo de endpoint adecuado para sus cargas de trabajo, discutiremos los criterios de selección a considerar en función de sus requisitos.

Descripción general del endpoint de VPC

Un endpoint de VPC es un componente de red virtual escalable que se crea en una VPC y se utiliza como punto de entrada privado para servicios de AWS compatibles y aplicaciones de terceros. Actualmente, se pueden utilizar dos tipos de endpoints de VPC para conectarse a Amazon S3: endpoint de VPC de tipo interfaz y endpoint de VPC de tipo gateway.

Cuando usted configura un endpoint de VPC de tipo interfaz, se implementa una interfaz de red elástica (ENI) con una dirección IP privada en su subred. Una instancia de Amazon EC2 en la VPC puede comunicarse con un bucket de Amazon S3 a través de la ENI y la red AWS. Usando el endpoint de tipo interfaz, las aplicaciones de su centro de datos local pueden consultar fácilmente los buckets de S3 a través de AWS Direct Connect o VPN de sitio a sitio. El endpoint de tipo interfaz admite una lista creciente de servicios de AWS. Consulte nuestra documentación para encontrar servicios de AWS compatibles con endpoints de tipo interfaz apalancados con la tecnología de AWS PrivateLink.

Los endpoints de VPC de tipo gateway utilizan listas de prefijos como ruta de la IP destino en una tabla de rutas de la VPC. Esto enruta el tráfico de forma privada a Amazon S3 o Amazon DynamoDB. Una instancia EC2 en una VPC sin acceso a Internet aún puede leer y/o escribir directamente en un bucket de Amazon S3. Amazon DynamoDB y Amazon S3 son los servicios actualmente accesibles a través de endpoints de tipo gateway.

Sus políticas de seguridad interna pueden tener reglas estrictas contra la comunicación entre su VPC e Internet. Para mantener el cumplimiento de estas políticas, usted puede usar el endpoint de VPC para conectarse a servicios públicos de AWS como Amazon S3. Para controlar el acceso de usuarios o aplicaciones al endpoint de VPC y los recursos que admite, usted puede usar una política de recursos de AWS Identity and Access Management (AWS IAM). Esto asegurará por separado el endpoint de la VPC y los recursos a los cuales se pueden acceder.

Seleccionando endpoints de VPC de tipo gateway o de tipo interfaz

Con ambos tipos de endpoints disponibles para Amazon S3, hay algunos factores a considerar al elegir una estrategia sobre la otra.

• Costo: Los endpoints de tipo gateway para S3 se ofrecen sin costo alguno y las rutas se administran a través de tablas de rutas. Los endpoints de tipo interfaz tienen un precio de $0.01/por Zona de Disponibilidad (AZ)/por hora. El costo depende de la Región, consulte los precios actuales. Los datos transferidos a través del endpoint de tipo interfaz se cobran a $0.01/por GB (dependiendo de la región).
• Patrón de acceso: El acceso a S3 a través de endpoints de tipo gateway solo se admiten para los recursos de la VPC específica a la que está asociado dicho endpoint. Los endpoints de tipo gateway para S3 actualmente no admiten el acceso desde recursos en una región diferente, una VPC diferente o desde un centro de datos local (no AWS). Sin embargo, si está dispuesto a administrar una arquitectura personalizada compleja, puede usar proxies. En todos esos escenarios, donde el acceso es desde recursos externos a la VPC, los endpoints de tipo interfaz para S3 permiten acceder a S3 de una manera segura.
• Arquitectura de endpoint de VPC: Algunos clientes utilizan patrones de arquitectura de endpoint de VPC centralizados. Aquí es donde se administran todos los endpoints de tipo interfaz en una VPC concentradora central  para acceder al servicio desde varias VPCs radiales (spoke VPCs). Esta arquitectura ayuda a reducir la complejidad y el mantenimiento de múltiples endpoints de VPC de tipo interfaz en diferentes VPCs. Al utilizar un endpoint de tipo interfaz para S3, debe tener en cuenta la cantidad de tráfico de red que fluiría a través de la red desde las VPCs radiales hasta la VPC concentradora (hub VPC). Si la conectividad de red entre las VPCs radiales y la VPC concentradora se configura mediante un AWS Transit Gateway o VPC peering, considere los cargos de procesamiento de datos (actualmente $0.02/GB). Si se utiliza VPC peering, no hay cargos por los datos transferidos entre VPCs que se encuentran en la misma zona de disponibilidad. Sin embargo, los datos transferidos entre Zonas de Disponibilidad o entre Regiones incurrirán en cargos según se define en nuestra documentación.

En escenarios en los que debe acceder a buckets de S3 de forma segura desde el centro de datos local o desde otras Regiones, se recomienda utilizar un endpoint de tipo interfaz. Si elige un endpoint de tipo gateway, instale una flota de proxies en la VPC para llevar a cabo el enrutamiento transitivo.

Figura 1. Arquitectura de endpoint de VPC

• Consideraciones de ancho de banda: Al configurar un endpoint de tipo interfaz, elija varias subredes en varias Zonas de Disponibilidad para implementar alta disponibilidad. El número de ENIs debe ser igual al número de subredes elegidas. Los endpoints de tipo interfaz ofrecen un rendimiento de 10 Gbps por ENI con una capacidad de ráfaga de 40 Gbps. Si su caso de uso requiere un mayor rendimiento, póngase en contacto con el equipo de Soporte de AWS.

Los endpoints de tipo gateway son entradas en la tabla de rutas que enrutan su tráfico directamente desde la subred donde se origina el tráfico hacia el servicio S3. El tráfico no fluye a través de un dispositivo o instancia intermedia. Por lo tanto, no hay límite de rendimiento para el endpoint de tipo gateway. La configuración inicial para los endpoints de tipo gateway consiste en especificar las tablas de rutas de la VPC que desea utilizar para acceder al servicio. Las entradas de la tabla de rutas para el destino (lista de prefijos) y el destino (ID del endpoint) se agregan automáticamente a las tablas de ruta.

Las dos opciones arquitectónicas para crear y administrar endpoints son:

Arquitectura de una sola VPC

Usando una única VPC, podemos configurar:

• Endpoints de tipo gateway para que recursos los de la VPC accedan a S3.
• Endpoints de tipo interfaz para que los recursos del centro de datos local accedan a S3.

La siguiente arquitectura muestra la configuración de cómo se pueden configurar ambos tipos de endpoint en una única VPC para el acceso. Esto es útil cuando el acceso desde AWS se limita a una sola VPC mientras se habilita el acceso externo (no AWS).

Figura 2. Arquitectura de una sola VPC

El DNS configurado en el centro de datos local apuntará a las direcciones IP del endpoint de tipo interfaz de la VPC. Este reenviará todo el tráfico desde el centro de datos a S3 a través del endpoint de tipo interfaz de la VPC. La tabla de rutas configurada en la subred garantizará que cualquier tráfico de S3 que se origina en la VPC fluya a S3 mediante endpoints de tipo gateway.

Arquitectura centralizada multi-VPC

En una arquitectura del tipo hub and spoke que centraliza el acceso S3 para cargas de trabajo multi-región, a través de diferentes VPCs y para las cargas de trabajo alojadas en el centro de datos local, recomendamos usar un endpoint de tipo interfaz en la VPC concentradora (hub). El mismo patrón también funcionaría en el diseño multicuenta/región donde múltiples VPC requieren acceso a buckets centralizados.

Tenga en cuenta que al usar una combinación de AWS Transit Gateway y Endpoints de VPC para enrutar el tráfico al servicio destino, se pueden incurrir en cargos acumulados de procesamiento de entrada y salida para AWS Transit Gateway y Endpoint de VPC. Se debe tener cuidado para entender esta implicación de costos. Consulte los precios de AWS PrivateLink y los precios de AWS Transit Gateway.

Adicionalmente, los dispositivos de firewall que monitorean el tráfico este-oeste experimentarán una mayor carga con la arquitectura centralizada Multi-VPC. Puede ser necesario utilizar el diseño de endpoint de VPC única para reducir el impacto en los dispositivos de firewall.

Figure 3. Multi-VPC centralized architecture

Conclusion

Based on preceding considerations, you can choose to use a combination of gateway and interface endpoints to meet your specific needs. Depending on the account structure and VPC setup, you can support both types of VPC endpoints in a single VPC by using a shared VPC architecture.

With AWS, you can choose between two VPC endpoint types (gateway endpoint or interface endpoint) to securely access your S3 buckets using a private network. In this blog, we showed you how to select the right VPC endpoint using criteria like VPC architecture, access pattern, and cost. To learn more about VPC endpoints and improve the security of your architecture, read Securely Access Services Over AWS PrivateLink.

Este artículo fue traducido del Blog de AWS en Inglés

Acerca de los autores

Jeff Harman es Arquitecto Sénior de Soluciones en AWS con sede en Boston. Le apasiona diseñar e implementar plataformas escalables y modernas en la nube, para servicios financieros. Trabajó en servicios financieros durante 20 años antes de unirse a AWS.

Gilles-Kuessan Satchivi es un Arquitecto de Soluciones Empresariales de AWS con experiencia en redes, infraestructura, seguridad y operaciones de TI. Le apasiona ayudar a los clientes a construir sistemas bien diseñados en AWS. Antes de unirse a AWS, trabajó en comercio electrónico durante 17 años. Fuera del trabajo, le gusta pasar tiempo con su familia, y animar a su equipo infantil de futbol.

Traductor

José Peñúñuri es Arquitecto de Soluciones en AWS especialista en temas de migración. José se enfoca en apoyar a clientes de diferentes industrias en la adopción de herramientas y servicios que los ayudan a acelerar su migración a la nube.