# Migrando Workloads Financeiros para EC2 R8i: Decisões e Trade-offs

A disponibilização das instâncias EC2 R8i (R8in, R8ib, R8idn, R8idb) em Tokyo, Frankfurt e Irlanda em julho de 2026 abre uma janela concreta de modernização para plataformas financeiras que ainda operam em R6i/R6in — gerações com limitações reais de banda de rede e throughput de EBS. Este artigo narra a jornada de migração como uma sequência de decisões de arquitetura, com os riscos gerenciados em cada etapa e os números que justificam a movimentação.

- URL: https://fernando.moretes.com/blog/migrando-workloads-financeiros-para-ec2-r8i-decisoes-e-trade-offs-amazon-ec2-n

- Markdown: https://fernando.moretes.com/blog/migrando-workloads-financeiros-para-ec2-r8i-decisoes-e-trade-offs-amazon-ec2-n/article.md?lang=pt

- Published: 2026-07-13T09:03:52.623Z

- Category: IA & Agentes

- Tags: EC2, R8i, migration, financial-grade, MSK, EBS, networking, performance

- Reading time: 12 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 expandiu as instâncias R8in, R8ib, R8idn e R8idb para Tokyo, Frankfurt e Irlanda em 10 de julho de 2026, a decisão não foi apenas de disponibilidade regional — foi um gatilho de modernização para plataformas financeiras que operam sob SLOs de latência de microssegundos e throughput de dados na casa dos terabytes por hora. Migrar não é trocar um tipo de instância; é reescrever contratos operacionais com o hardware.

## O Ponto de Partida: Por Que R6i Começou a Doer

Em ambientes financeiros de alta frequência — plataformas de liquidação em tempo real, motores de precificação de derivativos, caches de dados de mercado — o R6in era o teto prático durante anos. Com 100 Gbps de largura de banda de rede no tamanho 32xlarge, ele era suficiente para a maioria dos clusters Kafka/MSK de 2022. Mas o mercado não ficou parado.

O problema surgiu em três frentes simultâneas. Primeiro, os clusters MSK cresceram: tópicos de market data com retenção de 72 horas e fatores de replicação 3 começaram a saturar a largura de banda de rede dos brokers em horários de pico de volatilidade — exatamente quando você menos quer throttling. Segundo, os índices de banco de dados NoSQL (DynamoDB Accelerator em modo cluster, ScyllaDB auto-gerenciado) passaram a exigir IOPS de EBS na faixa de 256.000 por instância, e o R6ib com seu teto de ~260 Gbps de EBS começou a mostrar latências de leitura acima de 500µs no P99 — inaceitável para um motor de risco intraday. Terceiro, os pipelines de ML para detecção de fraude em tempo real, rodando em instâncias do mesmo cluster, precisavam de largura de banda de rede suficiente para trafegar feature vectors de alta dimensão entre nós sem introduzir jitter mensurável.

A combinação dessas três pressões criou um cenário claro: a geração R6i estava sendo usada no limite do envelope de performance, sem margem para crescimento orgânico. A expansão regional do R8i para os datacenters onde essas plataformas operam — Tokyo para mercados asiáticos, Frankfurt e Irlanda para compliance europeu sob MiFID II — tornou a migração não apenas desejável, mas necessária.

## A Jornada de Migração: Seis Decisões em Sequência

1. **Passo 1 — Mapeamento de Workload e Seleção de Subfamília** — Antes de qualquer movimentação, classifiquei cada workload em dois eixos: dominância de rede versus dominância de armazenamento. Brokers MSK e caches Redis Cluster foram para R8in (600 Gbps de rede, sem NVMe local — dados efêmeros não precisam de persistência local). Bancos de dados ScyllaDB e ClickHouse foram para R8idb (300 Gbps EBS + NVMe local para compactação e WAL). Motores de risco que precisam de ambos foram para R8idn (600 Gbps de rede + NVMe local). A regra: nunca pague por NVMe local se o workload não usa storage local de forma intensiva — o custo por hora do R8idn é materialmente maior que o R8in.

