Banco PAN moderniza o Pix com Amazon EKS além da infraestrutura

Por Diego Laranjeira e Lucas Daniel, Banco PAN – SRE & Cloud Engineering; Roberto Silva e Felipe Bortoletto – Solutions Architect na AWS; Ricardo da Silveira e Nicolas Tarzia – Technical Account Manager na AWS.

Neste blog post você verá como o Banco Pan migrou o seu ambiente Pix para a AWS reduzindo em 25% seus custos de processamento além de diminuir em 96% as tarefas para atualização dos clusters de Kubernetes.

Introdução

O avanço dos pagamentos instantâneos no Brasil, impulsionado pelo Pix, redefiniu os requisitos de disponibilidade, escalabilidade e resiliência das plataformas financeiras. Sistemas que anteriormente operavam com previsibilidade passaram a lidar com picos de carga dinâmicos, latência crítica e exigência de disponibilidade contínua.

No Banco PAN, a plataforma Pix rapidamente se consolidou como um dos principais componentes do ecossistema digital, suportando operações essenciais para mais de 30 milhões de clientes. Esse crescimento trouxe um aumento significativo no volume transacional, com padrões de uso altamente variáveis ao longo do dia.

Tornou-se evidente que a infraestrutura existente, embora funcional, não acompanhava mais o nível de exigência imposto pelo negócio. A necessidade não era apenas de escalar, mas de evoluir estruturalmente a forma como o sistema era operado.

Iniciamos a modernização da plataforma, migrando de um ambiente on-premises para uma arquitetura cloud-native baseada em Amazon Elastic Kubernetes Service (Amazon EKS). Essa iniciativa representou uma transformação profunda no modelo operacional, na resiliência e na capacidade de evolução contínua da plataforma.

Ponto de partida: uma arquitetura funcional, porém limitada

A arquitetura anterior era baseada em um modelo on-premises estruturado em múltiplos clusters organizados em topologia ativo/passivo, incluindo um site dedicado para recuperação de desastre.

Esse modelo foi projetado para garantir continuidade de serviço, porém apresentava limitações importantes à medida que o sistema evoluía.

A infraestrutura era composta por 31 servidores físicos, totalizando aproximadamente 824 GB de memória e 384 vCPUs, com ambientes completos mantidos continuamente, incluindo clusters de contingência em standby. Isso resultava em baixa eficiência no uso de recursos e custos elevados, já que a capacidade precisava ser provisionada antecipadamente pelo pico de processamento, uma vez que dependia de infraestrutura física.

Figura 1: Arquitetura anterior baseada em cluster ativo/passivo provisionado para o pico de demanda.

A estratégia de recuperação de desastre era baseada na replicação de estado via armazenamento. Entre os componentes estava o Kafka rodando como pods nos clusters usando volumes, replicados por meio de uma solução proprietária.

Esse modelo criava um alto nível de acoplamento entre o cluster e dados, tornando os cenários de falha mais complexos e aumentando a dependência de processos manuais.

Operacionalmente, o ambiente exigia um esforço significativo. As atualizações dos clusters eram conduzidas por meio de runbooks extensos, com aproximadamente 30 etapas sequenciais, incluindo validações de infraestrutura, verificação de replicação, drenagem de filas e reconfiguração de serviços.

Esse processo demandava coordenação entre múltiplos times, execução cuidadosa e validações intermediárias constantes, resultando em um tempo médio de recuperação de aproximadamente duas horas.

Além disso, a escalabilidade era limitada pela capacidade física disponível. Em cenários de alta demanda, havia risco de saturação, enquanto em períodos de baixa utilização, recursos permaneciam ociosos, especialmente devido à necessidade de manter ambientes completos para contingência.

O desafio: evoluir sem interromper

Modernizar uma plataforma com essas características exige equilíbrio entre evolução tecnológica e continuidade operacional.

Os principais requisitos eram claros:

• Preservar a integridade das transações.
• Manter a experiência do cliente inalterada.
• Reduzir complexidade operacional.
• Preparar a plataforma para crescimento contínuo.

Foi necessário repensar o modelo arquitetural e operacional como um todo.

A nova arquitetura: simplicidade, desacoplamento e elasticidade

Desenhamos a arquitetura com base em princípios cloud-native, priorizando desacoplamento, automação e uso de serviços gerenciados.

Figura 2: Arquitetura modernizada baseada em Amazon EKS.

Adotamos o Amazon EKS como ambiente de execução, separando a responsabilidade sobre o plano de controle da operação dos workloads.

Antes da modernização, a equipe precisava gerenciar componentes do plano de controle do Kubernetes, como API server, etcd, kube-scheduler e kube-controller-manager. Esse modelo exigia alto nível de especialização, planejamento cuidadoso para upgrades e forte dependência de conhecimento específico.

O primeiro benefício em migrar para o EKS foi que a responsabilidade do plano de controle passou a ser gerenciada pela AWS, reduzindo significativamente o esforço operacional e permitindo que o time focasse na aplicação e na evolução da plataforma.

O segundo benefício foi a escalabilidade, se antes se fazia necessário provisionar a infraestrutura pelo pico de processamento, agora o EKS e a sua integração nativa com o Amazon EC2 foi possível escalar o Pix conforme a demanda, reduzindo significativamente os custos bem como as limitações para o crescimento futuro do banco.

O terceiro benefício foi desacoplar as aplicações que mantinham estado no cluster e externalizar esses componentes, tornando os clusters stateless. Esta decisão foi essencial para reduzir a carga operacional durante upgrades uma vez que os clusters poderiam ser descartados e realocados conforme necessidade, de forma similar ao que já se pratica com instâncias em ambientes de nuvem.

