Este artigo trata de API Gateways com APIs públicas definidas com o tipo de endpoint Regional API.
TL;DR — Implementação passo a passo
As APIs são fundamentais para viabilizar a comunicação entre serviços nas arquiteturas cloud-native de hoje. A Amazon Web Services (AWS) oferece um serviço robusto de API Gateway, que permite aos desenvolvedores criar, publicar, manter e proteger APIs em qualquer escala.
Um cenário comum envolve serviços dentro de uma VPC que precisam acessar APIs públicas e privadas. As APIs públicas têm dois formatos de URL:
1. A URL padrão gerada pelo serviço API Gateway: api-id.execute-api.REGION.amazonaws.com
2. Um nome de domínio personalizado (por exemplo, api.mydomain.com) que permite usar um nome de domínio amigável e seu próprio certificado.
Vou primeiro descrever e resolver o problema com nome de domínio personalizado e, depois, explicar como lidar com a URL gerada pelo API Gateway.
O problema está em hospedar seu nome de domínio personalizado fora do Route 53 e usar um registro CNAME.
O objetivo deste artigo é proporcionar acesso fluido a APIs privadas e públicas dentro da VPC, garantindo uma comunicação eficiente e segura entre os serviços.
Usar APIs públicas e privadas a partir da mesma VPC não é problema se seus nomes de domínio personalizados públicos estiverem hospedados no Route 53 e usarem registros Alias apontando para o API Gateway Domain Name.
Como veremos a seguir, são necessárias etapas adicionais para garantir a resolução correta de DNS e a validação do certificado SSL ao usar provedores de DNS externos (que nos obrigam a usar registros CNAME).
Terminologia
API Gateway Domain Name
O API Gateway Domain Name é um endpoint gerenciado pela AWS, criado quando você configura o nome de domínio personalizado da sua API. Ele funciona como um alias para o endpoint padrão da API apiID.execute-api.REGION.amazonaws.com, viabilizando a terminação TLS e URLs mais amigáveis.
Veja como funciona:
1. Estrutura do API Gateway Domain Name para os dois tipos de endpoints de API públicos
- Edge-Optimized:
Usa uma distribuição CloudFront (por exemplo, d123.cloudfront.net) para acesso global de baixa latência.
- Regional:
Usa um endpoint específico da região (por exemplo, d-abc123.execute-api.us-east-1.amazonaws.com).
2. Configuração de DNS
- Seu provedor de DNS (por exemplo, GoDaddy):
Você cria um registro CNAME apontando seu nome de domínio personalizado (api.mydomain.com) para o API Gateway domain name (por exemplo, d-abc123.execute-api.us-east-1.amazonaws.com).
- Exemplo de registro DNS no GoDaddy:
Nome: api.mydomain.com
Tipo: CNAME
Valor: d-abc123.execute-api.us-east-1.amazonaws.com
- Esse registro garante que o tráfego para
api.mydomain.comseja roteado para o endpoint do API Gateway.
3. Associação de certificado
- Certificado do AWS Certificate Manager (ACM):
Quando você define um nome de domínio personalizado no API Gateway, ele é vinculado a um certificado ACM (por exemplo, *.mydomain.com).
- O Subject Alternative Name (SAN) do certificado precisa incluir seu nome de domínio personalizado (por exemplo,
api.mydomain.com, ou o wildcard de nível superior*.mydomain.com). - O API Gateway usa esse certificado para a terminação TLS na sua camada de borda.
4. Como tudo se encaixa — o fluxo da requisição
- Um cliente faz uma requisição para https://api.mydomain.com.
- O DNS resolve para o API Gateway domain name (por exemplo,
d-abc123.execute-api.us-east-1.amazonaws.com). - O DNS da AWS resolve o API Gateway domain name para os IPs públicos do serviço AWS Gateway, que faz a terminação TLS (usando seu certificado ACM) e o balanceamento de carga do tráfego.
- O serviço API Gateway invoca a API e o Stage que você mapeou para o seu nome de domínio personalizado.
O problema
O cerne da questão está no VPC Endpoint do API Gateway, necessário para acessar APIs privadas. Quando esse VPC Endpoint tem o Private DNS habilitado, podem surgir complicações no acesso a APIs públicas. Mais especificamente, chamadas a APIs públicas podem falhar por problemas de certificado SSL. Para entender isso, é preciso compreender como a resolução de DNS funciona nessa configuração arquitetural (veja o Apêndice A).
Uma API pública sem nome de domínio personalizado tem apenas uma URL de endpoint público, acessível por qualquer pessoa na Internet.
Como APIs públicas só podem ser invocadas pela Internet, chamar essa URL de dentro de uma VPC com um VPC Endpoint do API Gateway com Private DNS habilitado fará com que a API seja invocada pela VPC, e não pela Internet, retornando um erro HTTP 403 (forbidden).
APIs públicas exigem um certificado quando mapeadas a um nome de domínio personalizado.
Quando você cria um registro do tipo Alias A no Route 53 para invocar sua API pública pelo nome de domínio personalizado, é possível chamar APIs privadas e públicas de dentro da VPC mesmo com um VPC Endpoint do API Gateway com Private DNS configurado.
Se seu domínio estiver hospedado em um provedor externo, você pode criar um registro CNAME no DNS externo.
Esse registro CNAME é a origem do problema.
Quando você chama uma API pública com nome de domínio personalizado, é gerado um lookup de DNS para encontrar o registro que faz o mapeamento para o API Gateway domain name. Isso, por sua vez, exige um segundo lookup de DNS para obter o endereço IP do API Gateway domain name retornado no primeiro lookup.
Sem o Private DNS habilitado, o lookup retornará o IP público da sua API pública, que é o que queremos.
Esse IP público pertence ao serviço AWS Gateway, que vai procurar seu nome de domínio personalizado em um Subject Alternative Name (SAN) no certificado associado a esse domínio. Como o certificado do seu nome de domínio personalizado (por exemplo, mydomain.com) foi associado ao API Gateway domain name, ele vai concluir o SSL handshake com sucesso e invocar sua API pública.
Quando uma VPC tem um VPC Endpoint do API Gateway com private DNS habilitado, esse private DNS captura o lookup do API Gateway domain name (porque captura todos os subdomínios de execute-api.REGION.amazonaws.com) e retorna o IP privado atribuído à Elastic Network Interface (ENI) do VPC Endpoint.
Esse IP privado representa o endereço do serviço API Gateway, que só aceita endpoints de URL internas pertencentes à URL de endpoint da API privada, no formato apiID.execute-api.REGION.amazonaws.com.
O resultado será algo assim:

