AWS Graviton: Guia de Migração 2026

Atualizado: 08 de Julho de 2026

A migração para AWS Graviton em 2026 reduz o custo de cargas de trabalho EC2, RDS e Lambda em até 40% na relação preço-desempenho ao substituir instâncias x86 (Intel/AMD) por instâncias ARM baseadas nos processadores Graviton3 e Graviton4 da AWS. Na prática, a migração envolve recompilar containers para linux/arm64, trocar o tipo de instância (por exemplo, m6i para m7g ou m8g) e validar a compatibilidade de bibliotecas nativas. Neste guia, mostro o passo a passo que uso em clientes que operam entre 500 e 15.000 instâncias EC2, com benchmarks, comandos e as armadilhas que sempre aparecem em produção.

Instâncias Graviton3 (famílias c7g, m7g, r7g) e Graviton4 (c8g, m8g, r8g, x8g) entregam de 15% a 40% de economia por vCPU em relação a instâncias Intel Ice Lake e AMD EPYC equivalentes.
RDS Graviton (db.r7g, db.m7g) reduz custos de PostgreSQL, MySQL e MariaDB em até 35%, com ganhos adicionais em latência de consultas com IO intensivo.
AWS Lambda em arm64 é 20% mais barato por GB-segundo do que x86_64 e frequentemente executa código Python, Node.js e Go em menor tempo.
Graviton é totalmente compatível com Compute Savings Plans; combinado com um plano de 3 anos com pagamento antecipado, dá para chegar a 72% de economia versus On-Demand x86.
Os principais bloqueios são bibliotecas nativas compiladas apenas para x86 (Oracle Instant Client, alguns drivers antigos de ODBC) e imagens Docker single-arch. Ambos resolvem-se com QEMU e buildx.

O que é AWS Graviton e por que economiza custos

AWS Graviton é uma família de processadores ARM Neoverse desenhados pela Annapurna Labs (subsidiária da AWS) e fabricados em processo TSMC de 5 nm (Graviton3) e 4 nm (Graviton4). Diferentemente de instâncias Intel Xeon ou AMD EPYC, cujos preços a AWS repassa dos fornecedores, os chips Graviton são internos. A AWS controla margem, wafers e desenho térmico. É por isso que, historicamente, cada geração de Graviton chega ao mercado com preço 20% abaixo da geração x86 equivalente, mesmo ganhando em desempenho por vCPU.

Em números de 2026: um m7g.xlarge (Graviton3, 4 vCPUs, 16 GiB) custa US$ 0,1632/hora em us-east-1, enquanto um m6i.xlarge (Intel Ice Lake, 4 vCPUs, 16 GiB) custa US$ 0,192/hora, ou seja, 15% mais barato antes mesmo de olhar desempenho. Quando incluímos benchmarks reais de aplicações Java (Corretto 21) e Go 1.23, o m7g entrega entre 20% e 30% mais throughput por dólar. É a combinação de preço mais baixo com desempenho mais alto que produz a famosa métrica de "até 40% melhor relação preço-desempenho" que aparece nos slides da AWS.

Do ponto de vista de FinOps, Graviton é o único vetor de economia que não exige compromisso de tempo (como Savings Plans) nem tolerância a interrupções (como Spot). Você troca a arquitetura, valida, e o desconto é imediato e permanente. Por isso, no meu roteiro de otimização de clientes AWS, Graviton é sempre a segunda intervenção, logo depois de right-sizing baseado em Compute Optimizer e antes de qualquer compromisso de longo prazo.

Graviton3 vs Graviton4: comparação de famílias de instâncias

Em 2026 convivem duas gerações relevantes no catálogo AWS: Graviton3 (famílias com sufixo 7g: c7g, m7g, r7g, hpc7g, im4gn) e Graviton4 (sufixo 8g: c8g, m8g, r8g, x8g). Graviton4 é geralmente mais rápido, com até 30% mais desempenho por vCPU sobre Graviton3, suporte a até 96 vCPUs (vs 64 no c7g) e 384 GiB de memória em famílias R. Graviton3 continua vivo por dois motivos: disponibilidade regional mais ampla e preço marginalmente mais baixo em cargas que não saturam CPU.