2. **Passo 2 — Baseline de Performance e Definição de SLOs de Migração** — Instrumentei os clusters R6i existentes com CloudWatch Agent + métricas customizadas via EMF (Embedded Metrics Format) para capturar: network_bytes_in/out por instância em janelas de 1 minuto, EBS VolumeReadLatency e VolumeWriteLatency no P50/P95/P99, e CPU steal time (indicador de noisy neighbor em instâncias compartilhadas). Defini SLOs de migração: a instância R8i substituta deve demonstrar P99 de latência de rede ≤70% do baseline R6i sob carga sintética equivalente, antes de qualquer promoção para produção. Sem esse gate, a migração é um ato de fé.

3. **Passo 3 — Habilitação de EFA e Reconfiguração de Placement Groups** — O R8i nos tamanhos 48xlarge, 96xlarge, metal-48xl e metal-96xl suporta Elastic Fabric Adapter (EFA). Para clusters MSK e ScyllaDB que se beneficiam de comunicação inter-nó de baixa latência, habilitei EFA com placement group do tipo 'cluster' dentro de uma única AZ. A armadilha: EFA requer que a interface de rede seja configurada no momento do lançamento — não é possível adicionar depois. Isso significa que o processo de migração não pode ser um simples stop/resize; é necessário lançar novas instâncias com o perfil correto e migrar dados de forma controlada. Para ScyllaDB, usei streaming de dados via nodetool rebuild; para MSK, o reassignment de partições via kafka-reassign-partitions.sh com throttle de 50 MB/s para não impactar produção.

4. **Passo 4 — Estratégia de Volumes EBS io2 Block Express** — Com 300 Gbps de largura de banda de EBS disponível no R8ib/R8idb, o gargalo se desloca para a configuração do volume. Volumes io2 Block Express suportam até 256.000 IOPS e 4.000 MB/s de throughput por volume — mas esses limites só são atingidos em instâncias com envelope de EBS suficiente. Configurei volumes io2 Block Express com IOPS provisionados de 200.000 por instância R8ib para os índices ScyllaDB, usando multi-attach desabilitado (cada volume exclusivo por instância para evitar contenção de I/O). A criptografia foi mantida com chaves KMS gerenciadas pelo cliente (CMK) com política de chave que restringe uso a roles IAM específicas via condição `kms:ViaService` e `aws:SourceAccount`.

5. **Passo 5 — Migração Blue/Green com Traffic Shifting Controlado** — Para cada camada, executei uma migração blue/green: o cluster R8i (green) foi provisionado em paralelo ao R6i (blue), com dados sincronizados via replicação nativa. O traffic shifting foi feito em incrementos de 10% usando Target Groups do NLB com peso, monitorando CloudWatch alarms em NetworkPacketLoss, EBSIOBalance e latência P99 da aplicação. O critério de rollback automático: qualquer alarme em estado ALARM por mais de 3 minutos consecutivos dispara um Lambda que reverte os pesos do Target Group para 0% no green. Esse mecanismo de rollback foi testado em staging antes da janela de produção — não confie em rollback que nunca foi exercitado.

6. **Passo 6 — Otimização de Custo com Savings Plans e Right-Sizing Pós-Migração** — Após estabilização (72 horas de produção plena no R8i), executei right-sizing baseado em métricas reais: instâncias com CPU médio abaixo de 25% e network abaixo de 30% do envelope foram rebaixadas para o próximo tamanho menor. Em seguida, comprei Compute Savings Plans de 1 ano cobrindo 70% da capacidade baseline — os 30% restantes ficam em On-Demand para absorver picos. A regra que sigo: nunca compre Savings Plans antes de 72 horas de dados reais no novo tipo de instância. O perfil de consumo muda com a geração de hardware, e comprar cedo pode resultar em over-commitment.

