# Graviton4 R8g: Expansão Global e o Que Muda para Arquiteturas de Alta Memória

A AWS expandiu as instâncias EC2 R8g com Graviton4 para cinco novas regiões — Tailândia, Nova Zelândia, África do Sul, Itália e Canadá Oeste — completando um rollout global que transforma a equação de custo-desempenho para workloads de alta memória fora dos grandes hubs. Com até 1,5 TB de RAM, 48xlarge e ganhos de 40% em bancos de dados relacionais sobre o Graviton3, este não é um upgrade incremental. É um sinal de maturidade de plataforma que muda decisões de arquitetura em regiões onde a escolha de instâncias era até agora limitada.

- URL: https://fernando.moretes.com/blog/graviton4-r8g-expansao-global-e-o-que-muda-para-arquiteturas-de-alta-m-amazon-ec2-r

- Markdown: https://fernando.moretes.com/blog/graviton4-r8g-expansao-global-e-o-que-muda-para-arquiteturas-de-alta-m-amazon-ec2-r/article.md?lang=pt

- Published: 2026-06-27T09:03:09.845Z

- Category: IA & Agentes

- Tags: graviton4, ec2-r8g, memory-optimized, aws-regions, financial-grade, cost-optimization, arm64, database-performance

- Reading time: 8 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 anunciou a disponibilidade das instâncias EC2 R8g — baseadas no processador Graviton4 — em cinco novas regiões: Asia Pacific (Thailand), Asia Pacific (New Zealand), Africa (Cape Town), Europe (Milan) e Canada West (Calgary). Somadas às expansões de março de 2026 para UAE, México e Zurique, o R8g agora cobre um conjunto de regiões que até 18 meses atrás operavam exclusivamente com famílias x86 ou Graviton3. Para arquitetos que projetam sistemas financeiros, plataformas de dados e infraestrutura de cache distribuído fora dos hubs tradicionais como us-east-1 ou eu-west-1, isso muda o jogo — não pelo hype do chip, mas pela combinação de capacidade máxima (1,5 TB, 48xlarge), throughput de rede (50 Gbps) e a maturidade do ecossistema ARM64 que chegou tarde a essas regiões.

## R8g vs R7g: O Que os Números Realmente Significam

- **40%** — Ganho em bancos de dados relacionais. R8g vs R7g (Graviton4 vs Graviton3) — benchmark AWS oficial
- **45%** — Ganho em aplicações Java de grande porte. Relevante para middleware financeiro e motores de regras JVM-based
- **3x** — Mais vCPU e memória vs R7g. Até 48xlarge com 1,5 TB RAM — consolidação real de nós
- **50 Gbps** — Bandwidth de rede aprimorado. Crítico para replicação síncrona e tráfego de cache distribuído

## O Sinal Real: Maturidade de Plataforma em Regiões Periféricas

A expansão do R8g não é uma notícia de lançamento comum. É um indicador de maturidade de infraestrutura em regiões que historicamente recebem novos tipos de instância com 12 a 24 meses de atraso em relação a us-east-1. O fato de Cape Town, Milan, Calgary e Bangkok receberem o R8g em junho de 2026 — menos de dois anos após o lançamento inicial do Graviton4 — sinaliza que a AWS está acelerando a paridade de capacidade global.

Para quem projeta sistemas em regiões reguladas, isso tem implicações diretas. Muitos workloads financeiros e de saúde que exigem residência de dados em jurisdições específicas — como LGPD no Brasil, POPIA na África do Sul, ou PDPA na Tailândia — estavam até agora confinados a famílias de instâncias com menor headroom de memória ou custo-benefício inferior. A chegada do R8g a essas regiões significa que a decisão de 'ficar em us-east-1 por causa da capacidade' perde força como argumento arquitetural.

O padrão de rollout também é relevante: R8gd (com NVMe local) expandiu para regiões adicionais em março de 2026, e o R8g padrão seguiu em ondas. Isso sugere que a AWS está construindo capacidade física nessas regiões antes de habilitar os tipos — o que implica que o inventário de Spot e Reserved Instances levará alguns meses para amadurecer. Arquitetos que planejam migrações para essas regiões devem incluir esse fator de disponibilidade de RI no modelo de custo de longo prazo.

