Este artículo aborda API Gateways con APIs públicas definidas con un tipo de endpoint Regional.
TL;DR — Implementación paso a paso
Las APIs son fundamentales para la comunicación entre servicios en las arquitecturas cloud actuales. Amazon Web Services (AWS) ofrece un potente servicio de API Gateway que permite a los desarrolladores crear, publicar, mantener y proteger APIs a cualquier escala.
Un escenario típico son los servicios dentro de una VPC que necesitan acceder tanto a APIs públicas como privadas. Las APIs públicas tienen dos formatos de URL:
1. La URL predeterminada que genera el servicio API Gateway: api-id.execute-api.REGION.amazonaws.com
2. Un nombre de dominio personalizado (por ejemplo, api.mydomain.com) que te permite usar tu propio dominio y certificado.
Primero describiré y resolveré el problema del nombre de dominio personalizado, y después explicaré cómo trabajar con la URL generada por API Gateway.
El problema surge cuando alojas tu nombre de dominio personalizado fuera de Route 53 y usas un registro CNAME.
El objetivo de este artículo es ofrecer un acceso fluido a APIs privadas y públicas desde la VPC, garantizando una comunicación entre servicios eficiente y segura.
Usar APIs públicas y privadas desde la misma VPC no supone ningún problema si tus dominios personalizados públicos están alojados en Route 53 y usan registros Alias para apuntar al nombre de dominio de API Gateway.
Como veremos a continuación, se requieren pasos adicionales para asegurar la correcta resolución DNS y la validación del certificado SSL cuando se usan proveedores DNS externos (que nos obligan a usar registros CNAME).
Terminología
Nombre de dominio de API Gateway
El nombre de dominio de API Gateway es un endpoint gestionado por AWS que se crea al configurar el dominio personalizado de tu API. Funciona como un alias del endpoint predeterminado de tu API apiID.execute-api.REGION.amazonaws.com, y habilita la terminación TLS y URLs amigables.
Así funciona:
1. Estructura del nombre de dominio de API Gateway según los dos tipos de endpoints públicos
- Edge-Optimized:
Usa una distribución de CloudFront (por ejemplo, d123.cloudfront.net) para acceso global de baja latencia.
- Regional:
Usa un endpoint específico de la región (por ejemplo, d-abc123.execute-api.us-east-1.amazonaws.com).
2. Configuración del DNS
- Tu proveedor DNS (por ejemplo, GoDaddy):
Creas un registro CNAME que apunta tu dominio personalizado (api.mydomain.com) al nombre de dominio de API Gateway (por ejemplo, d-abc123.execute-api.us-east-1.amazonaws.com).
- Ejemplo de registro DNS en GoDaddy:
Nombre: api.mydomain.com
Tipo: CNAME
Valor: d-abc123.execute-api.us-east-1.amazonaws.com
- Este registro se asegura de que el tráfico hacia
api.mydomain.comse enrute al endpoint de API Gateway.
3. Asociación del certificado
- Certificado de AWS Certificate Manager (ACM):
Cuando defines un dominio personalizado en API Gateway, lo vinculas con un certificado ACM (por ejemplo, *.mydomain.com).
- El Subject Alternative Name (SAN) del certificado debe incluir tu dominio personalizado (por ejemplo,
api.mydomain.com, o el comodín de nivel superior*.mydomain.com). - API Gateway usa este certificado para la terminación TLS en su capa edge.
4. Cómo se integra todo: el flujo de la solicitud
- Un cliente solicita https://api.mydomain.com.
- El DNS resuelve al nombre de dominio de API Gateway (por ejemplo,
d-abc123.execute-api.us-east-1.amazonaws.com). - El DNS de AWS resuelve el nombre de dominio de API Gateway a las IPs públicas del servicio AWS Gateway, que se encarga de la terminación TLS (con tu certificado ACM) y del balanceo de carga del tráfico.
- El servicio API Gateway invoca la API y el Stage al que mapeaste tu dominio personalizado.
El problema
El núcleo del problema está en el VPC Endpoint de API Gateway que se necesita para acceder a APIs privadas. Cuando este VPC Endpoint tiene Private DNS habilitado, surgen complicaciones al acceder a APIs públicas. En concreto, las llamadas a APIs públicas pueden fallar por problemas con el certificado SSL. Para entenderlo, hay que comprender cómo se resuelve el DNS dentro de esta arquitectura (ver Apéndice A).
Una API pública sin dominio personalizado solo tiene una URL de endpoint público a la que cualquiera puede acceder desde Internet.
Como las APIs públicas solo se pueden invocar desde Internet, llamar a esta URL desde una VPC con un VPC Endpoint de API Gateway que tenga Private DNS habilitado intentará invocar la API desde la VPC y no desde Internet, y devolverá un error HTTP 403 (forbidden).
Las APIs públicas requieren un certificado cuando se mapean a un dominio personalizado.
Cuando creas un registro de tipo Alias A en Route 53 para invocar tu API pública mediante tu dominio personalizado, puedes llamar tanto a APIs privadas como públicas desde tu VPC, incluso con un VPC Endpoint de API Gateway con Private DNS configurado.
Si alojas tu dominio en un proveedor externo, puedes crear un registro CNAME en el DNS externo.
Ese registro CNAME es el origen del problema.
Cuando llamas a una API pública con un dominio personalizado, se realiza una búsqueda DNS para encontrar el registro que lo mapea al nombre de dominio de API Gateway. Esto, a su vez, requiere una segunda búsqueda DNS para obtener la dirección IP del nombre de dominio de API Gateway devuelto en la primera búsqueda.
Sin Private DNS habilitado, la búsqueda devolverá la IP pública de tu API pública, que es lo que queremos.
Esa IP pública pertenece al servicio AWS Gateway, que buscará tu dominio personalizado en un Subject Alternative Name (SAN) del certificado asociado a dicho dominio. Como el certificado de tu dominio personalizado (por ejemplo, mydomain.com) se asoció al nombre de dominio de API Gateway, el handshake SSL se completará con éxito y se invocará tu API pública.
Cuando una VPC tiene un VPC Endpoint de API Gateway con Private DNS habilitado, este Private DNS interceptará la búsqueda del nombre de dominio de API Gateway (porque captura todos los subdominios de execute-api.REGION.amazonaws.com) y devolverá la IP privada asignada a la Elastic Network Interface (ENI) del VPC Endpoint.
Esa IP privada representa la dirección del servicio API Gateway, que solo aceptará endpoints de URL internas que pertenezcan a la URL del endpoint de la API privada, con el formato apiID.execute-api.REGION.amazonaws.com.
El resultado se ve algo así:

