Custos de computação
Pagar o menor preço pela capacidade que a carga realmente precisa: a opção de compra certa, o tamanho certo e só as horas em que ela roda. Este é o Domínio 4: Design Cost-Optimized Architectures, 20% do conteúdo pontuado.
Opções de compra
Amazon EC2 billing and purchasing options
A mesma instância custa valores bem diferentes conforme o jeito de comprar. Escolha a opção pelo quanto a carga é estável, longa e tolerante a interrupção.
Pontos-chave
- Base estável: cubra com Savings Plans ou Reserved Instances e deixe o Auto Scaling somar On-Demand ou Spot nos picos.
- Cobrança On-Demand: por segundo, com mínimo de 60 segundos, para Linux e Windows. SUSE Linux Enterprise Server é cobrado por hora cheia.
- Formas de pagamento: All Upfront, Partial Upfront ou No Upfront. Quanto mais se paga adiantado, menor a tarifa.
- Capacidade não é desconto: Reserved Instances zonais e Capacity Reservations seguram capacidade em uma AZ. Reserved Instances regionais e Savings Plans dão desconto, mas não reservam capacidade.
- Combinação: Capacity Reservation não tem desconto próprio, mas Savings Plans ou Reserved Instances regionais se aplicam a ela.
Na prova
"Carga estável 24/7 por 3 anos, menor preço" -> Savings Plans ou Standard Reserved Instances. "Garantir capacidade em uma AZ para um lançamento, sem compromisso longo" -> On-Demand Capacity Reservation, não Reserved Instance.
Opções de compra em resumo
| Opção | Uso ideal e desconto máximo |
|---|---|
| On-Demand | Sem compromisso. Cargas curtas, com picos ou desconhecidas. Preço cheio. |
| Compute Savings Plans | USD por hora por 1 ou 3 anos em EC2, Fargate e Lambda, qualquer família, tamanho ou Region. Até 66%. |
| EC2 Instance Savings Plans | Uma família de instância em uma Region, qualquer tamanho, SO ou tenancy. Até 72%. |
| Standard Reserved Instances | Configuração fixa por 1 ou 3 anos. Até 72%. Podem ser vendidas no Reserved Instance Marketplace. |
| Convertible Reserved Instances | Podem ser trocadas por outra família, tipo, plataforma, escopo ou tenancy. Até 66%. |
| Spot Instances | Capacidade ociosa, interrompível com aviso de 2 minutos. Até 90%. |
| Dedicated Hosts | Um servidor físico inteiro, com visão de sockets e cores, para licenças atreladas ao servidor. |
| Capacity Reservations | Capacidade em uma AZ, sem prazo para uso imediato, cobrada com ou sem instância rodando. |
Savings Plans vs RIs
Savings Plans and Reserved Instances
Os dois trocam compromisso por tarifa menor. Savings Plans se comprometem com um gasto por hora e acompanham a carga, Reserved Instances se comprometem com uma configuração.
Pontos-chave
- Compute Savings Plans: o mais flexível. Vale para EC2 independente de família, tamanho, AZ, Region, SO ou tenancy, e também para Fargate e Lambda. Até 66%.
- EC2 Instance Savings Plans: preso a uma família em uma Region, livre para mudar tamanho, SO e tenancy. Até 72%.
- Convertible vs Standard RIs: a Convertible pode ser trocada durante o prazo, mas não vendida. A Standard não pode ser trocada, mas pode ser vendida no Reserved Instance Marketplace.
- Database Savings Plans: compromisso de 1 ano, sem pagamento adiantado, para Aurora, RDS, DynamoDB, ElastiCache, DocumentDB, Neptune, Keyspaces, Timestream, DMS e OpenSearch Service. Até 35%.
- Compartilhamento: por padrão o desconto vale para todas as contas da organização. A conta de gerenciamento pode limitar a grupos ou desligar por conta.
Na prova
"A carga pode migrar de EC2 para Fargate ou Lambda, ou para outra Region" -> Compute Savings Plans. "Maior desconto, a família da instância não vai mudar" -> EC2 Instance Savings Plans ou Standard RIs. Convertible RIs são o distrator quando aparecem Fargate ou Lambda.
Spot Instances
Amazon EC2 Spot Instances
Capacidade ociosa do EC2 com até 90% de desconto sobre o On-Demand. O EC2 pode tomá-la de volta a qualquer momento, então a carga precisa tolerar interrupção.
Pontos-chave
- Aviso de interrupção: chega 2 minutos antes, como evento do EventBridge e nos metadados da instância. O comportamento pode ser terminar, parar ou hibernar.
- Rebalance recommendation: um sinal anterior de risco elevado. O Capacity Rebalancing em Auto Scaling groups e EC2 Fleet troca a instância antes do aviso.
- Diversifique: seja flexível em tipos de instância (pelo menos 10 por carga é a regra prática) e em todas as AZs, ou use a seleção de tipos por atributos.
- Estratégia de alocação:
price-capacity-optimizedescolhe os pools com mais capacidade sobrando pelo menor preço, o que reduz a chance de interrupção. - Mixed instances group: um único Auto Scaling group com base On-Demand e Spot acima dela, em vários tipos. O EC2 Fleet faz o mesmo quando você gerencia o ciclo de vida. O Spot Fleet (
RequestSpotFleet) é uma API legada. - Encaixe: camadas web sem estado, batch, CI/CD, big data, HPC, renderização e containers. Não serve para carga com estado, fortemente acoplada ou intolerante a interrupção.
Na prova
"Job batch, pode recomeçar, menor custo" -> Spot com checkpoints. "Banco de dados que não pode cair" -> nunca Spot. "Manter sempre 2 instâncias e crescer barato" -> mixed instances group com base On-Demand e Spot por cima.
Capacidade dedicada
Dedicated Hosts, Dedicated Instances and Capacity Reservations
Hardware exclusivo resolve exigências de compliance e licenciamento, e Capacity Reservations resolvem capacidade. Nenhum deles é a opção barata por si só.
Pontos-chave
- Dedicated Hosts: um servidor físico inteiro, com visão de sockets e cores físicos, afinidade de host e cobrança por host. Permite trazer licenças por socket, por core ou por VM.
- Dedicated Instances: instâncias em hardware exclusivo, cobradas por instância, sem controle de posicionamento no host.
- On-Demand Capacity Reservations: capacidade em uma AZ por qualquer duração, sem compromisso para uso imediato e com cancelamento a qualquer momento. Cobradas com ou sem instância rodando.
- Reservas com data futura: pedem capacidade para uma data futura com período de compromisso, para eventos e lançamentos planejados.
- Capacity Blocks: reservam um cluster de instâncias com GPU para machine learning.
Na prova
"Licença cobrada por socket ou por core, continuar usando na AWS" -> Dedicated Hosts. "Só precisa de hardware exclusivo, sem visão de licença" -> Dedicated Instances.
Rightsizing
AWS Compute Optimizer
Desconto em instância superdimensionada continua sendo desperdício. Ajuste o tamanho e remova recursos ociosos primeiro, depois assuma compromisso com a nova base.
Pontos-chave
- Compute Optimizer: analisa os últimos 14 dias de métricas do CloudWatch e recomenda tamanhos e recursos ociosos para EC2, Auto Scaling groups, EBS, Lambda, ECS no Fargate, RDS, Aurora e outros.
- Enhanced infrastructure metrics: opção paga que estende a análise para 93 dias, para que picos mensais ou trimestrais entrem na conta.
- Família de instância: escolha pelo gargalo. Uso geral (M, T), otimizada para computação (C), para memória (R, X) e para armazenamento (I).
- Graviton: instâncias Arm custam até 20% menos que as x86 equivalentes e usam até 60% menos energia com o mesmo desempenho. Também disponíveis em RDS, Aurora e EKS.
- Ordem do trabalho: ajuste o tamanho e só depois compre Savings Plans ou Reserved Instances, para o compromisso não cobrir desperdício.
Na prova
"Instâncias com média de 10% de CPU, reduzir custo com o menor esforço" -> recomendações do Compute Optimizer e um tamanho menor. "Mesmo desempenho, preço menor, o código roda em Arm" -> Graviton.
Lambda e Fargate
AWS Lambda and AWS Fargate
Serverless elimina o custo ocioso: você paga por requisição e duração, ou por segundo de tarefa. Com carga alta e constante, instâncias bem usadas podem sair mais baratas.
Pontos-chave
- Lambda: cobrado por requisições e duração em GB-segundos, então a memória define o custo. Nada é cobrado com a função parada.
- Lambda em Arm: a arquitetura
arm64(Graviton2) oferece até 34% de preço-desempenho melhor que a x86. - Provisioned Concurrency: elimina cold starts, mas você paga pela concorrência configurada enquanto ela existir, mesmo sem tráfego.
- Fargate: cobrado por segundo de vCPU, memória e armazenamento acima dos 20 GB incluídos, com mínimo de 1 minuto (5 minutos no Windows). Sem instâncias para corrigir ou encaixar.
- Fargate Spot e Savings Plans: o Fargate Spot tem até 70% de desconto para tarefas ECS que toleram interrupção. Compute Savings Plans reduzem o uso estável de Fargate em até 50%.
- Trade-off: EC2 com Auto Scaling para uso alto e constante, Lambda para cargas com picos ou orientadas a eventos, Fargate para containers sem gerenciar cluster.
Na prova
"Roda algumas vezes por dia, poucos segundos cada" -> Lambda, não uma instância sempre ligada. "Containers, sem servidores para gerenciar, pode ser interrompido" -> Fargate Spot.
Agendamento e hibernação
Instance Scheduler on AWS
Ambientes de não produção raramente precisam rodar de madrugada ou ter disponibilidade de produção. Desligue fora do expediente e rode menor, em menos AZs.
Pontos-chave
- Instance Scheduler on AWS: uma AWS Solution que liga e desliga instâncias EC2, Auto Scaling groups e instâncias RDS por agendas baseadas em tags, em várias contas e Regions.
- EC2 parada: não há cobrança de instância, mas volumes EBS e endereços IPv4 públicos ou Elastic IPs continuam sendo cobrados.
- Hibernação: grava a RAM no volume raiz EBS criptografado e retoma os processos com o mesmo ID de instância. Habilitada no lançamento, RAM abaixo de 150 GiB no Linux. Serve para aplicações que demoram a aquecer.
- RDS parado: sem cobrança de horas de instância, mas armazenamento e backups são cobrados, e o RDS religa a instância após 7 dias seguidos.
- Disponibilidade por classe: produção ganha Multi-AZ e folga. Dev e teste podem rodar em uma AZ, menores e só no horário comercial.
Na prova
"Ambiente de dev usado só no horário comercial" -> parar e ligar por agenda com o Instance Scheduler. "Aplicação leva 20 minutos para carregar a memória antes de atender" -> hibernação, não um stop comum.