Uma vez que os clusters já não retinham estado, o próximo passo era fazer com que a partir de uma única entrada para recepção das transações do Pix fosse possível alocar múltiplos clusters. Para isto, usamos uma estratégia de separar o ciclo de vida do Application Load Balancer dos clusters Kubernetes, isto foi possível através do Target Group Binding, componente do AWS Load Balancer Controller. Este componente permite que você crie um Application Load Balancer fora da infraestrutura do Kubernetes e depois o anexe a um serviço do Kubernetes, nesse caso os serviços que recebiam as requisições eram o ingress do Istio que fazia o roteamento interno no cluster.

Esta decisão de arquitetura permitiu ao Banco Pan fazer o controle granular do tráfego entre os clusters, tornando o processo de atualização de versão de Kubernetes, assim como do software que roda nele muito mais previsível e controlado, permitindo facilmente a implementação de estratégias de deploy como o canary e blue/green.

Uma mudança de paradigma: DR orientado a tráfego

Um dos maiores ganhos da modernização foi a evolução do modelo de recuperação de desastre.

No modelo anterior, o teste de recuperação de desastre dependia de replicação de dados e execução de runbooks complexos. O processo envolvia aproximadamente 30 etapas manuais e exigia cerca de duas horas para ser concluído.

Na nova arquitetura, adotamos uma abordagem orientada a tráfego e automação. Esse modelo reduziu o tempo desse teste para aproximadamente 20 minutos, representando uma redução superior a 80%, além de tornar o processo mais previsível, consistente e menos dependente de intervenção humana.

Segurança, governança e operação

A modernização fortaleceu segurança e governança.

Centralizamos o gerenciamento de identidades com AWS IAM e integramos com o modelo de autenticação do EKS via Pod Identity, eliminando o uso de credenciais estáticas nos workloads.

As políticas de acesso seguem o princípio de menor privilégio, com controles baseados em namespaces e service accounts, garantindo isolamento adequado entre diferentes componentes da plataforma.

Adotamos Amazon GuardDuty com suporte a EKS para detecção contínua de ameaças. Isso inclui análise de logs de auditoria do Kubernetes e monitoramento em tempo de execução, permitindo identificar comportamentos anômalos de forma automatizada.

Operacionalmente, a plataforma é observada de ponta a ponta com métricas expostas via Prometheus e painéis centralizados em Amazon Managed Grafana, permitindo visibilidade em tempo real sobre o comportamento dos serviços e da infraestrutura.

Resultados

A migração para o Amazon EKS trouxe resultados mensuráveis e consistentes:

Conclusão

A modernização da plataforma Pix do Banco PAN demonstrou que a adoção de uma arquitetura cloud-native vai muito além da tecnologia.

Ao reduzir complexidade, minimizar acoplamentos e adotar serviços gerenciados, foi possível transformar um ambiente operacionalmente pesado em uma plataforma mais resiliente, eficiente e preparada para crescimento contínuo.

Essa evolução melhorou indicadores técnicos e reposicionou a engenharia como agente estratégico dentro do negócio, permitindo maior velocidade de inovação e melhor resposta às demandas do mercado.

O Amazon EKS teve papel central nessa transformação, possibilitando a base necessária para escalar com segurança, confiabilidade e eficiência em um cenário de alta criticidade.

Neste post, mostramos como o Banco PAN modernizou sua plataforma Pix migrando para uma arquitetura cloud-native baseada em Amazon EKS, reduzindo em 25% os custos de processamento, diminuindo em 96% as tarefas de atualização dos clusters e tornando a recuperação de desastre um processo orientado a tráfego e automação. Para aprofundar seus conhecimentos e explorar como o Amazon EKS pode apoiar a modernização das suas aplicações críticas, acesse a documentação oficial do Amazon EKS.

Tem dúvidas ou quer compartilhar como utiliza o Amazon EKS em suas plataformas críticas? Deixe o seu comentário abaixo.

Autores

	Diego Laranjeira é Coordenador de SRE no Banco PAN, responsável por iniciativas de confiabilidade, observabilidade e modernização de plataformas cloud-native. Atua na evolução de ambientes Kubernetes na AWS, automação operacional e estratégias de alta disponibilidade para sistemas financeiros críticos. LinkedIn
	Lucas Daniel é SRE Sênior no setor financeiro, onde lidera estratégias de resiliência e escalabilidade em ambientes híbridos (AWS e OpenShift). Especialista em automação de infraestrutura, arquitetura cloud e práticas de FinOps, dedica-se a elevar a cultura DevOps através de observabilidade avançada e eficiência operacional. LinkedIn
	Roberto Fernandes da Silva é arquiteto de soluções na AWS, com mais de 18 anos de experiência na área de tecnologia. Atua como trusted advisor no segmento financeiro, apoiando clientes nas decisões em torno de nuvem e tecnologia, nos últimos anos tem trabalhado com containers e modernização. LinkedIn

	Nicolas Tarzia é Senior Technical Account Manager na AWS, com mais de 13 anos de experiência, com ampla experiência em arquitetura cloud, engenharia e design de software. Sua área de interesse são tecnologias serverless. LinkedIn
	Felipe Bortoletto é um arquiteto de soluções na AWS. Trabalha com TI desde 2008, passando por várias áreas como suporte, SAP e atualmente cloud, onde se especializou em segurança e AI. LinkedIn
	Ricardo Da Silveira é Senior Technical Account Manager na AWS, atendendo clientes do setor financeiro na América Latina. Com mais de 20 anos de experiência em TI — passando por marketing digital, portais de internet e varejo — e 7 anos na AWS, atua na interseção entre tecnologia e negócios, ajudando organizações de retail, seguros e serviços financeiros a extrair o máximo da nuvem. Sua principal área de interesse é resiliência de sistemas e arquiteturas tolerantes a falhas. LinkedIn