# ADR: Migrando Workloads Financeiros para EC2 R8i no Tokyo e Frankfurt

A disponibilidade das instâncias EC2 R8in, R8ib, R8idn e R8idb em Tokyo, Frankfurt e Irlanda abre uma janela de decisão real para arquiteturas financeiras que dependem de latência de rede sub-milissegundo, throughput EBS extremo e conformidade de residência de dados. Este ADR documenta o raciocínio por trás da adoção — ou não — dessas instâncias em workloads de grau financeiro.

- URL: https://fernando.moretes.com/blog/adr-migrando-workloads-financeiros-para-ec2-r8i-no-tokyo-e-frankfurt-amazon-ec2-n

- Markdown: https://fernando.moretes.com/blog/adr-migrando-workloads-financeiros-para-ec2-r8i-no-tokyo-e-frankfurt-amazon-ec2-n/article.md?lang=pt

- Published: 2026-07-11T09:03:29.373Z

- Category: IA & Agentes

- Tags: ec2, r8i, financial-grade, adr, msk, eks, nitro, network-performance

- 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)

---

Em 10 de julho de 2026, a AWS expandiu as instâncias EC2 R8in, R8ib, R8idn e R8idb para as regiões Asia Pacific (Tokyo) e Europe (Frankfurt, Ireland). Para arquiteturas financeiras que já operam nessas regiões por exigência regulatória — LGPD, GDPR, FSA japonesa — essa não é uma notícia de roadmap. É um gatilho de decisão imediata.

## Contexto e Forças em Jogo

Workloads financeiros de grau institucional — plataformas de matching de ordens, motores de risco intraday, caches de preços em tempo real, pipelines de liquidação — têm uma característica que os distingue de sistemas web convencionais: eles são simultaneamente **memory-bound**, **network-bound** e **latency-sensitive**, e precisam operar dentro de janelas regulatórias de residência de dados que tornam a escolha de região não negociável.

Antes desta expansão, as instâncias R8i estavam disponíveis apenas em us-east-1, us-east-2, us-west-2 e ap-southeast-1 (via anúncios anteriores). Isso criava uma assimetria arquitetural dolorosa: os melhores nós de computação da família R ficavam geograficamente inacessíveis para sistemas que precisam operar em Tokyo por exigência da FSA japonesa ou em Frankfurt/Irlanda por exigência do GDPR e das diretrizes EBA.

As forças que tornam essa decisão não trivial são múltiplas. Primeiro, **custo de migração**: mover um cluster Kafka MSK ou um nó primário de banco de dados relacional para um novo tipo de instância em produção exige janelas de manutenção, testes de regressão de performance e validação de SLO. Segundo, **risco de regressão**: a geração anterior R6in/R6idn ainda está disponível e é uma plataforma estável — o argumento "se não está quebrado, não conserte" tem peso real em ambientes onde um incidente de P1 às 14h em Tokyo tem consequências regulatórias. Terceiro, **custo absoluto**: instâncias de 48xlarge e 96xlarge têm preços que justificam análise de ROI rigorosa, não adoção reflexiva.

## Capacidades Técnicas Chave — R8i vs R6i

- **43%** — Melhora de performance de computação por vCPU vs R6in/R6idn. Processadores Intel Xeon Scalable de 6ª geração customizados, exclusivos da AWS
- **600 Gbps** — Largura de banda de rede (R8in, R8idn) — maior entre instâncias EC2 enhanced. Habilitado por Nitro Cards de 6ª geração
- **300 Gbps** — Largura de banda EBS (R8ib, R8idb) — maior entre instâncias não-aceleradas. Crítico para workloads de banco de dados e data lake com I/O intenso
- **EFA** — Suporte a Elastic Fabric Adapter nos tamanhos 48xlarge, 96xlarge, metal-48xl e. Latência reduzida e melhor performance de cluster para workloads acoplados

## Mapeando os Workloads Financeiros para as Subfamílias R8i

