APRENDER. PRATICAR. EVOLUIR.Construir uma comparação com o mesmo âmbito
Num serviço fictício de fundos, FinOps pede uma redução mensal e APS exige preservar recuperação, desempenho e acesso privado. Começa por duas estimativas com a mesma procura, período, regiões e nível de serviço. Separa encargos fixos, consumo variável e custos que continuam depois da mudança. Uma Reserved DB Instance RDS é um desconto de faturação sobre utilização elegível, não uma nova base a instalar. Confirma os atributos de correspondência e a cobertura parcial do cluster. O desconto de instância não abrange automaticamente armazenamento, backups e I/O. Nos exercícios seguintes, todos os preços são unidades fictícias; numa decisão real, substitui-os pela proposta aplicável e documenta exclusões.
Comparar Aurora pelo total e pela variação
Aurora Standard inclui uma rubrica de I/O; I/O-Optimized elimina essa cobrança de leitura e escrita, mas é preciso comparar as restantes rubricas. No exemplo, Standard custa 900 de instâncias e armazenamento mais 600 de I/O; a alternativa custa 1200 para o mesmo serviço. A diferença é 300, não 600. Se a procura mudar e I/O cair para 150, Standard passa a 1050. Calcula meses fracos e fortes antes de recomendar. Não planeies alternância diária: existem limites de frequência para mudar de Standard para I/O-Optimized e possíveis impactos conforme a classe. Para serverless, ausência de queries não prova pausa; ligações de utilizadores abertas impedem-na. Confirma versão, mínimo zero e tolerância à retoma.
Separar modo de capacidade e classe DynamoDB
On-demand cobra pedidos; provisioned cobra capacidade configurada, mesmo que parte fique sem utilização. Procura imprevisível pode favorecer a simplicidade de on-demand. Uma carga estável com previsão credível pode justificar comparar provisioned, incluindo configuração e resposta aos picos. Esta escolha é diferente da classe Standard ou Standard-IA. Standard-IA reduz armazenamento, mas aumenta o preço de throughput; uma tabela grande com muitas leituras pode ficar mais cara. Os índices secundários usam a classe da tabela, e Standard-IA pode usar on-demand. Na oficina, calcula armazenamento mais pedidos antes e depois, incluindo índices, e explica que hipótese de procura faz inverter a decisão. Não confundas tamanho com frequência de acesso.
Calcular o custo evitável dos endpoints
Um gateway endpoint para S3 ou DynamoDB não tem encargo adicional próprio e pode retirar esse tráfego do NAT. Isso não elimina as horas do NAT se outros destinos ainda o exigirem. Um interface endpoint tem horas por zona e processamento de dados. Com valores fictícios, substituir apenas processamento NAT de 0,05 por GB por endpoint de 48 fixos mais 0,01 por GB dá igualdade em 1200 GB. Acima desse volume a alternativa poupa neste modelo; abaixo custa mais. Mantém no cálculo a mesma cobertura de zonas e o mesmo acesso exigido. Não retires uma zona para fabricar poupança nem declares todos os endpoints gratuitos por analogia com o gateway.
Contar o percurso completo do tráfego
Desenha origem, saltos e destino, marcando as rubricas em cada ligação. Um TGW acrescenta horas de attachment e processamento, além de transferências aplicáveis; o preço do processamento não é o total da solução. Num ALB sem reserva LCU, converte as quatro dimensões para LCU e usa a maior, acrescentando a hora do balanceador. Não somes dimensões já normalizadas. CloudFront pode reduzir trabalho na origem, mas a comparação inclui entrega, pedidos e funcionalidades ativadas, segundo o plano escolhido. Direct Connect mantém horas de porta enquanto provisionado, mesmo sem tráfego. Para uma ligação esporádica, compara também os encargos do parceiro e a disponibilidade exigida, sem decidir só pelo preço por GB.
Transformar a estimativa numa decisão verificável
Apresenta ao comité a alternativa, o âmbito, o ganho esperado, a sensibilidade à procura e a evidência de que os requisitos continuam satisfeitos. Uma previsão de poupança pode falhar porque o NAT ficou necessário, a aplicação manteve ligações ou um índice gerou mais pedidos do que o previsto. Atribui um responsável a cada hipótese e marca uma comparação posterior com a mesma base. Executa o modelo local da aula: prevê os resultados antes de correr, muda o volume para 600 e depois 2400 GB e explica a inversão. O código calcula apenas valores sintéticos em memória; não consulta preços, não representa uma fatura e não mede AWS.
// Synthetic teaching model: fictional units, no AWS prices or requests.
const endpoint = gb => ({nat: gb * .05, endpoint: 48 + gb * .01});
const savings = gb => {const c = endpoint(gb);return c.nat - c.endpoint;};
const result = {
auroraSaving: (900 + 600) - 1200,
endpointBreakEvenGB: 48 / (.05 - .01),
endpointSavingAt2000GB: savings(2000),
endpointSavingAt600GB: savings(600),
albLCU: Math.max(.4, .2, 1.4, .8),
cdnNetSaving: 400 - (100 + 250)
};
console.log(JSON.stringify(result));Oficina de vinte minutos: o NAT mantém-se para destinos externos. O endpoint custa 48 por mês mais 0,01 por GB; o processamento NAT evitável custa 0,05 por GB. Com 2000 GB, compara 68 com 100 e obtém 32 de poupança. Com 600 GB, compara 54 com 30 e obtém um acréscimo de 24. Todos os valores são fictícios e as restantes rubricas são iguais ou explicitamente excluídas.
Armadilhas comuns
Aplicar desconto RDS a toda a fatura; ignorar I/O e pedidos; tratar Standard-IA como arquivo sem throughput; contar todas as horas NAT como evitadas; esquecer endpoints por zona; somar dimensões LCU; assumir que serverless pausa com ligações abertas; confundir preços fictícios com uma proposta real.
Tópicos relacionados: Bases de dados, réplicas e cache · Custos, compromissos e retirada · Computação: compromissos e retoma de batches
Compara o serviço completo, separa custos evitáveis dos retidos e repete o cálculo para vários níveis de procura. A escolha mais barata só é elegível se mantiver os requisitos. Modelos e casos são fictícios; não comprovam poupanças reais nem execução na AWS.
Referência: SAA-C03 cost-optimized architectures · SAA-C03