Por qué los endpoints de API de AWS difieren por región - Diseño de servicios globales y regionales
Explicamos las razones de diseño por las que existen endpoints regionales como ec2.us-east-1.amazonaws.com y endpoints globales como iam.amazonaws.com, así como los endpoints dual-stack y FIPS.
La intención de diseño de los endpoints regionales
La mayoría de los servicios de AWS tienen endpoints de API independientes por región. Para EC2, por ejemplo, el código de región se incluye en la URL como ec2.us-east-1.amazonaws.com o ec2.ap-northeast-1.amazonaws.com. Este diseño tiene dos intenciones. La primera es el aislamiento de fallos. Dado que los endpoints de cada región operan en infraestructura independiente, si la API de EC2 en us-east-1 sufre una interrupción, la API de EC2 en ap-northeast-1 no se ve afectada. Si todas las regiones compartieran un único endpoint global, un fallo en ese endpoint se propagaría a todas las regiones. La segunda es la localidad de datos. Las solicitudes de API se procesan en el plano de control de esa región, por lo que no necesitan cruzar continentes. Cuando se llama a la API de EC2 de la región de Tokio, la solicitud se procesa en el plano de control de Tokio, minimizando la latencia. El SDK envía las solicitudes al endpoint de la región configurada por defecto, por lo que los desarrolladores rara vez necesitan ser conscientes de la URL del endpoint.
El diseño especial de los servicios globales
Los endpoints globales de IAM, Route 53, CloudFront, WAF (para CloudFront) y el endpoint global de STS utilizan URLs sin código de región (iam.amazonaws.com, route53.amazonaws.com). La razón por la que estos servicios son globales es que, por su naturaleza, gestionan recursos que no están vinculados a una región. Los usuarios y roles de IAM se aplican a toda la cuenta de AWS y no pertenecen a una región específica. Las zonas alojadas de Route 53 también son recursos globales. Sin embargo, el plano de control de los servicios globales opera físicamente en alguna región. El plano de control de IAM está concentrado en us-east-1, y durante la interrupción de us-east-1 en 2021, las operaciones de gestión de IAM se vieron afectadas. STS es una excepción interesante. STS tiene tanto un endpoint global (sts.amazonaws.com) como endpoints regionales (sts.ap-northeast-1.amazonaws.com). AWS recomienda usar los endpoints regionales de STS. Esto se debe a que el endpoint global se procesa en us-east-1, por lo que durante una interrupción de us-east-1, las llamadas a STS desde otras regiones también se ven afectadas.
La complejidad de los endpoints de S3
Los endpoints de S3 son los más complejos entre los servicios de AWS. Existen dos formatos de URL: estilo de ruta (s3.amazonaws.com/bucket-name/key) y estilo de host virtual (bucket-name.s3.amazonaws.com/key). AWS recomienda el estilo de host virtual desde 2020, y los SDK más recientes lo usan por defecto. Además, S3 tiene endpoints regionales (s3.ap-northeast-1.amazonaws.com) y un endpoint global legacy (s3.amazonaws.com). El endpoint global legacy redirige a us-east-1, por lo que al acceder a buckets en otras regiones se produce una redirección 307, añadiendo latencia adicional. Al habilitar S3 Transfer Acceleration, se utiliza otro endpoint diferente (bucket-name.s3-accelerate.amazonaws.com). Este endpoint transfiere datos a través de las ubicaciones de borde de CloudFront, mejorando la velocidad de carga a larga distancia. El endpoint dual-stack de S3 (s3.dualstack.region.amazonaws.com) soporta tanto IPv4 como IPv6.
Endpoints FIPS - Requisitos de cifrado para el gobierno de EE.UU.
AWS proporciona endpoints compatibles con FIPS (Federal Information Processing Standards) 140-2 para muchos servicios. Los endpoints FIPS utilizan módulos criptográficos certificados FIPS 140-2 para la comunicación TLS. La URL tiene el formato del endpoint normal con fips añadido (por ejemplo: ec2-fips.us-east-1.amazonaws.com, s3-fips.us-east-1.amazonaws.com). Los endpoints FIPS son necesarios principalmente para las agencias del gobierno federal de EE.UU. y sus contratistas. Regulaciones como FedRAMP y FISMA exigen cifrado compatible con FIPS 140-2 para las comunicaciones de datos gubernamentales. Las empresas privadas que tienen contratos con el gobierno también pueden necesitar usar endpoints FIPS. No hay diferencia funcional entre los endpoints FIPS y los normales. La única diferencia son las suites de cifrado utilizadas en el handshake TLS. En los endpoints FIPS, los algoritmos criptográficos no aprobados por FIPS 140-2 (como ChaCha20) están deshabilitados. El impacto en el rendimiento es prácticamente nulo.
VPC Endpoints - Acceso a APIs sin pasar por internet público
Normalmente, cuando una instancia EC2 llama a una API de AWS, la solicitud sale a internet público a través de un Internet Gateway o NAT Gateway para llegar al endpoint de la API de AWS. Con VPC Endpoints (PrivateLink), la solicitud se completa dentro de la red privada de AWS sin pasar por internet público. Existen dos tipos de VPC Endpoints. Los Gateway Endpoints son exclusivos para S3 y DynamoDB, y funcionan añadiendo entradas a la tabla de rutas. No tienen costo adicional. Los Interface Endpoints (PrivateLink) crean una ENI (Elastic Network Interface) dentro de la VPC y acceden a la API mediante una dirección IP privada. Tienen un costo de 0.01 USD por hora más cargos por procesamiento de datos. La ventaja de seguridad de los VPC Endpoints es que las solicitudes de API no se exponen a internet público. En entornos como instituciones financieras o sanitarias donde es necesario gestionar estrictamente la ruta de los datos, los VPC Endpoints son imprescindibles. Además, ofrecen el beneficio de reducir los cargos por procesamiento de datos del NAT Gateway (0.045 USD/GB). Para aprender sistemáticamente sobre el diseño de endpoints de AWS, libros especializados (Amazon) son una buena referencia.