Resultado de llamar a una API pública cuando hay un VPC Endpoint de API Gateway con Private DNS habilitado
Como consecuencia, cualquier intento de invocar la API pública desde la VPC provocará un fallo en el handshake SSL y bloqueará la conexión.
Resumen de la solución
Como acabamos de explicar, cuando un VPC Endpoint de API Gateway tiene Private DNS habilitado, todas las búsquedas DNS de execute-api.REGION.amazonaws.com resuelven a IPs privadas, lo que hace que las llamadas a APIs públicas (con dominios personalizados) fallen en la validación SSL. La solución consiste en priorizar el DNS mediante zonas hospedadas privadas de Route 53, técnica también conocida como DNS Split-Horizon / Split-View.
La idea es que, al usar una zona hospedada privada (PHZ), las búsquedas DNS desde la VPC consultarán primero la PHZ antes de acudir a cualquier otro servidor DNS público.
Supongamos que tenemos un servidor DNS de GoDaddy que aloja nuestro dominio en el nivel superior: mydomain.com.
Si mapeamos api.mydomain.com a nuestra API pública, alojaremos este subdominio en nuestra PHZ DNS para crear el split-view DNS.
Así, las búsquedas de api.mydomain.com que se originan en nuestra VPC se resuelven desde nuestra PHZ, mientras que las llamadas a otros subdominios que no usan API Gateway (por ejemplo, los que apuntan a otro servicio que el VPC Endpoint no captura) seguirán usando el DNS público.
Esta solución se basa en tres conceptos clave:
- VPC Endpoint: para el acceso a APIs privadas (con Private DNS habilitado)
- Zona hospedada privada: para crear el split-view DNS
- Un registro de tipo Alias A en la PHZ: para dirigir el tráfico al nombre de dominio público de API Gateway
Implementación paso a paso
Requisitos previos
- Una API Gateway pública con un dominio personalizado alojado fuera de Route 53 que se pueda invocar desde Internet, o un dominio personalizado público alojado en Route 53 pero que use un registro CNAME en lugar de un registro de tipo Alias A para apuntar a él.
- Un VPC Endpoint de API Gateway con Private DNS habilitado, definido en la VPC desde la que queremos llamar a nuestra API pública.
Si ya tienes este VPC Endpoint, comienza desde el paso 2.
Sin él, no podrás llamar a APIs privadas.
1. Configurar el VPC Endpoint para que API Gateway acceda a APIs privadas
Si ya tienes este endpoint, salta al paso "2".
- En la consola de AWS, navega a VPC Console > Endpoints.
- Crea un endpoint de interfaz para
com.amazonaws.REGION.execute-api. - Habilita Private DNS (configuración predeterminada).
- Asocia un security group que permita HTTPS entrante (puerto 443) desde la VPC (o desde las IPs de los recursos específicos dentro de tu VPC a los que quieras dar permiso para llamar a APIs privadas de API Gateway).
2. Crear una zona hospedada privada
- Crea una PHZ en la consola de Route 53 que coincida con la ruta de la API de tu dominio personalizado público (por ejemplo,
api.mydomain.com).
Ten en cuenta que si tienes URLs en tu dominio público que quieres llamar pero que no están mapeadas a una API Gateway (por ejemplo, si dev.mydomain.com apunta a un Load Balancer y no a API Gateway), debes usar el dominio personalizado completo de tu API (como api.mydomain.com) para el nombre de dominio de tu zona hospedada privada.
Si todos los subdominios de tu dominio están mapeados a APIs de API Gateway, usa el nivel superior mydomain.com como nombre de dominio.
- Asocia la zona con tu VPC.

