# EC2 R8g e Graviton4: Análise Técnica para Workloads Memory-Intensive

As instâncias EC2 R8g com Graviton4 chegam a regiões como África (Cape Town), Europa (Milão) e Ásia-Pacífico (Tailândia, Nova Zelândia), trazendo até 1,5 TB de memória e 3x mais vCPUs que a geração anterior. Neste artigo, analiso os mecanismos reais por trás desse salto de performance, os trade-offs de migração e os padrões de design que tornam essas instâncias relevantes para sistemas financeiros críticos.

- URL: https://fernando.moretes.com/blog/ec2-r8g-e-graviton4-analise-tecnica-para-workloads-memory-intensive-amazon-ec2-r

- Markdown: https://fernando.moretes.com/blog/ec2-r8g-e-graviton4-analise-tecnica-para-workloads-memory-intensive-amazon-ec2-r/article.md?lang=pt

- Published: 2026-06-29T09:03:29.985Z

- Category: IA & Agentes

- Tags: ec2, graviton4, r8g, memory-optimized, nitro, financial-grade, arm64, 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/)

---

A expansão das instâncias EC2 R8g com Graviton4 para novas regiões — incluindo África (Cape Town), Europa (Milão), Ásia-Pacífico (Tailândia e Nova Zelândia) e Canadá Oeste (Calgary) — não é apenas um evento de disponibilidade geográfica. É um sinal arquitetural: a AWS está consolidando sua aposta em ARM64 como plataforma de primeira classe para workloads de memória intensiva em ambientes regulados e de borda global. Para quem projeta sistemas financeiros, de dados em tempo real ou infraestrutura de cache distribuído, entender o que realmente mudou no Graviton4 — e o que não mudou — é o que separa uma migração bem-sucedida de um incidente de produção.

## O que o Graviton4 realmente entrega — e por quê os números importam

Os benchmarks publicados pela AWS indicam ganhos de até 30% para aplicações web, 40% para bancos de dados e 45% para aplicações Java de grande porte em comparação com instâncias R7g baseadas em Graviton3. Esses números não surgem de um único vetor de melhoria — eles são o resultado combinado de mudanças no design do processador, na hierarquia de cache, na largura de banda de memória e na integração com o Nitro System.

O Graviton4 introduz um núcleo Neoverse V2 com melhorias substanciais no pipeline de execução out-of-order, maior largura de banda para o barramento de memória e suporte a DDR5. Para workloads Java — que são dominantes em sistemas financeiros legados e modernos — o ganho de 45% é particularmente relevante porque o JVM é sensível a latência de acesso à memória, throughput de garbage collection e densidade de threads. Um r8g.48xlarge com 192 vCPUs e 1,5 TB de RAM pode hospedar JVMs de aplicações de trading que antes exigiam múltiplas instâncias menores com overhead de coordenação.

O salto de 3x em vCPUs (de r7g.16xlarge com 64 vCPUs para r8g.48xlarge com 192 vCPUs) e de memória (de 512 GB para 1,5 TB) não é incremental — é uma mudança de categoria. Isso permite consolidar workloads que antes precisavam de sharding horizontal por limitação de capacidade vertical, reduzindo complexidade operacional e latência de comunicação intra-cluster. Para sistemas de risco em tempo real, essa consolidação pode ser a diferença entre cálculos de VaR intra-day viáveis e inviáveis em uma única instância.

## R8g vs R7g: Comparativo de Capacidade e Performance

- **3x** — Mais vCPUs (até 192 no r8g.48xlarge). vs. 64 vCPUs no r7g.16xlarge
- **1.5 TB** — Memória máxima disponível. vs. 512 GB no R7g — mudança de categoria para workloads in-memory
- **45%** — Ganho de performance para Java. Crítico para sistemas financeiros JVM-based (trading, risco, liquidação)
- **50 Gbps** — Bandwidth de rede (Enhanced Networking). 40 Gbps para EBS — viabiliza I/O intensivo sem gargalo de rede

## Pipeline de Workload Memory-Intensive em EC2 R8g com Graviton4

Fluxo de dados e camadas de processamento para um sistema financeiro de risco em tempo real rodando em R8g. Mostra a separação entre plano de controle Nitro, camadas de dados e integração com serviços AWS gerenciados.

