Construir uma base de comparação
Uma equipa apresenta uma redução de despesa num gráfico, mas outro relatório mantém o total anterior. Antes de alterar a arquitetura, fixa período, contas, serviços, moeda e base de custo. Um pagamento antecipado de reserva pode aparecer concentrado numa data; a vista amortizada distribui o seu efeito pelo período. Uma previsão também não é uma fatura fechada. Numa oficina fictícia, entrega ao colega dois gráficos com filtros diferentes e pede-lhe uma tabela de reconciliação, não uma justificação inventada para a diferença. Regista os filtros, o momento de atualização e as rubricas excluídas. Só depois compara opções técnicas com os mesmos pressupostos e o mesmo nível de serviço.
Atribuir custos sem inventar histórico
Aplicar uma tag a EC2 não equivale a ativá-la para imputação na faturação. Mantém um responsável pela chave, valores permitidos e tratamento dos custos sem tag. Se a etiqueta Project só existe no recurso desde março e foi ativada em junho, o backfill pode recuperar atribuição desde março, dentro das condições suportadas; não cria valores de janeiro que nunca existiram. Pede evidência do histórico antes de preencher lacunas. Num serviço partilhado, um nome de projeto no dashboard não prova que todos os consumidores lhe pertencem. Documenta a regra de repartição aprovada e preserva o montante ainda não atribuído, em vez de o ocultar para fazer o relatório parecer completo.
Ligar orçamento a uma resposta operacional
Um aviso de orçamento não é um limite instantâneo de despesa. A atualização de custos e a entrega da notificação podem ocorrer depois do consumo. Se existir uma ação, identifica o recurso, a conta, as permissões e se exige aprovação manual. Uma ação à espera dessa aprovação ainda não executou a mudança. Na reunião APS, apresenta quem recebe o alerta, quem decide e que serviço pode ser afetado. Bloquear novos lançamentos também pode prejudicar a recuperação de capacidade; avalia essa consequência antes de automatizar. A oficina termina com uma matriz de limiares e respostas, incluindo exceções justificadas e uma condição de recuperação do serviço. Nenhuma ação é aplicada a contas reais nesta aula.
Separar cobertura, utilização e poupança
Cobertura responde a quanto consumo elegível recebe o benefício. Utilização responde a quanto compromisso comprado é efetivamente consumido. Uma equipa pode ter cobertura total e ainda desperdiçar compromisso; comprar mais não resolve esse desperdício. Compara também o custo equivalente On-Demand com a despesa do compromisso no mesmo âmbito. No exemplo fictício, 200 unidades monetárias de compromisso para consumo equivalente a 180 significam menos 20 de poupança, sem outros encargos no modelo. Revê horas de menor utilização, mudanças de arquitetura e retiradas planeadas. A proposta para FINOPS deve mostrar o que continua elegível depois dessas mudanças, a incerteza da previsão e uma decisão justificável, não apenas a maior percentagem de desconto anunciada. Usa consumo sustentável, incluindo horas de menor atividade, para avaliar compromisso; um pico mensal curto não justifica comprar o mesmo compromisso para todas as horas. Para um batch tolerante a interrupções, Spot pode ser adequado com checkpoints duráveis e retoma sem duplicar efeitos. Inclui a possibilidade de capacidade indisponível e o prazo do batch na decisão.
Escolher âmbito e capacidade separadamente
Uma migração pode trocar a família EC2 e a região. Antes de comprar, compara a flexibilidade de Compute Savings Plans com o âmbito de família e região de EC2 Instance Savings Plans. Distingue ainda desconto e reserva de capacidade: uma Reserved Instance regional não reserva capacidade, enquanto o âmbito zonal inclui capacidade na zona especificada. Mesmo assim, confirma os atributos exigidos e a estratégia de falha. Num cluster EKS, o custo das instâncias EC2 elegíveis e o encargo do serviço EKS são rubricas diferentes. Não estendas automaticamente um desconto de compute a todas as linhas da solução. Mantém a análise condicionada ao tipo de plano, em vez de generalizar regras para produtos diferentes. Se instâncias numa zona usam um NAT gateway zonal noutra, compara transferência entre zonas, processamento, horas adicionais de gateways e resiliência. Um gateway por zona pode reduzir essa transferência, mas aumenta outros custos; calcula o total para o tráfego previsto. Identifica explicitamente o tipo de gateway para não aplicar este modelo zonal a um desenho regional.
Fechar a retirada com custos residuais
Parar compute não elimina necessariamente armazenamento, backups ou compromissos existentes. Uma instância EC2 stopped pode continuar associada a EBS faturável. Para RDS, distingue suspensão temporária e retirada: a instância parada volta a arrancar automaticamente após sete dias e conserva custos de armazenamento. Numa oficina de vinte minutos, constrói um inventário com recurso, consumidor, dono, retenção, ação, evidência de recuperação e custo residual. Acrescenta uma revisão posterior com o mesmo âmbito da base inicial. O serviço só sai do inventário operacional quando a responsabilidade restante está atribuída. Não apagues backups para fechar uma meta financeira sem uma decisão de retenção. Estes casos bancários são fictícios e não representam procedimentos internos do BNP Paribas.
Num exercício fictício, gastar 200 num compromisso para consumo que custaria 180 On-Demand representa uma perda de 20, mesmo que todo o consumo esteja coberto.
Armadilhas comuns
Confundir tag aplicada com tag ativada; confundir cobertura com utilização; esperar execução sem aprovação; assumir que stopped significa custo total zero.
Tópicos relacionados: Armazenamento e distribuição de conteúdo · Bases relacionais, ligações e recuperação · Computação: compromissos e retoma de batches
A poupança defensável tem âmbito, pressupostos, evidência de consumo e uma transição operacional aceite.
Referência: Savings Plans overview · SAA-C03