# R8i: Anatomia de uma Família de Instâncias para Workloads Intensivos

A família R8i chega a Tokyo, Frankfurt e Irlanda com 600 Gbps de banda de rede e 300 Gbps de banda EBS — os maiores números entre instâncias EC2 não aceleradas. Antes de migrar cargas críticas, vale dissecar a anatomia dessas quatro variantes, entender os trade-offs reais e saber exatamente quando essa família resolve o problema e quando ela é a escolha errada.

- URL: https://fernando.moretes.com/blog/r8i-anatomia-de-uma-familia-de-instancias-para-workloads-intensivos-amazon-ec2-n

- Markdown: https://fernando.moretes.com/blog/r8i-anatomia-de-uma-familia-de-instancias-para-workloads-intensivos-amazon-ec2-n/article.md?lang=pt

- Published: 2026-07-12T09:03:31.392Z

- Category: IA & Agentes

- Tags: ec2, r8i, nitro, efa, financial-grade, data-platform, storage, networking

- Reading time: 10 min

- Source: [Amazon EC2 network/EBS instances now available in additional regions](https://aws.amazon.com/about-aws/whats-new/2026/07/amazon-ec2-r8in-r8ib-r8idn-r8idb)

---

Quando a AWS anuncia que uma família de instâncias chega a novas regiões, a notícia parece operacional. Mas a expansão das R8in, R8ib, R8idn e R8idb para Tokyo, Frankfurt e Irlanda é um sinal arquitetural: essas instâncias carregam os maiores números de largura de banda de rede e EBS entre instâncias EC2 não aceleradas, e agora estão disponíveis nos três hubs de latência mais críticos para sistemas financeiros globais. Este artigo disseca o padrão de design que essas instâncias habilitam — não apenas o hardware, mas a lógica de quando cada variante é a escolha certa, quando ela é um desperdício e como instrumentar e operar esse padrão em produção.

## O Problema que a Família R8i Resolve

Durante anos, arquitetos de sistemas financeiros e de dados em larga escala conviveram com um dilema clássico de instâncias EC2: escolher entre memória abundante (família R) e largura de banda de rede ou armazenamento suficiente para não criar gargalos nos nós de processamento. A geração R6i entregava boas densidades de memória, mas a banda de rede e EBS ficavam aquém quando o padrão de acesso era intensivo em I/O — pense em caches distribuídos de dados de mercado, clusters Kafka com retenção longa, ou nós de coordenação de bancos de dados analíticos como Apache Doris ou ClickHouse.

O problema não é teórico. Em um cluster MSK com nós R6i.8xlarge, a largura de banda de rede por nó limitava o throughput de replicação entre brokers durante picos de ingestão de eventos de mercado — o que forçava over-provisioning horizontal para compensar um gargalo que era fundamentalmente de I/O de rede, não de CPU ou memória. O mesmo padrão aparecia em clusters de cache Redis para pricing engines: a latência de leitura P99 degradava não por contenção de memória, mas por saturação de banda de rede entre os nós de réplica e os clientes.

A família R8i resolve isso atacando os dois eixos de I/O simultaneamente, com quatro variantes especializadas que cobrem os casos de uso mais comuns: workloads puramente de rede (R8in), workloads de rede com necessidade de armazenamento local (R8idn), workloads de alto throughput EBS (R8ib) e workloads que precisam dos dois — EBS e NVMe local (R8idb). A distinção entre essas variantes não é cosmética; ela determina o modelo de custo, o padrão de resiliência e a estratégia de observabilidade.

## Números que Importam: R8i vs. Geração Anterior

- **600 Gbps** — Banda de rede máxima (R8in / R8idn). Maior entre instâncias EC2 com enhanced networking, sem acelerador dedicado
- **300 Gbps** — Banda EBS máxima (R8ib / R8idb). Maior entre instâncias EC2 não aceleradas para throughput de bloco
- **+43%** — Ganho de compute por vCPU vs. R6in/R6idn. Processadores Intel Xeon Scalable de 6ª geração customizados para AWS, com Nitro cards de 6ª geração
- **EFA** — Suporte a Elastic Fabric Adapter nos tamanhos 48xlarge, 96xlarge, metal-48xl e. Habilita clusters fortemente acoplados com menor latência de comunicação inter-nó

## Mapa de Decisão: Qual Variante R8i para Qual Workload

O diagrama mostra os quatro eixos de decisão (rede, armazenamento local, EBS, compute) e como cada variante da família R8i se posiciona em relação aos padrões de workload mais comuns em sistemas financeiros e de dados.

### 🧠 Workload Patterns

- Distributed Cache (Redis/Memcached) (data)
- MSK / Kafka Broker (messaging)
- NoSQL DB (Cassandra/Mongo) (storage)
- Data Lake Node (Spark/Flink) (compute)

### ⚡ R8i Variants

- R8in 600 Gbps Net No local NVMe (network)
- R8idn 600 Gbps Net + Local NVMe (network)
- R8ib 300 Gbps EBS No local NVMe (storage)
- R8idb 300 Gbps EBS + Local NVMe (storage)

### 🔗 EFA Cluster Layer

- EFA 48xl / 96xl metal sizes (network)
- Placement Group (Cluster) (network)

### 📊 Observability

- CloudWatch NetworkIn/Out EBSReadBytes (external)
- OpenTelemetry Collector (node-level) (external)

### Fluxos

- wl_cache -> r8in: rede dominante
- wl_kafka -> r8idn: rede + log local
- wl_nosql -> r8ib: EBS alto throughput
- wl_datalake -> r8idb: EBS + NVMe shuffle
- r8in -> efa: 48xl/96xl/metal
- r8idn -> efa: 48xl/96xl/metal
- r8ib -> efa: 48xl/96xl/metal
- r8idb -> efa: 48xl/96xl/metal
- efa -> placement: requer cluster PG
- r8in -> cw_net: métricas de rede
- r8ib -> cw_net: métricas EBS
- cw_net -> otel: exporta para OTEL

## Anatomia das Quatro Variantes: Mais do que Sufixos de Nome

A nomenclatura da AWS para a família R8i segue uma lógica precisa que vale decodificar antes de qualquer sizing exercise. O sufixo **'n'** indica enhanced networking — a instância tem capacidade de rede elevada como característica primária. O sufixo **'b'** indica EBS-optimized com banda de bloco maximizada. O sufixo **'d'** indica a presença de armazenamento local NVMe (instance store). As combinações resultam nas quatro variantes: R8in (rede alta, sem NVMe local), R8idn (rede alta com NVMe local), R8ib (EBS alto, sem NVMe local) e R8idb (EBS alto com NVMe local).

O ponto crítico para arquitetos é que **NVMe local (instance store) não é persistente**. Dados gravados no instance store são perdidos quando a instância para ou falha. Isso não é um bug — é um contrato de design. Para workloads como brokers Kafka, onde o log de partição pode ser reconstruído por replicação, o NVMe local é excelente para throughput de escrita sequencial e latência de leitura de dados quentes. Para workloads como bancos de dados primários sem replicação síncrona, usar NVMe local como storage principal é um anti-padrão grave.

A distinção entre R8in e R8idn é igualmente importante do ponto de vista de custo. O R8idn carrega o custo do NVMe local no preço da instância — você paga por ele independentemente de usá-lo. Se o workload não tem acesso sequencial intensivo a dados locais (por exemplo, um cache Redis puro onde todos os dados cabem na memória), o R8in entrega a mesma banda de rede a um custo menor. Em sistemas financeiros onde o sizing de instâncias é revisado trimestralmente por equipes de FinOps, essa distinção pode representar dezenas de milhares de dólares por ano em clusters de dezenas de nós.

O suporte a EFA (Elastic Fabric Adapter) nos tamanhos 48xlarge, 96xlarge, metal-48xl e metal-96xl merece atenção especial. EFA não é apenas 'rede mais rápida' — é um modelo de comunicação diferente que bypassa o kernel para operações MPI e NCCL, reduzindo latência de comunicação inter-nó de dezenas de microssegundos para single-digit microseconds em clusters fortemente acoplados. Para workloads de treinamento distribuído de modelos de risco ou simulações de Monte Carlo em larga escala, isso muda o modelo de paralelismo viável.

## R8i: Guia de Seleção de Variante por Padrão de Workload
| Critério | Critério | R8in | R8idn | R8ib | R8idb |
| --- | --- | --- | --- | --- | --- |
| Banda de rede máxima | 600 Gbps | 600 Gbps | Alta (EBS-otimizado) | Alta (EBS-otimizado) | — |
| Banda EBS máxima | Padrão R8i | Padrão R8i | 300 Gbps | 300 Gbps | — |
| Armazenamento local NVMe | Não | Sim | Não | Sim | — |
| Persistência de dados | EBS (persistente) | EBS + NVMe (NVMe efêmero) | EBS (persistente) | EBS + NVMe (NVMe efêmero) | — |
| Caso de uso primário | Cache distribuído, analytics em tempo real, 5G UPF | Kafka/MSK broker, sistemas de arquivos distribuídos | NoSQL DB, file systems de alto throughput | Data lakes, bancos comerciais grandes, NoSQL com NVMe | — |
| Suporte EFA | 48xl, 96xl, metal | 48xl, 96xl, metal | 48xl, 96xl, metal | 48xl, 96xl, metal | — |

## Quando Usar a Família R8i: Padrões de Referência em Sistemas Financeiros

Em sistemas financeiros de grau institucional, os padrões que mais se beneficiam das instâncias R8i são aqueles onde o gargalo é mensurável e está explicitamente no plano de I/O — não em CPU, não em memória, mas em bytes por segundo que precisam se mover entre nós ou entre instância e storage.

**Padrão 1: Cluster MSK/Kafka de alta ingestão.** Um cluster de brokers MSK self-managed com R8idn.12xlarge ou R8idn.24xlarge é a escolha certa quando o throughput de replicação entre brokers (replication.factor=3, min.insync.replicas=2) satura a banda de rede dos nós. O NVMe local serve como log de partição de baixa latência, enquanto o EBS (gp3 ou io2) serve como camada de retenção de longo prazo. A métrica de alerta crítica aqui é `NetworkOut` por broker — quando ela ultrapassa 70% da banda máxima sustentada por mais de 5 minutos, é hora de escalar horizontalmente ou fazer upsizing. Com R8idn, esse threshold sobe substancialmente em relação ao R6i.

**Padrão 2: Cache de dados de mercado (Redis Cluster).** Para pricing engines e sistemas de risk management que mantêm snapshots de dados de mercado em memória, o R8in.8xlarge ou R8in.16xlarge é o sweet spot. A banda de 600 Gbps garante que a latência de leitura P99 não degrade durante picos de volatilidade quando múltiplos clientes fazem pipeline de leituras simultaneamente. A configuração recomendada inclui `maxmemory-policy allkeys-lru`, replicação assíncrona entre AZs e CloudWatch Alarm em `CurrConnections` e `NetworkBytesOut`.

**Padrão 3: Nós de coordenação de data lake (Apache Spark/Flink).** Para nós de driver e executor em jobs de processamento de dados de fim de dia (EOD batch) em sistemas de liquidação, o R8idb combina NVMe local para shuffle de dados intermediários (eliminando spill para EBS durante joins grandes) com banda EBS de 300 Gbps para leitura de datasets de origem em S3 via S3 Mount ou EMRFS. O ganho de 43% em compute por vCPU em relação ao R6i reduz diretamente o tempo de janela de processamento noturno — crítico para sistemas que precisam fechar posições antes da abertura do mercado asiático.

## Anti-Padrões: Quando a Família R8i é a Escolha Errada

- **Usar R8idn/R8idb para workloads stateful sem estratégia de replicação para o NVMe local.** O instance store é efêmero. Se a aplicação trata o NVMe local como storage primário sem replicação síncrona para EBS ou outro nó, qualquer falha de hardware ou stop/start da instância resulta em perda de dados.
- **Over-provisioning com R8in quando o gargalo real é de CPU ou memória.** Se o perfil de uso mostra CPU acima de 70% e rede abaixo de 30% da capacidade máxima, a família R8i é cara demais para o problema. Instâncias R8g (Graviton4) ou M8g oferecem melhor custo-benefício para workloads compute-bound com requisitos de memória moderados.
- **Usar EFA sem Placement Group de cluster.** EFA entrega suas garantias de latência apenas quando os nós estão no mesmo placement group de cluster dentro de uma AZ. Habilitar EFA em instâncias distribuídas por múltiplas AZs sem placement group resulta em latência de rede normal — você paga pelo tamanho de instância que suporta EFA sem obter o benefício de latência que justifica o custo.
- **Migrar para R8i sem baseline de métricas da geração anterior.** Sem dados históricos de `NetworkIn/Out`, `EBSReadBytes/WriteBytes` e `CPUUtilization` da geração R6i, é impossível validar se o upgrade entregou o benefício esperado ou se o gargalo real estava em outro lugar.
- **Assumir que 600 Gbps de banda de rede é disponível em todos os tamanhos.** A banda máxima de 600 Gbps é atingida nos tamanhos maiores (48xlarge, 96xlarge, metal). Instâncias menores como R8in.8xlarge têm banda proporcionalmente menor. Sempre consultar a tabela de especificações por tamanho antes de sizing — o erro de assumir banda máxima em tamanhos menores leva a SLOs de latência não atingidos

## Operação e Observabilidade: O que Monitorar em Produção

A capacidade de hardware das instâncias R8i é necessária mas não suficiente. O valor real só se materializa se a stack de observabilidade consegue detectar quando o workload está se aproximando dos limites — e quando está subutilizando recursos pagos.

Para instâncias R8in e R8idn, as métricas primárias de CloudWatch são `NetworkIn` e `NetworkOut` em bytes/segundo. O threshold de alerta recomendado é 75% da banda máxima sustentada para o tamanho específico da instância, com janela de avaliação de 5 minutos e 3 pontos de dados consecutivos — isso evita falsos positivos por bursts curtos enquanto captura saturação real. Complementarmente, `NetworkPacketsIn/Out` revela se o gargalo é de throughput (bytes) ou de packet rate (PPS) — dois problemas diferentes com soluções diferentes.

Para R8ib e R8idb, `EBSReadBytes`, `EBSWriteBytes`, `EBSReadOps` e `EBSWriteOps` são as métricas centrais. Para volumes io2 Block Express (recomendados para workloads financeiros que precisam de IOPS garantidos), monitorar também `BurstBalance` se o volume for gp3 — embora para R8ib com 300 Gbps de banda, gp3 raramente é a escolha certa; io2 com IOPS provisionados é mais adequado. A configuração de volume recomendada para bancos de dados NoSQL em R8ib é io2 Block Express com `--iops` calculado como throughput_alvo_MB/s × 4 (para blocos de 256KB), com `--throughput` explicitamente definido em MB/s.

Para clusters com EFA, o CloudWatch não expõe métricas nativas de EFA diretamente — é necessário usar o EFA metrics plugin para o agente CloudWatch ou exportar via OpenTelemetry Collector com o receiver `awscontainerinsightreceiver`. As métricas críticas são `rdma_read_bytes`, `rdma_write_bytes` e `rdma_read_wqe_errors` — erros de WQE indicam problemas de configuração de placement group ou de versão de driver EFA. Em ambientes EKS, o Device Plugin da EFA para Kubernetes deve ser instalado e os pods que precisam de EFA devem requisitar `vpc.amazonaws.com/efa: 1` como resource limit.

## Segurança e Governança: O que Muda com Instâncias de Alta Performance

Instâncias de alta performance introduzem superfícies de ataque e vetores de risco que não existem em instâncias de uso geral. A banda de 600 Gbps significa que uma instância comprometida pode exfiltrar dados em velocidade que torna a detecção baseada em threshold de volume praticamente inútil — o dado já saiu antes do alarme disparar. Isso exige uma postura de segurança diferente.

O primeiro controle é o de rede: Security Groups para instâncias R8i em ambientes financeiros devem seguir o princípio de least privilege estrito. Para clusters Kafka com R8idn, as regras de Security Group devem permitir tráfego de replicação (porta 9093 para TLS) apenas entre os Security Groups dos brokers, e tráfego de cliente apenas dos Security Groups dos produtores e consumidores autorizados. VPC Flow Logs devem estar habilitados com formato personalizado incluindo `pkt-src-aws-service` e `pkt-dst-aws-service` para distinguir tráfego AWS-interno de tráfego externo — e esses logs devem ser exportados para S3 com retenção mínima de 90 dias para compliance.

Para volumes EBS em R8ib e R8idb, a criptografia com KMS é obrigatória em ambientes regulados (PCI-DSS, SOC2). A configuração recomendada usa uma CMK (Customer Managed Key) por workload com política de chave que restringe `kms:Decrypt` e `kms:GenerateDataKeyWithoutPlaintext` ao IAM Role específico da instância — não ao account root. A rotação automática de chave deve estar habilitada. Para o NVMe local em R8idn e R8idb, a criptografia é gerenciada pelo Nitro card e é transparente — mas isso não substitui criptografia em nível de aplicação para dados altamente sensíveis, pois o NVMe local não tem o mesmo modelo de auditoria do EBS com KMS.

IAM Instance Profiles para instâncias R8i devem usar condições de contexto de sessão (`aws:RequestedRegion`, `aws:SourceVpc`) para garantir que as permissões só são exercidas dentro do perímetro esperado. Em ambientes multi-conta, o uso de Resource Control Policies (RCPs) na AWS Organizations para restringir o lançamento de instâncias R8i a contas específicas evita que equipes de desenvolvimento usem esses tipos de instância inadvertidamente — o custo por hora de um R8in.96xlarge pode surpreender um time sem governança de FinOps.

## Lente Well-Architected: Família R8i em Sistemas Financeiros

- **security**: Criptografia EBS com CMK por workload, VPC Flow Logs com retenção de 90 dias, Security Groups com least privilege estrito, e RCPs para controlar quais contas podem lançar instâncias R8i. Para NVMe local, complementar a criptografia Nitro com criptografia em nível de aplicação para dados de PII ou dados de mercado proprietários.
- **reliability**: Nunca tratar NVMe local (instance store) como storage primário sem replicação síncrona. Para clusters Kafka com R8idn, manter replication.factor=3 e min.insync.replicas=2. Para bancos NoSQL em R8idb, usar o NVMe como cache de leitura ou log de escrita com flush periódico para EBS. Placement Groups de cluster para EFA devem ser planejados considerando o limite de capacidade por AZ.
- **performance**: Validar o gargalo real antes de migrar para R8i — se o bottleneck é CPU ou memória, outras famílias são mais eficientes. Para EFA, usar Placement Groups de cluster e validar com benchmark de latência inter-nó antes de produção. Monitorar NetworkOut e EBSWriteBytes com thresholds de 75% para detectar saturação antes que impacte SLOs.

> **Sizing Correto: Comece pelo Gargalo, não pela Família:** Antes de qualquer migração para R8i, execute pelo menos 2 semanas de coleta de métricas de `NetworkIn/Out`, `EBSReadBytes/WriteBytes` e `CPUUtilization` na geração atual com granularidade de 1 minuto no CloudWatch. Exporte para S3 e analise os percentis P95 e P99 — não a média. Se o P95 de `NetworkOut` está abaixo de 40% da capacidade máxima da instância atual, o gargalo provavelmente não é de rede e a migração para R8in não vai resolver o problema. Se o P95 está acima de 80%, você tem um caso claro. O intervalo entre 40% e 80% exige análise de correlação com latência de aplicação antes de decidir.

> **Nota do Curador:** Na minha experiência com clusters de dados em ambientes financeiros, o erro mais caro que já vi não foi escolher a instância errada — foi migrar para uma instância mais cara sem instrumentação suficiente para provar o valor. Com R8i chegando a Tokyo e Frankfurt, a pressão para migrar clusters críticos vai aumentar, especialmente em equipes que operam sistemas de liquidação ou pricing engines nessas regiões. Minha recomendação prática: implante um único nó R8idn em shadow mode no cluster Kafka de produção, exporte métricas via OpenTelemetry para Datadog ou CloudWatch, e compare o perfil de saturação de rede por 30 dias antes de comprometer o cluster inteiro. O custo do experimento é marginal; o custo de um sizing errado em 20 nós com Savings Plans de 1 ano não é. A lição dura: hardware melhor não substitui arquitetura melhor — ele amplifica o que já está lá, para o bem e para o mal.

## Veredicto: R8i é Especialista, não Generalista

A família R8i — especialmente com a chegada a Tokyo, Frankfurt e Irlanda — é a escolha certa para workloads onde o gargalo é explicitamente de I/O de rede ou de bloco: clusters Kafka/MSK de alta ingestão, caches de dados de mercado em Redis, nós de processamento de data lake com shuffle intensivo, e bancos NoSQL com requisitos de throughput de bloco acima do que gp3 pode entregar de forma econômica. O ganho de 43% em compute por vCPU sobre a geração R6i é real e relevante para workloads que combinam I/O intensivo com processamento não trivial. O suporte a EFA nos tamanhos maiores abre um caso de uso adicional para clusters fortemente acoplados em HPC financeiro.

Mas a família R8i não é uma upgrade universal. Para workloads compute-bound ou memory-bound sem gargalo de I/O mensurável, R8g (Graviton4) ou M8g oferecem melhor TCO. Para workloads stateful que precisam de persistência garantida, o NVMe local das variantes 'd' exige uma estratégia de replicação explícita — sem isso, é um risco de perda de dados esperando para acontecer. A decisão de migrar deve ser baseada em dados de observabilidade, não em especificações de marketing. Instrumente primeiro, migre depois.

## Referências

- [AWS What's New: Amazon EC2 R8in, R8ib, R8idn, R8idb now available in Tokyo, Frankfurt, Ireland (Jul 10, 2026)](https://aws.amazon.com/about-aws/whats-new/2026/07/amazon-ec2-r8in-r8ib-r8idn-r8idb)
- [Amazon EC2 R8i Instance Page](https://aws.amazon.com/ec2/instance-types/r8i/)
- [AWS Blog: Automating Amazon EBS Volume Resizing with Step Functions and Systems Manager](https://aws.amazon.com/blogs/storage/automating-amazon-ebs-volume-resizing-with-aws-step-functions-and-aws-systems-manager/)
- [AWS Documentation: Elastic Fabric Adapter (EFA)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/efa.html)
- [AWS Documentation: Amazon EBS Volume Types (io2 Block Express)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volume-types.html)
- [AWS Documentation: Instance Store Volumes](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/InstanceStorage.html)
- [AWS Architecture Center: Data Analytics Lens](https://docs.aws.amazon.com/wellarchitected/latest/analytics-lens/analytics-lens.html)
- [AWS Documentation: VPC Flow Logs Custom Format](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html)