## O Perfil de Rede que Muda Tudo: 600 Gbps e o que Isso Significa na Prática

O número 600 Gbps de largura de banda de rede no R8in/R8idn precisa de contexto para ser útil. Em termos práticos, isso é 75 GB/s de throughput sustentado — suficiente para replicar um snapshot de 1 TB em menos de 14 segundos entre instâncias no mesmo placement group. Para um broker MSK com retenção de 72 horas e 50 partições por tópico, isso significa que o rebalanceamento de partições após uma falha de broker pode completar em segundos em vez de minutos, reduzindo drasticamente a janela de exposição a lag de consumidor.

Mas o número bruto esconde uma nuance importante: a largura de banda é compartilhada entre todas as interfaces de rede da instância, incluindo tráfego de replicação intra-cluster, tráfego de dados de aplicação e tráfego de gerenciamento. Em clusters MSK com alto volume de replicação, vi cenários onde 40% da largura de banda disponível era consumida por replicação interna — deixando 360 Gbps para tráfego de produção. Ainda assim, 360 Gbps é 3,6x o teto do R6in, o que representa uma margem operacional completamente diferente.

O suporte a EFA nos tamanhos maiores adiciona uma dimensão qualitativa, não apenas quantitativa. EFA bypassa o kernel TCP/IP para comunicação inter-nó usando RDMA-like semantics via libfabric, reduzindo latência de comunicação de dezenas de microssegundos para sub-10µs em condições ideais. Para um motor de precificação de opções que executa Monte Carlo distribuído entre 96 vCPUs em múltiplas instâncias, essa redução de latência de comunicação se traduz diretamente em redução do tempo de ciclo de simulação — o que, em um contexto de trading, pode ser a diferença entre uma cotação chegando dentro ou fora da janela de validade.

A configuração prática para EFA em clusters de computação financeira: use placement group do tipo 'cluster', habilite enhanced networking com ENA Express (disponível no R8i), e configure o MTU para 9001 bytes (jumbo frames) em toda a VPC subnet usada pelo cluster. Sem jumbo frames, você deixa throughput na mesa.

## Arquitetura de Migração: R6i → R8i em Plataforma Financeira

Fluxo de migração blue/green mostrando as camadas de workload, o roteamento controlado de tráfego e os mecanismos de observabilidade e rollback automático.

### 🔵 Blue — R6i (Produção Atual / Current Production)

- MSK Brokers R6in.32xlarge 100 Gbps (messaging)
- ScyllaDB R6ib.32xlarge ~260 Gbps EBS (storage)
- Risk Engine R6idn.32xlarge 100 Gbps + NVMe (compute)

### 🟢 Green — R8i (Novo Cluster / New Cluster)

- MSK Brokers R8in.48xlarge 600 Gbps + EFA (messaging)
- ScyllaDB R8idb.48xlarge 300 Gbps EBS io2 200k IOPS (storage)
- Risk Engine R8idn.48xlarge 600 Gbps + NVMe + EFA (compute)

### 🔀 Roteamento / Traffic Routing

- NLB Weighted Target Groups (network)

### 📊 Observabilidade / Observability

- CloudWatch Alarms P99 / EBSIOBalance (data)
- Rollback Lambda → 0% Green se ALARM 3min (compute)

### 🔐 Segurança / Security

- KMS CMK kms:ViaService aws:SourceAccount (security)

### Fluxos

- nlb -> msk_r6in: 90% → 0% (shifting)
- nlb -> msk_r8in: 10% → 100% (shifting)
- msk_r6in -> msk_r8in: Replicação de partições / Partition replication
- scylla_r6ib -> scylla_r8idb: nodetool rebuild
- scylla_r8idb -> kms_cmk: Criptografia EBS / EBS encryption
- cw_alarms -> rollback_lambda: ALARM → dispara / triggers
- rollback_lambda -> nlb: Reverte pesos / Reverts weights
- risk_r6idn -> risk_r8idn: Migração paralela / Parallel migration

