Modelos de conectividade

O data plane pode ser conectado a ambientes privados para:

1 - Consumo do backend para o gateway pool público, conforme diagrama 1:

public gateway

2 - Consumo do gateway pool privado, conforme diagrama 2:

private gateway
Um gateway pool não pode ser público e privado ao mesmo tempo.

Modelos de conectividade suportados

Allow list (Padrão)

  • Pontos positivos

    • Modelo mais recomendado devido à praticidade e à resiliência.

    • Cada data plane possui ao menos 2 IPs fixos de saída. Esses IPs podem/devem ser utilizados para controles de firewall no lado cliente.

    • Para incrementar ainda mais a segurança, pode ser utilizada uma estratégia de mTLS entre os gateways e o backend.

    • Custo já embutido nas ofertas padrão.

  • Limitações

    • Não é possível acessar backends sem externalização, a não ser por meio de um proxy ou tecnologia similar.

O diagrama abaixo representa a conectividade via Allow list:

allow list

VPN (sob consulta)

  • Pontos positivos

    • Modelo com acesso privado, garantindo segurança na comunicação entre os Gateways e os Backends.

  • Pontos de atenção

    • Responsabilidade compartilhada entre Sensedia e o cliente para configuração e manutenção da conectividade.

    • O SLA pode ser diferente para ambientes com VPN, devido à maior incidência de problemas de rede.

    • Maior custo de setup, manutenção e troubleshooting.

    • A comunicação ocorre diretamente entre os Gateways e os Backends, sem suporte a NAT para saída.

    • Os Gateways operam em um ambiente autoescalável, o que significa que novos IPs podem ser atribuídos dinamicamente dentro do range configurado. Por isso, é necessário liberar todo o range de IPs alocado ao data plane, não sendo possível alocar apenas IPs específicos (ex.: /32).

  • Limitações

    • Cada data plane pode ser conectado a até 4 redes, limitado a 8190 IPs.

    • O protocolo BGP (Border Gateway Protocol) não é suportado no modelo atual.

    • Não há suporte nativo para NAT, o que significa que a comunicação entre Gateways e Backends ocorre sempre com os IPs originais dos Gateways.

O diagrama abaixo representa a conectividade via VPN:

vpn

Por que não há NAT de saída na VPN

A conectividade privada via VPN Site-to-Site é operada sobre o serviço gerenciado de VPN do provedor de nuvem em que o data plane do cliente está hospedado (AWS, GCP ou OCI). Em nenhum dos três provedores esse serviço gerenciado oferece NAT configurável na saída do túnel como parte nativa da oferta:

Onde existe alguma alternativa técnica, ela reintroduz uma peça extra de infraestrutura para configurar e manter por cima da VPN — o mesmo tipo de complexidade operacional que a padronização sobre o serviço gerenciado busca evitar.

Além disso, mesmo quando o NAT está disponível, ele resolve apenas metade do conflito de endereçamento: mascara a origem, mas não resolve o caso em que a rede de destino trata o range de origem como rede local. Nessa situação, o pacote nem chega a ser roteado para dentro do túnel.

Operar NAT em escala também traz riscos operacionais conhecidos, como o esgotamento de portas sob picos de tráfego. Preferimos não assumir esse tipo de risco operacional como parte do produto, mantendo o foco da Sensedia em API Management — não em operar infraestrutura de rede sob medida para cada cliente.

Como o range de IP de um novo data plane é dimensionado

O data plane roda sobre uma rede nativa da VPC/VCN do provedor de nuvem: cada pod do Kubernetes recebe um IP roteável real da rede, e não um IP virtual de overlay. Esse modelo é implementado por meio do VPC CNI (AWS/EKS), do alias IP em clusters VPC-native (GCP/GKE) ou do VCN-Native Pod Networking (OCI/OKE), dependendo de onde o data plane está hospedado. Em todos os casos, o consumo de endereços não se compara ao modelo de "1 ou 2 servidores" de uma infraestrutura legada baseada em instâncias fixas.

Os pontos abaixo explicam por que o consumo de IPs é maior do que o número de pods sugere:

  • Esse modo de rede reserva um pool mínimo de IPs por nó, independentemente de quantos pods o nó está de fato rodando. No caso da AWS/EKS, foram medidos entre 12 e 19 IPs reservados por nó em ambientes reais. A mecânica exata de reserva varia por provedor e por CNI, mas o princípio — consumo por nó, e não apenas por pod — se aplica aos três.

  • O ambiente escala automaticamente sob demanda. Picos de tráfego podem adicionar múltiplos nós de uma vez, cada um consumindo dezenas de IPs adicionais instantaneamente, antes mesmo de considerar os pods que sobem com eles.

  • Em um caso real (AWS/EKS), um ambiente com apenas 4 nós de baseline e cerca de 50 pods de sistema — ainda sem tráfego de produção — já havia consumido 60 IPs privados.

A recomendação técnica padrão da Sensedia é um range mínimo /23 dedicado por novo data plane. Um range menor reduz a margem de segurança para autoscaling e rolling updates, aumentando o risco de esgotamento da subnet. Aceitar esse risco é uma decisão do cliente, mas não é a recomendação da Sensedia.

Quando há conflito de IP entre a rede do cliente e o range do data plane, as alternativas são:

  • Verificar se existe um serviço equivalente em uma rede não conflitante do lado do cliente.

  • Provisionar um novo data plane com range próprio (mínimo /23) e migrar por meio de um cutover controlado.

