C7a em us-west-1: Retro de Migração e Resiliência em Produção

A chegada do C7a em us-west-1 não é um evento isolado. É o capítulo final de uma expansão que começou em fevereiro de 2024, quando a AWS trouxe C7a e R7a para regiões adicionais. Equipes que já operavam C7a em us-east-1 ou eu-west-1 tinham playbooks. Equipes em us-west-1 que dependiam de C6a como baseline compute não tinham, e foi exatamente aí que os incidentes aconteceram em ciclos anteriores de expansão regional similares.

O padrão que observo repetidamente: uma equipe de plataforma recebe o sinal do What's New, abre um ticket de 'upgrade de instância', e trata a migração como uma substituição 1:1. O C7a tem até 50% mais performance que o C6a segundo o anúncio oficial, mas 'performance' aqui é throughput de CPU em benchmarks sintéticos. O que não aparece no anúncio é que o AMD EPYC Genoa (4ª geração) com DDR5 e 2,25x mais bandwidth de memória muda o perfil de pressão do sistema. Workloads que eram CPU-bound no C6a podem se tornar I/O-bound ou network-bound no C7a, simplesmente porque o gargalo se move quando você remove a restrição de CPU.

Em sistemas financeiros, isso importa porque SLOs são definidos sobre o comportamento observado do sistema, não sobre capacidade teórica. Um job de reconciliação de posições que rodava em 8 minutos no C6a.4xlarge pode rodar em 5 minutos no C7a.4xlarge, ou pode travar em 12 minutos se o perfil de acesso a dados não for compatível com a nova hierarquia de cache do Genoa. A diferença está em como o workload foi instrumentado e validado antes da migração.

Antes de falar em remediação, é necessário entender o que o C7a traz de concreto, além do marketing de '50% mais performance'. O processador AMD EPYC Genoa de 4ª geração opera com frequência máxima de 3,7 GHz e introduz três capacidades que têm impacto direto em workloads financeiros e de analytics: AVX-512, VNNI e bfloat16.

AVX-512 é relevante para operações vetoriais em larga escala, pense em cálculos de risco de portfólio, transformações matriciais em modelos de precificação, ou compressão/descompressão de dados em pipelines Glue. VNNI (Vector Neural Network Instructions) e bfloat16 são diretamente aplicáveis a inferência de modelos ML, se você roda scoring de crédito ou detecção de fraude em instâncias EC2 (em vez de SageMaker), o C7a oferece aceleração de hardware sem custo adicional de instância especializada.

O DDR5 com 2,25x mais bandwidth de memória que o C6a é o diferencial mais subestimado. Em jobs de analytics que fazem hash joins em memória (Spark, Trino, Flink), o bandwidth de memória frequentemente é o gargalo real, não a frequência do clock. Um executor Spark com 32 GB de memória em c7a.8xlarge vai processar shuffles significativamente mais rápido que no c6a.8xlarge, não por causa da CPU, mas porque o pipeline de dados entre CPU e RAM é mais largo.

A mudança de 28 para 128 volumes EBS por instância é cirúrgica para casos de uso específicos: clusters de banco de dados com múltiplos volumes de dados, ambientes de HPC com storage distribuído, ou nós de analytics que precisam de múltiplos volumes gp3 para atingir o IOPS agregado necessário sem usar io2 Block Express. Para a maioria dos workloads, esse limite nunca foi o constraint, mas para os que eram, essa mudança é desbloqueadora.

A remediação estruturada que implementei em contextos similares começa antes de qualquer mudança de Launch Template. O primeiro passo é uma análise de saturation da cadeia completa: não apenas CPU e memória da instância, mas EBS throughput (MB/s e IOPS), network bandwidth, latência de chamadas downstream (RDS, DynamoDB, S3, serviços internos), e queue depth em qualquer sistema de mensageria no caminho.

No CloudWatch, isso significa configurar métricas customizadas com namespace ApplicationPerformance para cada componente da cadeia, com alarmes compostos que disparam quando qualquer componente atinge 70% de saturação, não 90%, porque a margem de 20% é o que separa um alerta acionável de um incidente em andamento. Para RDS, o RDS Performance Insights com retenção de 7 dias (gratuito) é suficiente para identificar top SQL por wait events antes da migração.