A família R8i não é monolítica — ela tem quatro variantes com perfis de I/O radicalmente diferentes, e a decisão de qual usar é tão importante quanto a decisão de migrar.

**R8in** (network-optimized, sem NVMe local): O caso de uso mais direto para sistemas de cache de preços em tempo real baseados em Redis ou Memcached. Com 600 Gbps de largura de banda de rede e memória abundante, um nó R8in.48xlarge pode servir como nó primário de um cluster ElastiCache self-managed com replicação síncrona para múltiplas AZs em Frankfurt sem que o gargalo seja a rede. Para pipelines MSK (Kafka) que precisam de brokers com alta capacidade de recebimento de mensagens — pense em feeds de mercado de alta frequência com 10M+ eventos/segundo — o R8in elimina a contenção de rede que frequentemente aparece como `NetworkIn` throttling em instâncias R6in sob carga de pico.

**R8idn** (network + NVMe local): O candidato natural para brokers Kafka auto-gerenciados onde você precisa de throughput de rede extremo E armazenamento local rápido para os logs de partição. Em Tokyo, onde operadores de exchanges precisam de brokers Kafka com latência de produção P99 < 2ms, a combinação de 600 Gbps de rede com NVMe local de baixa latência elimina dois gargalos simultaneamente.

**R8ib** (EBS-optimized, sem NVMe): O caso canônico aqui é Aurora PostgreSQL ou RDS para bancos de dados de posições e reconciliação. Com 300 Gbps de largura de banda EBS — o maior entre instâncias não-aceleradas — você pode sustentar workloads de OLTP pesado com `io2 Block Express` volumes sem que o throughput EBS seja o limitante. Isso é relevante para sistemas de liquidação T+1 em Frankfurt que precisam processar reconciliações em lote de madrugada com janelas de 2-3 horas.

**R8idb** (EBS + NVMe local): Data lakes em escala institucional que usam S3 como storage tier mas precisam de scratch space local para transformações intermediárias — pense em jobs Glue ou Spark que materializam datasets de risco de 500GB+ antes de escrever resultados agregados de volta ao S3. O NVMe local aqui não é persistência; é aceleração de shuffle.

## Opções Consideradas: Estratégia de Adoção das Instâncias R8i

### Opção A: Manter R6in/R6idn — Estabilidade Conservadora

**Pros**
- Zero risco de regressão de performance em produção
- Savings Plans existentes já cobrem os custos
- Sem necessidade de janelas de manutenção ou reteste de SLO

**Cons**
- Perde 43% de eficiência de computação por vCPU — custo de oportunidade real em clusters grandes
- Gargalos de rede em picos de mercado continuam sem solução estrutural
- R6i eventualmente entrará em fim de suporte — a migração será forçada em piores condições

**Verdict:** Válido apenas como posição temporária com plano de migração documentado

### Opção B: Migração Big-Bang — Substituição Total Imediata

**Pros**
- Captura imediata dos benefícios de performance e eficiência de custo
- Simplifica o inventário de instâncias — sem gerenciar duas gerações simultaneamente

**Cons**
- Risco operacional alto: múltiplos clusters críticos migrando em paralelo
- Requer invalidação e reconstrução de Savings Plans — custo de transição real
- Em ambientes financeiros regulados, mudanças em massa requerem aprovação de Change Advisory Board (CAB) — latência de processo

**Verdict:** Não recomendado para ambientes financeiros de grau institucional

### Opção C: Migração Faseada por Criticidade de Workload — Abordagem Selecionada

**Pros**
- Risco controlado: cada fase tem blast radius limitado e rollback definido
- Permite captura de benefícios nos workloads de maior ROI primeiro (caches, brokers Kafka)
- Savings Plans podem ser escalonados progressivamente — sem penalidade de transição abrupta
- Compatível com processos CAB e janelas de manutenção regulatórias