Característica	Graviton3 (c7g/m7g/r7g)	Graviton4 (c8g/m8g/r8g)
Núcleos ARM Neoverse	V1	V2
Processo de fabricação	TSMC 5 nm	TSMC 4 nm
vCPUs máximos	64	96
Memória DDR5	DDR5-4800	DDR5-5600
Desempenho por vCPU vs G3	Baseline	+30% (SPECrate)
Rede máxima	30 Gbps	50 Gbps
Preço vs Intel m6i	~15% mais barato	~10% mais barato
Disponibilidade regional	Praticamente todas	us-east-1, us-west-2, eu-west-1, ap-south-1 e outras 8

Como regra prática: se sua carga é CPU-bound (processamento de imagens, compilação, JVM sob carga), migre direto para Graviton4. O ganho por vCPU paga o pequeno prêmio. Se sua carga é memory-bound ou I/O-bound (bancos de dados, caches, filas), Graviton3 continua com excelente custo-benefício e evita o risco de indisponibilidade regional.

Quanto mais barato é o Graviton em relação ao x86?

A resposta curta: entre 10% e 40% mais barato, dependendo da métrica que você mede. A resposta longa é o que separa uma migração bem-feita de um rollback constrangedor três semanas depois. Vamos ver os três eixos.

1. Preço da instância (comparação direta)

Comparando SKUs equivalentes em us-east-1 (preços de julho de 2026, On-Demand):

m6i.xlarge (Intel Ice Lake): US$ 0,192/hora
m7i.xlarge (Intel Sapphire Rapids): US$ 0,2016/hora
m7a.xlarge (AMD EPYC 4ª geração): US$ 0,2176/hora
m7g.xlarge (Graviton3): US$ 0,1632/hora, 15% mais barato que m6i
m8g.xlarge (Graviton4): US$ 0,17472/hora, 9% mais barato que m6i e 13% mais barato que m7i

2. Desempenho por vCPU (SPECrate2017 integer)

Aqui Graviton domina em cargas modernas. Em benchmarks internos que rodo com clientes usando Corretto 21 e OpenJDK 23, m7g.xlarge entrega 22% mais transações/segundo que m6i.xlarge em aplicações Spring Boot. Go 1.23 no Graviton4 chega a 35% mais throughput em cargas HTTP puras (benchmark wrk2 contra API REST).

3. Custo total por transação

Combinando (1) e (2), a métrica que interessa é dólar por transação processada. Em uma amostra de 12 microserviços Java que migrei em 2025-2026 (fintech brasileira, ~800 EC2 rodando ECS):

Antes (m6i.xlarge, 240 tarefas):    US$ 33.177/mês
Depois (m7g.xlarge, 192 tarefas):   US$ 22.567/mês
Redução:                            32%

Observação importante: a redução de 32% incluiu duas coisas simultâneas, ou seja, preço da instância 15% menor E menos instâncias necessárias porque cada m7g entregou mais throughput. Isso é o "40% de melhor preço-desempenho" na prática, e é por isso que benchmarks isolados sempre subestimam a economia real.

Quais serviços AWS suportam processadores Graviton?

Em 2026, Graviton está disponível praticamente em todo lugar onde a AWS oferece computação gerenciada. A lista curta dos que uso com clientes:

EC2: famílias c7g/c8g (compute), m7g/m8g (general purpose), r7g/r8g/x8g (memory), i4g/im4gn (storage), hpc7g (HPC), g5g (GPU + Graviton2).
Amazon RDS: PostgreSQL, MySQL, MariaDB, Oracle e SQL Server em db.m7g, db.r7g, db.m8g, db.r8g. SQL Server ainda tem restrições, e nem todas as edições estão cobertas.
Amazon Aurora: PostgreSQL e MySQL em db.r7g/r8g. Aurora Serverless v2 também roda em Graviton por padrão desde 2024.
Amazon ElastiCache: Redis e Memcached em cache.m7g, cache.r7g, cache.m8g.
Amazon MemoryDB for Redis: db.r7g nativo.
AWS Lambda: arquitetura arm64 disponível em todas as regiões, com 20% de desconto por GB-segundo.
AWS Fargate: ECS e EKS em Fargate suportam runtimePlatform: { cpuArchitecture: ARM64 }.
Amazon EMR: EMR 6.6+ suporta Graviton para Spark, Hive e Presto.
Amazon OpenSearch Service: r7g e c7g para nós de dados.
AWS App Runner: arm64 disponível desde 2024.

Serviços que ainda não suportam Graviton em 2026: alguns SKUs de instâncias GPU antigos (p4d, p5), instâncias de rede aceleradas específicas (F1, DL1) e algumas edições legadas de licenciamento Oracle no RDS. Sempre verifique a documentação oficial de instâncias Graviton antes de assumir.