Crea una PHZ para tu dominio personalizado y asóciala con la VPC que necesita acceso a este dominio
3. Configurar registros DNS
- Necesitas crear un Alias de tipo A para cada dominio que use una API.
Por ejemplo, si tienes api.mydomain.com y special-api.mydomain.com, debes crear un registro para cada uno: uno para api y otro para special-api. Por lo tanto, elige el tipo de registro "A".
- Para el nombre del registro:
- Si el nombre de tu dominio personalizado coincide con el dominio completo de tu API, no escribas el subdominio (no escribas "api") en el campo "Record Name" (déjalo vacío). Por ejemplo, si creaste la PHZ para api.mydomain.com porque es el único subdominio que usa API Gateway, deja el campo Record Name vacío.
- Si estás usando el nivel superior — mydomain.com, porque tienes varios subdominios mapeados a API Gateway, ingresa el nombre de tu API como valor del "Record Name" en cada registro. Por ejemplo, ingresa "api" en un registro y "special-api" en otro.
- Configúralo como registro Alias marcando la casilla 'alias'.
- Elige "Alias to API Gateway API".
- Selecciona la región de tu API.
- Selecciona el endpoint regional (el nombre de dominio de API Gateway creado para tu dominio personalizado) de tu API pública.
Tiene un nombre como:
d-abc123.execute-api.REGION.amazonaws.com
- Si no aparece allí, cópialo desde la consola de API Gateway, en "custom domain names" -> API Gateway domain name.
- Guarda el registro.

Es posible que Route 53 tarde un poco en hacer disponible tu zona hospedada privada recién creada para tu VPC.
Consulta el Apéndice B para ver la arquitectura de esta solución.
Pruebas
Necesitarás una EC2 corriendo en tu VPC con conexión a Internet para las APIs públicas.
Conéctate a tu instancia EC2 y, tras reemplazar la URL de abajo por la tuya, ejecuta:
curl -v https://your-public-api.yourdomain.com/your-path
Deberías obtener un resultado similar a este:

Observa que antes de crear y configurar la PHZ, la IP que devolvía el Private DNS (el asociado al VPC Endpoint de API Gateway) era una IP privada para el dominio personalizado (10.0.3.79), y esa IP privada pertenece a la ENI del VPC Endpoint. Con una PHZ para el dominio personalizado, ahora obtenemos las IPs públicas del nombre de dominio de API Gateway, que (en este ejemplo) son:
IPv4: 44.221.197.141, 34.192.177.183, 34.232.190.93
Trabajar con las URLs públicas predeterminadas de API Gateway
Para trabajar con APIs privadas y públicas, deshabilita el Private DNS asociado a tu VPC Endpoint de API Gateway. Después, crea una PHZ llamada execute-api.REGION.amazonaws.com y asóciala con todas las VPCs a las que quieras dar acceso a la VPC que aloja tus APIs privadas. (Nota: asociarla con una VPC en otra región se relaciona con la sección "Bonus" de este artículo).
Crea un registro comodín para capturar todos los API-IDs de API Gateway, así:

