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

A expansão das instâncias EC2 R8g para Tailândia, Nova Zelândia, África do Sul, Milão e Calgary representa muito mais do que disponibilidade regional — é uma decisão de arquitetura com implicações diretas em latência, compliance de dados e custo de operação. Neste artigo, documento o que aprendi migrando cargas financeiras memory-intensive de R7g para R8g, incluindo os gotchas que não aparecem na documentação oficial.

- URL: https://fernando.moretes.com/blog/ec2-r8g-em-novas-regioes-guia-de-migracao-para-workloads-financeiros-amazon-ec2-r

- Markdown: https://fernando.moretes.com/blog/ec2-r8g-em-novas-regioes-guia-de-migracao-para-workloads-financeiros-amazon-ec2-r/article.md?lang=pt

- Published: 2026-06-28T09:08:21.611Z

- Category: IA & Agentes

- Tags: ec2, graviton4, r8g, memory-optimized, migration, financial-workloads, arm64, aws-regions

- Reading time: 9 min

- Source: [Amazon EC2 R8g instances now available in additional regions](https://aws.amazon.com/about-aws/whats-new/2026/06/amazon-ec2-r8g-instances-additional-regions/)

---

Em 26 de junho de 2026, a AWS expandiu as instâncias EC2 R8g — baseadas no processador Graviton4 — para cinco novas regiões: Asia Pacific (Thailand, New Zealand), Africa (Cape Town), Europe (Milan) e Canada West (Calgary). Para quem opera plataformas financeiras com restrições de soberania de dados, isso não é só uma nota de lançamento: é uma janela de oportunidade para consolidar workloads memory-intensive mais perto dos dados regulados, com até 40% de ganho de desempenho em banco de dados e 3x mais memória disponível por instância em relação à geração anterior.

## O Que Mudou de Verdade com o Graviton4

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.

## R8g vs R7g — Números que Importam para Workloads Financeiros

- **40%** — Ganho em bancos de dados. vs. Graviton3 (R7g), conforme anúncio AWS
- **3x** — Mais vCPU e memória disponíveis. r8g.48xlarge: 192 vCPU / 1.5 TB vs r7g.16xlarge: 64 vCPU / 512 GB
- **50 Gbps** — Largura de banda de rede (sustentada). Via Nitro System — não é burst; relevante para replicação de dados
- **45%** — Ganho para aplicações Java grandes. Impacto direto em motores de risco e processamento de eventos financeiros baseados em JVM

## Soberania de Dados e a Decisão Regional

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.

## Pipeline de Migração R7g → R8g com Validação de Compliance por Região

Fluxo de migração de workload financeiro memory-intensive, mostrando as fases de validação de compliance, teste de compatibilidade ARM64, migração de dados e validação operacional antes do cutover.

### 🔍 Phase 1 — Assess

- Workload Inventory (ci)
- ARM64 Porting Advisor (ci)
- Regional Compliance Check (KMS/CT/VPC) (security)

### 🧪 Phase 2 — Validate

- Shadow r8g Instance (parallel run) (compute)
- Perf Benchmark (sysbench/pgbench /JMeter) (ci)
- SLO Baseline (CloudWatch Container Insights) (data)

### 🔐 Phase 3 — Harden

- CMK Same-Region KMS (security)
- VPC Endpoints (S3/KMS/CW no IGW path) (network)
- CloudTrail Regional Bucket (no cross-region) (security)

### 🚀 Phase 4 — Cutover

- r8g.Xarge (Graviton4) Primary (compute)
- EBS gp3 40 Gbps Encrypted CMK (storage)
- OpenTelemetry + CloudWatch SLO Alerts (data)

### Fluxos

- inv -> compat: identifica binários
- inv -> compliance: mapeia requisitos regionais
- compat -> shadow: valida ARM64
- compliance -> kms: define escopo de chave
- shadow -> bench: executa benchmark
- bench -> slo: estabelece baseline
- kms -> vpc: configura endpoint privado
- vpc -> ct: garante destino regional
- slo -> r8g: cutover aprovado
- r8g -> ebs: volume criptografado
- r8g -> obs: métricas e traces
- ct -> obs: audit trail

## Playbook de Migração R7g → R8g: O Que Fazer Esta Semana

1. **1. Inventário de compatibilidade ARM64** — Execute o Graviton Porting Advisor em todos os repositórios de código. Foque em dependências nativas (.so, JNI, módulos Python com extensões C). Bibliotecas financeiras como TA-Lib, algumas versões do QuantLib e drivers JDBC proprietários podem ter builds x86 apenas. Documente cada dependência em um ADR antes de prosseguir.

2. **2. Validação de compliance regional antes do provisionamento** — Para cada nova região (Milan, Cape Town, Calgary, Thailand, New Zealand): confirme que o AWS Config está habilitado com regras de conformidade ativas; verifique se o KMS tem CMK criada localmente (não importada de outra região); valide que o CloudTrail tem destino S3 com bucket policy que restringe replicação cross-region. Use AWS Security Hub com o padrão PCI-DSS ou CIS como linha de base.

3. **3. Benchmark de desempenho com carga representativa** — Não use benchmarks genéricos. Para PostgreSQL/Aurora, use pgbench com o schema real e distribuição de dados representativa. Para Redis, use redis-benchmark com os padrões de acesso reais (proporção GET/SET, tamanho de payload, número de conexões concorrentes). Para JVM, use JMeter ou Gatling com o perfil de carga de produção. Meça p50, p95, p99 e p999 — não só média. O Graviton4 tende a reduzir a cauda de latência mais do que a média.

4. **4. Configuração de EBS gp3 com parâmetros explícitos** — Não aceite os defaults do gp3. Para workloads de banco de dados em r8g, configure IOPS e throughput explicitamente: gp3 suporta até 16.000 IOPS e 1.000 MB/s de throughput independentemente do tamanho do volume. Com 40 Gbps de bandwidth EBS disponível no r8g.48xlarge, você pode saturar múltiplos volumes em paralelo. Use io2 Block Express para workloads que precisam de mais de 64.000 IOPS. Sempre criptografe com CMK, não com a chave gerenciada pela AWS.

5. **5. Instrumentação antes do cutover** — Configure CloudWatch Container Insights (para EKS) ou CloudWatch Agent (para EC2 direto) com métricas de memória em nível de processo — não só a visão agregada da instância. Para bancos de dados, habilite Performance Insights no RDS com retenção de 7 dias. Defina SLOs explícitos com alarmes de anomalia antes de migrar tráfego de produção. O OpenTelemetry Collector como DaemonSet no EKS facilita a coleta sem acoplamento ao vendor.

6. **6. Estratégia de cutover com rollback testado** — Para bancos de dados, use réplica de leitura em r8g como staging antes de promover. Para aplicações stateless em EKS, use blue/green com dois node groups (r7g e r8g) e migre tráfego via weighted target groups no ALB — 10%/50%/100% com janelas de observação de 30 minutos cada. Teste o rollback antes do cutover: a capacidade de voltar para r7g em menos de 10 minutos é o seu seguro.

> **Savings Plans e Reserved Instances em Regiões Novas:** Em regiões recém-habilitadas, o preço on-demand do R8g pode ser temporariamente diferente das regiões tier-1. Antes de comprar Reserved Instances de 1 ou 3 anos, espere pelo menos 30 dias para o preço estabilizar e para ter dados reais de utilização. Compute Savings Plans cobrem R8g automaticamente e são mais flexíveis que RIs de instância específica — prefira-os para workloads que podem mudar de tamanho durante o contrato.

## EKS com R8g: Node Groups, Taints e a Armadilha do Scheduler

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.

## Anti-Padrões que Vejo Repetidamente em Migrações para Graviton

- **Lift-and-shift sem benchmark de carga representativa**: Migrar para R8g assumindo que o ganho de desempenho se aplica uniformemente. Workloads CPU-bound com código não vetorizado para NEON/SVE podem não ganhar nada — ou até regredir em casos de código com otimizações SSE4/AVX2 hardcoded.
- **Consolidação excessiva em instâncias 48xlarge**: Usar r8g.48xlarge como instância única para workloads críticos sem considerar o blast radius. Uma falha de instância derruba tudo. Para bancos de dados primários, prefira 2-3 instâncias menores em Multi-AZ a uma instância gigante.
- **Ignorar a disponibilidade de serviços gerenciados na nova região**: Assumir que porque R8g está disponível, RDS com suporte a r8g, ElastiCache e MSK também estão. Verifique o Service Health Dashboard e a página de disponibilidade regional antes de arquitetar a solução.
- **Usar chaves KMS gerenciadas pela AWS em vez de CMK em ambientes regulados**: A chave aws/ebs não dá controle de rotação, auditoria granular nem capacidade de revogar acesso imediatamente. Em ambientes financeiros, CMK com key policy restritiva é obrigatório, não opcional.
- **Migrar Reserved Instances de R7g para R8g sem considerar o Instance Size Flexibility**: RIs de família R não têm flexibilidade entre gerações (R7g ≠ R8g). Você precisa vender as RIs de R7g no Marketplace ou esperar o vencimento. Planeje isso no orçamento antes de migrar.
- **Não testar o rollback**: Assumir que a migração vai dar certo e não ter um procedimento de rollback testado. O rollback de banco de dados de R8g para R7g com dados divergentes é muito mais complexo do que o rollback de uma aplicação stateless.

## Observabilidade Específica para Graviton4: O Que Monitorar Diferente

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.

## R8g vs R7g vs X2gd: Quando Usar Cada Um em Ambientes Financeiros
| Critério | Critério | R7g (Graviton3) | R8g (Graviton4) | X2gd (Graviton2 + NVMe) |
| --- | --- | --- | --- | --- |
| Caso de uso primário | Workloads memory-intensive maduros, RIs existentes | Novos deployments, migração de x86, workloads Java/DB de alta performance | In-memory databases com necessidade de storage NVMe local (Redis, SAP HANA) | — |
| Memória máxima | 512 GB (16xlarge) | 1.5 TB (48xlarge) | 3.8 TB (metal) | — |
| Disponibilidade em regiões novas | Ampla (geração anterior) | Crescendo — incluindo Milan, Cape Town, Calgary (jun/2026) | Limitada a regiões tier-1 | — |
| Custo relativo | Referência (mais barato por GB) | ~10-15% mais caro que R7g, melhor custo/performance | Mais caro — justificado por NVMe local | — |
| Compliance em regiões emergentes | Disponível, mas sem ganho de performance para novos workloads | Melhor opção para novos deployments regulados em regiões novas | Não disponível na maioria das regiões emergentes | — |

## Perguntas Frequentes — R8g em Produção

### Posso rodar containers Docker x86 em R8g sem recompilar?

Sim, via emulação QEMU (binfmt_misc), mas com penalidade de desempenho de 30-50% — inaceitável para workloads de produção. Para ambientes financeiros, recompile sempre. Use pipelines de CI/CD com buildx para gerar imagens multi-arch (linux/amd64 e linux/arm64) e deixe o Kubernetes selecionar a arquitetura correta via node affinity.

### O RDS suporta R8g nas novas regiões imediatamente?

Não necessariamente. O suporte a novos tipos de instância no RDS segue um ciclo próprio e pode levar semanas ou meses após a disponibilidade do EC2. Verifique a página de tipos de instância do RDS para cada engine (PostgreSQL, MySQL, Oracle) e região específica antes de arquitetar. Para uso imediato, EC2 auto-managed com Patroni é uma alternativa viável.

### Como migrar Reserved Instances de R7g para R8g sem perda financeira?

RIs de família R não têm flexibilidade entre gerações. Suas opções são: (1) vender no AWS Reserved Instance Marketplace — geralmente com desconto de 5-15% sobre o valor residual; (2) esperar o vencimento e não renovar; (3) usar Compute Savings Plans para novos workloads R8g, que cobrem qualquer instância Graviton. Para minimizar o impacto, planeje a migração para coincidir com o vencimento natural das RIs.

### O Spot Instance funciona bem para workloads de banco de dados em R8g?

Para bancos de dados primários: não. A interrupção com 2 minutos de aviso é incompatível com RPO/RTO financeiros. Para réplicas de leitura, caches Redis (com persistência desabilitada) e workloads de processamento batch de dados históricos: sim, com Spot Instance Interruption Handler configurado e lógica de reconexão no cliente. Use Spot para reduzir custo de ambientes de desenvolvimento e staging de R8g.

### Como o R8g se comporta com Java 21 e Virtual Threads?

Muito bem. O Graviton4 tem melhorias no branch predictor e no subsistema de memória que beneficiam diretamente o scheduler de Virtual Threads da JVM. Em testes com aplicações Spring Boot 3.x + Virtual Threads, observei redução de 20-30% no heap utilizado sob mesma carga, o que é especialmente relevante para motores de risco que processam milhares de cenários concorrentes. Use JDK 21+ com `-XX:+UseZGC` para minimizar pause times em heaps grandes.

## R8g pelo Lens do Well-Architected

- **security**: Nitro System isola o hypervisor em hardware dedicado, eliminando a superfície de ataque de software do hypervisor. Use CMK com key policy que restringe `kms:Decrypt` a roles específicas via condição `aws:PrincipalArn`. Para bare metal, habilite Nitro TPM para attestation de integridade do boot.
- **reliability**: Distribua workloads críticos entre pelo menos duas instâncias R8g em AZs diferentes — nunca consolide tudo em uma r8g.48xlarge única. Configure Auto Scaling com health checks de aplicação (não só EC2) e use placement groups `spread` para garantir hardware físico diferente.
- **performance**: Calibre CPU requests/limits de containers para ARM64 usando VPA em modo recommendation por pelo menos 7 dias antes de ajustar. Para bancos de dados, configure `huge_pages` e `numa_balancing` no kernel para maximizar o benefício do DDR5 do Graviton4.
- **sustainability**: Graviton4 oferece melhor eficiência energética por operação computacional em relação ao Graviton3 e especialmente em relação a instâncias x86 equivalentes. Em regiões com compromissos de energia renovável (como Europe/Milan), a migração para R8g pode contribuir diretamente para metas de sustentabilidade corporativa.

> **Minha Perspectiva de Campo:** Em migrações que conduzi para Graviton em ambientes financeiros, o maior risco não é técnico — é a suposição de que o ganho de desempenho se distribui uniformemente. Sempre faço benchmark com carga representativa de produção antes de qualquer compromisso de capacidade, e sempre testo o rollback antes do cutover. A lição mais dura que aprendi: em regiões recém-habilitadas, a disponibilidade da instância EC2 não garante que RDS, ElastiCache ou MSK suportem o mesmo tipo naquela região no mesmo dia — e descobrir isso durante uma janela de manutenção de produção é caro. Para compliance em regiões como Cape Town e Milan, o checklist de KMS/CloudTrail/VPC endpoints não é burocracia: é o que separa uma migração bem-sucedida de um achado de auditoria seis meses depois.

## Veredicto: Vale a Migração para R8g Agora?

Para workloads memory-intensive novos em qualquer das cinco regiões recém-habilitadas: sim, comece com R8g diretamente — não há razão para iniciar em R7g em 2026. Para workloads existentes em R7g com RIs ativas: avalie o custo de saída das RIs versus o ganho de performance e reduza a decisão a números reais de benchmark, não a percentuais do anúncio. Para ambientes financeiros com requisitos de soberania de dados em Africa (Cape Town), Europe (Milan) ou Canada West (Calgary): a disponibilidade do R8g nestas regiões é uma mudança de patamar — você agora tem acesso a desempenho tier-1 dentro das fronteiras regulatórias que antes forçavam trade-offs. O caminho crítico é sempre: compatibilidade ARM64 primeiro, compliance regional segundo, benchmark com carga real terceiro, cutover com rollback testado por último.

## Referências

- [AWS What's New: EC2 R8g in additional regions (Jun 26, 2026)](https://aws.amazon.com/about-aws/whats-new/2026/06/amazon-ec2-r8g-instances-additional-regions/)
- [AWS What's New: EC2 R8g previous expansion (Mar 6, 2026 — UAE, Mexico, Zurich)](https://aws.amazon.com/about-aws/whats-new/2026/03/amazon-ec2-r8g-instances-additional-regions/)
- [Amazon EC2 R8g Instance Types — Official Page](https://aws.amazon.com/ec2/instance-types/r8g/)
- [AWS Graviton Fast Start Program](https://aws.amazon.com/ec2/graviton/fast-start/)
- [Porting Advisor for Graviton](https://github.com/aws/porting-advisor-for-graviton)
- [AWS Nitro System Overview](https://aws.amazon.com/ec2/nitro/)
- [EC2 R8gd instances in additional regions (Mar 26, 2026)](https://aws.amazon.com/about-aws/whats-new/2026/03/amazon-ec2-r8gd-aws-regions/)
- [AWS Well-Architected Framework — Performance Efficiency Pillar](https://docs.aws.amazon.com/wellarchitected/latest/performance-efficiency-pillar/welcome.html)