R8i vs R8i-flex: Anatomia de uma Decisão de Instância Memory-Optimized

Durante anos, o mercado de instâncias memory-optimized operou com uma premissa implícita: se você precisa de muita RAM, provavelmente também precisa de CPU proporcional o tempo todo. Essa premissa é falsa para a maioria das cargas reais. Um servidor PostgreSQL de banco de dados analítico pode precisar de 256 GiB de RAM para manter o working set em memória e evitar I/O, mas sua utilização de CPU raramente ultrapassa 30-40% fora de janelas de manutenção ou picos de relatórios. Um servidor de cache Redis com replicação, um nó de coordenação de Kafka, um serviço de scoring de modelos de recomendação em batch — todos compartilham esse perfil: alta demanda de memória, demanda de CPU burstável ou moderada.

O modelo tradicional forçava o arquiteto a pagar por vCPUs que ficavam ociosas para obter a RAM necessária. O R8i-flex quebra essa equação ao introduzir um modelo de baseline de CPU com capacidade de burst, análogo ao que o T-family faz para compute-general, mas agora no segmento memory-optimized. A diferença crítica é que o R8i-flex não é uma instância de propósito geral disfarçada: ele roda no mesmo hardware Xeon 6 customizado, com o mesmo throughput de memória de 2,5x em relação à geração anterior, apenas com um contrato diferente de entrega de CPU.

Para ambientes financeiros regulados — pense em um motor de precificação de derivativos rodando na Europa com requisitos de residência de dados na Itália — essa distinção tem impacto direto no TCO. Um r8i.4xlarge tem 128 GiB de RAM e 16 vCPUs dedicadas. Um r8i-flex equivalente em memória entrega a mesma RAM com baseline de CPU menor, a um custo por hora inferior. A escolha errada em uma frota de 200 instâncias representa centenas de milhares de dólares por ano em CPU que nunca foi usada.

O modelo Flex não é novo na AWS — ele existe na família C-series para compute-optimized há alguns ciclos. O que é novo é sua aplicação ao segmento memory-optimized, historicamente dominado por cargas que justificavam CPU dedicada. O mecanismo é simples na teoria: uma instância Flex tem um baseline de CPU garantido (tipicamente proporcional ao tamanho) e pode fazer burst acima desse baseline usando créditos de CPU, de forma análoga ao T4g/T3, mas sem o teto rígido de créditos esgotáveis. A distinção importante é que o R8i-flex não é um T-instance renomeado — ele não tem o mesmo risco de throttling agressivo quando os créditos se esgotam em cargas sustentadas.

Para um arquiteto de sistemas financeiros, o R8i-flex abre uma janela de otimização específica: serviços de middle-office que mantêm grandes estruturas de dados em memória para lookups rápidos (tabelas de referência de instrumentos, curvas de yield, matrizes de correlação) mas que processam transações em rajadas previsíveis — abertura de mercado, fechamento de posições, reconciliação noturna. Nesses casos, o perfil de CPU é bimodal: baixo por horas, alto por minutos. Pagar por CPU dedicada 24/7 para cobrir os picos de 15 minutos é exatamente o problema que o Flex resolve.

O range de tamanhos disponíveis no R8i-flex — de large a 16xlarge — cobre a vasta maioria dos workloads de middle e back-office financeiro. Para referência, um r8i-flex.16xlarge entrega 512 GiB de RAM, suficiente para manter um grafo de risco de portfólio inteiro em memória para um banco de médio porte. Acima disso, você inevitavelmente migra para o R8i puro, que oferece até o 96xlarge com capacidade de RAM correspondente para os maiores ambientes SAP HANA e bancos de dados in-memory de escala enterprise.

O R8i puro é a escolha correta em três cenários que se sobrepõem frequentemente em ambientes financeiros de missão crítica.

Primeiro: SAP HANA e workloads certificados. O benchmark de 142,100 aSAPS não é um número de marketing — ele representa a capacidade de processar transações SAP SD em escala enterprise com latência previsível. Bancos e seguradoras que rodam SAP S/4HANA para contabilidade geral, gestão de ativos ou compliance regulatório precisam de instâncias certificadas. O R8i-flex não está nessa lista. A certificação SAP impõe requisitos de CPU dedicada e comportamento determinístico que o modelo Flex não pode garantir por design.

Segundo: PostgreSQL com alta concorrência sustentada. O ganho de 30% sobre o R7i no PostgreSQL não vem apenas do clock do processador — ele vem do aumento de 2,5x no bandwidth de memória, que reduz diretamente a latência de acesso ao buffer pool. Para um banco de dados de trading com 500+ conexões simultâneas processando ordens em tempo real, a latência de P99 importa mais do que o throughput médio. Nesse cenário, qualquer throttling de CPU — mesmo que raro — é inaceitável. O R8i dedicado é a única escolha defensável.

Terceiro: Instâncias de grande porte e bare metal. O novo 96xlarge e os dois tamanhos bare metal existem por uma razão: algumas cargas não podem ser particionadas. Um banco de dados in-memory que precisa de 3+ TiB de RAM com acesso NUMA otimizado, um ambiente de backtesting que carrega anos de dados de mercado em memória, um nó SAP HANA scale-up de grande porte — todos requerem o modelo de instância dedicada. O R8i-flex simplesmente não oferece esses tamanhos, tornando a decisão trivial nesse extremo do espectro.

A chegada do R8i e R8i-flex à região eu-south-1 (Europa/Milão) em agosto de 2026 completa um padrão de expansão europeia que seguiu a sequência: Paris (eu-west-3) e Mumbai/Hyderabad em janeiro de 2026, depois Estocolmo (eu-north-1) e Zurique (eu-central-2) em julho de 2026, e agora Milão. Essa cadência não é aleatória — ela reflete a demanda de clientes com requisitos de residência de dados regulatórios.

Milão é particularmente relevante para o setor financeiro europeu. A Itália é sede de instituições financeiras de grande porte com obrigações de conformidade sob o DORA (Digital Operational Resilience Act) e o GDPR, que em certos contextos exigem que dados de clientes e logs de transações permaneçam dentro de fronteiras jurisdicionais específicas. Para um banco italiano ou uma seguradora que já usa AWS mas estava forçado a rodar cargas memory-intensive em Frankfurt (eu-central-1) por falta de opções em Milão, a disponibilidade do R8i em eu-south-1 elimina um trade-off arquitetural desconfortável.

Do ponto de vista operacional, a expansão regional também afeta a estratégia de disaster recovery. Um arquiteto que projeta um ambiente SAP HANA com DR entre regiões europeias agora pode construir uma topologia ativo-passivo entre eu-south-1 (Milão) e eu-central-1 (Frankfurt) usando instâncias da mesma geração, eliminando a assimetria de performance que ocorre quando a região primária tem R8i e a região de DR ainda roda R7i. Essa assimetria é um vetor de falha silencioso: o failover funciona no teste, mas a performance pós-failover é 20% inferior, o que pode violar SLOs de latência em produção.

A compra via Savings Plans — disponível para ambas as famílias — permite comprometer capacidade em eu-south-1 com desconto, sem vincular o compromisso a um tamanho de instância específico. Para ambientes financeiros com planejamento de capacidade de 1-3 anos, esse é o modelo de compra padrão, combinado com On-Demand para burst e Spot apenas para cargas tolerantes a interrupção como backtesting e treinamento de modelos.