Crea la zona hospedada para APIs privadas en esta región
Ahora crearás un registro "catch-all" que apuntará al DNS del VPC Endpoint, así:

Crea un registro catch-all para todas las APIs privadas en esta región
Con esto, todas las URLs de una API Gateway privada definida en us-east-1 serán capturadas por esta PHZ y devolverán la dirección IP privada del VPC Endpoint de API Gateway.
Para APIs públicas con dominio personalizado, ya vimos cómo crear una PHZ para ese dominio resuelve el problema.
Para APIs públicas sin dominio personalizado, hay que añadir un registro Alias usando el ID de la API y apuntándolo a la URL pública.
Por ejemplo, supongamos que tenemos una API pública en us-east-1 cuya URL es: bmf11pk5je.execute-api.us-east-1.amazonaws.com
Si la llamamos desde la VPC, devolverá "Forbidden (403)", como se explicó antes para el caso del dominio personalizado. Para resolverlo, agregamos un registro llamado "bmf11pk5je" y lo apuntamos a la URL de invocación así:

Ahora podremos llamar a la API pública definida en este registro desde la VPC. Cada API pública adicional que queramos llamar en esta región requerirá un registro Alias propio, igual que el que acabamos de crear.
Bonus
Llamar a una API privada ubicada en una región desde una VPC en otra región de AWS.
El problema
Las APIs privadas se pueden compartir fácilmente entre varias VPCs dentro de la misma región. Solo necesitas tener VPC Endpoints de API Gateway en cada VPC, una resource policy para tu API privada que permita el acceso desde estas VPCs, y agregar los VPC Endpoints a la API privada (desde su API Settings).
Esto no funciona si tu VPC está en una región distinta a la que aloja la API privada.
En ese caso, debes hacer lo siguiente:
- Establecer un peering entre las dos VPCs: la que aloja la API privada y aquella a la que quieres dar acceso.
Para el peering de VPC, debes asegurarte de que ambas VPCs no tengan bloques CIDR superpuestos. 2. Si no tienes una zona hospedada privada para la región de API Gateway que aloja tu API privada, debes crearla. 3. El nombre de la zona hospedada privada (PHZ) debe ser:
execute-api.REGION.amazonaws.com
4. Necesitas asociar esta PHZ con el VPC Endpoint de API Gateway en la región y con la VPC a la que quieres dar acceso.
5. Agrega un registro Alias de tipo A a la PHZ (configúralo como alias marcando la casilla 'alias') y luego selecciona "Alias to VPC Endpoint" en el desplegable.
6. Selecciona la región de la VPC a la que quieres dar acceso.
7. Elige el VPC Endpoint para API Gateway en esta VPC.
8. Agrega el bloque CIDR de la VPC peered al Security Group del VPC Endpoint. Sin esto, se bloqueará la comunicación desde la VPC peered.
9. Guarda el registro.
Una vez completados los pasos anteriores, podrás invocar la API privada desde la VPC en la otra región.
Ten en cuenta que, al usar VPC Peering, la Resource Policy de tu API Gateway privada no necesita aprobar tráfico desde la VPC peered; solo necesita aprobarlo desde la VPC principal en la que está desplegada. Esto es así porque la comunicación con la API Gateway llegará desde el VPC Endpoint dentro de su propia VPC, aunque se haya originado en la VPC peered.
Este peering entre regiones provocará el mismo problema de fallo de certificación SSL si intentas acceder a una API pública definida en la misma VPC que la API privada. Aunque esté en otra región, sigue estando asociada a una PHZ para execute-api.REGION (la REGION donde está desplegada la API) y, por lo tanto, intentará llamar a la IP privada del VPC Endpoint a menos que se defina una PHZ para tu API pública.
Si quieres llamar tanto a APIs privadas como públicas, ya sea entre regiones o no, debes seguir las instrucciones de la primera parte de este artículo.
Apéndice A
El siguiente diagrama muestra qué ocurre cuando una instancia EC2 llama a una API Gateway pública con un VPC Endpoint de API Gateway con Private DNS habilitado.