### 🌐 Ingestion Layer

- Amazon MSK Kafka Streams (messaging)
- API Gateway REST / WebSocket (edge)

### ⚙️ Graviton4 Compute (R8g)

- r8g.12xlarge Java Risk Engine 48 vCPU / 384 GB (compute)
- r8g.4xlarge Redis / Valkey 16 vCPU / 128 GB (data)
- r8g.8xlarge PostgreSQL / Aurora 32 vCPU / 256 GB (data)

### 🔒 Nitro Security Plane

- Nitro Hypervisor CPU/Net/Storage Offload (security)
- AWS KMS EBS Encryption CMK (security)

### 💾 Storage & Observability

- EBS gp3 / io2 40 Gbps throughput Encrypted CMK (storage)
- CloudWatch Container Insights SLO Alarms (ci)
- OpenTelemetry Collector Datadog Exporter (ci)

### Fluxos

- msk -> r8g_app: eventos de mercado
- apigw -> r8g_app: requisições síncronas
- r8g_app -> r8g_cache: leitura/escrita in-memory
- r8g_app -> r8g_db: persistência transacional
- r8g_app -> nitro: I/O offload (sem overhead de hypervisor)
- nitro -> kms: envelope key decrypt
- r8g_db -> ebs: 40 Gbps EBS throughput
- r8g_app -> otel: traces / métricas
- otel -> cw: métricas e logs

## O Nitro System como Fundação de Segurança — Não Apenas de Performance

Uma das narrativas mais comuns sobre o Nitro System é que ele existe para melhorar performance ao offloading de funções de virtualização para hardware dedicado. Isso é verdade, mas incompleto. Para ambientes financeiros regulados — onde PCI-DSS, SOC 2 e BACEN/CVM impõem controles rigorosos sobre isolamento de dados e auditabilidade — o Nitro oferece uma propriedade de segurança que vai além da performance: **o hypervisor não tem acesso ao tráfego de dados do cliente**.

Essa separação arquitetural significa que operadores da AWS não podem, por design, acessar memória ou armazenamento de instâncias R8g em execução. Para sistemas que processam dados de clientes, posições de trading ou informações de liquidação, isso é um controle de segurança auditável, não apenas uma declaração de marketing. O Nitro Card gerencia I/O de rede e EBS de forma independente, e a criptografia de EBS com CMK via KMS é aplicada no nível do controlador de armazenamento — não no sistema operacional da instância.

Na prática, isso tem implicações diretas para o design de IAM. Uma política de bucket S3 ou uma key policy do KMS que usa a condição `aws:SourceVpc` combinada com `ec2:SourceInstanceARN` permite que você construa um perímetro de dados que vincula acesso a uma instância R8g específica — não apenas a uma role IAM genérica. Em ambientes de alta conformidade, esse nível de granularidade é o que permite passar auditorias de controles de acesso sem depender exclusivamente de controles compensatórios.

> **Graviton4 + Nitro: O Isolamento de Memória como Controle de Conformidade:** O Nitro System não apenas offloads I/O — ele implementa um modelo de isolamento onde o plano de controle da AWS não tem visibilidade sobre dados em execução. Para workloads financeiros com requisitos de residência de dados (LGPD, GDPR, regulações locais), a combinação de R8g em regiões como Cape Town ou Milão com CMKs regionais do KMS e políticas de SCP que negam `ec2:RunInstances` fora de regiões aprovadas cria um perímetro de dados auditável e defensável.

## Migração para ARM64: Os Modos de Falha Reais que Ninguém Documenta

A AWS oferece o Porting Advisor for Graviton e o Graviton Fast Start program para facilitar migrações, e eles são genuinamente úteis para identificar dependências de bibliotecas nativas. Mas os modos de falha mais custosos que já vi em migrações para Graviton não são detectados por essas ferramentas — eles emergem em produção.

**Dependências nativas implícitas em containers**: Imagens Docker construídas sem especificação de plataforma (`--platform linux/arm64`) frequentemente contêm camadas compiladas para x86_64. Em pipelines de CI/CD que usam `docker buildx` sem multi-arch manifests, a imagem é silenciosamente executada via emulação QEMU — com degradação de performance de 30-60% e comportamentos de timing diferentes que podem afetar locks distribuídos e timeouts de heartbeat em clusters Kafka ou Zookeeper.