**Cons**
- Período de heterogeneidade de frota — dois tipos de instância para monitorar e operar
- Benefícios totais de performance demoram mais para se materializar

**Verdict:** Abordagem recomendada — balanceia captura de valor com gestão de risco operacional

### Opção D: Adoção Seletiva Apenas para Novos Workloads (Greenfield)

**Pros**
- Zero impacto em sistemas existentes em produção
- Ideal para novos serviços de AI/ML cache ou 5G UPF que ainda não têm baseline de performance

**Cons**
- Não resolve os gargalos existentes nos clusters R6i já em produção
- Aumenta a heterogeneidade da frota sem um plano de convergência

**Verdict:** Complementar à Opção C, não substituto

## A Decisão: Migração Faseada com Gates de Validação de SLO

A decisão é adotar a **Opção C** — migração faseada por criticidade de workload — com gates explícitos de validação de SLO entre cada fase. O raciocínio central é que em ambientes financeiros regulados, a velocidade de adoção de nova infraestrutura é secundária à **previsibilidade operacional**. Um incidente de P1 causado por uma migração mal executada em Tokyo às 9h JST (abertura do mercado) tem consequências que vão além do SLA técnico — há notificações regulatórias, relatórios de incidente para a FSA e potencial impacto reputacional.

O sequenciamento das fases é deliberado. **Fase 1** começa com os caches de preços em tempo real (R8in) — esses são os workloads com maior ROI de migração porque são stateless do ponto de vista de dados persistentes, têm rollback trivial (basta apontar o Auto Scaling Group para o tipo anterior) e o benefício de 600 Gbps de rede é imediatamente mensurável via métricas `NetworkIn`/`NetworkOut` no CloudWatch. **Fase 2** endereça os brokers Kafka MSK ou self-managed (R8idn) — aqui o risco é maior porque Kafka tem estado (logs de partição), mas o processo de rolling restart de brokers é bem documentado e testado. **Fase 3** cobre os nós de banco de dados (R8ib para Aurora/RDS, R8idb para nós de processamento de data lake) — esses têm o maior risco e o maior benefício de throughput EBS.

Cada fase tem um gate de validação: 72 horas de observação em produção com SLOs definidos (P99 de latência de rede, throughput de mensagens, IOPS de EBS) antes de prosseguir. Se qualquer SLO regredir mais de 5% em relação ao baseline R6i, a fase é revertida e investigada antes de continuar. Isso não é conservadorismo excessivo — é o padrão operacional mínimo para sistemas que processam transações financeiras reais.

## Fluxo de Decisão e Migração Faseada R8i em Ambiente Financeiro

Mostra o sequenciamento das três fases de migração, os gates de validação de SLO e o mapeamento de subfamílias R8i para workloads financeiros específicos em Tokyo e Frankfurt.

### 📋 Baseline — R6i (Current)

- R6in Brokers Kafka / MSK (messaging)
- R6ib DB Nodes Aurora / RDS (data)
- R6in Cache Redis / Memcached (storage)

### 🔀 Phase 1 — R8in: Network Cache (Tokyo / Frankfurt)

- R8in.48xlarge 600 Gbps Network Price Cache (compute)
- SLO Gate 1 NetworkIn P99 72h Observation (security)

### 🔀 Phase 2 — R8idn: Kafka Brokers (Tokyo / Frankfurt)

- R8idn.48xlarge 600 Gbps + NVMe Kafka Partition Logs (messaging)
- SLO Gate 2 Msg Throughput P99 72h Observation (security)

### 🔀 Phase 3 — R8ib/R8idb: DB & Data Lake (Frankfurt)

- R8ib.48xlarge 300 Gbps EBS Aurora / RDS (data)
- R8idb.48xlarge EBS + NVMe Glue / Spark Shuffle (storage)
- SLO Gate 3 EBS IOPS / Latency 72h Observation (security)

### 📊 Observability (CloudWatch + OpenTelemetry)

