Como comparar o custo de EC2 em x86 e em Graviton no AWS Pricing Calculator

Para que serve essa comparação antes de migrar

Antes de trocar uma frota de c7i.large (x86) por c7g.large (Graviton3), dá para saber o impacto na fatura sem mover um único workload. O AWS Pricing Calculator tem um modo chamado Workload Estimates, acessível direto do Billing and Cost Management console, que monta esse comparativo sem custo algum: criar e guardar estimativas não gera cobrança.

A AWS Cloud Financial Management Blog publicou o passo a passo exato para isso. A ideia central é simples: você cria duas estimativas idênticas em tudo, menos no tipo de instância, e deixa o calculador isolar o efeito do processador.

Pré-requisitos

Você precisa de três coisas antes de começar:

• Uma conta AWS ativa.
• Acesso ao console do Billing and Cost Management.
• Permissões de AWS IAM para o AWS Pricing Calculator.

Com isso, o caminho é Billing and Cost Management > Budgets and Planning > Pricing Calculator > Create workload estimates.

Passo a passo: a estimativa baseline em Graviton3

O tutorial usa um cenário concreto: 20 instâncias c7i.large contra 20 instâncias c7g.large, com storage, transferência de dados e descontos idênticos dos dois lados. Comece pela estimativa Graviton, que serve de base:

1. Dê um nome descritivo, como graviton3-comparison-baseline, e adicione tags se quiser rastrear depois.
2. Escolha Before Discounts como rate type. Isso trava a comparação no preço de lista, sem Savings Plans nem Reserved Instances influenciando o resultado.
3. Em Add service, escolha a conta, o location type Region e a região de destino. A AWS usou US East (N. Virginia) no exemplo publicado; se seu workload roda em São Paulo (sa-east-1), refaça com essa região, porque o preço muda e o resultado em reais vai ser outro.
4. Adicione o serviço Amazon EC2 pelo caminho Guided configuration > template Amazon EC2. O modo guiado já empacota Amazon EBS, transferência de dados e Amazon CloudWatch numa tela só.
5. Configure: Operating system = Linux, Tenancy = Shared, instance family c7g, instance type c7g.large, Number of instances = 20.
6. No storage, escolha gp3 com 100 GB por volume.
7. Informe 10 GB de transferência de entrada e 10 GB de saída por mês.
8. Desmarque snapshots do Amazon EBS, métricas do CloudWatch e transferência intra-região, para manter o foco em compute e storage.
9. Clique em Save.

Replicando a estimativa em x86

Com a baseline Graviton salva, crie uma segunda estimativa, por exemplo x86-comparison-baseline, repetindo os mesmos nove passos acima. A única mudança fica no passo 5: em vez de c7g.large, você busca c7i.large no campo de instance type.

Mantenha a mesma conta, o mesmo location type e a mesma região usadas na primeira estimativa. Região diferente distorce a comparação, porque o preço de cada instância varia por região, e você deixaria de isolar a variável que importa, que é o processador.

Depois de salvar as duas, elas aparecem juntas na tela de saved estimates, com duas formas de leitura: comparação lado a lado do total em escala (as 20 instâncias) e comparação por família de instância (C7g contra C7i), que ajuda a olhar performance e custo ao mesmo tempo.

O resultado do exemplo publicado

No exemplo da AWS, rodado em US East (N. Virginia) a preço de lista on-demand, os números saíram assim:

A diferença é US$ 309,23 por mês, ou 19% de economia em compute. O storage, 100 GB em gp3 por instância, custou US$ 160 por mês dos dois lados, e a transferência de dados também ficou igual nas duas estimativas, então os 19% valem só para o compute, não para o total da fatura.

Vale frisar: esse número é um exemplo de walkthrough, não um benchmark publicado pela AWS. Sua economia real depende da família de instância, da região e do padrão de uso do seu workload, exatamente o que essa comparação existe para quantificar no seu caso.

Aplicando seus descontos reais

O comparativo acima roda a preço de lista de propósito, para isolar a decisão arquitetural. Depois de validar que a troca faz sentido nesse nível, duplique a estimativa e mude o rate type para After Discounts and Purchase Commitments.

Nesse modo, o calculador incorpora os dados de faturamento do mês anterior e os Savings Plans ou Reserved Instances já ativos na sua conta. O total com desconto que aparece é o seu, porque depende dos compromissos vinculados à sua própria conta, não dá para generalizar o número de outra pessoa aqui.

Outras decisões que cabem no mesmo método

O fluxo de duas estimativas paralelas, mudando uma variável de cada vez, não serve só para Graviton. A AWS Cloud Financial Management Blog sugere outros cenários para o mesmo exercício:

• EC2 sempre ligado versus AWS Lambda orientado a eventos, modelando contagem de invocações, duração e memória. Serverless costuma ganhar quando o tráfego varia mais de 3 vezes entre pico e vale.
• EC2 com Application Load Balancer versus Amazon API Gateway com Lambda, para APIs com tráfego instável.
• Decompor um monolito em Amazon ECS com Fargate ou Amazon EKS versus instâncias EC2 superdimensionadas para o pico.

Note que este post usou Graviton3 (C7g) porque ele mapeia direto para a comparação com C7i, mas a AWS já tem gerações mais novas, como Graviton4 (C8g). Antes de fechar a decisão, confira as opções de instância disponíveis na sua região e os preços publicados, porque a AWS atualiza esses números periodicamente.

Limpando as estimativas

Workload estimates não geram cobrança, mas vale manter o workspace organizado. Para remover o que você criou: volte ao Pricing Calculator pelo Billing and Cost Management, selecione as estimativas (graviton3-comparison-baseline e x86-comparison-baseline) e escolha Delete. Apagar a estimativa não afeta recursos nem a fatura real da conta.

O que fica de fora deste primeiro passo a passo é o Bill Estimates, o outro modo do Pricing Calculator, que cruza esse tipo de simulação com o histórico real de cobrança da sua organização e os compromissos já contratados. A AWS Cloud Financial Management Blog promete tratar isso na parte dois da série.

Fonte: AWS Cloud Financial Management Blog