## Workloads Financeiros e o Caso para Consolidação de Nós com R8g

Em ambientes financeiros de grau enterprise, os workloads de maior custo operacional raramente são os de computação intensiva — são os de memória intensiva: bancos de dados OLTP com buffer pools grandes (PostgreSQL shared_buffers, Oracle SGA), motores de cache distribuído (Redis/Valkey, Memcached), e plataformas de streaming com brokers Kafka que mantêm grandes volumes de dados em memória para retenção de curto prazo.

O R8g.48xlarge com 1,5 TB de RAM muda o cálculo de consolidação de forma concreta. Considere um cluster Kafka MSK com brokers r7g.4xlarge (128 GB cada): para suportar 500 GB de retenção em memória por broker, você precisaria de quatro nós com margem mínima. Com r8g.12xlarge (384 GB), você chega ao mesmo resultado com dois nós, reduzindo overhead de coordenação, custo de licença por nó (em software que cobra por host), e a superfície de falha do cluster. O ganho de 40% em throughput de banco de dados se traduz diretamente em menor latência de P99 para transações ACID — o que em sistemas de pagamento significa a diferença entre SLOs de 50ms e 80ms no percentil 99.

Há um trade-off importante aqui que precisa ser nomeado: consolidação agressiva aumenta o raio de explosão de falhas. Um r8g.48xlarge que falha leva consigo 1,5 TB de estado. A resposta arquitetural correta não é evitar instâncias grandes, mas garantir que o design de replicação e failover seja proporcional — Multi-AZ com réplicas síncronas, RTO testado regularmente com Game Days, e monitoramento de EBS stall metrics (VolumeQueueLength, BurstBalance) como sinais de degradação precoce.

## Arquitetura de Referência: Plataforma de Dados Financeiros com R8g em Região Regulada

Fluxo de workload de alta memória em região regulada (ex: af-south-1 / Cape Town) usando R8g como espinha dorsal de compute, com camadas de ingestão, processamento, cache e observabilidade.

### 🌐 Ingestion Layer

- API Gateway REST/HTTP (edge)
- NLB TCP/TLS (network)

### ⚙️ Streaming & Processing

- MSK Kafka r8g.4xlarge brokers 128GB x3 (messaging)
- Flink on EKS r8g.2xlarge nodes stream processing (compute)

### 🧠 Memory-Intensive Compute

- RDS PostgreSQL r8g.8xlarge 256GB shared_buffers (data)
- ElastiCache Valkey r8g.4xlarge 128GB cache (data)
- App Tier EKS r8g.2xlarge JVM heap 96GB (compute)

### 🔒 Security & Compliance

- KMS CMK AES-256 at-rest (security)
- Security Groups Zero Trust egress (security)

### 📊 Observability

- CloudWatch VolumeQueueLength BurstBalance (external)
- OpenTelemetry Collector sidecar P99 latency (external)

### Fluxos

- apigw -> nlb: roteamento TLS
- nlb -> msk: eventos financeiros
- msk -> flink: consume / enrich
- flink -> rds: ACID write
- flink -> redis: cache-aside write
- app -> redis: read-through
- app -> rds: fallback read
- kms -> rds: encrypt at-rest
- kms -> msk: encrypt at-rest
- sg -> app: Zero Trust egress
- otel -> cw: métricas / traces
- flink -> otel: instrumentação

## O Que Muda para Arquitetos com a Expansão do R8g

