Como o TrueFoundry se Integra com a AWS: A Arquitetura de um Plano de Controle

Para arquitetos de nuvem e engenheiros de DevOps, o principal desafio na escalada de IA Generativa muitas vezes não é a disponibilidade de recursos de computação, mas sim a orquestração desses recursos. A AWS oferece primitivas poderosas -- Amazon EKS, Spot Instances, IAM roles, e Amazon Bedrock. No entanto, combinar tudo isso em uma plataforma de desenvolvedor interna coesa muitas vezes envolve configuração complexa e manutenção contínua.

TrueFoundry atua como essa camada de orquestração, funcionando como uma sobreposição de infraestrutura diretamente dentro da sua conta AWS. Abaixo, detalharemos exatamente como a plataforma se integra com a AWS—abordando limites de segurança, federação de identidade, rede e otimização de computação.

O Modelo de Implantação: Plano de Controle vs. Plano de Computação

Utilizamos uma arquitetura de plano dividido para desacoplar o gerenciamento da execução.

• O Plano de Controle: Esta é a camada de gerenciamento (API e painel). Ela lida com metadados, autenticação de usuário (RBAC) e agendamento de tarefas.
• O Plano de Computação: É aqui que o trabalho real acontece. Consiste em agentes e controladores executados em seu cluster Amazon EKS, lidando com pesos de modelo, dados de clientes e processamento de GPU.

A conectividade depende de um fluxo WebSocket ou gRPC seguro e apenas de saída. O agente em execução no seu cluster inicia a conexão com o Plano de Controle para buscar novos manifestos de implantação e enviar atualizações de status (como a saúde do pod). Como o tráfego é apenas de saída, você não precisa abrir nenhuma porta de entrada nos seus grupos de segurança da VPC, mantendo sua VPC completamente privada.

‍

Diagrama de Arquitetura: Segurança de Plano Dividido

‍

Fig 1: A Arquitetura de Plano Dividido garante que a residência dos dados permaneça dentro da VPC do cliente.

Topologia de Rede e Fluxo de Tráfego

Ao implantar o TrueFoundry em um ambiente AWS, a configuração de rede utiliza o AWS VPC CNI plugin para Kubernetes. Os recursos de computação operam dentro de sub-redes privadas, garantindo que os endpoints de inferência não sejam expostos à internet pública por padrão.

Padrões de Ingress e Egress

• Tráfego de Entrada (Requisições de Inferência): O tráfego da aplicação entra na VPC através de um AWS Application Load Balancer (ALB), gerenciado pelo AWS Load Balancer Controller. O ALB encerra as conexões TLS e encaminha as requisições para o Istio Ingress Gateway em execução dentro do cluster EKS.
• Tráfego de Saída (Registro e APIs): Os nós de trabalho do EKS exigem acesso de rede de saída para extrair imagens de contêiner do Amazon ECR e se comunicar com a API do Plano de Controle. Este tráfego é roteado através de um NAT Gateway associado às sub-redes privadas.

Integração de Service Mesh

O TrueFoundry implanta Istio para gerenciar o tráfego leste-oeste entre microsserviços. Por exemplo, em um pipeline RAG onde um serviço de embedding se comunica com um banco de dados vetorial, o Istio gerencia o roteamento e impõe TLS mútuo (mTLS). Isso garante que o tráfego interno do cluster seja criptografado em trânsito sem exigir alterações no nível do aplicativo.

Fig. 2: Fluxo de tráfego de rede demonstrando entrada para inferência e saída para dependências.

Federação de Identidade e Segurança

Um objetivo de segurança principal em ambientes AWS corporativos é a remoção de credenciais estáticas. A TrueFoundry aborda isso implementando IAM Roles for Service Accounts (IRSA).

O Fluxo de Autenticação

Quando um usuário implanta uma carga de trabalho, como um trabalho de ajuste fino ou um serviço de inferência, a plataforma executa o seguinte fluxo de trabalho:

1. Criação de Conta de Serviço: A TrueFoundry cria uma Conta de Serviço Kubernetes no namespace da carga de trabalho.
2. Associação de Função: A Conta de Serviço é anotada com o ARN de uma Função IAM da AWS pré-provisionada.
3. Troca de Token: O EKS OIDC provider valida o JSON Web Token (JWT) emitido pelo cluster para o pod.
4. Emissão de Credenciais: O pod troca este token OIDC com o AWS STS (Security Token Service) para receber credenciais AWS temporárias e rotativas.

Este mecanismo garante que o código do aplicativo use SDKs AWS padrão (por exemplo, boto3) sem segredos codificados. Se um pod for comprometido, o impacto potencial é limitado às permissões específicas concedidas a essa função IAM, e as credenciais expiram automaticamente.

