Arquitetura SaaS Multi-Conta na AWS
Uma arquitetura SaaS privada e enterprise usando AWS Organizations, Direct Connect, PrivateLink, shared services, DNS privado com Route53, GitLab e Terraform.
Esta arquitetura evoluiu para um modelo SaaS seguro e multi-conta na AWS, desenhado em torno de tráfego privado, isolamento por ambiente, tooling centralizado e exposição escalável de serviços.
O caminho principal do tráfego é: Direct Connect do cliente para uma VPC de acesso ou egress, peering para VPCs de ingress, Interface Endpoints, PrivateLink, Endpoint Services e, por fim, serviços de aplicação dentro de App VPCs isoladas.
Modelo de Contas
AWS Organizations fica no topo e fornece ciclo de vida de contas, governança, SCPs, limites de IAM e controle centralizado. As contas de ambiente são separadas por ciclo de vida, como produção, desenvolvimento, treinamento e validação.
A conta de shared services mantém a infraestrutura central, como Egress VPC e Tooling VPC. A Egress VPC atua como ponto de entrada do Direct Connect, camada centralizada de saída para internet e caminho de acesso aos endpoints. A Tooling VPC hospeda CI/CD e ferramentas internas, incluindo GitLab runners, sem exposição direta para redes de clientes.
Uma conta separada de shared applications hospeda serviços centralizados como Artifactory. O Artifactory é exposto por um NLB interno e VPC Endpoint Service, sendo consumido de forma privada pela Tooling VPC e pelas App VPCs usando Interface Endpoints.
Padrão de VPC por Ambiente
Cada conta de ambiente contém uma Ingress VPC e uma App VPC. A Ingress VPC é a camada consumidora de endpoints e entrada de DNS. Ela hospeda Interface Endpoints para padrões de acesso a EKS, MSK e API Gateway, além de Route53 Private Hosted Zones.
A App VPC contém os workloads de aplicação, como EKS, Istio, MSK, RDS, integrações com API Gateway, zonas internas do Route53, NLBs e Endpoint Services. Isso separa o ownership da aplicação da camada privada de entrada para clientes.
Desenho com PrivateLink
O padrão validado de PrivateLink é: VPC consumidora para Interface Endpoint, depois PrivateLink, Endpoint Service, NLB, ALB e finalmente serviços em EKS ou Istio.
Endpoint Services são recursos do lado provedor e são apoiados por NLBs. Interface Endpoints são recursos do lado consumidor, criados dentro de cada VPC que precisa consumir o serviço. Interface Endpoints não são compartilhados e não são transitivos.
Esse comportamento não transitivo é importante. Se Tooling, Produção e Desenvolvimento precisam acessar Artifactory, cada VPC consumidora cria seu próprio Interface Endpoint para o Endpoint Service do Artifactory.
Estratégia de DNS
A estratégia final de DNS usa o mesmo domínio interno nas VPCs de App e Ingress, como int.arc-one.com. Isso evita rewrite de host-header no ALB e evita workarounds de tradução no Istio ou Envoy.
Com o mesmo hostname em todos os lugares, o cliente usa o nome que o Istio já espera, por exemplo dashboard.int.arc-one.com. O resultado é um roteamento mais simples, com menos peças móveis e sem mudança nas VirtualServices do Istio.
Uma limitação importante do Route53 influenciou o desenho: uma VPC não pode ser associada a duas Private Hosted Zones com o mesmo nome. Cada VPC só pode ter um caminho de associação para int.arc-one.com.
Decisão de Direct Connect
Dois padrões de Direct Connect foram avaliados. O primeiro mantinha o caminho enterprise existente com Transit VIF, DX Gateway, Transit Gateway e attachments para VPCs. Esse modelo funciona bem para roteamento enterprise amplo e multi-cloud.
O segundo criava um caminho dedicado para acesso SaaS usando Private VIF, DX Gateway, VGW, Egress VPC, peering, Ingress VPC, Interface Endpoints, PrivateLink, Endpoint Services e workloads na App VPC.
A recomendação final para o caminho SaaS com endpoints privados foi o modelo baseado em VGW, pois reduz a dependência de Transit Gateway, simplifica o roteamento e se alinha melhor com acesso SaaS centrado em endpoints.
Por Que o Peering Foi Necessário
PrivateLink é cross-VPC, mas as ENIs dos Interface Endpoints ainda ficam dentro da VPC consumidora. Clientes chegando pela Egress VPC precisam de conectividade L3 até essas ENIs.
Por isso, o peering entre a Egress VPC e cada Ingress VPC é necessário nesse modelo. O caminho final do cliente fica: Direct Connect, Egress VPC, VPC peering, ENI do Interface Endpoint, PrivateLink, Endpoint Service, App VPC e finalmente serviços como EKS, MSK ou API Gateway.
Automação com Terraform e GitLab
O modelo de deploy usa GitLab runners com STS AssumeRole para aplicar infraestrutura cross-account. O GitLab não precisa de conectividade direta com as VPCs de destino para executar Terraform.
A arquitetura Terraform usa módulos reutilizáveis para ingress VPCs, endpoint services, consumidores e provedores de endpoints, DNS e stacks específicas por ambiente. A ordem do pipeline importa: serviços provedores precisam existir antes de consumidores criarem Interface Endpoints, e o DNS deve seguir o ciclo de vida dos endpoints.
Resultado Final
A arquitetura final entrega ausência de exposição pública para caminhos SaaS, isolamento claro de contas e ambientes, tooling centralizado, exposição privada de serviços com PrivateLink, simplicidade de roteamento por DNS, compatibilidade com Istio sem rewrites e automação completa com Terraform.
A principal lição é que PrivateLink, Direct Connect, DNS e fronteiras de conta precisam ser desenhados juntos. Tratar esses pontos como detalhes separados normalmente cria complexidade de roteamento depois.