Resultado de chamar uma API pública quando há um VPC Endpoint do API Gateway com private DNS habilitado
Como consequência, qualquer tentativa de invocar a API pública de dentro da VPC vai resultar em falha no SSL handshake, bloqueando a conexão.
Visão geral da solução
Como acabamos de explicar, quando um VPC Endpoint para API Gateway tem o Private DNS habilitado, todos os lookups de DNS para execute-api.REGION.amazonaws.com resolvem para IPs privados, fazendo com que chamadas a APIs públicas (usando nomes de domínio personalizados) falhem na validação SSL. A solução envolve priorização de DNS via private hosted zones do Route 53, também conhecida como Split-Horizon / Split-View DNS.
A ideia é que, ao usar uma private hosted zone (PHZ), os lookups de DNS originados dentro da VPC consultem a PHZ antes de buscar em qualquer outro servidor DNS público.
Digamos que temos um servidor DNS no GoDaddy hospedando nosso domínio no nível superior: mydomain.com.
Se mapearmos api.mydomain.com para nossa API pública, vamos hospedar esse subdomínio no nosso DNS PHZ para criar o split-view DNS.
Isso permite que lookups para api.mydomain.com originados dentro da nossa VPC sejam atendidos pela nossa PHZ, e que chamadas para outros subdomínios que não usam o API Gateway (por exemplo, apontando para algum outro serviço que um VPC Endpoint não esteja capturando) usem o DNS público.
Esta solução se baseia em três conceitos-chave:
- VPC Endpoint: para acesso a APIs privadas (Private DNS habilitado)
- Private Hosted Zone: para criar o split-view DNS
- Um registro do tipo Alias A na PHZ: usado para direcionar o tráfego ao API Gateway domain name público
Implementação passo a passo
Pré-requisitos
- Um API Gateway público com nome de domínio personalizado hospedado fora do Route 53 que possa ser invocado pela Internet, ou um nome de domínio personalizado público hospedado no Route 53 mas que use um registro CNAME em vez de um registro do tipo Alias A para apontar para ele.
- Um VPC Endpoint do API Gateway com Private DNS habilitado, definido na VPC a partir da qual queremos chamar nossa API pública.
Se você já tem esse VPC Endpoint, comece pelo passo 2 abaixo.
Sem ele, não será possível chamar APIs privadas.
1. Configure o VPC Endpoint para o API Gateway acessar APIs privadas
Se você já tem esse endpoint, vá para o passo "2"
- No Console da AWS, navegue até VPC Console > Endpoints.
- Crie um interface endpoint para
com.amazonaws.REGION.execute-api. - Habilite o Private DNS (configuração padrão).
- Anexe um security group permitindo HTTPS de entrada (porta 443) a partir da VPC (ou dos IPs dos recursos específicos dentro da sua VPC que você quer habilitar para chamar APIs privadas do API Gateway).
2. Crie uma Private Hosted Zone
- Crie uma PHZ no Console do Route 53 correspondente ao caminho da API do seu nome de domínio personalizado público (por exemplo,
api.mydomain.com).
Vale notar que, se você tem URLs no seu domínio público que quer chamar mas que não estão mapeadas a um API Gateway (por exemplo, se dev.mydomain.com aponta para um Load Balancer e não para o API Gateway), use o nome de domínio personalizado completo da sua API (como api.mydomain.com) como nome de domínio da sua private hosted zone.
Se todos os subdomínios do seu domínio estiverem mapeados a APIs do API Gateway, use o nível superior mydomain.com como nome de domínio.
- Associe a zona à sua VPC.

