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

A disponibilização do EC2 C7a em us-west-1 em julho de 2026 parece trivial — mais uma região, mais um tipo de instância. Mas para equipes que operam workloads compute-intensivos com SLOs rígidos, cada expansão regional carrega riscos reais de migração que raramente aparecem nos anúncios. Neste retro, analiso o que pode (e costuma) dar errado, qual a causa raiz sistêmica, e como construir a remediação certa.

- URL: https://fernando.moretes.com/blog/c7a-em-us-west-1-retro-de-migracao-e-resiliencia-em-producao-amazon-ec2-c

- Markdown: https://fernando.moretes.com/blog/c7a-em-us-west-1-retro-de-migracao-e-resiliencia-em-producao-amazon-ec2-c/article.md?lang=pt

- Published: 2026-07-23T09:04:04.635Z

- Category: IA & Agentes

- Tags: ec2, c7a, amd-epyc, migration, resilience, financial-grade, well-architected, incident-retro

- Reading time: 10 min

- Source: [Amazon EC2 C7a instances are now available in the US West (N. California) Region](https://aws.amazon.com/about-aws/whats-new/2026/07/amazon-ec2-c7a-instances-us-west-ncalifornia-region/)

---

Em 22 de julho de 2026, a AWS anunciou a disponibilidade do EC2 C7a na região US West (N. California). Para a maioria das equipes, isso é uma nota de rodapé. Para quem opera batch financeiro, analytics distribuído ou inferência de modelos com SLOs de latência P99 abaixo de 50 ms, é um gatilho de decisão — e um vetor de incidente se a migração não for tratada como engenharia de produção.

## O que aconteceu: a anatomia de uma migração silenciosa que virou incidente

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.

## Timeline do Incidente Típico de Migração Regional

1. **T+0h — Anúncio recebido** — Engenheiro de plataforma vê o What's New do C7a em us-west-1. Abre PR para atualizar o Terraform com o novo instance_type. Sem análise de workload, sem benchmark, sem janela de mudança formal.

2. **T+2h — Deploy em staging** — Auto Scaling Group atualizado para c7a.4xlarge via Launch Template. Staging não replica o volume de dados de produção nem o padrão de acesso concorrente. Testes passam. Equipe confia.

3. **T+6h — Rollout em produção (canary 10%)** — Canary deployment ativo. Métricas de CPU mostram queda de 40% — exatamente o esperado. Equipe interpreta como sucesso. Não há alerta configurado para latência P99 de downstream (banco de dados RDS e S3 GetObject).

4. **T+8h — Primeiro alerta de SLO** — Job de reconciliação financeira dispara alerta de SLO: duração P95 subiu de 8 min para 14 min. O C7a processa mais rápido, mas agora satura o throughput de leitura do RDS (gp2 EBS, 3 IOPS/GB baseline) que não foi redimensionado. O gargalo migrou do CPU para o storage.

5. **T+9h — Rollback do canary** — Equipe reverte o Launch Template para c6a.4xlarge. SLO normaliza em 12 minutos. Post-mortem iniciado. Root cause identificado: ausência de análise de gargalo sistêmico antes da migração.

6. **T+72h — Remediação estruturada** — Equipe executa análise de bottleneck com CloudWatch Container Insights + RDS Performance Insights. Identifica que o volume EBS precisa migrar para gp3 com 6000 IOPS provisionados. Migração re-executada com sucesso após ajuste de storage.

> **Causa Raiz: O Gargalo Migra, Não Some:** O erro sistêmico não foi técnico — foi de modelo mental. A equipe tratou a migração de instância como uma operação de capacidade isolada. Em sistemas distribuídos, remover um gargalo de CPU em um nó de processamento não aumenta throughput end-to-end: ele apenas revela o próximo gargalo na cadeia. Com C7a processando 50% mais rápido, o volume de requisições para RDS, S3 e serviços downstream aumentou proporcionalmente — sem que esses componentes tivessem sido dimensionados para absorver a carga adicional. A ausência de observabilidade sistêmica (métricas de saturation em todos os componentes da cadeia, não apenas no compute) foi o vetor real do incidente.

## O Perfil Técnico do C7a: O Que Realmente Muda

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.

## Fluxo de Migração Segura: C6a → C7a com Análise de Gargalo Sistêmico

O diagrama mostra as fases de uma migração de instância tratada como engenharia de produção: análise de gargalo antes do rollout, canary com observabilidade sistêmica, e gate de decisão antes do rollout completo.

### 🔍 Phase 1: Pre-Migration Analysis

- RDS Performance Insights (data)
- CloudWatch Saturation Metrics (CPU/Net/EBS/DB) (security)
- Bottleneck Analysis Gate (pass/fail) (edge)

### 🚀 Phase 2: Canary Rollout (10%)

- Launch Template c7a.4xlarge (new) (compute)
- Auto Scaling Group Canary Weight 10% Instance Refresh (compute)
- Launch Template c6a.4xlarge (baseline) (compute)

### 📊 Phase 3: Systemic Observability

- OpenTelemetry Collector Trace + Metrics (security)
- SLO Composite Alarm P99 + Duration (messaging)
- Datadog Dashboard Chain Saturation (security)

### ✅ Phase 4: Decision & Full Rollout

- Promote / Rollback Decision Gate (automated+human) (edge)
- Full Rollout c7a.4xlarge 100% (compute)
- Rollback c6a.4xlarge (Launch Template revert) (compute)

### Fluxos

- perf_insights -> bottleneck_gate: satura storage?
- cw_metrics -> bottleneck_gate: satura rede/EBS?
- bottleneck_gate -> lt_c7a: aprovado
- lt_c7a -> asg_canary: 10% tráfego
- lt_c6a -> asg_canary: 90% tráfego
- asg_canary -> otel: traces + spans
- otel -> slo_alarm: métricas SLO
- otel -> datadog: saturation chain
- slo_alarm -> decision: breach / ok
- decision -> full_rollout: promover
- decision -> rollback: reverter

## Remediação: Engenharia de Migração, Não Operação de Ticket

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ã.

## Números Concretos: C6a vs C7a em Workloads Financeiros

- **50%** — Ganho de performance CPU vs C6a. Fonte: anúncio oficial AWS, benchmarks sintéticos AMD EPYC Genoa 3.7 GHz
- **2.25x** — Bandwidth de memória DDR5 vs C6a (DDR4). Impacto direto em hash joins, shuffles Spark e operações vetoriais
- **128** — Volumes EBS por instância (vs 28 no C6a). Desbloqueador para clusters HPC e nós de analytics com IOPS agregado alto
- **12** — Tamanhos disponíveis (medium a 48xlarge + bare-metal). Bare-metal elimina overhead de hypervisor para workloads HPC e latência ultra-baixa

## C6a vs C7a: Análise de Trade-offs para Decisão de Migração
| Critério | Dimensão | C6a (AMD EPYC Milan, DDR4) | C7a (AMD EPYC Genoa, DDR5) |
| --- | --- | --- | --- |
| Frequência máxima | 3.6 GHz (boost) | 3.7 GHz (max) | — |
| Bandwidth de memória | DDR4 — baseline | DDR5 — 2.25x maior | — |
| Instruções vetoriais | AVX2 | AVX-512, VNNI, bfloat16 | — |
| Volumes EBS máximos | 28 volumes | 128 volumes | — |
| Risco de migração | Baseline conhecido, comportamento previsível | Gargalo migra para downstream se não houver análise sistêmica | — |
| Melhor caso de uso | Workloads estáveis com SLOs definidos sobre C6a | Batch financeiro, ML inference, analytics vetorial, HPC | — |

## Considerações de Segurança e Governança na Migração

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.

## Lentes Well-Architected: O Que Este Incidente Revela

- **security**: Valide SCPs e políticas de chave KMS antes de qualquer migração de tipo de instância em ambientes regulados. Use AWS Config Rule `ec2-instance-managed-by-ssm` para garantir que novas instâncias C7a são automaticamente registradas no SSM para patch management. Certifique-se de que o IMDSv2 está habilitado obrigatoriamente no Launch Template (`HttpTokens: required`) — o Nitro System suporta IMDSv2 nativamente.
- **reliability**: A migração de instância sem análise de gargalo sistêmico viola o princípio de 'test recovery procedures'. O canary deployment é necessário mas não suficiente — ele precisa ser acompanhado de alarmes compostos que cobrem toda a cadeia de dependências, não apenas a instância migrada. Use Instance Refresh com `MinHealthyPercentage: 90` e `CheckpointPercentages: [10, 50, 100]` para controle granular do rollout.
- **performance**: O C7a com AVX-512 e bfloat16 oferece aceleração de hardware para workloads vetoriais e ML. Mas a aceleração só se materializa se o código foi compilado com suporte a essas instruções. Verifique se os binários do workload (JVM flags para Spark, flags de compilação para C++/Rust, bibliotecas NumPy/PyTorch) estão configurados para usar AVX-512. Caso contrário, o ganho de performance será apenas o delta de clock e DDR5.

## Anti-Padrões Comuns em Migrações de Instância

- Tratar a migração de instância como uma operação de infraestrutura isolada, sem análise de impacto nos componentes downstream (RDS, S3, DynamoDB, serviços internos).
- Usar staging como proxy de produção sem replicar o volume de dados, padrão de concorrência e mix de workload real — staging passa, produção falha.
- Configurar alarmes apenas na instância nova durante o canary, ignorando a saturação de componentes downstream que absorvem o throughput adicional.
- Assumir que 'mais performance de CPU' equivale a 'menor latência end-to-end' sem verificar se o gargalo atual é realmente CPU — em muitos workloads financeiros, é I/O ou rede.
- Não atualizar SCPs e allowlists de tipo de instância antes do deploy, resultando em falhas silenciosas de AccessDenied em ambientes com Zero Trust rigoroso.
- Comprometer Reserved Instances para C7a imediatamente após a disponibilização regional, sem dados de uso suficientes para validar o commitment de 1 ou 3 anos.

## O Caso Específico de us-west-1: Por Que Esta Região Importa

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.

## Perguntas Frequentes: C7a em Produção

### O C7a é compatível com AMIs existentes do C6a?

Sim, desde que a AMI use uma arquitetura x86_64. O C7a é x86_64 como o C6a. No entanto, para aproveitar AVX-512 e bfloat16, os binários precisam ser recompilados ou ter flags de runtime configurados (ex: `-march=znver4` para GCC/Clang, ou `-XX:+UseAVX=3` para JVM em workloads Spark).

### O bare-metal C7a é adequado para workloads financeiros de latência ultra-baixa?

Sim, o bare-metal elimina o overhead do hipervisor e permite acesso direto ao hardware. Para trading de alta frequência ou processamento de mercado em tempo real, isso pode reduzir latência de jitter em microssegundos. O trade-off é a perda de flexibilidade de EC2 (sem Live Migration, sem Hibernate) e maior complexidade operacional. O Nitro System ainda está presente no bare-metal para isolamento de rede e storage.

### Como o C7a se compara ao C7i (Intel) para workloads Java/JVM?

Para workloads JVM puros (Spring Boot, Kafka brokers, Flink), o C7i (Sapphire Rapids) tem vantagem em single-thread performance e suporte a Intel AMX para aceleração de ML. O C7a tem vantagem em throughput multi-thread e bandwidth de memória (DDR5). A decisão deve ser baseada em benchmark do workload real — não em especificações de papel. Em geral, workloads de analytics distribuído (Spark, Trino) se beneficiam mais do C7a; workloads de serviço web com alta concorrência de threads podem preferir C7i.

> **Nota do Arquiteto:** Em 16 anos trabalhando com migrações de compute em ambientes financeiros, a lição que mais custa aprender é esta: a performance de uma instância é uma propriedade local; a performance de um sistema é uma propriedade emergente. Toda vez que migro um nó de processamento para hardware mais rápido sem fazer a análise de saturation da cadeia completa, estou essencialmente empurrando o gargalo para outro lugar e esperando que ninguém note. O C7a em us-west-1 é uma oportunidade real — DDR5 com 2,25x de bandwidth muda o jogo para analytics vetorial e ML inference. Mas eu não tocaria em um Launch Template de produção sem antes rodar uma semana de CloudWatch Contributor Insights no RDS e S3 para entender onde está o próximo gargalo. E o rollback automatizado via EventBridge não é opcional — é o que separa uma migração controlada de um incidente de madrugada.

## Veredicto: Migre, Mas com Engenharia

O EC2 C7a em us-west-1 é um upgrade legítimo para workloads compute-intensivos — especialmente batch financeiro, analytics distribuído com Spark/Trino, e inferência de modelos ML que podem aproveitar AVX-512 e bfloat16. O ganho de 50% em throughput de CPU e 2,25x em bandwidth de memória DDR5 é real e mensurável em workloads que eram CPU ou memória-bound no C6a. A expansão de 28 para 128 volumes EBS por instância é um desbloqueador específico para arquiteturas HPC e analytics de alta densidade.

Mas a migração precisa ser tratada como engenharia de produção, não como operação de ticket. O protocolo mínimo: (1) análise de saturation de toda a cadeia antes do rollout, (2) sizing coordenado de EBS (gp3 com IOPS provisionados), RDS e serviços downstream, (3) canary com alarmes compostos cobrindo P99 end-to-end, (4) rollback automatizado via EventBridge + Lambda, (5) validação de SCPs e políticas KMS em ambientes regulados. Para us-west-1 especificamente, diversifique o pool de Spot com múltiplos tipos de instância e não comprometa Reserved Instances antes de 30 dias de dados de uso. A lição central deste retro: remover um gargalo sem analisar o próximo é a receita mais comum para transformar um upgrade de performance em um incidente de SLO.

**Rating:** Migrate with structured engineering — hi

## Referências

- [AWS What's New: Amazon EC2 C7a instances now available in US West (N. California)](https://aws.amazon.com/about-aws/whats-new/2026/07/amazon-ec2-c7a-instances-us-west-ncalifornia-region/)
- [AWS EC2 C7a Instance Types — Official Documentation](https://aws.amazon.com/ec2/instance-types/c7a/)
- [AWS What's New: EC2 C7a and R7a in additional regions (Feb 2024)](https://aws.amazon.com/about-aws/whats-new/2024/02/amazon-ec2-c7a-r7a-instances-additional-regions/)
- [AWS EC2 Instance Types Overview](https://aws.amazon.com/ec2/instance-types/)
- [AWS Nitro System — Security and Architecture](https://aws.amazon.com/ec2/nitro/)
- [AWS Well-Architected Framework — Reliability Pillar](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/welcome.html)
- [Amazon EBS gp3 Volume Configuration](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volume-types.html)
- [AWS Auto Scaling Instance Refresh with Checkpoints](https://docs.aws.amazon.com/autoscaling/ec2/userguide/asg-instance-refresh.html)