## Compliance Europeu e a Relevância de Frankfurt e Irlanda

A expansão do R8i para Frankfurt (eu-central-1) e Irlanda (eu-west-1) não é geograficamente trivial para plataformas financeiras europeias. Sob MiFID II e DORA (Digital Operational Resilience Act, vigente desde janeiro de 2025), instituições financeiras que operam em mercados europeus precisam demonstrar que seus sistemas críticos têm resiliência operacional documentada, com RTO e RPO definidos e testados. A escolha de região não é apenas de latência — é de soberania de dados e conformidade regulatória.

Frankfurt é a região preferida para dados de clientes alemães e austríacos sob o BDSG (Bundesdatenschutzgesetz) e para operações que precisam permanecer dentro da jurisdição do Regulamento Geral de Proteção de Dados (RGPD) alemão. Irlanda cobre o restante da União Europeia com menor custo operacional. A disponibilidade do R8i em ambas as regiões significa que posso construir uma arquitetura ativa-ativa entre eu-central-1 e eu-west-1 usando R8in para os brokers MSK de cada região, com replicação cross-region via MirrorMaker 2 — e agora com hardware homogêneo nas duas pontas, o que elimina assimetrias de performance que antes complicavam o capacity planning.

Um detalhe operacional crítico para compliance: os volumes EBS io2 Block Express criptografados com CMK regional não podem ser copiados cross-region sem re-criptografia explícita. O processo correto é usar AWS Backup com planos de backup cross-region, garantindo que a chave de destino em eu-west-1 seja uma CMK separada com política de acesso auditada. Isso deve estar documentado em um ADR (Architecture Decision Record) com a justificativa regulatória — auditores do DORA vão perguntar especificamente sobre esse fluxo.

Para Tokyo (ap-northeast-1), o contexto é diferente: a FSA (Financial Services Agency) japonesa exige que dados de transações de clientes japoneses residam em território japonês. A disponibilidade do R8i em Tokyo significa que plataformas que antes usavam R6in em ap-northeast-1 com workarounds de capacidade podem agora operar com o mesmo envelope de hardware disponível nas regiões americanas e europeias — paridade que tem impacto direto na capacidade de oferecer SLAs consistentes globalmente.

## Antes e Depois: Números Mensuráveis da Migração

- **43%** — Melhora de performance de compute por vCPU. R8i vs R6in/R6idn — processador Intel Xeon Scalable de 6ª geração customizado pela AWS, conforme anúncio oficial de julho de 2026
- **6×** — Aumento de largura de banda de rede (R6in → R8in). De 100 Gbps (R6in.32xlarge) para 600 Gbps (R8in.48xlarge) — eliminação do gargalo de replicação MSK em picos de volatilidade
- **<10µs** — Latência de comunicação inter-nó com EFA habilitado. Vs. 30-80µs via TCP/IP padrão — crítico para Monte Carlo distribuído em motores de precificação de derivativos
- **300 Gbps** — Largura de banda EBS no R8ib/R8idb. O maior entre instâncias EC2 não-aceleradas — permite io2 Block Express com 200k IOPS sem saturação do envelope de EBS

> **Riscos Reais que Podem Destruir a Migração:** **1. EFA não é retrocompatível com instâncias menores:** Se você planeja usar Auto Scaling Groups com mix de tamanhos (ex: 48xlarge e 32xlarge), saiba que EFA só está disponível nos tamanhos 48xlarge, 96xlarge e metal. Um ASG heterogêneo vai lançar instâncias sem EFA silenciosamente, quebrando a homogeneidade do cluster de baixa latência. Use Launch Templates separados por tamanho ou restrinja o ASG a tamanhos EFA-compatíveis.

**2. NVMe local não sobrevive a stop/start:** Os volumes NVMe locais do R8idn/R8idb são efêmeros — um stop/start de instância apaga os dados. Para bancos de dados que usam NVMe local como WAL ou cache de compactação (ScyllaDB, ClickHouse), o processo de inicialização deve incluir re-hidratação automática a partir de EBS ou S3. Documente isso no runbook de DR e teste o RTO real.