- **Residência de dados sem sacrifício de capacidade**: Regiões como Cape Town (POPIA) e Bangkok (PDPA) agora têm acesso a instâncias com até 1,5 TB RAM — eliminando a justificativa de usar us-east-1 como proxy para workloads regulados.
- **Migração ARM64 com menor risco**: O ecossistema Java/JVM em ARM64 está maduro (OpenJDK 21 LTS, Spring Boot 3.x, Quarkus). O ganho de 45% em Java grandes é verificável com JMH benchmarks internos antes de migrar produção.
- **EBS io2 Block Express como complemento natural**: Com 40 Gbps de bandwidth EBS, o R8g suporta volumes io2 Block Express com até 256.000 IOPS por volume — relevante para bancos de dados que excedem o buffer pool e precisam de I/O determinístico.
- **Bare metal para workloads de latência ultra-baixa**: Os dois tamanhos bare metal do R8g eliminam o overhead do hypervisor — crítico para trading engines e sistemas de matching de ordens que medem latência em microssegundos.
- **Inventário de RI e Spot em maturação**: Novas regiões têm inventário inicial limitado de Reserved Instances. Planejar com On-Demand nos primeiros 3-6 meses e migrar para RI 1-year no-upfront conforme o inventário estabiliza é a abordagem prudente.
- **Nitro System como baseline de segurança**: O offload de virtualização para hardware dedicado no Nitro reduz a superfície de ataque de side-channel (Spectre/Meltdown mitigations são mais eficientes) e permite usar nitro-enclaves para processamento de dados sensíveis em memória isolada.

## Estratégia de Migração: Do x86 ao Graviton4 em Ambientes Financeiros

A migração de workloads financeiros para ARM64 tem um padrão de risco diferente de aplicações web convencionais. O principal vetor de falha não é o código de aplicação — a maioria dos frameworks modernos compila nativamente para ARM64 sem modificação. O risco real está em três camadas: bibliotecas nativas (JNI, BLAS, LAPACK para modelos quantitativos), drivers de banco de dados com otimizações SIMD específicas para x86, e ferramentas de observabilidade que ainda têm agentes com binários x86-only.

A abordagem que recomendo é um pipeline de validação em três fases. Na primeira fase, use o AWS Graviton Fast Start e o Porting Advisor for Graviton para fazer um scan estático das dependências — o Porting Advisor identifica bibliotecas com código nativo x86 e sugere alternativas ARM64. Na segunda fase, execute benchmarks de carga realista (não sintéticos) em r8g com dados de produção anonimizados: para bancos de dados, isso significa pg_bench com o schema real e distribuição de queries do seu AWR/pg_stat_statements. Para Kafka, significa reproduzir o perfil de produção com kafka-producer-perf-test com o mesmo tamanho de mensagem e taxa de compressão. Na terceira fase, use deployment canário com feature flags — direcione 5% do tráfego para nós R8g e compare P50/P95/P99 lado a lado no mesmo dashboard CloudWatch com métricas customizadas por tipo de instância.

Um detalhe operacional que frequentemente é ignorado: o scheduler do Linux tem comportamentos diferentes em ARM64 para workloads NUMA em instâncias muito grandes. Para r8g.24xlarge e acima, vale a pena validar a afinidade NUMA explicitamente com numactl e monitorar numa_miss no /proc/vmstat como indicador de degradação de localidade de memória.

## Observabilidade e Segurança: O Que Muda com Graviton4 em Produção

A adoção do R8g em produção exige ajustes específicos na estratégia de observabilidade. O primeiro ponto é que as métricas de CPU do CloudWatch (CPUUtilization) não capturam adequadamente o comportamento de workloads memory-bound — um banco de dados com buffer pool de 200 GB pode mostrar 30% de CPU enquanto está completamente gargalado em I/O de memória. Os sinais corretos para R8g são: para RDS, FreeableMemory com alarme quando cair abaixo de 10% da RAM total; para ElastiCache, CurrConnections e Evictions como indicadores de pressão de memória; para EKS, container_memory_working_set_bytes via kube-state-metrics, não memory_usage que inclui cache de página.

No plano de segurança, o Nitro System traz benefícios concretos que merecem ser configurados explicitamente. O AWS Nitro Enclaves está disponível em instâncias R8g e permite criar ambientes de execução isolados com memória dedicada — relevante para processamento de dados de cartão (PCI DSS) ou chaves criptográficas em HSM software. Para habilitar, o parâmetro EnclaveOptions.Enabled=true deve ser definido no launch template, e o tamanho do enclave é alocado a partir da memória total da instância (tipicamente 25-50% para workloads de processamento sensível).

