AWS Builder Center

Builder Center

Graviton no EKS: arquitetura mista, imagens multi-arch e migração gradual

Quer trocar parte dos nós do seu cluster AWS EKS por instâncias AWS Graviton? Neste artigo, você vai ver o que precisa ser compatível, como criar imagens multi-arch no AWS ECR, como usar Graviton no EKS com o Karpenter numa arquitetura mista e como migrar workloads x86 aos poucos, sem a armadilha de subir um pod x86 num nó Arm.

Felipe Olivieri

Solution Architect
No post sobre Karpenter  no AWS EKS , vimos que o Karpenter escolhe o tipo de instância a cada provisionamento. Isso abre uma oportunidade: trocar parte dos nós x86 por instâncias com processadores AWS Graviton, baseados em Arm. Neste post, você vai ver como adotar Graviton no EKS sem quebrar nada: o que precisa ser compatível, como criar imagens multi-arch, como montar uma arquitetura mista e como migrar aos poucos.
Um post da série "Otimização de custos com AWS EKS".

Por que considerar o AWS Graviton

O AWS Graviton  é a família de processadores Arm projetada pela AWS para instâncias AWS EC2 . Segundo as páginas oficiais do Graviton:
  • As instâncias Graviton custam até 20% menos que instâncias x86 comparáveis;
  • O Graviton oferece até 40% melhor preço-desempenho  para vários tipos de workload, como microsserviços, bancos de dados e analytics;
  • As instâncias Graviton usam até 60% menos energia que instâncias EC2 comparáveis, para o mesmo desempenho.
💰 Preços de referência: outubro de 2026. Os percentuais acima são os divulgados pela AWS nessa data, comparam instâncias equivalentes e variam por workload. Antes de estimar a economia, compare os preços atuais das famílias Graviton e x86 na página de preços do AWS EC2  e teste com o seu workload.
Para workloads em containers, no entanto, a troca costuma ser mais simples do que parece. A aplicação já está empacotada, a orquestração é a mesma e o Kubernetes já sabe escolher nós por arquitetura. O trabalho principal está nas imagens.

O que precisa ser compatível

Antes de mover qualquer pod para um nó Arm, portanto, confirme três coisas:
  1. As imagens das suas aplicações precisam existir para linux/arm64. Linguagens interpretadas e com runtime, como Python, Node.js e Java, costumam exigir pouco ou nenhum ajuste no código. Já linguagens compiladas, como Go e Rust, precisam ser recompiladas para Arm, o que em geral é simples.
  2. As dependências nativas (bibliotecas em C, drivers, agentes de terceiros) também precisam de versão Arm.
  3. Os componentes do cluster, como DaemonSets de observabilidade, segurança e rede. A página de add-ons do EKS  não traz uma tabela de compatibilidade com Arm, então valide cada add-on e cada ferramenta de terceiros.
O guia oficial aws-graviton-getting-started  reúne orientações por linguagem, containers e ferramentas, e é o melhor ponto de partida para o levantamento.

Imagens multi-arch: uma tag, duas arquiteturas

Uma imagem multi-arch é, na prática, uma lista de imagens (manifest list ou image index) com uma variante por arquitetura. Quando o nó baixa a imagem, o runtime escolhe automaticamente a variante da sua arquitetura. Assim, o mesmo manifesto do Kubernetes roda em nós x86 e Arm.
 
Imagem multi-arch no AWS ECR com variantes amd64 e arm64, e cluster EKS com um NodePool x86 e um Nod

Construindo com Docker Buildx

O Docker Buildx  constrói as duas variantes e envia a lista de uma vez. Em seguida, o imagetools inspect confere as arquiteturas publicadas na tag:
1
2
3
4
5
6
docker buildx build \
--platform linux/amd64,linux/arm64 \
-t 111122223333.dkr.ecr.us-east-1.amazonaws.com/minha-app:1.0 \
--push .

docker buildx imagetools inspect 111122223333.dkr.ecr.us-east-1.amazonaws.com/minha-app:1.0
O AWS ECR  aceita essas listas de imagens. A documentação também mostra como montá-las manualmente com docker manifest create, a partir de imagens já enviadas.

Builds nativos em vez de emulação