**3. Custo de io2 Block Express escala não-linearmente:** O custo de IOPS provisionados acima de 32.000 em io2 Block Express é $0,065/IOPS-mês. Provisionar 200.000 IOPS custa ~$10.920/mês só em IOPS — antes do custo de armazenamento. Sem right-sizing pós-migração, é fácil provisionar 2x o necessário baseado em métricas de pico que não refletem a média.

**4. Placement group de cluster aumenta risco de falha correlacionada:** Colocar todos os brokers MSK em um placement group de cluster maximiza throughput de rede, mas aumenta o risco de falha correlacionada (todos os nós no mesmo rack físico). Para produção financeira, use spread placement group entre AZs para MSK e reserve cluster placement group apenas para clusters de computação HPC onde a latência é o fator dominante.

## Observabilidade Como Pré-Requisito, Não Como Afterthought

Uma migração de geração de instância em ambiente financeiro sem observabilidade adequada é uma operação cega. O que aprendi ao longo de múltiplas migrações similares é que os problemas raramente aparecem no momento da virada — eles emergem 6 a 18 horas depois, quando padrões de carga que não estavam presentes durante o teste de smoke começam a se manifestar.

A stack de observabilidade que uso para esse tipo de migração combina três camadas. Na camada de infraestrutura, CloudWatch Container Insights (para workloads containerizados) e CloudWatch Agent com configuração de métricas de alta resolução (1 segundo) para as métricas críticas: `NetworkIn`, `NetworkOut`, `EBSReadBytes`, `EBSWriteBytes`, `EBSReadOps`, `EBSWriteOps` e o frequentemente ignorado `BurstBalance` — que em instâncias com créditos de burst pode mascarar um problema de throughput por horas antes de colapsar.

Na camada de aplicação, uso OpenTelemetry com exportação para CloudWatch Logs via OTLP, capturando spans de latência de operações críticas: tempo de produção de mensagem Kafka, tempo de leitura de ScyllaDB por operação, e tempo de ciclo de simulação do motor de risco. Esses spans são correlacionados com as métricas de infraestrutura via `trace_id` propagado como atributo de métrica customizada — o que permite, em um único dashboard, ver que um spike de latência de aplicação coincide com um evento de throttling de EBS.

Na camada de negócio, defino SLIs específicos para o contexto financeiro: taxa de ordens processadas por segundo, latência de confirmação de ordem (P50/P95/P99/P99.9), e taxa de rejeição por timeout. Esses SLIs são os critérios finais de sucesso da migração — não métricas de infraestrutura. Uma migração que melhora o throughput de EBS mas aumenta a taxa de timeout de ordens é uma migração que falhou, independentemente dos números de hardware.

Para o R8i especificamente, adicionei um alarme em `NetworkBandwidthOutAllowanceExceeded` — uma métrica que indica quando a instância está sendo throttled na saída de rede. Com 600 Gbps disponíveis, esse alarme raramente deveria disparar, mas sua ausência de configuração é um ponto cego clássico que só se descobre em incidentes.

## Lente Well-Architected na Migração R8i

- **security**: Mantenha CMKs regionais separadas para cada região (Tokyo, Frankfurt, Irlanda) com políticas de chave que usam `kms:ViaService` e `aws:SourceAccount`. Nunca compartilhe CMKs cross-region. Revise as políticas de IAM para garantir que roles de instância R8i usem `ec2:DescribeInstances` com condição de tag — não wildcards. EFA adiciona uma superfície de ataque de rede intra-cluster; garanta que Security Groups restrinjam tráfego EFA a CIDRs do placement group.
- **reliability**: Use spread placement groups para MSK brokers entre AZs — nunca cluster placement group para dados persistentes. Configure Multi-AZ para todos os volumes EBS críticos via AWS Backup cross-AZ. Teste o mecanismo de rollback automatizado em staging antes de cada janela de produção. Defina e teste RTO para re-hidratação de NVMe local após stop/start.
- **performance**: Habilite EFA apenas nos tamanhos que o suportam (48xlarge+). Configure MTU 9001 (jumbo frames) em toda a subnet do cluster. Use io2 Block Express com IOPS provisionados baseados em percentil P99.9 de IOPS observados, não no pico absoluto. Valide que o driver ENA Express está ativo para maximizar throughput de rede single-flow.