**Comportamento de JVM e garbage collection**: O Graviton4 com Neoverse V2 tem características de cache L3 diferentes do x86. Aplicações Java que foram tuned com flags como `-XX:+UseG1GC -XX:G1HeapRegionSize=16m` para um perfil de cache específico podem exibir padrões de GC diferentes em ARM64. Em sistemas de trading com SLOs de latência p99 < 5ms, uma regressão de GC pause de 2ms pode ser a diferença entre cumprir e violar o SLO.

**Bibliotecas de criptografia nativas**: Aplicações que usam OpenSSL via JNI ou libssl diretamente precisam de builds específicos para ARM64. O OpenSSL 3.x tem suporte nativo a instruções criptográficas ARM (AES-CE, SHA-CE), e quando compilado corretamente pode ser 2-3x mais rápido que x86 para operações TLS. Mas uma build incorreta silenciosamente cai para implementações de software, degradando throughput de conexões mTLS em APIs de alta frequência.

## Anti-Padrões Críticos na Adoção de R8g em Ambientes Financeiros

- **Lift-and-shift sem validação de binários ARM64**: Migrar AMIs ou imagens de container de x86 para R8g sem verificar cada dependência nativa resulta em execução silenciosa via emulação ou falhas de segfault em produção. Use `file $(which java)` e `ldd` para auditar binários antes de qualquer deploy.
- **Sizing baseado em equivalência de vCPU x86**: Um r8g.4xlarge com 16 vCPUs ARM64 não é equivalente a um r6i.4xlarge com 16 vCPUs x86 para todos os workloads. Para cargas com alta densidade de threads e operações de inteiros (processamento de mensagens FIX, por exemplo), o Graviton4 frequentemente supera.
- **EBS sem io2 Block Express para bancos de dados críticos**: Usar gp3 com throughput padrão (125 MB/s) em um r8g.8xlarge que suporta 40 Gbps de bandwidth para EBS é desperdiçar a capacidade da instância. Para PostgreSQL ou Oracle em R8g, io2 Block Express com IOPS provisionados (até 256.000 IOPS por volume) é o único volume que escala proporcionalmente à capacidade de I/O da instância.
- **Ignorar NUMA topology em instâncias bare metal**: Os dois tamanhos bare metal do R8g (r8g.metal-24xl e r8g.metal-48xl) expõem a topologia NUMA diretamente ao sistema operacional. Aplicações que não são NUMA-aware — especialmente bancos de dados que alocam grandes pools de memória — podem sofrer degradação severa de latência por remote NUMA access.
- **Ausência de estratégia de Savings Plans antes da migração**: R8g em regiões recém-habilitadas (Cape Town, Milão, Calgary) pode ter capacidade On-Demand limitada nos primeiros meses. Planejar migrações críticas sem Compute Savings Plans ou Reserved Instances de 1 ano para os tamanhos-alvo expõe a operação a risco de capacidade e custo variável elevado.

## Sizing e Custo: A Matemática Real para Sistemas de Cache e Banco de Dados

A decisão de sizing em R8g para sistemas financeiros envolve três variáveis que raramente aparecem juntas nas análises: **working set de memória**, **taxa de transferência de I/O sustentada** e **densidade de conexões**.

Para um cluster Redis/Valkey que serve como cache de posições de trading com 200 GB de working set ativo, um r8g.2xlarge (8 vCPU, 64 GB) em múltiplas instâncias com replicação é inferior a um r8g.4xlarge (16 vCPU, 128 GB) com réplica de leitura — não apenas por custo, mas porque a latência de rede entre nós de cluster adiciona jitter que viola SLOs de p99 < 1ms em operações GET/SET de alta frequência. O Graviton4 com DDR5 entrega latência de acesso à memória consistentemente menor que DDR4 em cargas de cache, o que é mensurável em benchmarks Redis com `redis-benchmark -n 1000000 -c 100`.