Fig 3: O fluxo de autenticação IRSA usado pelas cargas de trabalho TrueFoundry.

Mecanismo de Computação: EKS, Karpenter e Otimização de Spot

Executar Grandes Modelos de Linguagem (LLMs) em instâncias sob demanda apresenta desafios de custo significativos. A TrueFoundry orquestra Karpenter, o sistema de provisionamento de nós Kubernetes de código aberto, para otimizar a utilização da computação.

Orquestração de Instâncias Spot

A TrueFoundry oferece lógica especializada para gerenciar Instâncias Spot EC2:

• Provisionamento de Capacidade: Quando uma implantação solicita recursos (por exemplo, 24GB de VRAM), a plataforma direciona o Karpenter para provisionar o tipo de instância mais econômico que atenda às restrições. Isso pode resultar em um g5.2xlarge, g5.4xlarge ou p3.2xlarge, dependendo da disponibilidade atual na região da AWS.
• Tratamento de Interrupções: O sistema monitora o Aviso de Encerramento de Instância Spot EC2, que fornece um aviso de dois minutos antes da recuperação da instância.
• Substituição Proativa: Ao detectar um sinal de encerramento via AWS Node Termination Handler, a plataforma isola o nó afetado, drena as conexões e aciona o Karpenter para provisionar uma substituição imediatamente.

Essa orquestração permite o uso confiável de Instâncias Spot para cargas de trabalho de inferência em produção, gerando tipicamente economias de até 70% em comparação com os preços sob demanda para cargas de trabalho tolerantes a spot.

O Gateway de IA: Unificando Bedrock e SageMaker

Para organizações que utilizam modelos proprietários, o TrueFoundry serve como uma interface de API unificada para Amazon Bedrock e Amazon SageMaker.

Padrões de Integração do Bedrock

Em vez de incorporar chamadas diretas do AWS SDK no código da aplicação, os desenvolvedores direcionam as requisições através do Gateway TrueFoundry. O Gateway executa:

• Autenticação: Verifica a chave de API interna contra o registro do Control Plane.
• Telemetria: Registra as contagens de tokens de entrada e saída para atribuição granular de custos e trilhas de auditoria.
• Proxy: Assina as requisições usando a própria função IAM do Gateway e as encaminha para o endpoint InvokeModel do Bedrock.

Essa centralização permite que os administradores gerenciem políticas de acesso no nível do Gateway sem a necessidade de modificar constantemente as políticas IAM ou rotacionar as credenciais AWS.

Padrões de Integração do SageMaker

O TrueFoundry suporta a implantação de modelos em endpoints do SageMaker. No entanto, a plataforma também oferece a capacidade de implantar modelos diretamente no EC2/EKS. Essa alternativa permite que as organizações evitem os custos adicionais tipicamente associados a endpoints de inferência totalmente gerenciados, mantendo uma experiência de implantação consistente para o desenvolvedor.

Compatibilidade com Infraestrutura como Código (IaC)

O TrueFoundry foi projetado para se integrar com fluxos de trabalho existentes de Infraestrutura como Código. A plataforma oferece Módulos Terraform para provisionar a infraestrutura subjacente necessária:

• VPC e Rede: Configura sub-redes privadas, gateways NAT e Grupos de Segurança de acordo com as melhores práticas da AWS.
• Cluster EKS: Provisiona o plano de controle do Kubernetes, grupos de nós gerenciados e complementos essenciais, como o VPC CNI e o driver EBS CSI.
• Bancos de Dados: Provisiona Amazon RDS instâncias para armazenamento de metadados se o Plano de Controle for auto-hospedado.

Isso garante que o ambiente consista em recursos AWS padrão definidos no arquivo de estado Terraform do cliente, permanecendo totalmente auditável.

Comparação: AWS Nativo vs. AWS + TrueFoundry

A tabela a seguir descreve as diferenças operacionais entre construir uma plataforma usando primitivos AWS brutos versus usar a camada TrueFoundry.

Conclusão: Alinhamento Arquitetônico

A integração do TrueFoundry com a AWS se alinha ao padrão arquitetônico de utilizar o hiperescalador para confiabilidade da infraestrutura, enquanto implementa um plano de controle especializado para gerenciamento específico de aplicações.

Para organizações que investem na AWS, este modelo oferece um mecanismo para modernizar as operações de IA, mantendo a residência de dados e os perímetros de segurança existentes. O cliente mantém o controle sobre a VPC e os limites de segurança, utilizando o TrueFoundry para simplificar a complexidade do ciclo de vida das aplicações de IA.

‍