Crie uma PHZ para o seu nome de domínio personalizado e associe-a à VPC que precisa de acesso a esse domínio
3. Configure os registros DNS
- Você precisa criar um Alias do tipo A para cada domínio usado por uma API.
Por exemplo, se você tem api.mydomain.com e special-api.mydomain.com, precisa criar um registro para cada um. Um para api e outro para special-api. Então escolha o tipo de registro como "A".
- Para o nome do registro:
- Se o nome do seu domínio personalizado for igual ao nome de domínio completo da sua API, não digite o subdomínio (não digite "api") no "Record Name" (deixe-o vazio). Por exemplo, se você criou a PHZ para api.mydomain.com porque é o único subdomínio usado com o API Gateway, deixe o campo Record Name em branco.
- Se você está usando o nível superior — mydomain.com, porque tem vários subdomínios mapeados ao API Gateway, digite o nome da sua api como valor do "Record Name" para cada registro. Por exemplo, digite "api" para um registro e "special-api" para outro.
- Defina-o como registro Alias marcando a caixa 'alias'
- Escolha "Alias to API Gateway API"
- Selecione a região da sua API
- Selecione o regional endpoint (o API Gateway domain name criado para o seu nome de domínio personalizado) da sua API pública.
Ele tem um nome assim:
d-abc123.execute-api.REGION.amazonaws.com
- Se não estiver aparecendo aí, copie do console do API Gateway, em "custom domain names" -> API Gateway domain name.
- Salve o registro

O Route 53 pode levar algum tempo até que sua nova private hosted zone fique disponível para a sua VPC.
Veja o Apêndice B para a arquitetura desta solução.
Testando
Você vai precisar de uma EC2 rodando na sua VPC com conexão à Internet para APIs públicas.
Conecte-se à sua instância EC2 e, depois de substituir a URL abaixo pela sua, execute:
curl -v https://your-public-api.yourdomain.com/your-path
Você deve obter um resultado parecido com este:

Repare que, antes de criar e configurar a PHZ, o IP que o Private DNS (aquele associado ao VPC Endpoint do API Gateway) retornava para o nome de domínio personalizado era um IP privado (era 10.0.3.79), e esse IP privado pertence à ENI do VPC Endpoint. Com uma PHZ para o nome de domínio personalizado, agora obtemos os IPs públicos do API Gateway domain name, que (neste exemplo) são:
IPv4: 44.221.197.141, 34.192.177.183, 34.232.190.93
Trabalhando com as URLs públicas padrão do API Gateway
Para trabalhar com APIs privadas e públicas, desabilite o Private DNS associado ao seu VPC Endpoint do API Gateway. Em seguida, crie uma PHZ chamada execute-api.REGION.amazonaws.com e associe-a a todas as VPCs que você pretende dar acesso à VPC que hospeda suas APIs privadas. (Observação: associá-la a uma VPC em outra região está relacionado à parte "Bônus" deste artigo.)
Você cria um registro wildcard para capturar todos os API-IDs do API Gateway, assim:

Crie a hosted zone para APIs privadas nesta região
Agora você vai criar um registro "catch-all" que aponta para o DNS do VPC Endpoint, assim:

Crie um registro catch-all para todas as APIs privadas nesta região
Isso garante que todas as URLs de uma API privada do API Gateway definida em us-east-1 sejam capturadas por essa PHZ e retornem o endereço IP privado do VPC Endpoint do API Gateway.
Para APIs públicas com nome de domínio personalizado, vimos como criar uma PHZ para esse nome de domínio resolve o problema.
Para APIs públicas sem nome de domínio personalizado, precisamos adicionar um registro Alias usando o ID da API e apontá-lo para a URL pública.
Por exemplo, suponha que temos uma API pública em us-east-1 cuja URL é: bmf11pk5je.execute-api.us-east-1.amazonaws.com
Se a chamarmos de dentro da VPC, ela retornará "Forbidden (403)", como explicado acima para o cenário de nome de domínio personalizado. Para resolver isso, adicionamos um registro chamado "bmf11pk5je" e o apontamos para a invoke URL, assim:

Agora conseguimos chamar a API pública definida nesse registro de dentro da VPC. Cada nova API pública que você quiser chamar nessa região vai exigir a adição de um registro Alias, como fizemos aqui.
Bônus
Como chamar uma API privada localizada em uma região a partir de uma VPC em outra região da AWS.
O problema
APIs privadas podem ser facilmente compartilhadas entre várias VPCs dentro da mesma região. Basta ter VPC Endpoints do API Gateway em cada VPC, ter uma resource policy na sua API privada permitindo acesso a partir dessas VPCs e adicionar os VPC Endpoints à API privada (em API Settings).
Isso não funciona se sua VPC estiver em uma região diferente daquela que hospeda a API privada.
Nesse caso, você precisaria fazer o seguinte:
- Faça peering das duas VPCs, a que hospeda a API privada e a que você quer dar acesso.
Para o VPC peering, é preciso garantir que as duas VPCs não tenham blocos CIDR sobrepostos. 2. Se você não tem uma Private Hosted Zone para a região do API Gateway que hospeda sua API privada, é preciso criar uma. 3. O nome da private hosted zone (PHZ) deve ser:
execute-api.REGION.amazonaws.com
4. Você precisa associar essa PHZ ao VPC Endpoint do API Gateway na região e à VPC à qual quer conceder acesso.
5. Adicione um registro Alias do tipo A à PHZ (defina-o como alias marcando a caixa 'alias') e, em seguida, selecione "Alias to VPC Endpoint" no dropdown.
6. Selecione a região da VPC à qual você quer dar acesso
7. Escolha o VPC Endpoint do API Gateway nessa VPC
8. Adicione o bloco CIDR da VPC peered ao Security Group do VPC Endpoint. Sem isso, a comunicação a partir da VPC peered será bloqueada.
9. Salve o registro
Depois de concluir o procedimento acima, você poderá invocar a API privada a partir da VPC na outra região.
Observe que, como você está usando VPC Peering, a Resource Policy do seu API Gateway privado não precisa aprovar tráfego da VPC peered; basta aprovar o tráfego da VPC principal em que está implantada. Isso porque a comunicação com o API Gateway virá do VPC Endpoint dentro da própria VPC, mesmo que tenha se originado na VPC peered.
Esse peering cross-region vai gerar o mesmo problema de falha de Certificação SSL se você tentar acessar uma API pública definida na mesma VPC que a API privada. Mesmo estando em outra região, ela continua associada a uma PHZ para execute-api.REGION (REGION onde a API está implantada) e, por isso, vai tentar chamar o IP privado do VPC Endpoint, a menos que uma PHZ para sua API pública seja definida.
Se você quiser chamar tanto APIs privadas quanto públicas, sejam cross-region ou não, siga as instruções da primeira parte deste artigo.
Apêndice A
O diagrama abaixo mostra o que acontece quando uma instância EC2 chama um API Gateway público com um VPC Endpoint do API Gateway com Private DNS habilitado.