Para PostgreSQL em workloads OLTP de alta concorrência (sistemas de liquidação com 5.000+ conexões simultâneas), o r8g.8xlarge (32 vCPU, 256 GB) com `max_connections=5000` e `shared_buffers=64GB` é um ponto de partida razoável. O ganho de 40% em performance de banco de dados do Graviton4 sobre Graviton3 se manifesta principalmente em operações de sort, hash join e index scan — operações centrais em queries de reconciliação de transações.

Na perspectiva de custo, Graviton4 historicamente oferece 20-40% de melhor custo por performance que instâncias x86 equivalentes. Com Compute Savings Plans de 3 anos com pagamento parcial antecipado, o TCO de um r8g.8xlarge é tipicamente 50-60% menor que um r6i.8xlarge equivalente em On-Demand, considerando o delta de performance. Para equipes de FinOps em instituições financeiras, esse delta justifica o investimento em migração mesmo considerando o custo de retrabalho de binários e testes de regressão.

## R8g vs R7g vs R6i: Trade-offs para Workloads Financeiros
| Critério | Dimensão | R8g (Graviton4) | R7g (Graviton3) | R6i (Intel Ice Lake) |
| --- | --- | --- | --- | --- |
| Memória máxima | 1,5 TB (48xlarge) | 512 GB (16xlarge) | 1,5 TB (48xlarge) | — |
| vCPUs máximos | 192 vCPUs | 64 vCPUs | 192 vCPUs | — |
| Bandwidth de rede | 50 Gbps | 25 Gbps | 50 Gbps | — |
| Compatibilidade binária | ARM64 — requer validação | ARM64 — requer validação | x86_64 — compatibilidade ampla | — |
| Custo relativo (On-Demand) | Mais baixo (~20-40% vs x86) | Baixo | Referência x86 | — |
| Melhor para | Novos projetos, Java, cache, DB — máxima performance e economia | Workloads ARM64 já validados sem necessidade de escala extrema | Legado x86, ISVs com licença por socket, dependências nativas x86 | — |

## Expansão Regional e Soberania de Dados: Por Que Cape Town e Milão Importam

A disponibilização do R8g em regiões como África (Cape Town) e Europa (Milão) não é apenas uma questão de latência geográfica — é uma questão de soberania de dados e conformidade regulatória. A região da África do Sul é relevante para instituições financeiras que operam sob o POPIA (Protection of Personal Information Act) e que precisam manter dados de clientes sul-africanos em território nacional. Antes da disponibilização do R8g em Cape Town, a escolha era entre instâncias de geração anterior com capacidade limitada ou aceitar o custo de compliance de processar dados fora do país.

Para a Europa (Milão), a relevância é o GDPR e as regulações do Banco d'Italia para instituições financeiras italianas. A disponibilidade de instâncias R8g com 1,5 TB de RAM na região eu-south-1 permite que bancos e fintechs italianas consolidem workloads de análise de risco e anti-lavagem de dinheiro (AML) que antes exigiam arquiteturas distribuídas entre regiões, com toda a complexidade de conformidade associada.

Do ponto de vista arquitetural, a expansão regional do R8g também tem implicações para estratégias de DR (Disaster Recovery). Com R8g disponível em múltiplas regiões dentro de uma mesma jurisdição regulatória (por exemplo, eu-south-1 Milão e eu-central-1 Frankfurt para a União Europeia), é possível construir estratégias de Active-Active com failover automático via Route 53 ARC (Application Recovery Controller) sem violar requisitos de residência de dados — algo que antes exigia compromissos de performance com instâncias de menor capacidade nas regiões secundárias.

## R8g no Framework Well-Architected: Análise por Pilar