> **Nota do Arquiteto:** Na minha experiência com migrações de geração de instância em ambientes financeiros, o maior risco não é técnico — é a tentação de tratar a migração como uma operação simples de resize. O R8i representa um salto qualitativo real: 600 Gbps de rede e 300 Gbps de EBS não são incrementais, são mudanças de regime que alteram onde o gargalo se manifesta. O que faço invariavelmente é começar pelo mapeamento de workload por subfamília antes de qualquer provisionamento — pagar por R8idn quando você precisa de R8in é desperdiçar dinheiro em NVMe que nunca vai ser usado. A lição mais dura que aprendi: rollback automatizado não é opcional em produção financeira; é o que separa uma janela de manutenção de um incidente P1 às 2h da manhã.

## Veredicto: Migre, Mas com Disciplina de Engenharia

A expansão do R8i para Tokyo, Frankfurt e Irlanda em julho de 2026 é um gatilho legítimo de modernização para plataformas financeiras que operam nessas regiões com R6i/R6in. Os ganhos são reais e mensuráveis: 43% de melhora de compute por vCPU, 6x de largura de banda de rede, e o maior throughput de EBS entre instâncias não-aceleradas. Para clusters MSK em pico de volatilidade, para motores de risco com Monte Carlo distribuído, e para bancos de dados NoSQL com IOPS intensivos, o R8i resolve gargalos que o R6i não conseguia mais absorver.

Mas a migração exige disciplina: mapeie workloads por subfamília antes de provisionar, instrumente observabilidade antes de mover tráfego, construa e teste rollback automatizado, e compre Savings Plans apenas após estabilização. Em ambientes regulados (MiFID II, DORA, FSA japonesa), documente cada decisão em ADRs com justificativa regulatória — o hardware muda, os auditores permanecem.

A recomendação objetiva: inicie pelo cluster mais crítico em staging, valide os SLOs de migração definidos previamente, e só então execute a sequência blue/green em produção. Não tente migrar todas as camadas simultaneamente — o isolamento de falha é mais valioso que a velocidade de migração.

**Rating:** Migrate with structured blue/green + aut

## Referências

- [AWS What's New: Amazon EC2 R8in, R8ib, R8idn, R8idb now in Tokyo, Frankfurt, Ireland (Jul 2026)](https://aws.amazon.com/about-aws/whats-new/2026/07/amazon-ec2-r8in-r8ib-r8idn-r8idb)
- [Amazon EC2 Instance Types — R8i family](https://aws.amazon.com/ec2/instance-types/)
- [AWS What's New: Amazon EC2 R8g instances in additional regions (Jun 2026)](https://aws.amazon.com/about-aws/whats-new/2026/06/amazon-ec2-r8g-instances-additional-regions/)
- [Elastic Fabric Adapter (EFA) documentation](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/efa.html)
- [Amazon EBS io2 Block Express volumes](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/provisioned-iops.html)
- [AWS Well-Architected Framework — Performance Efficiency Pillar](https://docs.aws.amazon.com/wellarchitected/latest/performance-efficiency-pillar/welcome.html)
- [Amazon MSK Best Practices](https://docs.aws.amazon.com/msk/latest/developerguide/bestpractices.html)
- [AWS Compute Optimizer — EC2 instance recommendations](https://docs.aws.amazon.com/compute-optimizer/latest/ug/view-ec2-recommendations.html)