- CloudWatch NetworkIn/Out EBSBytesPerSec (ai)
- OpenTelemetry Collector Datadog Exporter (ai)

### Fluxos

- r6cache -> r8in_cache: Fase 1: ASG swap
- r8in_cache -> slo1: Validar SLO
- slo1 -> r8idn_kafka: Gate aprovado → Fase 2
- r6in -> r8idn_kafka: Rolling restart brokers
- r8idn_kafka -> slo2: Validar SLO
- slo2 -> r8ib_db: Gate aprovado → Fase 3
- r6ib -> r8ib_db: Multi-AZ failover
- r8ib_db -> r8idb_lake: Paralelo na Fase 3
- r8idb_lake -> slo3: Validar SLO
- r8in_cache -> cw: Métricas de rede
- r8idn_kafka -> cw: Throughput Kafka
- r8ib_db -> otel: IOPS / Latência EBS
- cw -> otel: Métricas unificadas

## Configurações Específicas que Determinam o Sucesso ou Fracasso

A decisão de instância é apenas o começo. O que diferencia uma migração bem-sucedida de um incidente de P1 são as configurações específicas que frequentemente não aparecem nos anúncios de produto.

**Placement Groups e EFA**: Para os tamanhos 48xlarge, 96xlarge, metal-48xl e metal-96xl, o suporte a EFA (Elastic Fabric Adapter) é um multiplicador de performance para clusters acoplados — mas ele só funciona corretamente quando as instâncias estão em um **Cluster Placement Group** na mesma AZ. Em ambientes financeiros com requisito de multi-AZ, isso cria uma tensão arquitetural: você não pode ter EFA e multi-AZ simultaneamente no mesmo cluster. A solução é segmentar: use Cluster Placement Groups com EFA para o tier de processamento de alta frequência (matching engine, risk calculation) e Spread Placement Groups para o tier de persistência (brokers Kafka, nós de banco de dados).

**IAM e KMS para instâncias com NVMe local (R8idn, R8idb)**: O NVMe local NÃO é criptografado por padrão pela AWS — a criptografia é responsabilidade do sistema operacional ou da aplicação. Em ambientes financeiros sob GDPR (Frankfurt) ou FSA (Tokyo), dados em repouso em NVMe local devem ser criptografados. A abordagem correta é usar `dm-crypt` com LUKS no Linux, com a chave derivada de um segredo armazenado no AWS Secrets Manager e recuperada via IAM Role da instância com condição `aws:SourceVpc`. Nunca use a chave diretamente hardcoded no user-data.

**Auto Scaling e Instance Refresh**: Ao usar Launch Templates para migração, configure `InstanceRefresh` com `MinHealthyPercentage: 90` e `CheckpointPercentages: [25, 50, 75, 100]` — isso garante que a migração pause em cada checkpoint para validação antes de continuar. Para clusters Kafka, configure `MaxBatchSize: 1` para garantir que apenas um broker seja substituído por vez, preservando a disponibilidade de todas as partições durante a migração.

**CloudWatch Alarms para os SLO Gates**: Os alarms de validação devem monitorar `NetworkPacketsIn`, `EBSWriteBytes`, `EBSWriteOps` e — crítico para Kafka — a métrica customizada `UnderReplicatedPartitions` via JMX exportada para CloudWatch via agente OTEL. Um valor de `UnderReplicatedPartitions > 0` por mais de 60 segundos durante a migração de um broker é sinal de rollback imediato.

## Análise de Custo e Modelo de Compra: Savings Plans vs On-Demand vs Spot

A disponibilidade das instâncias R8i em Tokyo e Frankfurt via **Savings Plans, On-Demand e Spot** (conforme anunciado) abre três estratégias de compra com trade-offs distintos para ambientes financeiros.

