# Migrando Workloads de Alta Rede para EC2 R6in/R6idn em Paris e Canadá

A disponibilização das instâncias R6in e R6idn na Europa (Paris) e Canadá (Central) em julho de 2026 fecha uma lacuna de residência de dados crítica para workloads financeiros e de analytics em tempo real. Este artigo narra a jornada de migração de instâncias R5n para R6in/R6idn, detalhando decisões de arquitetura, riscos operacionais e os ganhos mensuráveis de rede e IOPS que justificam o movimento.

- URL: https://fernando.moretes.com/blog/migrando-workloads-de-alta-rede-para-ec2-r6in-r6idn-em-paris-e-canada-amazon-ec2-r

- Markdown: https://fernando.moretes.com/blog/migrando-workloads-de-alta-rede-para-ec2-r6in-r6idn-em-paris-e-canada-amazon-ec2-r/article.md?lang=pt

- Published: 2026-07-22T09:03:44.922Z

- Category: IA & Agentes

- Tags: ec2, r6in, migration, financial-grade, networking, efa, data-residency, performance

- Reading time: 10 min

- Source: [Amazon EC2 R6in and R6idn instances are now available in additional regions](https://aws.amazon.com/about-aws/whats-new/2026/07/amazon-ec2-r6in-r6idn/)

---

Quando a AWS expande a disponibilidade regional de uma família de instâncias, o anúncio parece incremental. Mas para arquitetos que operam sistemas financeiros sob RGPD francês ou PIPEDA canadense, a chegada das R6in e R6idn em Paris e Canadá Central em julho de 2026 não é incremental — é desbloqueadora. Até agora, mover workloads de cache distribuído e analytics em tempo real para essas regiões significava aceitar o gargalo de rede das gerações anteriores ou manter arquiteturas híbridas caras. Esse trade-off acabou.

## O Ponto de Partida: Por Que R5n Não Era Suficiente

Durante anos, a família R5n foi a escolha padrão para workloads memory-bound com exigências de rede acima da média em regiões europeias e canadenses. Um cluster Redis de seis nós em `r5n.4xlarge` entregava 25 Gbps por nó — suficiente para a maioria dos cenários de cache de sessão financeira, mas insuficiente quando o volume de transações cresce e o padrão de acesso se torna mais fan-out: múltiplos microsserviços consultando o mesmo cluster com pipelines de 50 a 200 comandos por requisição.

O problema se manifesta primeiro no tail latency. O p99 de leitura no Redis começa a escalar quando a NIC do host satura, não quando o Redis em si está sob pressão de CPU ou memória. Em ambientes de trading ou processamento de pagamentos, um p99 de 4–6 ms em operações de cache que deveriam custar 300–500 µs é um sinal de alarme de infraestrutura, não de aplicação. Monitorar isso com CloudWatch `NetworkIn`/`NetworkOut` e correlacionar com métricas de latência do ElastiCache (ou do Redis autogerenciado via exportador Prometheus + CloudWatch Container Insights) revela o padrão com clareza.

A alternativa óbvia — escalar horizontalmente adicionando mais nós — resolve o throughput mas aumenta o custo de replicação intra-cluster e a complexidade do resharding. Em Paris e Canadá Central, antes de julho de 2026, não havia saída elegante: as R6in/R6idn simplesmente não estavam disponíveis nessas regiões. Workloads que precisavam de residência de dados nessas geografias ficavam presos com R5n ou com instâncias de propósito geral que sacrificavam memória por rede.

## O Que a Família R6in/R6idn Realmente Entrega

Antes de planejar a migração, é necessário entender o envelope de capacidade real dessas instâncias, não apenas os números de marketing. As R6in e R6idn são instâncias de sexta geração otimizadas para rede, alimentadas por processadores Intel Xeon Scalable de 3ª geração e construídas sobre o AWS Nitro System. O headline é 200 Gbps de largura de banda de rede no tamanho `32xlarge` e metal — o dobro das R5n equivalentes. Mas o que importa para design de sistema são os números nos tamanhos que você realmente vai usar.

Um `r6in.8xlarge` entrega 50 Gbps de rede e 40 Gbps de EBS, com 256 GiB de RAM e 32 vCPUs. Compare com `r5n.8xlarge`: 25 Gbps de rede e 19 Gbps de EBS. Para um cluster Redis de três nós onde antes eu precisava de seis nós R5n para saturar a largura de banda de replicação, agora consigo consolidar com ganho de margem. O IOPS máximo de EBS chega a 400K no topo da família — relevante para bancos de dados como SAP HANA ou PostgreSQL com tablespaces de alto throughput.

A variante R6idn adiciona armazenamento de instância NVMe: até 7,6 TB de armazenamento local de alta velocidade e baixa latência. Isso é transformador para workloads como Apache Spark que fazem shuffle intensivo em disco — o shuffle local em NVMe elimina o round-trip para EBS e reduz dramaticamente o tempo de estágio de shuffle em jobs de analytics. Para Hadoop HDFS em modo local, o mesmo princípio se aplica.

O suporte a EFA (Elastic Fabric Adapter) nos tamanhos `32xlarge` e metal merece atenção especial em contextos de HPC financeiro ou treinamento de modelos de risco. EFA bypassa o kernel TCP/IP do host usando RDMA sobre Ethernet convergente, reduzindo latência de MPI para dezenas de microssegundos. Para a maioria dos workloads de banco de dados e cache, EFA não é necessário — mas para simulações de Monte Carlo ou backtesting paralelo massivo, é um diferencial real.

## Antes e Depois: Comparativo R5n → R6in por Tamanho Equivalente

- **2×** — Largura de banda de rede (r6in vs r5n equivalente). De 25 Gbps para 50 Gbps no 8xlarge; de 100 Gbps para 200 Gbps no 32xlarge
- **2×** — Performance de processamento de pacotes. Relevante para Redis com pipelines de alta frequência e SAP HANA com replicação síncrona
- **400K** — IOPS máximo de EBS. Contra ~80K IOPS nas R5n — diferença crítica para bancos de dados OLTP de alta frequência
- **7.6 TB** — Armazenamento de instância NVMe (R6idn). Elimina dependência de EBS para shuffle Spark e buffers temporários de alto throughput

## A Jornada de Migração: Decisões e Passos

1. **1. Baseline de observabilidade antes de qualquer mudança** — Antes de tocar em instâncias, instrumentei métricas de baseline com granularidade de 1 minuto no CloudWatch: `NetworkIn`, `NetworkOut`, `EBSReadBytes`, `EBSWriteBytes`, `EBSIOBalance%`. Para Redis autogerenciado, adicionei o exportador `redis_exporter` com scraping via CloudWatch Agent no modo Prometheus. Defini SLOs explícitos: p99 de latência de leitura < 1 ms, p99 de escrita < 2 ms. Qualquer migração que não preserve esses SLOs é um rollback imediato.

2. **2. Validação de disponibilidade e quotas na região-alvo** — Executei `aws ec2 describe-instance-type-offerings --location-type availability-zone --filters Name=instance-type,Values=r6in.8xlarge --region eu-west-3` para confirmar disponibilidade por AZ em Paris. Verifiquei quotas de vCPU via Service Quotas console — a família R6in consome quota da categoria 'Running On-Demand R instances'. Para Reserved Instances, validei que o escopo regional está disponível para R6in em eu-west-3 antes de fazer qualquer compromisso financeiro.

3. **3. Migração piloto: um nó não-primário em ambiente de staging** — Iniciei com um único nó réplica do cluster Redis em staging. O processo foi: snapshot do volume EBS do nó R5n existente → launch de nova instância R6in.4xlarge na mesma AZ → attach do snapshot → validação de integridade do Redis com `redis-cli --cluster check`. Monitorei por 72 horas com alertas no CloudWatch Alarms para `NetworkPacketsOut` e `CPUSurplusCreditsCharged` (irrelevante aqui, mas boa prática de verificação). Nenhuma surpresa: a instância R6in não usa créditos de CPU — é uma família de desempenho fixo.

4. **4. Configuração de ENI e placement groups para latência intra-cluster** — Para clusters Redis e Kafka onde a latência de replicação intra-nó importa, coloquei as instâncias em um Cluster Placement Group dentro da mesma AZ. Isso garante que os nós estejam fisicamente próximos no rack, minimizando a latência de rede interna. Configurei Enhanced Networking (ENA) — habilitado por padrão nas R6in — e verifiquei com `ethtool -i eth0` que o driver `ena` estava ativo. Para os nós com EFA nos tamanhos 32xlarge, o processo de configuração adicional inclui instalar o pacote `aws-efa-installer` e validar com `fi_info -p efa`.

5. **5. Migração em ondas com blue/green por grupo de instâncias** — Adotei uma estratégia blue/green no nível de Auto Scaling Group. Criei um novo ASG com launch template apontando para R6in, com a mesma configuração de VPC, security groups e IAM instance profile. Usei instance refresh com `MinHealthyPercentage: 80` e `InstanceWarmup: 300` segundos. O tráfego foi migrado progressivamente via weighted target groups no ALB interno — 10% → 30% → 70% → 100% — com rollback automático acionado por alarme de p99 > 2 ms por 5 minutos consecutivos.

6. **6. Otimização de custo pós-migração com Savings Plans e Spot** — Após validar estabilidade por 30 dias em On-Demand, comprei Compute Savings Plans de 1 ano para a capacidade baseline (70% do consumo médio). Os 30% restantes ficaram em On-Demand para absorver picos. Para os nós de analytics Spark com R6idn, onde a tolerância a falhas é gerenciada pelo próprio Spark (recomputação de partições), usei Spot Instances com estratégia `capacity-optimized` no ASG — reduzindo o custo de compute de analytics em aproximadamente 60-70% versus On-Demand.

## Arquitetura de Migração: R5n → R6in/R6idn em Paris (eu-west-3)

Fluxo de migração blue/green mostrando o estado anterior (R5n), o estado alvo (R6in/R6idn), o controle de tráfego via ALB com weighted target groups, e a camada de observabilidade que governa o rollback automático.

### 🔵 Before — R5n Fleet

- Redis Cluster 6× r5n.4xlarge 25 Gbps/node (data)
- Spark Workers 4× r5n.8xlarge EBS shuffle (compute)

### 🟢 After — R6in/R6idn Fleet

- Redis Cluster 3× r6in.4xlarge 50 Gbps/node Cluster PG (data)
- Spark Workers 2× r6idn.8xlarge 7.6 TB NVMe Shuffle local (compute)

### ⚖️ Traffic Control

- Internal ALB Weighted TGs 10→30→70→100% (network)
- ASG Blue (R5n — drain) (compute)
- ASG Green (R6in — active) (compute)

### 📊 Observability & Rollback

- CloudWatch Alarms p99 > 2ms / 5min NetworkIn saturation (security)
- Redis Exporter + CW Agent Prometheus mode (security)
- Auto Rollback ASG Instance Refresh MinHealthy: 80% (ci)

### 💰 Cost Layer

- Compute Savings Plans 1yr — 70% baseline (external)
- Spot Instances capacity-optimized Spark analytics (external)

### Fluxos

- alb -> asg_blue: peso decrescente
- alb -> asg_green: peso crescente
- asg_green -> r6in_redis: serve tráfego
- asg_green -> r6idn_spark: jobs analytics
- prom -> cw_alarms: métricas Redis
- cw_alarms -> rollback: aciona rollback
- rollback -> asg_blue: restaura peso 100%
- savings -> asg_green: cobre 70% baseline
- spot -> r6idn_spark: nós analytics

## Residência de Dados, Conformidade e o Contexto Regulatório de Paris e Canadá

A expansão regional das R6in/R6idn para Paris e Canadá Central não é apenas uma questão de performance — é uma questão de viabilidade regulatória. Para empresas financeiras operando na França, o RGPD impõe restrições sobre onde dados de clientes podem ser processados. A interpretação estrita adotada por muitos DPOs franceses exige que o processamento de dados pessoais ocorra dentro da UE, e de preferência dentro da França para dados de cidadãos franceses sujeitos a regulamentações específicas do setor financeiro (ACPR, AMF).

No Canadá, o PIPEDA e as leis provinciais como a Lei 25 do Québec (em vigor desde 2023) estabelecem requisitos de residência de dados que afetam diretamente onde clusters de processamento de analytics e caches de sessão podem residir. Antes desta expansão, um arquiteto que precisava de performance de rede de nível R6in nessas regiões tinha duas opções ruins: usar R5n com suas limitações de rede, ou aceitar que parte do processamento ocorresse em Frankfurt ou us-east-1, criando exposição regulatória.

Do ponto de vista de arquitetura de segurança, a presença das R6in/R6idn nessas regiões também simplifica o design de VPC. Workloads que antes precisavam de Transit Gateway cross-region para acessar capacidade de rede superior em outra região agora podem ser totalmente contidos dentro de uma única VPC regional. Isso reduz a superfície de ataque, simplifica as políticas de VPC Endpoint e elimina custos de transferência de dados inter-região — que em ambientes financeiros de alto volume podem ser significativos.

Para conformidade com PCI-DSS, a contenção regional também simplifica o escopo de auditoria. Um ambiente de processamento de cartões que reside inteiramente em `eu-west-3` com criptografia KMS usando CMKs regionais, CloudTrail regional e VPC sem internet gateway tem um perímetro de auditoria muito mais limpo do que uma arquitetura multi-região com dados em trânsito entre regiões.

## Configurações Críticas: O Que Vai Errado se Você Não Prestar Atenção

A migração para R6in/R6idn parece direta, mas há configurações específicas que determinam se você captura o ganho de performance prometido ou apenas paga mais por hardware subutilizado.

**EBS Bandwidth vs. IOPS Balance**: O `EBSIOBalance%` é uma métrica crítica que muitos arquitetos ignoram. Instâncias com volumes `gp2` legados têm um sistema de créditos de IOPS que pode esgotar durante bursts prolongados. Para capturar os 400K IOPS disponíveis nas R6in, você precisa de volumes `gp3` ou `io2 Block Express` explicitamente configurados — `gp3` com IOPS provisionados até 16K por volume, ou múltiplos volumes em RAID-0 para workloads que exigem mais. Migrar a instância sem migrar o tipo de volume é um erro comum que deixa performance na mesa.

**Jumbo Frames e MTU**: Para maximizar o throughput de rede em comunicação intra-cluster, configure MTU 9001 (Jumbo Frames) nas interfaces de rede. Isso é especialmente importante para replicação Redis e Kafka onde pacotes grandes são comuns. Verifique com `ip link show eth0` e configure com `sudo ip link set dev eth0 mtu 9001`. O Nitro System suporta Jumbo Frames nativamente, mas a configuração não é automática em todos os AMIs.

**NUMA Awareness para Redis**: Em instâncias grandes como `r6in.16xlarge` ou maiores, o Redis por padrão não é NUMA-aware e pode sofrer penalidades de acesso a memória remota. Use `numactl --cpunodebind=0 --membind=0` para fixar o processo Redis a um único nó NUMA, ou configure múltiplas instâncias Redis por host com binding explícito por nó NUMA. Monitorar `node_memory_numa_hit` via Prometheus revela se esse problema existe no seu ambiente.

**Security Groups e Stateful Tracking**: Com 200 Gbps disponíveis, é possível gerar volumes de tráfego que estressam o tracking de conexões stateful do Security Group. Para clusters de alta frequência, considere usar Network ACLs stateless para tráfego intra-cluster e Security Groups apenas para o perímetro externo. Isso reduz a overhead de tracking e evita drops silenciosos em picos de tráfego.

> **Riscos Gerenciados: O Que Pode Dar Errado na Migração:** **1. Disponibilidade por AZ não garantida uniformemente**: Mesmo com a expansão regional confirmada, nem todos os tamanhos de R6in/R6idn estarão disponíveis em todas as AZs de Paris e Canadá Central simultaneamente. Sempre valide por AZ antes de comprometer Reserved Instances ou Savings Plans. Um cluster multi-AZ que não consegue lançar instâncias na AZ-b pode quebrar sua estratégia de HA.

**2. Armazenamento de instância R6idn é efêmero**: Os 7,6 TB NVMe da R6idn são perdidos em qualquer stop/start ou falha de hardware. Para Spark, isso é aceitável (recomputação). Para qualquer dado que precise sobreviver a falhas, use EBS. Confundir armazenamento de instância com armazenamento persistente é um erro clássico que aparece em post-mortems.

**3. Custo de EBS com 400K IOPS provisionados**: Provisionar IOPS máximos em `io2 Block Express` para capturar o teto da instância pode custar mais do que o próprio compute. Calcule o custo total de propriedade incluindo EBS antes de comparar com alternativas gerenciadas como ElastiCache ou RDS.

**4. Compatibilidade de AMI**: Algumas AMIs customizadas com drivers de rede antigos podem não suportar ENA corretamente. Valide com `aws ec2 describe-images --image-ids <ami-id> --query 'Images[].EnaSupport'` antes de usar em R6in.

## Matriz de Decisão: Quando Usar R6in vs R6idn vs Alternativas Gerenciadas
| Critério | Critério | R6in (sem NVMe) | R6idn (com NVMe) | ElastiCache / RDS |
| --- | --- | --- | --- | --- |
| Redis autogerenciado com controle total | ✅ Ideal | ⚠️ Custo extra sem benefício | ❌ Menos controle | — |
| Spark com shuffle intensivo | ⚠️ Shuffle em EBS — latência maior | ✅ NVMe local elimina overhead EBS | ❌ Não aplicável | — |
| SAP HANA em produção | ✅ Alta rede + EBS io2 | ✅ NVMe para log volumes | ❌ Não suportado em managed | — |
| Cache de sessão simples < 50 Gbps | ⚠️ Oversized — custo desnecessário | ⚠️ Oversized | ✅ ElastiCache mais econômico | — |
| Conformidade de residência de dados em Paris/Canadá | ✅ Disponível desde jul/2026 | ✅ Disponível desde jul/2026 | ✅ Sempre disponível via managed | — |

## Lente Well-Architected: R6in/R6idn em Ambientes Financeiros

- **security**: Contenção regional em eu-west-3 ou ca-central-1 simplifica o escopo PCI-DSS e RGPD. Use KMS CMKs regionais para criptografia de EBS (aws:kms com `kms:ViaService` condition). Restrinja o lançamento de instâncias R6in via SCP: `ec2:InstanceType` condition key em políticas de Organizations para evitar uso não autorizado de instâncias de alto custo.
- **reliability**: Distribua nós de cluster entre pelo menos 2 AZs, mesmo que isso signifique abrir mão do Cluster Placement Group (que é intra-AZ). Para Redis com replicação assíncrona, a latência intra-AZ é aceitável; para SAP HANA com replicação síncrona, o Cluster PG intra-AZ é obrigatório. Valide disponibilidade de capacidade com `aws ec2 describe-instance-type-offerings` antes de cada deploy.
- **performance**: Configure MTU 9001, use gp3/io2 Block Express em vez de gp2, e valide NUMA binding para instâncias ≥ 16xlarge. Monitore `NetworkPacketsIn/Out` além de `NetworkIn/Out` — o dobro de pacotes por segundo é o diferencial real das R6in para workloads de alta frequência como Redis e Kafka.

> **Nota do Arquiteto:** Na minha experiência com sistemas financeiros em regiões europeias, a expansão regional de famílias de instâncias especializadas como a R6in frequentemente desbloqueia consolidações que estavam bloqueadas por compliance — não por falta de vontade técnica. O que eu faria de diferente do que a maioria faz: antes de migrar qualquer instância, eu instrumentaria o `NetworkPacketsOut` (não apenas `NetworkOut`) para confirmar que o workload é realmente packet-rate-bound e não apenas bandwidth-bound — porque a solução para cada um é diferente. A lição mais dura que aprendi em migrações assim é que o maior risco não é técnico: é comprar Reserved Instances de 3 anos em uma família nova antes de validar que a capacidade está disponível em todas as AZs que seu SLA de HA exige. Sempre valide, sempre prefira Compute Savings Plans na primeira rodada.

## Veredicto: Vale a Migração?

Para workloads de banco de dados em memória, cache distribuído de alta frequência e analytics Spark em Paris ou Canadá Central que hoje estão em R5n ou instâncias de propósito geral: **sim, a migração para R6in/R6idn é justificada**. O dobro de largura de banda de rede e o dobro de performance de processamento de pacotes se traduzem em redução real de tail latency e possibilidade de consolidação de cluster — o que frequentemente resulta em custo total menor mesmo com instâncias mais caras por unidade. A variante R6idn com NVMe é especialmente atraente para Spark com shuffle intensivo, onde o armazenamento local elimina um gargalo de EBS que não tem outra solução elegante.

A ressalva importante: não migre por migrar. Se seu workload de cache está confortável em ElastiCache gerenciado e não exige controle de configuração avançado, o serviço gerenciado continua sendo a escolha mais operacionalmente eficiente. A R6in brilha quando você precisa de controle total sobre a configuração do Redis, quando opera SAP HANA, ou quando roda Spark com requisitos de shuffle que justificam o NVMe local. Para esses casos, em Paris e Canadá Central, a disponibilidade das R6in/R6idn a partir de julho de 2026 fecha a última lacuna geográfica que impedia a adoção plena dessas famílias em ambientes regulados europeus e canadenses.

## Referências

- [AWS What's New: EC2 R6in and R6idn now available in Paris and Canada Central (Jul 2026)](https://aws.amazon.com/about-aws/whats-new/2026/07/amazon-ec2-r6in-r6idn/)
- [AWS What's New: EC2 R6in and R6idn available in Asia Pacific (Sydney) (Sep 2024)](https://aws.amazon.com/about-aws/whats-new/2024/09/amazon-ec2-r6in-r6idn-instances-additional-region/)
- [AWS What's New: EC2 R6in and R6idn available in Europe (Stockholm) (Feb 2024)](https://aws.amazon.com/about-aws/whats-new/2024/02/amazon-ec2-r6in-r6idn-instances-additional-region/)
- [Amazon EC2 Instance Types — R6in and R6idn](https://aws.amazon.com/ec2/instance-types/r6i/)
- [AWS Nitro System](https://aws.amazon.com/ec2/nitro/)
- [Elastic Fabric Adapter (EFA)](https://aws.amazon.com/hpc/efa/)
- [Amazon EBS Volume Types — gp3 and io2 Block Express](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volume-types.html)
- [AWS Compute Optimizer — EC2 Instance Recommendations](https://docs.aws.amazon.com/compute-optimizer/latest/ug/view-ec2-recommendations.html)