O segundo passo é o sizing coordenado. Se o C7a vai processar 50% mais rápido, o EBS precisa ser dimensionado para absorver 50% mais IOPS. Para volumes gp3, isso é uma operação online sem downtime: aws ec2 modify-volume --volume-id vol-xxx --iops 6000 --throughput 250. O limite de 6000 IOPS e 250 MB/s do gp3 cobre a maioria dos workloads financeiros sem custo de io2. Se o workload exige mais, io2 Block Express com até 256.000 IOPS é o próximo patamar, mas o custo é 3x maior que gp3, então a análise de ROI precisa ser explícita.

O terceiro passo é o canary com observabilidade sistêmica. Não basta monitorar a instância nova, é preciso monitorar o comportamento de todos os componentes downstream durante o canary. Um SLO Composite Alarm no CloudWatch que combina P99 de latência da aplicação, duração de jobs batch e error rate de chamadas downstream é o mínimo aceitável. O rollback deve ser automatizado via EventBridge + Lambda que reverte o Launch Template se o alarme disparar, não depender de intervenção humana às 2h da manhã.

Migrações de instância em ambientes financeiros têm uma dimensão de segurança que frequentemente é ignorada no calor do incidente: a mudança de instância pode invalidar controles de compliance que foram certificados para uma configuração específica.

O primeiro vetor é o Nitro System. O C7a é construído sobre o AWS Nitro System, o que é positivo do ponto de vista de segurança, o hipervisor Nitro isola o hardware de rede e storage do host, e o Nitro Security Chip garante que o firmware do host não pode ser modificado. Mas se o seu ambiente tem um relatório de conformidade (PCI DSS, SOC 2, ISO 27001) que referencia explicitamente o tipo de instância ou a geração do processador como parte do escopo de controle, a mudança para C7a pode exigir uma atualização da documentação de controle antes do deploy em produção.

O segundo vetor é o IAM e as políticas de controle de serviço (SCPs). Em ambientes com Zero Trust rigoroso, é comum ter SCPs que restringem os tipos de instância permitidos por conta ou OU, por exemplo, ec2:RunInstances com condição ec2:InstanceType restrita a uma lista aprovada. A chegada do C7a em us-west-1 significa que esse tipo precisa ser explicitamente adicionado à allowlist antes de qualquer tentativa de launch, caso contrário o deploy vai falhar silenciosamente com AccessDenied, o que é um vetor de confusão operacional em ambientes de alta pressão.

O terceiro vetor é o KMS e a criptografia de volumes EBS. Se os volumes EBS usam CMKs (Customer Managed Keys) com políticas de chave que referenciam ARNs de instância ou tags específicas, a migração para um novo tipo de instância pode quebrar o acesso ao volume se as políticas não forem atualizadas. A boa prática é usar condições baseadas em tags (aws:RequestedRegion, ec2:InstanceType) em vez de ARNs hardcoded nas políticas de chave KMS.

A US West (N. California) tem um perfil de uso diferente de us-east-1 ou us-west-2. Historicamente, us-west-1 é uma região de menor escala, com portfólio de serviços mais restrito e frequentemente usada como região secundária em arquiteturas de DR ativo-passivo ou como região de compliance para dados que precisam permanecer na Califórnia por requisitos legais (CCPA, regulações financeiras estaduais).

Essa característica tem implicações diretas para a chegada do C7a. Primeiro, a disponibilidade de instâncias Spot em us-west-1 é historicamente menor que em us-east-1 e us-west-2, o pool de capacidade Spot é proporcional à escala da região. Isso significa que workloads que dependem de Spot para custo (ETL, reprocessamento batch) precisam de estratégias de diversificação mais agressivas: múltiplos tipos de instância no ASG (c7a.4xlarge, c7a.8xlarge, c6a.4xlarge como fallback), múltiplas AZs, e Capacity Rebalancing habilitado.

Segundo, us-west-1 é frequentemente a região onde empresas de tecnologia da Califórnia mantêm dados de usuários por compliance. Se o seu workload processa dados de clientes com restrições de residência geográfica, a migração para C7a nessa região pode ser o gatilho para revisar a arquitetura de data residency, especialmente com o aumento de 28 para 128 volumes EBS por instância, que pode viabilizar consolidação de nós de processamento que antes exigiam múltiplas instâncias.

Terceiro, a chegada do C7a em us-west-1 em julho de 2026, mais de dois anos após a disponibilização inicial em outras regiões, é um sinal de que a AWS está expandindo o portfólio de instâncias de geração atual para regiões menores de forma gradual. Para equipes que operam em us-west-1 como região primária, isso significa que o gap de capacidade compute em relação a us-east-1 está diminuindo, mas ainda existe. Planejar workloads críticos assumindo paridade completa de portfólio entre regiões é um erro de arquitetura que vejo repetidamente.