Por padrão, o Buildx pode construir a variante Arm por emulação, mas isso costuma ser lento. A alternativa é construir cada variante numa máquina da própria arquitetura. O AWS CodeBuild  oferece ambientes Arm para isso. Um blog da AWS mostra o padrão completo com GitHub Actions : cada arquitetura é construída num runner nativo gerenciado pelo CodeBuild e, no fim, um passo junta as duas variantes numa única tag no ECR.

Graviton no EKS com o Karpenter: arquitetura mista

Com o Karpenter, adotar Graviton no EKS não exige node groups separados por arquitetura. A arquitetura é só mais um requisito do NodePool, usando o rótulo kubernetes.io/arch, como descreve a documentação de scheduling do Karpenter .

A armadilha: imagem só x86 num nó Arm

Se o NodePool aceita amd64 e arm64, o Karpenter pode criar um nó Arm para um pod cuja imagem só existe para x86. O resultado é um container que não inicia, com erro de formato de executável. Há duas formas de evitar o problema:

Migração gradual com um NodePool dedicado

Há duas formas de o Karpenter provisionar nós Graviton, e o mesmo blog da AWS sobre migração de x86 para Graviton com Karpenter  apresenta as duas:
  • Ampliar o NodePool que você já tem, incluindo arm64 ao lado de amd64 na lista de arquiteturas. É o caminho mais simples e, para um cluster em regime permanente, um padrão perfeitamente normal: o Karpenter passa a escolher entre x86 e Arm a cada provisionamento, pelo melhor custo. Nesse modelo, você controla o que vai para Arm pelas restrições dos próprios pods (nodeSelector ou node affinity em kubernetes.io/arch).
  • Criar um NodePool dedicado ao Graviton, protegido por um taint. Essa opção dá mais controle sobre o ritmo do rollout: com limits, weight e o taint, é você quem decide quando e quanto cada workload migra, em vez de deixar essa decisão por conta do Karpenter.
Um ponto importante: o NodePool separado não é um requisito da arquitetura mista. As duas formas rodam x86 e Arm no mesmo cluster e dependem igualmente de imagens multi-arch — o NodePool dedicado é uma estratégia de migração, não uma exigência. Como aqui o objetivo é justamente migrar aos poucos e com controle, é o padrão que vamos usar neste artigo: só os workloads que você liberar explicitamente vão para os nós Arm.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: graviton
spec:
weight: 10 # prioridade sobre o NodePool x86
template:
spec:
nodeClassRef:
group: karpenter.k8s.aws
kind: EC2NodeClass
name: default
taints:
- key: graviton-migration
effect: NoSchedule # só entra quem tolera o taint
requirements:
- key: kubernetes.io/arch
operator: In
values: ["arm64"]
- key: karpenter.sh/capacity-type
operator: In
values: ["spot", "on-demand"]
- key: karpenter.k8s.aws/instance-category
operator: In
values: ["c", "m", "r"]
limits:
cpu: "500" # limita o tamanho da migração
disruption:
consolidationPolicy: WhenEmptyOrUnderutilized
consolidateAfter: 1m
E, no workload que já tem imagem multi-arch e foi testado:
1
2
3
4
5
6
7
8
spec:
template:
spec:
tolerations:
- key: graviton-migration
operator: Exists
nodeSelector:
kubernetes.io/arch: arm64 # força o nó Arm durante a migração
Por fim, depois que a maior parte dos workloads estiver validada, você pode remover o taint e deixar o Karpenter escolher entre x86 e Arm livremente.

E com managed node groups?

Por outro lado, se você usa managed node groups em vez do Karpenter, crie um grupo separado com instâncias Graviton e a variante Arm da AMI otimizada do EKS . A lógica de taint, toleration e nodeSelector é a mesma.

Caso real: Localiza

Um blog da AWS Brasil , publicado em novembro de 2025, mostra como a Localiza migrou as aplicações de infraestrutura dos seus clusters EKS para Graviton. A migração seguiu três fases:
  1. Validação de compatibilidade: levantamento das aplicações, das imagens Arm disponíveis e das dependências. A maior parte das ferramentas já suportava Arm, incluindo Prometheus, Datadog, ArgoCD, FluxCD, AWS Load Balancer Controller, Ingress Nginx e Istio.
  2. Testes de desempenho: no cenário analisado, o tempo de resposta melhorou cerca de 30%.
  3. Implementação gradual, começando pelos clusters menos críticos, com NodePools e EC2NodeClasses do Karpenter para nós Arm e labels e tolerations para controlar o agendamento.