Chamando uma API pública de uma VPC sem PHZ configurada
- A EC2 está tentando chamar
https://api.mydomain.com, então um lookup de DNS é feito - A resposta do DNS é o API Gateway domain name
- O segundo lookup de DNS é feito e capturado pelo Private DNS associado ao VPC Endpoint do API Gateway.
- Ele retorna o endereço IP privado do VPC Endpoint
- A EC2 está tentando invocar a API pelo endereço IP privado
- O serviço API Gateway, acessível via IP privado, fornece um certificado válido para
*.execute-api.REGION.amazonaws.com, e não paraapi.mydomain.com, então um erro de certificado é retornado
Apêndice B
O diagrama abaixo mostra o que acontece quando uma instância EC2 chama um API Gateway público com um VPC Endpoint do API Gateway com Private DNS habilitado. Desta vez, também há uma private hosted zone definida para o nome de domínio personalizado.

Chamando APIs públicas de uma VPC com PHZ configurada
Chamando a API pública pela Internet
- Um lookup de DNS é feito ao serviço de hospedagem de domínio externo (por exemplo, GoDaddy) para o nome de domínio personalizado da API (por exemplo,
api.mydomain.com) - A consulta retorna o API Gateway domain name para esse nome de domínio personalizado
- O API Gateway domain name é consultado no Route 53 da AWS
- Retorna um endereço IP público para o serviço público do API Gateway
- O IP público é usado para chamar o serviço API Gateway e, como ele está associado aos certificados de
api.mydomain.com, faz a terminação SSL e chama o alvo correspondente do estado do API Gateway
Chamando uma API privada de dentro da VPC
6. APIs privadas têm uma URL no formato apiID.execute-api.REGION.amazonaws.com. Quando essa URL é chamada de uma VPC com um VPC Endpoint para API Gateway que tem private DNS ativo, a requisição é tratada por esse private DNS.
7. O private DNS retorna o IP privado da ENI do VPC Endpoint do API Gateway.
8. O serviço API Gateway acessível por esse IP privado tem um certificado para *.execute-api.REGION.amazonaws.com, então a chamada à API privada que usou essa URL é autenticada e encaminhada ao alvo da API privada.
Chamando uma API pública do API Gateway de dentro da VPC
9. O DNS da Private Hosted Zone criada para o nome de domínio personalizado captura e trata as consultas que se enquadram nesse nome de domínio.
10. A PHZ, com um registro do tipo Alias A, retorna o IP público do API Gateway domain name associado ao nome de domínio personalizado.
11. O IP público é chamado pelo Internet Gateway, alcançando o endereço do serviço API Gateway. Como o serviço acessível pelo IP público de fato possui a associação de certificado entre o nome de domínio personalizado e o API Domain name, o SSL handshake é bem-sucedido e o TLS é terminado. A requisição é encaminhada ao alvo do stage correspondente da API pública do API Gateway.
Chamada para ação
Espero que este artigo tenha trazido insights valiosos. Se você quiser saber mais ou tiver interesse nos nossos serviços, não hesite em entrar em contato. Você pode falar com a gente aqui.
Referências
- 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
Traz uma boa explicação sobre registros alias no Route 53
A solução mais simples é hospedar seu nome de domínio personalizado público no Route 53 e usar um registro do tipo Alias A. Isso permite chamar APIs públicas e privadas com um VPC Endpoint do API Gateway com Private DNS.
Se você não puder ou não quiser fazer isso, dá para usar o método descrito neste artigo.
Algumas observações importantes
- Ter um VPC Endpoint do API Gateway com Private DNS faz com que todas as chamadas a qualquer API pública do API Gateway nessa região falhem com erro de incompatibilidade de Certificação. O fato de eu ter discutido apenas
api.mydomain.comfoi arbitrário. Se você tiver (por exemplo)api.mydomain.com,api.example.comemyapi.myspecialdomain.com, todos eles vão precisar de PHZs próprias, já que não há relação entre um domínio e os outros. - Embora eu esteja me referindo a uma REST API, isso também funciona para HTTP APIs (testado) e WebSocket APIs (não testado), porque não se trata do protocolo. Trata-se da rede e do DNS.