A resolução de DNS privado — apontar a plataforma para servidores DNS internos do cliente pela conectividade privada — é uma customização adicional à parte, descrita em Customização: resolução de DNS privado do backend. Pedidos adicionais de customização (como NAT) para sustentá-la são avaliados com cautela, com prioridade para soluções estruturais — como um data plane com range próprio — em vez do acúmulo de exceções pontuais.

VPC Peering (sob consulta)

  • Pontos positivos

    • Estabilidade e resiliência.

    • Setup simplificado.

  • Pontos de atenção

    • Oferta disponível somente para clientes cujo backend também está alocado na AWS.

  • Limitações

    • Cada data plane pode ser conectado a até 4 redes, limitado a 8190 IPs.

O diagrama abaixo representa a conectividade via VPC Peering:

vpc

Transit Gateway (sob consulta)

  • Pontos positivos

    • Possibilidade de acessar backends por meio de link privado.

    • Sem necessidade de uso de VPN.

    • Maior flexibilidade de comunicação entre VPCs.

    • Dentro dos limites da AWS, referentes ao Transit Gateway e à conectividade, pontos essenciais são ajustáveis.

    • Para mais informações, consulte a documentação de Limites de AWS Transit Gateway.

  • Pontos de atenção

    • Cliente deve compartilhar o AWS Transit Gateway com a conta Sensedia.

    • Necessidade de criação de rotas do lado da Sensedia e do lado do cliente.

    • A taxa de cobrança da AWS acontece dos 2 lados (Cliente e Sensedia), pois a AWS cobra por VPC anexada ao AWS Transit Gateway.

  • Limitações

O diagrama abaixo representa a conexão via Transit Gateway:

transit gateway
Para mais informações sobre o processo de estabelecimento de conectividade utilizando AWS Transit Gateway, acesse o link.

Direct Connect (sob consulta)

  • Pontos positivos

    • Possibilidade de acessar backends por meio de link privado.

  • Pontos de atenção

    • Custo.

    • Modelo de responsabilidade compartilhada entre Sensedia, cliente e fornecedor de link.

  • Limitações

    • Cada data plane pode ser conectado a até 4 redes, limitado a 8190 IPs.

O diagrama abaixo representa a conexão via Direct Connect:

direct connect
Redes acima de 8190 hosts (/19) não são suportadas.

Private link (sob consulta)

  • Pontos positivos

    • Facilita a comunicação entre componentes na AWS.

    • Garante o acesso privado com alta resiliência.

    • Para mais informações, consulte a documentação oficial AWS.

  • Pontos negativos

    • Exige exposição por meio de NLB no lado cliente.

  • Private DNS name

    • Conforme a documentação da AWS, é possível utilizar um nome com domínio próprio (<service>.customer.com.br, por exemplo) no endpoint service. Este nome é privado, pois a AWS o registra em uma zona DNS local às VPCs conectadas ao endpoint service.

    • A vantagem é poder consolidar a exposição do serviço em um nome único para diferentes service consumers.

    • Para os clientes que desejem utilizar a funcionalidade, é necessário habilitar e validar o endpoint service para utilizar o nome selecionado. Uma vez configurado, o cliente deve abrir ticket junto ao suporte Sensedia, solicitando a ativação do Private DNS name e informando o endpoint service em questão.

  • Limitações

    • São suportados até 4 VPC endpoints (powered by AWS Private link) por data plane.

O diagrama abaixo representa a conectividade utilizando VPC endpoint powered by AWS Private link:

vpc aws

Adicionalmente, é possível utilizar o mesmo VPC endpoint associado a um mesmo load balancer, com múltiplas portas e target groups. O diagrama abaixo representa esse modelo:

vpc load balancer

Customização: resolução de DNS privado do backend

Por padrão, a plataforma resolve apenas hostnames de backend publicamente resolvíveis.

Em ambientes que já utilizam um dos modelos de conectividade privada acima (VPN, Direct Connect, VPC Peering ou Transit Gateway), é possível, como customização adicional, configurar a resolução do hostname do backend diretamente contra os servidores DNS privados do cliente, alcançados pela mesma conectividade.

Essa customização requer que um dos modelos de conectividade privada acima (VPN, Direct Connect, VPC Peering ou Transit Gateway) já esteja estabelecido entre o ambiente e a rede do cliente — independentemente do modelo de conectividade usado pelo gateway pool para o tráfego de API. Sem conectividade privada já ativa, não há como alcançar o DNS privado do cliente.

Antes da implementação, é necessário o aceite formal de um termo de risco, que cobre:

  • Disponibilidade condicionada — a resolução passa a depender da estabilidade da conectividade privada e do servidor DNS do cliente.

  • Latência adicional — o hop extra de resolução pode impactar o tempo de resposta das chamadas.

  • Isolamento de SLA — o SLA da Sensedia não cobre falhas originadas no DNS ou na conectividade sob gestão do cliente.

  • Troubleshooting mais complexo — a causa raiz pode estar fora do ambiente gerenciado pela Sensedia.

  • Exposição a atualizações de ambiente — migrações ou upgrades de plataforma podem exigir reconfigurar a customização.

  • Possível descontinuação futura — caso a Sensedia disponibilize uma solução nativa equivalente, a customização pode ser descontinuada mediante aviso prévio.

Essa customização não inclui NAT de saída nem IP fixo de saída. Como detalhado nas seções acima (veja Por que não há NAT de saída na VPN), os modelos de conectividade privada não oferecem NAT — isso vale mesmo quando a resolução de DNS privado está habilitada.

Para avaliar elegibilidade e iniciar o processo de aceite de risco, entre em contato com o suporte Sensedia.

Thanks for your feedback!
EDIT

Share your suggestions with us!
Click here and then [+ Submit idea]