ADR: Migrando Workloads Financeiros para EC2 R8i no Tokyo e Frankfurt
Ouvir estudo
gerado ao ouvirGerado apenas no primeiro play
Com tecnologia Amazon Polly + OmniVoice
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.
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
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
- 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
- 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
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
- 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
- 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
Não recomendado para ambientes financeiros de grau institucional
Opção C: Migração Faseada por Criticidade de Workload — Abordagem Selecionada
- 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
- 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
Abordagem recomendada — balanceia captura de valor com gestão de risco operacional
Opção D: Adoção Seletiva Apenas para Novos Workloads (Greenfield)
- 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
- Não resolve os gargalos existentes nos clusters R6i já em produção
- Aumenta a heterogeneidade da frota sem um plano de convergência
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.
- R6in Brokers · Kafka / MSK
- R6ib DB Nodes · Aurora / RDS
- R6in Cache · Redis / Memcached
- R8in.48xlarge · 600 Gbps Network · Price Cache
- SLO Gate 1 · NetworkIn P99 · 72h Observation
- R8idn.48xlarge · 600 Gbps + NVMe · Kafka Partition Logs
- SLO Gate 2 · Msg Throughput P99 · 72h Observation
- R8ib.48xlarge · 300 Gbps EBS · Aurora / RDS
- R8idb.48xlarge · EBS + NVMe · Glue / Spark Shuffle
- SLO Gate 3 · EBS IOPS / Latency · 72h Observation
- CloudWatch · NetworkIn/Out · EBSBytesPerSec
- OpenTelemetry · Collector · Datadog Exporter
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
Segurança
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.
Confiabilidade
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.
Eficiência de 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.
Sustentabilidade
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.
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.
Referências
Post-mortems, ADRs e deep dives de arquitetura no seu email — do jeito que um arquiteto lê.
Sem spam · cancele quando quiser
Pergunte ao Fernando sobre isto
Receba uma resposta focada sobre este estudo do meu assistente de IA, baseada no meu trabalho.
Participe da conversa
Entre para comentar
Confirme seu e-mail para participar — você também recebe a newsletter. Sem senha.