Do ponto de vista de IAM e controle de acesso, a prática que recomendo para instâncias R8g em ambientes financeiros é usar instance profiles com IAM conditions baseadas em aws:RequestedRegion para garantir que credenciais de instância não possam ser usadas fora da região regulada — uma defesa em profundidade contra credential exfiltration. Combinado com VPC endpoints para todos os serviços AWS consumidos (S3, KMS, SSM, CloudWatch), você elimina o tráfego de dados sensíveis pelo internet gateway e reduz a superfície de ataque de rede.

> **O Caso para Bare Metal R8g em Trading Engines:** Os dois tamanhos bare metal do R8g (r8g.metal-24xl e r8g.metal-48xl) eliminam completamente o overhead do hypervisor Nitro — que já é mínimo, mas mensurável em latência de P99.9. Para sistemas de matching de ordens e trading engines que operam com latência alvo abaixo de 500 microssegundos, bare metal em Graviton4 oferece um perfil de latência mais determinístico do que instâncias virtualizadas equivalentes. O custo adicional de bare metal vs. a instância virtualizada equivalente é tipicamente 5-8% — um trade-off favorável quando o SLO de latência é contratual.

## Anti-Padrões Comuns na Adoção do R8g

- **Migrar para r8g.48xlarge sem redesenhar o failover**: Instâncias maiores exigem estratégias de failover proporcionais. Manter o mesmo design de HA de instâncias menores com um nó de 1,5 TB é uma receita para RTO inaceitável.
- **Assumir que todos os containers ARM64 estão disponíveis**: Imagens Docker multi-arch não são universais. Validar o manifesto de todas as imagens de produção com `docker manifest inspect` antes de migrar evita surpresas em runtime.
- **Usar métricas de CPU como proxy de saúde em workloads memory-bound**: Em instâncias de alta memória, CPU baixa não significa sistema saudável. Monitorar FreeableMemory, swap usage e NUMA miss rates é obrigatório.
- **Comprar Reserved Instances imediatamente em regiões novas**: O inventário de RI em regiões recém-expandidas pode ser limitado. Aguardar 90-120 dias e usar Cost Explorer para validar a disponibilidade antes de comprometer capital em RIs de 3 anos.
- **Ignorar o Porting Advisor e assumir compatibilidade total**: Especialmente para workloads com dependências nativas (C extensions em Python, JNI em Java, bibliotecas BLAS para ML), o Porting Advisor é uma etapa não-opcional.

## R8g vs R7g vs R6i: Decisão de Instância para Workloads Financeiros
| Critério | Critério | R8g (Graviton4) | R7g (Graviton3) | R6i (Intel Ice Lake) |
| --- | --- | --- | --- | --- |
| Memória máxima | 1,5 TB (48xlarge) | 512 GB (16xlarge) | 1,5 TB (48xlarge) | — |
| Ganho em DB relacional | +40% vs Graviton3 | Baseline | ~-10% vs R8g (estimado) | — |
| Compatibilidade x86 | Requer validação ARM64 | Requer validação ARM64 | Drop-in replacement | — |
| Custo relativo (estimado) | ~20-25% menor que R6i | ~30-35% menor que R6i | Referência | — |
| Bare metal disponível | Sim (2 tamanhos) | Sim | Sim | — |
| Disponibilidade em regiões novas | Expansão ativa (Jun 2026) | Ampla disponibilidade | Ampla disponibilidade | — |

## R8g pelo Prisma do AWS Well-Architected