Llamar a una API pública desde una VPC sin una PHZ configurada
- EC2 intenta llamar a
https://api.mydomain.com, por lo que se realiza una búsqueda DNS. - La respuesta del DNS es el nombre de dominio de API Gateway.
- Se realiza la segunda búsqueda DNS, que es capturada por el Private DNS asociado al VPC Endpoint de API Gateway.
- Devuelve la dirección IP privada del VPC Endpoint.
- EC2 intenta invocar la API a través de la dirección IP privada.
- El servicio API Gateway, accesible mediante la IP privada, presenta un certificado válido para
*.execute-api.REGION.amazonaws.com, no paraapi.mydomain.com, por lo que se devuelve un error de certificado.
Apéndice B
El siguiente diagrama muestra qué ocurre cuando una instancia EC2 llama a una API Gateway pública con un VPC Endpoint de API Gateway con Private DNS habilitado. En esta ocasión, también hay una zona hospedada privada definida para el dominio personalizado.

Llamar a APIs públicas desde una VPC con una PHZ configurada
Llamar a la API pública desde Internet
- Se realiza una búsqueda DNS al servicio externo de hosting de dominio (por ejemplo, GoDaddy) para el dominio personalizado de la API (por ejemplo,
api.mydomain.com). - La consulta devuelve el nombre de dominio de API Gateway asociado a este dominio personalizado.
- El nombre de dominio de API Gateway se consulta en Route 53 de AWS.
- Devuelve una dirección IP pública para el servicio público de API Gateway.
- La IP pública se usa para llamar al servicio API Gateway, y como está asociada a los certificados de
api.mydomain.com, termina el SSL e invoca el destino correspondiente del stage de la API Gateway.
Llamar a una API privada desde la VPC
6. Las APIs privadas tienen una URL con el formato apiID.execute-api.REGION.amazonaws.com. Cuando se llama a una URL así desde una VPC con un VPC Endpoint para API Gateway que tiene Private DNS activo, la solicitud es gestionada por este Private DNS.
7. El Private DNS devuelve la IP privada de la ENI del VPC Endpoint de API Gateway.
8. El servicio API Gateway, accesible mediante esta IP privada, tiene un certificado para *.execute-api.REGION.amazonaws.com, así que la llamada a la API privada que usó esta URL se autentica y se reenvía al destino de la API privada.
Llamar a una API pública de API Gateway desde la VPC
9. La zona hospedada privada DNS creada para el dominio personalizado captura y gestiona las consultas que caen bajo su nombre de dominio.
10. La PHZ, al tener un registro de tipo Alias A, devuelve la IP pública del nombre de dominio de API Gateway asociado al dominio personalizado.
11. La IP pública se llama mediante el Internet Gateway, alcanzando la dirección del servicio de API Gateway. Como el servicio accesible desde la IP pública sí cuenta con la asociación de certificado entre el dominio personalizado y el nombre de dominio de la API, el handshake SSL se completa y el TLS termina. La solicitud se reenvía al destino del stage correspondiente de la API pública de API Gateway.
Llamada a la acción
Espero que este artículo te haya resultado útil. Si quieres saber más o te interesan nuestros servicios, no dudes en escribirnos. Puedes contactarnos aquí.
Referencias
- API Gateway Custom Domain Names
- API endpoint types for REST APIs in API Gateway
- Working with private hosted zones
- AWS Route 53 Split View DNS
- Choosing between alias and non-alias records
Incluye una buena explicación de los registros alias en Route 53.
La solución más sencilla es alojar tu dominio personalizado público en Route 53 y usar un registro de tipo Alias A. Así podrás llamar a APIs públicas y privadas con un VPC Endpoint de API Gateway con Private DNS.
Si no puedes o no quieres hacerlo, puedes usar el método descrito en este artículo.
Algunos puntos a tener en cuenta
- Tener un VPC Endpoint de API Gateway con Private DNS hará que todas las llamadas a cualquier API pública de API Gateway en esa región fallen con el error de incompatibilidad de certificación. El hecho de que solo haya hablado de
api.mydomain.comes arbitrario. Si tienes (por ejemplo)api.mydomain.com,api.example.comymyapi.myspecialdomain.com, todos necesitarán su propia PHZ, ya que no existe relación entre un dominio y los demás. - Aunque hablo de una API REST, esto también funciona con APIs HTTP (probado) y APIs WebSocket (sin probar), porque no se trata del protocolo, sino de la red y el DNS.