- **security**: O Nitro System fornece isolamento de hardware auditável. Combine com EBS encryption usando CMKs regionais do KMS, políticas de SCP que restringem `ec2:RunInstances` a regiões aprovadas, e IMDSv2 obrigatório (desabilite IMDSv1 via `aws ec2 modify-instance-metadata-options --http-tokens required`). Para bare metal, implemente dm-crypt com LUKS para volumes de dados sensíveis adicionalmente à criptografia EBS.
- **reliability**: Use Auto Scaling Groups com `InstanceMaintenancePolicy` configurado para `MinHealthyPercentage=100` durante manutenção para evitar degradação de capacidade. Para bancos de dados críticos em R8g, implemente Multi-AZ com réplicas em instâncias do mesmo tipo para garantir failover sem regressão de performance. Monitore `EBSIOBalance%` e `EBSByteBalance%` no CloudWatch — quando abaixo de 10%, o burst de I/O está esgotado.
- **performance**: Habilite Enhanced Networking com ENA Express para latência de rede sub-100μs entre instâncias R8g no mesmo placement group. Para workloads Java, use Amazon Corretto 21 com ZGC (`-XX:+UseZGC`) — o ZGC foi otimizado para ARM64 e entrega pausas de GC sub-millisecond em heaps de até 256 GB, crítico para SLOs de latência em sistemas de trading.
- **sustainability**: Graviton4 oferece a melhor eficiência energética da linha EC2 para workloads de memória intensiva. A AWS reporta que instâncias Graviton consomem até 60% menos energia que instâncias x86 equivalentes para a mesma performance. Para relatórios de ESG de instituições financeiras, a migração de R6i para R8g pode ser documentada como redução de pegada de carbono computacional — use o Customer Carbon Footprint Tool para quantificar o delta.

> **Minha Perspectiva: O Que Eu Faria de Diferente:** Na prática, a migração para R8g que eu recomendaria começa não pelo lift-and-shift, mas por um workload novo ou por um componente de cache — especificamente Redis ou Valkey — onde o risco de regressão é baixo e o ganho de memória é imediato e mensurável. A lição mais cara que aprendi em migrações Graviton é que o maior risco não está nos binários que falham — está nos que funcionam silenciosamente com performance degradada por emulação ou por ausência de otimizações SIMD específicas. Por isso, nunca inicio uma migração sem um benchmark de baseline documentado com `wrk2` ou `gatling` para APIs e `pgbench` para bancos de dados, executado na instância de origem antes de qualquer mudança. E para ambientes financeiros regulados nas novas regiões (Cape Town, Milão), a primeira ação é garantir que a CMK do KMS seja regional e que as SCPs estejam em vigor antes de provisionar qualquer instância R8g — compliance não é uma etapa posterior.

## Veredicto: R8g é a Escolha Padrão para Novos Workloads Memory-Intensive

As instâncias EC2 R8g com Graviton4 representam uma mudança de geração genuína, não incremental. O salto de 3x em capacidade de memória (até 1,5 TB), os ganhos de 40-45% em performance para bancos de dados e Java, e a expansão para regiões com requisitos de soberania de dados (Cape Town, Milão, Calgary) tornam o R8g a escolha padrão para qualquer novo workload memory-intensive que não tenha dependências nativas x86 irreconciliáveis. Para workloads existentes em R7g ou R6i, a migração é justificável economicamente — mas exige um processo rigoroso de validação de binários, benchmarking de baseline e estratégia de rollback. O Nitro System como fundação de segurança, combinado com CMKs regionais e perímetros de dados via IAM conditions, torna o R8g defensável em auditorias de conformidade financeira. A recomendação prática: comece com cache e bancos de dados não-críticos nas novas regiões, estabeleça métricas de baseline, e migre workloads críticos apenas após validação completa de performance e conformidade. Não trate a expansão regional como um evento de disponibilidade — trate como uma oportunidade de redesenho arquitetural com critérios de sucesso mensuráveis.

**Rating:** Adopt for new workloads / Migrate with r

## 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 Instance Types — AWS Documentation](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 — AWS GitHub](https://github.com/aws/porting-advisor-for-graviton)
- [AWS Nitro System — Architecture Overview](https://aws.amazon.com/ec2/nitro/)
- [Amazon EC2 R8gd Instances in Additional Regions (Mar 26, 2026)](https://aws.amazon.com/about-aws/whats-new/2026/03/amazon-ec2-r8gd-aws-regions/)
- [Amazon EC2 R8g Instances in Additional Regions — Mar 2026 (UAE, Mexico, Zurich)](https://aws.amazon.com/about-aws/whats-new/2026/03/amazon-ec2-r8g-instances-additional-regions/)
- [AWS Well-Architected Framework — Performance Efficiency Pillar](https://docs.aws.amazon.com/wellarchitected/latest/performance-efficiency-pillar/welcome.html)