Implementação de nomes de domínio personalizados para endpoints privados do Amazon API Gateway usando um proxy reverso

Este post foi escrito por Heeki Park, arquiteto principal de soluções, Sachin Doshi, arquiteto sênior de aplicativos, e Jason Enderle, arquiteto sênior de soluções.

O Amazon API Gateway permite que os desenvolvedores criem APIs REST privadas que só podem ser acessadas de dentro de uma nuvem privada virtual (VPC). O tráfego para a API privada é transmitido por meio de conexões seguras e permanece na rede da AWS e, especificamente, na VPC do cliente, protegendo-a da Internet pública. Essa abordagem pode ser usada para atender aos requisitos regulatórios ou de segurança de um cliente, garantindo a confidencialidade do tráfego transmitido. Isso torna os endpoints privados do API Gateway adequados para publicar APIs internas, como aquelas usadas por microsserviços e APIs de dados.

Nas arquiteturas de microsserviços, as equipes geralmente criam e gerenciam componentes em contas separadas da AWS e preferem acessar esses endpoints de API privados usando nomes de domínio personalizados específicos da empresa. Os nomes de domínio personalizados servem como um alias para um nome de host e um caminho para sua API. Isso facilita a conexão dos clientes usando um URL intuitivo, fácil de lembrar e também mantém um URL estável caso o URL do endpoint da API subjacente seja alterado. Os nomes de domínio personalizados também podem melhorar a organização das APIs de acordo com suas funções na empresa. Por exemplo, o formato de URL padrão do API Gateway: “https://api-id.execute-api.region.amazonaws.com/stage” pode ser transformado em “https://api.private.example.com/myservice”.

Visão geral

Este blog se baseia na documentação que abrange invocação de front-end de endpoints privados e padrões de integração de back-end e duas postagens de blog publicadas anteriormente.

O primeiro blog ajuda você consumir endpoints de API privados do API Gateway, usando uma função Lambda habilitada para VPC e uma aplicação baseada em container usando mTLS. A segunda postagem ajuda você a implementar integrações privadas de back-end em suas APIs de microsserviços que são implementados usando o AWS Fargate ou o Amazon EC2. Esta postagem os completam, permitindo que você simplifique o acesso aos seus endpoints de API implantando nomes de domínio personalizados para endpoints privados usando um proxy reverso NGINX.

Essa solução usa o NGINX porque atua como um proxy (intermediário) de alto desempenho, permitindo o encaminhamento eficiente do tráfego dentro de uma rede privada. Um arquivo de configuração de mapeamento associa seu domínio personalizado ao endpoint privado correspondente em todas as contas da AWS. Esse arquivo de configuração de mapeamento pode então ser controlado na origem e usado para implantações governadas em seus ambientes menores e de produção.

O diagrama a seguir ilustra as interações entre os componentes e o caminho para uma solicitação de API. Nesse caso de uso, uma conta de serviços compartilhados (Conta A) é responsável por gerenciar centralmente os mapeamentos de domínios personalizados e criar uma conexão do AWS PrivateLink com endpoints de API privados em contas de provedores (Conta B e Conta C).

1. Uma solicitação para a API é feita usando um domínio personalizado privado de dentro de uma VPC ou outro dispositivo capaz de rotear para a VPC. Por exemplo, a solicitação pode usar o domínio https://api.private.example.com.
2. Um registro de alias na zona hospedada privada do Amazon Route 53 é resolvido para o nome de domínio totalmente qualificado do Elastic Load Balancing (ELB) privado. O ELB pode ser configurado para ser um Network Load Balancer (NLB) ou um Application Load Balancer (ALB).
3. O ELB usa um certificado do AWS Certificate Manager (ACM) para encerrar o TLS (Transport Layer Security) do domínio privado personalizado correspondente.
4. O listener do ELB redireciona as solicitações para um target group associado ao ELB, que, por sua vez, encaminha a solicitação para uma tarefa (task) do Amazon Elastic Container Service em execução no AWS Fargate.
5. O serviço Fargate hospeda um container baseado no NGINX que atua como um proxy reverso para o endpoint privado da API em uma ou mais contas de provedores. O serviço Fargate é configurado para escalar usando uma métrica que rastreia automaticamente a utilização da CPU.
6. A tarefa do Fargate encaminha o tráfego para os endpoints privados apropriados na Conta B ou Conta C  por meio de um endpoint VPC do PrivateLink.
7. A política de recursos do API Gateway limita o acesso aos endpoints privados com base em um endpoint VPC específico, verbos HTTP e domínio de origem usados para solicitar a API.