Como migrar cargas EC2 para Graviton passo a passo

Este é o roteiro que sigo em toda migração. Ele assume que você já tem uma frota EC2 x86 em produção, gerenciada por Auto Scaling Groups (ASG) ou ECS. Se você usa apenas instâncias standalone, o processo é mais simples. Pule direto para o passo 3.

Passo 1: Inventariar candidatos com AWS Compute Optimizer

Compute Optimizer analisa 14 dias de métricas CloudWatch e recomenda migrações para Graviton quando faz sentido. Ative a análise avançada (paga, US$ 0,0003 por recurso/hora) para receber recomendações de família ARM. O comando abaixo lista todas as recomendações de instâncias com potencial de economia acima de US$ 100/mês:

aws compute-optimizer get-ec2-instance-recommendations \
  --recommendation-preferences '{"cpuVendorArchitectures": ["AWS_ARM64"]}' \
  --filters '[{"name":"Finding","values":["Underprovisioned","Overprovisioned"]}]' \
  --query 'instanceRecommendations[?estimatedMonthlySavings.value > `100`].[instanceArn, currentInstanceType, recommendationOptions[0].instanceType, estimatedMonthlySavings.value]' \
  --output table

Passo 2: Testar compatibilidade de binários e bibliotecas

Honestamente, 90% das aplicações Java, Python, Node.js e Go rodam sem modificação em arm64. Os 10% que quebram costumam usar:

Bibliotecas nativas compiladas apenas para x86 (JNI antigo, SciPy com wheels antigos)
Drivers proprietários (Oracle Instant Client, embora hoje já haja build ARM oficial)
Binários estáticos empacotados no container (verificar com file /caminho/binario)

Para testar rapidamente, suba uma instância t4g.medium (Graviton2, disponível sob free tier estendido), instale sua stack e rode a suíte de testes. Se estiver em containers, use docker buildx com QEMU:

# Configurar buildx multi-plataforma (uma vez)
docker buildx create --use --name multiarch --platform linux/amd64,linux/arm64
docker run --privileged --rm tonistiigi/binfmt --install arm64

# Construir imagem multi-arch e enviar para ECR
docker buildx build \
  --platform linux/amd64,linux/arm64 \
  --tag 123456789012.dkr.ecr.us-east-1.amazonaws.com/api:v2.7 \
  --push \
  .

Passo 3: Trocar o tipo de instância no Launch Template

Crie uma nova versão do Launch Template apontando para AMI ARM (Amazon Linux 2023 arm64, Ubuntu 24.04 arm64) e o novo tipo de instância. Em Terraform:

data "aws_ami" "al2023_arm64" {
  most_recent = true
  owners      = ["amazon"]
  filter {
    name   = "name"
    values = ["al2023-ami-2023.*-arm64"]
  }
}

resource "aws_launch_template" "api" {
  name_prefix   = "api-graviton-"
  image_id      = data.aws_ami.al2023_arm64.id
  instance_type = "m7g.xlarge"  # antes: m6i.xlarge
  # ...
}

Passo 4: Migrar em ondas com deployment blue/green

Nunca troque 100% do ASG de uma vez. Use CodeDeploy ou instance refresh do ASG com MinHealthyPercentage=90 para trocar 10% da frota, observar SLOs por 24 horas, e continuar. Métricas críticas para observar: latência p99, taxa de erro HTTP 5xx, uso de CPU (deve ser menor no Graviton), uso de memória (idêntico) e custo horário por transação.

Migrando RDS, Aurora e ElastiCache para Graviton

RDS Graviton é a migração de maior retorno com menor risco que existe na AWS. Você troca a classe da instância e a AWS faz o resto. O binário do banco (PostgreSQL, MySQL, MariaDB) já é compilado para ARM pela equipe da AWS. Não há mudança de comportamento, de plano de execução ou de charset.

Para PostgreSQL 16 em RDS, o comando é literalmente:

aws rds modify-db-instance \
  --db-instance-identifier prod-postgres-01 \
  --db-instance-class db.r7g.2xlarge \
  --apply-immediately

Downtime esperado: 3 a 8 minutos, exatamente como qualquer modificação de instance class. Se você tem Multi-AZ ativado, o failover reduz para menos de 60 segundos. Em Aurora, a operação é ainda mais suave: a mudança da instância writer aciona um failover para uma réplica, e você promove uma nova réplica Graviton no lugar da antiga.

