EC2 R8g em Novas Regiões: Guia de Migração para Workloads Financeiros

Antes de falar de migração, preciso ser honesto sobre o que os números significam na prática. O anúncio cita 30% de melhoria geral, 40% para bancos de dados e 45% para aplicações Java grandes em relação ao Graviton3. Esses benchmarks são reais, mas o contexto importa.

O Graviton4 trouxe melhorias substanciais no subsistema de memória: maior largura de banda por core, latência de cache L3 reduzida e suporte a DDR5, o que se traduz diretamente em ganhos para workloads que fazem acesso intenso a estruturas de dados em memória: Redis, Kafka brokers, PostgreSQL com shared_buffers generosos, e JVMs com heaps grandes. Em ambientes financeiros, isso afeta diretamente o throughput de processamento de eventos de mercado e a latência de consultas analíticas em tempo real.

O que me chamou atenção foi o salto de capacidade máxima: de r7g.16xlarge (64 vCPU, 512 GB RAM) para r8g.48xlarge (192 vCPU, 1.5 TB RAM) e dois tamanhos bare metal. Isso muda a equação de consolidação, workloads que antes exigiam clusters de 4-6 nós de r7g.16xlarge podem ser revisitados para 1-2 instâncias r8g.48xlarge, reduzindo overhead de coordenação distribuída. Mas atenção: consolidação excessiva cria blast radius maior. Essa é a primeira armadilha.

Além disso, o Nitro System nessa geração offloada ainda mais funções de rede e storage para hardware dedicado, o que significa que os 50 Gbps de rede e 40 Gbps para EBS são sustentados, não picos burst. Para workloads de banco de dados com I/O intenso, isso elimina o gargalo de rede que frequentemente aparece em instâncias anteriores sob carga máxima.

A disponibilidade em regiões como Africa (Cape Town), Europe (Milan) e Canada West (Calgary) não é acidente, é resposta a requisitos regulatórios que estão se tornando mais rigorosos globalmente. Para plataformas financeiras, a escolha de região não é só latência: é LGPD, GDPR, POPIA (África do Sul), PIPEDA/Lei 25 (Canadá) e regulações bancárias locais que exigem que dados de clientes residam dentro de fronteiras específicas.

O que muda com o R8g nessas regiões é que agora você pode rodar workloads de banco de dados primário, não apenas réplicas de leitura, dentro da fronteira regulatória, com desempenho comparável ao que antes só estava disponível em regiões tier-1. Isso é relevante para bancos regionais africanos que precisam de processamento OLTP de alto desempenho dentro da África do Sul, ou para fintechs italianas que não podem exfiltrar dados de pagamento para fora da UE.

A armadilha aqui é assumir que a disponibilidade da instância resolve o problema de compliance. Não resolve. Você ainda precisa validar: (1) se o KMS Customer Managed Key está na mesma região e não tem réplica automática para fora dela; (2) se os logs do CloudTrail e CloudWatch Logs estão configurados com destino na região correta, não em us-east-1 por padrão; (3) se os snapshots de EBS têm política de cópia que respeita as fronteiras; (4) se os endpoints de VPC estão configurados para que o tráfego não saia pela internet pública. Esses quatro pontos são onde auditores financeiros encontram não-conformidades.

Para regiões recém-habilitadas, também vale verificar a disponibilidade de serviços complementares: nem todas as regiões têm RDS com suporte a r8g imediatamente, e o ElastiCache pode ter lag de semanas na adoção de novos tipos de instância.

Se você opera workloads em EKS, a migração para R8g tem nuances que vão além do simples swap de AMI. O primeiro ponto é a AMI: use Amazon Linux 2023 (AL2023) com suporte nativo ARM64, não AL2 com bootstrap customizado. A AL2023 tem melhor suporte a Graviton4 no kernel e resolve problemas de NUMA topology awareness que afetavam workloads de banco de dados em instâncias grandes.

O segundo ponto é o Karpenter vs. Managed Node Groups. Para R8g em regiões novas, o Karpenter é mais ágil: você define um NodePool com instance-family: [r8g] e capacity-type: [on-demand, spot], e ele provisiona automaticamente o tamanho correto baseado nos requests de Pod. Mas há uma armadilha: se você tem Pods com nodeSelector: kubernetes.io/arch: amd64 hardcoded (comum em charts Helm legados), eles vão falhar no scheduling silenciosamente ou ficar em Pending. Faça um grep em todos os seus Helm values antes de criar o node group.

O terceiro ponto é o resource requests/limits. O Graviton4 tem características de desempenho diferentes por core, em alguns workloads, você pode reduzir o CPU request em 20-30% mantendo o mesmo throughput, o que melhora a densidade de Pods por nó. Mas isso requer re-baselining com VPA (Vertical Pod Autoscaler) em modo recommendation antes de ajustar manualmente. Não assuma que os requests calibrados para x86 são ótimos para ARM64.

Finalmente, para workloads de banco de dados rodando diretamente em EC2 (não RDS), o placement group cluster com R8g oferece latência de rede consistente abaixo de 100 microsegundos entre nós no mesmo rack, relevante para clusters Patroni/Pacemaker e replicação síncrona do PostgreSQL.

Depois de migrar, o conjunto de métricas que você monitora precisa ser ajustado. O Graviton4 tem características de desempenho que tornam algumas métricas tradicionais menos informativas e outras mais críticas.

A primeira mudança é no monitoramento de CPU. Em instâncias Graviton, CPUUtilization no CloudWatch mede o percentual de vCPUs em uso, mas o que importa para workloads de banco de dados é a distribuição de uso entre os cores, o Graviton4 tem NUMA domains em instâncias grandes, e um banco de dados mal configurado pode saturar um NUMA node enquanto outros ficam ociosos. Use perf stat ou o AWS Systems Manager Run Command para coletar numastat periodicamente e detectar NUMA imbalance.

A segunda mudança é no monitoramento de memória. Com até 1.5 TB de RAM disponível, o risco de memory pressure muda de natureza: não é mais "vou ficar sem memória" mas sim "meu working set não cabe no cache L3 e estou fazendo muitos cache misses". Monitore cache_miss_ratio no Performance Insights do RDS e keyspace_hits/keyspace_misses no Redis/ElastiCache. Uma degradação nesses ratios antes de qualquer sinal de pressão de memória é o indicador precoce de que o working set cresceu além do esperado.

A terceira mudança é no monitoramento de rede. Com 50 Gbps disponíveis, o gargalo se move para o lado da aplicação, buffers TCP, número de conexões concorrentes, tamanho de janela TCP. Use ss -s e métricas de NetworkPacketsIn/NetworkPacketsOut no CloudWatch para detectar retransmissões TCP que indicam saturação de buffer, não de largura de banda.

Por fim, para ambientes EKS, configure o CloudWatch Container Insights com métricas de node_memory_working_set por namespace, não só node_memory_utilization. Em instâncias grandes com muitos Pods, a diferença entre working set e utilização total pode mascarar Pods com memory leaks que ainda não atingiram o OOM killer.