A solução passa todas as informações adicionais encontradas nos cabeçalhos das chamadas upstream, como cabeçalhos de autenticação, cabeçalhos de tipo de conteúdo ou cabeçalhos de dados personalizados não modificados para endpoints privados nas contas do provedor (Conta B e Conta C).

Pré-requisitos

Para usar nomes de domínio personalizados, você precisa de dois componentes: um certificado TLS e um alias de DNS. Este exemplo usa o ACM para gerenciar o certificado TLS e o Route 53 para criar o alias de DNS.

O ACM oferece várias opções para integrar um certificado TLS, como:

1. Importando um certificado TLS existente para o ACM.
2. Solicitando um certificado TLS no ACM com validação baseada em e-mail.
3. Solicitando um certificado TLS no ACM com validação baseada em DNS.
4. Solicitando um certificado TLS do ACM usando a CA privada da sua organização na AWS.

O diagrama a seguir ilustra as vantagens e desvantagens associadas a cada opção.

Essa solução usa validação baseada em DNS (opção #3) para solicitar certificados TLS do ACM. Supõe-se que uma zona hospedada pública com um domínio raiz registrado (como exemplo.com) já esteja implantada na conta de destino. Em seguida, a solução usa o ACM para validar a propriedade dos nomes de domínio especificados no arquivo de mapeamento de configuração durante a implantação.

Com uma zona hospedada pública implementada, domínios secundários privados (como api.private.example.com) podem ser implantados usando a validação de DNS, o que permite a implementação de infraestrutura como código (IaC) para automatizar a validação de certificados durante a implementação da solução. Além disso, a validação baseada em DNS renova automaticamente o certificado ACM antes que ele expire.

Essa solução requer a presença de endpoints VPC específicos, ou seja, execute-api, logs, ecr.dkr, ecr.api e gateway Amazon S3 em uma conta de serviços compartilhados (Conta A). Habilitar o DNS privado no endpoint VPC execute-api é opcional e não é um requisito da solução. Alguns clientes podem optar por não habilitar o DNS privado no endpoint VPC execute-api, pois isso permite que os aplicativos dentro da VPC acessem os endpoints privados da API por meio do proxy reverso NGINX, mas também resolvam os endpoints públicos do API Gateway.

Implantando o exemplo

Você pode usar o exemplo do AWS Cloud Development Kit (CDK) ou o código do Terraform disponível no GitHub para implementar esse padrão em sua própria conta.

Essa solução usa um arquivo de configuração de mapeamento baseado em YAML para adicionar, atualizar ou excluir um mapeamento entre um domínio personalizado e um endpoint de API privado. Durante a implementação, o script de infraestrutura automatizada como código (IaC) analisa o arquivo YAML fornecido e faz o seguinte:

• Cria um arquivo de configuração NGINX.
• Aplica o arquivo de configuração do NGINX à imagem padrão do contêiner NGINX.
• Analisa o arquivo de mapeamento e cria as zonas hospedadas privadas necessárias do Route 53 na Conta A.
• Cria certificados SSL baseados em curingas (como *.exemplo.com) na Conta A. O ACM valida esses certificados usando sua respectiva zona pública hospedada (como exemplo.com) e os anexa ao ouvinte do ELB. Por padrão, um ouvinte ELB suporta até 25 certificados SSL. Os curingas são usados para proteger um número ilimitado de subdomínios, facilitando o gerenciamento e o escalonamento de vários subdomínios.

Descrição dos campos do arquivo de mapeamento

Usando políticas de recursos do API Gateway para endpoints privados

Para permitir o acesso a endpoints privados de suas VPCs ou de VPCs em outra conta, você deve implementar uma política de recursos. As políticas de recursos podem ser usadas para restringir o acesso com base em critérios específicos, como endpoints de VPC, caminhos de API e verbos de API. Para habilitar essa funcionalidade, siga estas etapas:

• Conclua a implementação da infraestrutura como código (IaC).
• Crie ou atualize uma política de recursos do API Gateway nas contas do provedor (como Conta B e Conta C). Essa política deve incluir o ID do VPC endpoint da conta de serviços compartilhados (Conta A).
• Implemente sua API para aplicar as alterações nas contas do provedor (como Conta B e Conta C).

Para atualizar a política de recursos do API Gateway com código, consulte a documentação e os exemplos de código no repositório do GitHub.

Implantando atualizações no arquivo de mapeamento

Para adicionar, atualizar ou excluir um mapeamento entre seu domínio personalizado e o endpoint privado, você pode atualizar o arquivo de mapeamento e, em seguida, executar novamente a implementação usando as mesmas etapas anteriores.

A implantação de atualizações subsequentes no arquivo de mapeamento usando a infraestrutura existente como pipeline de código reduz o risco de erro humano, aumenta a rastreabilidade, evita desvios na configuração e permite que o processo de implantação siga seus processos de DevOps e governança existentes.

Por exemplo, você pode armazenar o arquivo de mapeamento de configuração em um repositório de controle de origem separado e confirmar cada alteração nesse repositório. Cada alteração poderia então acionar um processo de implantação, que então verificaria as alterações de configuração e conduziria a implantação apropriada. Se necessário, você pode introduzir portas para impor verificações manuais ou um processo de emissão de bilhetes para garantir que os processos de controle de mudanças sejam aplicados.

Entendendo o custo da solução

A maioria dos serviços mencionados nesta solução é cobrada de acordo com o uso, que é determinado pelo número de solicitações feitas.

No entanto, existem alguns serviços que incorrem em custos horários ou mensais. Isso inclui taxas mensais para zonas hospedadas do Route 53, cobranças por hora para VPC endpoints, Elastic Load Balancing e o custo por hora de execução do proxy reverso NGINX no Fargate. Para estimar o custo dessas opções com base em sua carga de trabalho específica, você pode utilizar a calculadora de preços da AWS. Aqui está um exemplo que descreve o custo aproximado associado à arquitetura implementada nessa solução.

Conclusão

Esta postagem demonstra uma solução que permite que os clientes utilizem seus endpoints privados com segurança com o API Gateway em todas as contas da AWS e em uma rede VPC usando um proxy reverso com um nome de domínio personalizado. A solução oferece uma abordagem simplificada para gerenciar o mapeamento entre endpoints privados com o API Gateway e nomes de domínio personalizados, garantindo conectividade e segurança perfeitas.

Para obter mais recursos de aprendizado Serverless, visite Serverless Land.

Este blog é uma tradução do conteúdo original em inglês (link aqui).

Biografia do Autor

	Heeki Park, Principal Solutions Architect
	Sachin Doshi, Senior Application Architect
	Jason Enderle, Senior Solutions Architect

Biografia do tradutor

Rodrigo Peres é Arquiteto de Soluções na AWS, com mais de 20 anos de experiência trabalhando com arquitetura de soluções, desenvolvimento de sistemas e modernização de sistemas legados.

Biografia do revisor

Daniel Abib é arquiteto de soluções sênior na AWS, com mais de 25 anos trabalhando com gerenciamento de projetos, arquiteturas de soluções escaláveis, desenvolvimento de sistemas e CI/CD, microsserviços, arquitetura Serverless & Containers e segurança. Ele trabalha apoiando clientes corporativos, ajudando-os em sua jornada para a nuvem. https://www.linkedin.com/in/danielabib/