**Savings Plans (Compute)** são a escolha certa para o baseline de capacidade de workloads críticos — brokers Kafka, nós de banco de dados, caches de preços. A flexibilidade do Compute Savings Plan (vs. EC2 Instance Savings Plan) é crucial aqui: ele se aplica automaticamente ao R8in mesmo que você tenha comprado o plano quando estava no R6in, sem necessidade de renegociação. Em termos de números: um R8in.48xlarge em Frankfurt com 1-year Compute Savings Plan oferece aproximadamente 38-42% de desconto sobre On-Demand — em um cluster de 10 nós, isso representa uma economia anual de seis dígitos em USD.

**On-Demand** deve ser a posição de entrada durante as fases de migração — você não quer estar preso a um Savings Plan em um tipo de instância que pode precisar ser revertido. Use On-Demand pelos primeiros 30 dias pós-migração de cada fase, validando o baseline de performance antes de converter para Savings Plan.

**Spot** tem aplicabilidade limitada mas real em ambientes financeiros: jobs de processamento de risco batch (cálculo de VaR overnight, stress testing), pipelines de backtesting e transformações de data lake em R8idb são candidatos legítimos para Spot. A chave é usar **Spot com diversificação de tipo de instância** via `capacity-optimized` allocation strategy no ASG — inclua R8idb, R8idn e R6idn no mesmo pool para maximizar a disponibilidade de Spot. Para jobs críticos de batch financeiro, use o padrão de checkpointing com Step Functions: a cada 15 minutos de processamento, persista o estado intermediário no S3 com versionamento habilitado, de forma que uma interrupção Spot não descarte mais de 15 minutos de trabalho.

Um anti-padrão que vejo frequentemente: usar Reserved Instances (RI) em vez de Savings Plans para novas gerações de instâncias. RIs são amarradas a um tipo de instância específico e região — em um ciclo de migração de geração, você fica preso. Compute Savings Plans são a escolha correta para qualquer workload que vai passar por uma migração de geração nos próximos 1-3 anos.

> **Consequências e Riscos da Decisão:** **1. NVMe local não persiste entre reinicializações de instância**: Qualquer dado armazenado no NVMe local de R8idn ou R8idb é perdido em um stop/start de instância (não em um reboot). Em clusters Kafka self-managed, isso significa que logs de partição no NVMe local são destruídos se a instância for parada — não apenas reiniciada. O design correto é usar NVMe apenas para escrita temporária e ter os logs de partição replicados em pelo menos 3 brokers, com `min.insync.replicas=2`. Nunca dependa do NVMe local como única cópia de dados persistentes.

**2. EFA requer reconfiguração de security groups**: EFA usa um tipo de interface de rede diferente que não segue as regras de security group padrão para tráfego inter-nó. Em ambientes com postura Zero Trust onde todo tráfego é explicitamente permitido, a migração para EFA pode silenciosamente quebrar a comunicação inter-nó se os security groups não forem atualizados para permitir `All traffic` entre os membros do placement group via self-referencing security group rule.

**3. Custo de capacidade reservada em regiões novas**: Tokyo e Frankfurt têm preços On-Demand historicamente mais altos que us-east-1. A análise de ROI deve ser feita com os preços regionais específicos, não com os preços US como proxy. Um R8in.48xlarge em Tokyo pode custar 15-20% mais que o equivalente em us-east-1 — isso afeta o breakeven do Savings Plan.

**4. Conformidade regulatória de dados em NVMe**: Em Frankfurt sob GDPR, a destruição segura de dados em NVMe local requer procedimentos específicos de sanitização ao descomissionar instâncias. A AWS garante sanitização de NVMe entre clientes diferentes, mas dentro do mesmo ciclo de vida de instância, a responsabilidade de criptografia e sanitização é do operador.

## Avaliação pelo AWS Well-Architected Framework