Sobre ElastiCache Redis: cache.r7g.large custa 12% menos que cache.r6i.large, e o desempenho de comandos SET/GET é praticamente idêntico. Latências p50 na minha última migração ficaram em 0,42ms (r6i) versus 0,44ms (r7g), diferenças irrelevantes. O ganho vem da conta, não do relógio.

AWS Lambda em arm64 com Graviton2

AWS Lambda executa em Graviton2 quando você define Architectures: [arm64], e o desconto é de 20% no custo por GB-segundo. Como Lambda cobra por 1ms, cada milissegundo economizado também é dinheiro. Em runtimes modernos (Python 3.13, Node.js 22, Go 1.23), arm64 costuma ser 5 a 10% mais rápido.

No AWS SAM ou CDK, a mudança é uma linha:

# template.yaml (SAM)
Resources:
  ProcessorFunction:
    Type: AWS::Serverless::Function
    Properties:
      Runtime: python3.13
      Architectures:
        - arm64  # antes: x86_64
      CodeUri: ./src
      Handler: app.handler
      MemorySize: 1024
      Timeout: 30

O único cuidado é com dependências Python que trazem wheels binários. Rodar pip install -r requirements.txt em um Mac M-series ou em Docker --platform=linux/arm64 baixa as wheels arm64 corretas. Se você faz pip install em CI/CD Intel e sobe para Lambda arm64, seu cryptography, numpy ou pydantic-core vai quebrar com invalid ELF header. Eu já perdi uma tarde depurando exatamente essa mensagem em um projeto de fintech. Use sam build --use-container --parameter-overrides Architecture=arm64 para forçar build na arquitetura correta.

EKS multi-arquitetura com Graviton e Karpenter

Em EKS, a estratégia ideal é rodar node pools mistos (x86 + arm64) e deixar o scheduler distribuir. Karpenter simplifica isso. Declare uma NodePool permitindo ambas as arquiteturas e o Karpenter escolhe a mais barata que atende ao pod:

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: default
spec:
  template:
    spec:
      requirements:
        - key: kubernetes.io/arch
          operator: In
          values: ["amd64", "arm64"]
        - key: karpenter.k8s.aws/instance-family
          operator: In
          values: ["m7g", "m8g", "c7g", "c8g", "m7i", "c7i"]
        - key: karpenter.sh/capacity-type
          operator: In
          values: ["on-demand", "spot"]
      nodeClassRef:
        group: karpenter.k8s.aws
        kind: EC2NodeClass
        name: default
  disruption:
    consolidationPolicy: WhenEmptyOrUnderutilized
    consolidateAfter: 30s

Para o Karpenter escolher arm64, seus containers precisam ser multi-arch (feitos com docker buildx, como mostrei no passo 2). Se um container é single-arch, adicione um nodeSelector ou nodeAffinity restringindo a arquitetura suportada. Para uma abordagem completa de otimização em Kubernetes, veja o guia de otimização de custos no Kubernetes com Kubecost e autoscaling.

Combinando Graviton com Compute Savings Plans

Aqui é onde a matemática fica interessante. Graviton sozinho: até 40% de economia. Compute Savings Plan de 3 anos com pagamento antecipado: até 66% de desconto sobre On-Demand. Juntos, com stacking multiplicativo:

Preço base m6i.xlarge On-Demand:      US$ 0,192/h
Migração para m7g.xlarge (–15%):     US$ 0,1632/h
CSP 3-year All Upfront (–48%):       US$ 0,0849/h
Economia total vs baseline:          55,8%
Economia efetiva por transação
(considerando +22% throughput):      ~64%

O Compute Savings Plan é o instrumento certo aqui porque cobre qualquer família, região e sistema operacional, inclusive Graviton3, Graviton4 e a futura Graviton5. Se você comprou um Instance Savings Plan atrelado a m6i em 2024 e agora quer migrar para m7g, terá que negociar (ou esperar o plano expirar). É outra razão para eu recomendar sempre Compute SP quando o cliente está no início da jornada. Aprofundo esse trade-off em Savings Plans vs Reserved Instances. E antes de fechar qualquer plano de longo prazo, revise seu portfólio de Spot Instances com Graviton, porque parte da capacidade já pode estar coberta com desconto maior.

Erros comuns na migração para arquitetura ARM

