Como encaminhar o tráfego SaaS para o VPN correto do cliente

Uma plataforma SaaS se conecta a uma dúzia de redes de clientes, e dois desses clientes usam ambos 10.20.0.10 para seu banco de dados principal. Um worker que recebe esse endereço em um job não tem como saber qual banco de dados o job significa, e uma tabela de roteamento compartilhada o enviará de bom grado para o túnel que o prefixo aponta. A solução não são mais túneis; é decidir onde a identidade do locatário entra no caminho e qual modelo de isolamento o plano de endereços exige. Três condições decidem a escolha: se os prefixos dos clientes se sobrepõem, até onde um erro pode se espalhar e quem opera o conector.

Dois bancos de dados de clientes, um endereço de destino

Um endereço IP é um local, não uma identidade. A requisição precisa carregar um locatário que o servidor verificou, e esse locatário precisa selecionar o contexto de rede antes que o destino seja resolvido.

Quando isso não acontece, a falha é silenciosa. A conexão é bem-sucedida, a consulta roda e a resposta vem do banco de dados do cliente errado porque a tabela de roteamento tinha uma entrada para 10.20.0.10. O DNS piora: um nome em cache resolvido no contexto do locatário A pode ser reutilizado por um job executado para o locatário B. Nada no pacote distingue os dois, então nenhuma lógica de nova tentativa o conserta.

Decida primeiro o modelo de isolamento

Escreva as três condições antes de comparar produtos. A sobreposição decide se um espaço de endereços pode ser compartilhado; o raio de impacto decide se um erro de roteamento é um chamado de suporte ou uma violação; a propriedade operacional decide se você pode operar uma frota de conectores por locatário.

Se os prefixos são distintos e a política permite um hub controlado, um Transit Gateway com tabelas de roteamento por locatário é viável. A associação do attachment escolhe a tabela de roteamento usada para o tráfego que entra por esse attachment, e a propagação escolhe quais rotas aparecem em uma tabela. Um attachment de locatário associado apenas à sua própria tabela e que propaga apenas seus próprios prefixos alcança o hub e nada mais. Isso é uma decisão de roteamento, e ela só permanece correta enquanto ninguém adiciona uma rota padrão à tabela compartilhada.

Se os prefixos se sobrepõem, o roteamento sozinho não pode separá-los. Você precisa de um contexto de rede distinto por locatário ou de um plano de tradução que dê ao espaço de cada cliente um significado inequívoco.

O que o isolamento do Transit Gateway realmente significa

Associação e propagação são os dois controles que importam, e é fácil confundi-los. A associação responde em qual tabela um pacote deste attachment é procurado; a propagação responde quais tabelas aprendem as rotas deste attachment. O isolamento vem de tornar ambos específicos do locatário, não de criar mais attachments.

Uma configuração padrão todos-para-todos é conveniente e não é isolamento. Tabelas de roteamento separadas restringem a conectividade, mas não dão a um mesmo endereço de destino dois significados dentro do mesmo contexto de roteamento. Se a aplicação resolve 10.20.0.10 antes de conhecer o locatário, a camada de roteamento já perdeu a informação de que precisaria.

A AWS adicionou em 23 de outubro de 2026 NAT 1:1 no nível do attachment para Transit Gateway e Cloud WAN, o que muda a resposta de sobreposição para attachments compatíveis. A documentação de NAT do Transit Gateway descreve mapeamentos IPv4 estáticos, sem estado e de prefixo igual com bits de host preservados. Verifique os tipos de attachment compatíveis e as restrições regionais antes de projetar em torno disso.

Vincule o job a um locatário verificado

Cada job deve carregar uma identidade de locatário verificada pelo servidor, e essa identidade deve selecionar um registro de conexão de propriedade do administrador. O registro nomeia o contexto de rede aprovado, o endereço do serviço, a referência das credenciais e as operações permitidas ali. Uma requisição não confiável nunca deve fornecer seu próprio identificador de VPN, gateway ou destino privado, porque um login válido não é permissão para sondar o espaço de endereços de cada cliente conectado.

Em um design de conectores isolados, o trabalho do locatário A vai para um conector específico de A que roda na VPC de A e só pode alcançar os recursos aprovados de A. Contêineres separados em um único host não criam essa separação sozinhos; os namespaces de rede, as rotas e a política de saída precisam implementá-la. O conector também precisa de credenciais e filas com escopo de locatário, já que uma rota privada não limita um segredo compartilhado nem um item de trabalho compartilhado. Workers de aplicação agrupados estão bem desde que o contexto de rede e as credenciais sejam escolhidos por locatário, não por host.

As verificações de saúde devem nomear o locatário e o estágio: túnel estabelecido, rota presente e uma requisição de serviço real bem-sucedida são três sinais diferentes. Uma contagem agregada de túneis ativos esconderá o único cliente cujo conector está quebrado.

Teste os caminhos que devem falhar

Execute três testes antes do lançamento. Uma operação A permitida deve ter sucesso, uma operação B permitida deve ter sucesso, e um job A direcionado deliberadamente ao conector de B ou ao seu alias traduzido deve falhar fechado. Depois quebre um túnel e confirme que o job falha apenas para esse locatário, sem recorrer à sub-rede de mesmo número de outro cliente. A restauração também deve ser testada, porque uma rota obsoleta ou credencial em cache pode sobreviver à interrupção.

A arquitetura pode ser workers agrupados com conectores isolados, ou recursos de locatário totalmente separados. O invariante é o mesmo: o contexto de locatário verificado seleciona a rota e as credenciais, e nenhuma mudança de rota concede jamais permissão de aplicação entre locatários.