Como resultado, segundo o blog, o custo das aplicações de infraestrutura caiu 58% nos ambientes não produtivos e 45% em produção. No gateway de APIs, que usa a plataforma Sensedia, a redução foi de 66% e 31%, respectivamente.
💰 Preços de referência: outubro de 2026. As reduções da Localiza foram relatadas no blog da AWS Brasil de novembro de 2025 e dependem dos workloads e dos preços da época. Para estimar o efeito no seu ambiente, compare os preços atuais na página de preços do AWS EC2 .

Boas práticas de Graviton no EKS

  1. Comece pelo levantamento. Liste imagens, dependências nativas e DaemonSets antes de criar o primeiro nó Arm.
  2. Padronize imagens multi-arch no pipeline. Uma tag para as duas arquiteturas evita manifestos diferentes por ambiente.
  3. Prefira builds nativos em vez de emulação, para ganhar velocidade no CI.
  4. Proteja os workloads só x86 com nodeSelector ou affinity enquanto a migração não termina.
  5. Migre por fases, começando por ambientes e serviços menos críticos, com um NodePool dedicado e limitado.
  6. Teste desempenho e custo com dados reais. O ganho varia por workload; meça antes de mover a produção.
  7. Combine Graviton com Spot. Mais arquiteturas no NodePool significam mais tipos de instância disponíveis, assunto do próximo post.

Por onde começar

Para adotar Graviton no EKS:
  1. Escolha um serviço sem dependências nativas e com imagem fácil de reconstruir.
  2. Gere a imagem multi-arch com Buildx ou com builds nativos no CodeBuild.
  3. Crie o NodePool Graviton com taint e libere esse serviço com toleration e nodeSelector.
  4. Compare desempenho e custo com a versão x86 por alguns dias, usando a visibilidade de custos por workload.
  5. Expanda aos poucos e, no fim, remova o taint.

Checklist do post

  • As imagens dos workloads candidatos existem para linux/arm64
  • As dependências nativas e os DaemonSets foram validados em Arm
  • O pipeline publica imagens multi-arch numa única tag no ECR
  • Os workloads só x86 têm nodeSelector ou affinity em amd64
  • Existe um NodePool Graviton com taint e limits para a migração
  • Desempenho e custo foram comparados antes de mover a produção
  • Há um plano para remover o taint ao fim da migração

Perguntas frequentes

Preciso mudar o código da aplicação para rodar no Graviton?

Na maioria dos casos, não. Linguagens como Python, Node.js e Java costumam rodar sem mudanças, e Go e Rust precisam apenas ser recompiladas para Arm. O que costuma exigir atenção são dependências nativas e imagens de terceiros.

O que é uma imagem multi-arch?

É uma lista de imagens com uma variante por arquitetura, publicada numa única tag. O runtime do nó escolhe a variante certa automaticamente.

Posso misturar nós x86 e Graviton no mesmo cluster EKS?

Sim. Com o Karpenter, basta permitir as duas arquiteturas no NodePool. O cuidado é garantir que workloads com imagem só x86 fiquem restritos a nós amd64.

Quanto dá para economizar com Graviton?

A AWS divulga que as instâncias Graviton custam até 20% menos que instâncias x86 comparáveis e oferecem até 40% melhor preço-desempenho, em valores de outubro de 2026. O resultado real depende do workload, por isso vale testar.
💰 Preços de referência: outubro de 2026. Esses percentuais podem ter mudado. Confira os preços atuais na página de preços do AWS EC2 .

Os add-ons do EKS funcionam em Arm?

A documentação  de add-ons do EKS não traz uma tabela de compatibilidade com Arm. Por isso, confirme cada add-on e cada ferramenta de terceiros antes de mover os nós.

Próximo post

Com o Graviton, você muda o tipo de capacidade. A próxima alavanca é o modelo de compra. No próximo post da série, vamos combinar Spot, Savings Plans e On-Demand no EKS e ver como lidar com interrupções de Spot sem afetar as aplicações.
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article