- **security**: Criptografar NVMe local com dm-crypt/LUKS e chaves do Secrets Manager. Usar IAM Role com condição aws:SourceVpc para recuperação de chave. EFA requer self-referencing security group rule explícita. Auditar acesso com CloudTrail para DescribeInstances e ModifyInstanceAttribute.
- **reliability**: Nunca usar NVMe local como única cópia de dados persistentes. min.insync.replicas=2 para Kafka. Instance Refresh com CheckpointPercentages para rollback automático. Alarme CloudWatch em UnderReplicatedPartitions > 0 por mais de 60s.
- **performance**: Cluster Placement Groups com EFA para tiers de alta frequência. Separar tiers de processamento (EFA+single-AZ) de tiers de persistência (Spread+multi-AZ). Validar baseline de performance com 72h de observação em produção antes de cada gate de migração.
- **sustainability**: 43% de melhora de performance por vCPU significa que o mesmo throughput pode ser alcançado com menos instâncias — redução direta de consumo de energia. Avaliar consolidação de clusters R6i em menos nós R8i antes de migrar para capturar tanto o benefício de performance quanto a redução de footprint.

> **Nota do Arquiteto:** Na prática, o que me convence a recomendar a migração para R8in em caches de preços em Tokyo não é o número de 600 Gbps em si — é o fato de que em picos de abertura de mercado, o gargalo que vejo repetidamente em clusters R6in é exatamente `NetworkIn` throttling, não CPU nem memória. O R8in resolve o problema certo. Dito isso, a lição mais dura que aprendi em migrações de instância em ambientes financeiros é que o risco real não está na instância nova — está na **suposição implícita de que o comportamento de rede da aplicação foi testado em velocidades que ela nunca viu antes**. Um broker Kafka que nunca processou mais de 50 Gbps de throughput pode ter comportamentos inesperados quando o gargalo de rede desaparece e o throughput real de disco ou de CPU se torna visível pela primeira vez. Sempre faça load testing com o throughput máximo teórico da nova instância antes de colocar em produção — não apenas com o throughput histórico.

## Decisão Final

**Adotar as instâncias R8i em Tokyo e Frankfurt via migração faseada com gates de SLO.** A expansão regional das instâncias R8in/R8ib/R8idn/R8idb remove a última barreira geográfica para workloads financeiros regulados que precisavam das capacidades de rede e EBS de ponta da família R. O ganho de 43% de performance por vCPU e os 600 Gbps de largura de banda de rede não são incrementais — eles mudam o perfil de gargalo de clusters inteiros. A decisão de migrar não é se, mas quando e como. A resposta para 'quando' é: comece pela Fase 1 (caches R8in) no próximo ciclo de manutenção planejado. A resposta para 'como' é: migração faseada com Instance Refresh, SLO gates de 72h, criptografia de NVMe com LUKS, Compute Savings Plans (não RIs), e load testing ao throughput máximo teórico antes de cada promoção para produção. Para workloads greenfield em Tokyo — especialmente caching de clusters AI/ML ou 5G UPF — o R8in é a escolha de instância padrão a partir de hoje.

**Rating:** Adopt — Phased

## 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 Instance Types — R8i Family](https://aws.amazon.com/ec2/instance-types/)
- [AWS Nitro System — Nitro Cards and Enhanced Networking](https://aws.amazon.com/ec2/nitro/)
- [Elastic Fabric Adapter (EFA) — User Guide](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/efa.html)
- [EC2 Instance Refresh — Auto Scaling User Guide](https://docs.aws.amazon.com/autoscaling/ec2/userguide/asg-instance-refresh.html)
- [AWS Compute Savings Plans — Flexibility Across Instance Families](https://docs.aws.amazon.com/savingsplans/latest/userguide/what-is-savings-plans.html)
- [Amazon MSK Best Practices — Broker Sizing and Instance Types](https://docs.aws.amazon.com/msk/latest/developerguide/bestpractices.html)
- [AWS Well-Architected Framework — Performance Efficiency Pillar](https://docs.aws.amazon.com/wellarchitected/latest/performance-efficiency-pillar/welcome.html)