Depois de dezenas de migrações, os mesmos erros aparecem. Guardei estes cinco para o final porque são os que mais causam rollback:

Imagem Docker single-arch em produção multi-arch. Você faz build em Intel, sobe para ECR, e a task no Fargate arm64 falha com exec format error. Já shipeei esse bug pessoalmente e é uma daquelas dores que ninguém quer sentir duas vezes. Sempre construa com buildx --platform linux/amd64,linux/arm64 e verifique com docker manifest inspect.
Assumir que "Graviton é mais barato" sem medir throughput. Em cargas single-threaded muito específicas (parsers legados, código Perl antigo), o Intel Sapphire Rapids ainda vence em latência absoluta. Meça antes de migrar cargas críticas.
Migrar todos os ambientes de uma vez. Faça dev, staging, 10% de produção, 50%, 100%, em ondas separadas por 3-5 dias. Rollback custa mais que paciência.
Ignorar bibliotecas nativas de monitoramento. Agentes antigos de APM (Datadog agent 6 antes de 6.30, New Relic Java antes de 7.4.0) não tinham build ARM. Verifique a versão mínima do seu observability stack antes de trocar o AMI.
Esquecer de atualizar imagens base em CI/CD. Um FROM node:22 resolve para arm64 no runner ARM e amd64 no runner x86. Se seu pipeline de CI é x86 mas seu deploy é arm64, os testes rodam em amd64 e você só descobre a incompatibilidade em produção. Force --platform=linux/arm64 nos passos de teste.

Para acompanhar os detalhes técnicos oficiais, o repositório aws-graviton-getting-started da AWS mantém guias de tuning por linguagem (Java, Go, Rust, Python), flags de compilador e comparações de instruções SIMD (NEON vs SVE) que você vai precisar em cargas de alto desempenho. Para monitorar economia após a migração, os relatórios do AWS Cost Explorer com filtro por instance family mostram a redução mês a mês.

Perguntas Frequentes

O AWS Graviton é realmente mais rápido que Intel Xeon?

Em cargas modernas (Java 21+, Go 1.20+, Node.js 20+, Python 3.11+), Graviton3 e Graviton4 entregam desempenho por vCPU comparável ou superior ao Intel Ice Lake e Sapphire Rapids. Em cargas legadas single-threaded muito específicas, o Intel ainda pode vencer em latência absoluta. A vantagem real do Graviton está na relação preço-desempenho (dólar por transação), não na latência crua.

Preciso reescrever meu código para rodar em AWS Graviton?

Não. Linguagens interpretadas ou compiladas para bytecode (Python, Java, Node.js, .NET 8+, Ruby) rodam sem modificação. Linguagens compiladas para binário nativo (Go, Rust, C, C++) precisam de recompilação para linux/arm64, geralmente uma mudança de GOARCH=arm64 ou --target aarch64-unknown-linux-gnu. Apenas bibliotecas com código assembly x86 explícito exigem trabalho maior.

Quanto tempo leva uma migração completa para Graviton?

Para uma frota de 100-500 instâncias EC2 gerenciadas por ASG e ECS, a migração típica leva de 4 a 8 semanas: 1 semana de inventário e prova de conceito, 2 semanas de builds multi-arch em CI/CD, 2-4 semanas de rollout em ondas por ambiente. RDS Graviton é bem mais rápido, dá para migrar em uma janela de manutenção de 15 minutos por instância.

Posso combinar Graviton com Spot Instances para maior economia?

Sim, e essa é uma das combinações mais poderosas em 2026. Instâncias Spot de Graviton (c7g, m7g) costumam ter capacidade sobrando em muitas regiões porque a demanda ainda está atrás da x86, resultando em taxas de interrupção baixas (2-5%). Combinado com Karpenter e cargas stateless, dá para atingir desconto acumulado de 85-90% sobre On-Demand x86.

O que é diferente entre Graviton2, Graviton3 e Graviton4?

Graviton2 (famílias c6g, m6g, r6g, t4g) usa núcleos Neoverse N1, é a geração mais antiga ainda comercializada; hoje só compensa em cargas leves ou em Lambda. Graviton3 (c7g, m7g, r7g) usa Neoverse V1, adiciona DDR5 e é a opção mais equilibrada. Graviton4 (c8g, m8g, r8g, x8g) usa Neoverse V2, entrega ~30% mais desempenho por vCPU sobre o G3 e suporta até 96 vCPUs e 384 GiB de RAM.