- **security**: Nitro System com offload de virtualização para hardware dedicado reduz a superfície de ataque de side-channel. Habilitar Nitro Enclaves para processamento de dados sensíveis (PCI, PII). Usar VPC endpoints para eliminar tráfego sensível pelo IGW. IAM conditions com aws:RequestedRegion para confinamento de credenciais à região regulada.
- **reliability**: Instâncias grandes aumentam o blast radius — compensar com Multi-AZ obrigatório, réplicas síncronas e Game Days regulares para testar RTO real. Monitorar BurstBalance e VolumeQueueLength no EBS como sinais precoces de degradação. Definir SLOs de latência P99 com alertas no CloudWatch antes de migrar produção.
- **performance**: Validar NUMA affinity para instâncias 24xlarge e acima com numactl. Usar io2 Block Express para workloads de banco de dados que excedem o buffer pool. Benchmarks realistas com dados de produção anonimizados antes de migrar — não confiar apenas em benchmarks sintéticos da AWS.
- **sustainability**: Graviton4 oferece melhor eficiência energética por operação computacional vs. x86 equivalente. Consolidação de nós com R8g reduz o número total de instâncias, diminuindo o consumo de energia e a pegada de carbono — alinhado com metas de sustentabilidade corporativa e relatórios ESG.

> **Nota do Curador:** Na minha experiência com migrações de workloads financeiros para Graviton, o maior risco não é técnico — é organizacional: equipes que validam ARM64 apenas em ambiente de staging com carga sintética e descobrem problemas de compatibilidade de biblioteca nativa em produção às 2h da manhã. O que funciona é tratar a migração como um projeto de engenharia com três artefatos obrigatórios: um relatório do Porting Advisor com todos os riscos mapeados, um benchmark de carga realista com P99 documentado, e um ADR com o trade-off explícito de blast radius vs. economia de custo. A expansão do R8g para regiões como Cape Town e Bangkok é genuinamente estratégica para arquiteturas que precisam de residência de dados com capacidade de ponta — mas o valor só se realiza com disciplina de validação, não com otimismo de migração.

## Veredito: Adotar com Disciplina, Não com Pressa

A expansão do EC2 R8g com Graviton4 para regiões como Cape Town, Bangkok, Milan e Calgary é um sinal de maturidade de plataforma que muda decisões arquiteturais reais. Para workloads financeiros com restrições de residência de dados, o R8g elimina o argumento de 'capacidade insuficiente em regiões reguladas'. Para qualquer workload de alta memória — bancos de dados OLTP, caches distribuídos, brokers Kafka — o ganho de 40% em throughput de banco de dados e 45% em Java sobre o Graviton3 é verificável e materialmente relevante.

Minha recomendação: iniciar avaliação imediata para workloads Java e PostgreSQL com o Porting Advisor e benchmarks realistas. Planejar migração em canário com 5-10% do tráfego antes de comprometer produção completa. Aguardar 90-120 dias antes de comprar Reserved Instances em regiões recém-expandidas para garantir estabilidade de inventário. Documentar a decisão com um ADR que inclua explicitamente o trade-off de blast radius vs. economia de custo. O R8g não é hype — é a evolução natural de uma plataforma ARM64 que amadureceu o suficiente para ser a escolha padrão em novos projetos de infraestrutura de alta memória na AWS.

## Referências

- [Amazon EC2 R8g Instances — AWS What's New (Jun 26, 2026)](https://aws.amazon.com/about-aws/whats-new/2026/06/amazon-ec2-r8g-instances-additional-regions/)
- [Amazon EC2 R8g Instances — Instance Types Page](https://aws.amazon.com/ec2/instance-types/r8g/)
- [Amazon EC2 R8g Instances — Previous Regional Expansion (Mar 6, 2026)](https://aws.amazon.com/about-aws/whats-new/2026/03/amazon-ec2-r8g-instances-additional-regions/)
- [Amazon EC2 R8gd Instances — Additional Regions (Mar 26, 2026)](https://aws.amazon.com/about-aws/whats-new/2026/03/amazon-ec2-r8gd-aws-regions/)
- [AWS Graviton Fast Start Program](https://aws.amazon.com/ec2/graviton/fast-start/)
- [Porting Advisor for Graviton — GitHub](https://github.com/aws/porting-advisor-for-graviton)
- [AWS Nitro System](https://aws.amazon.com/ec2/nitro/)
- [AWS Nitro Enclaves](https://aws.amazon.com/ec2/nitro/nitro-enclaves/)