APRENDER. PRATICAR. EVOLUIR.1. Distinguir estimativa, utilização e orçamento
Antes de criar um ambiente, AWS Pricing Calculator ajuda a estimar encargos a partir dos serviços e pressupostos introduzidos. Depois de existir utilização, Cost Explorer permite explorar custos e utilização observados. Um orçamento define um valor a acompanhar; não transforma esse valor numa previsão exata nem numa garantia de paragem automática. Regista região, volumes, períodos e opções relevantes quando comparas configurações. Uma estimativa que omite transferência de dados, recursos mantidos ou custos de suporte pode parecer mais favorável por estar incompleta. Os números deste percurso são fictícios e servem para praticar cálculos. Não representam preços AWS, propostas contratuais ou uma previsão para uma aplicação real.
2. Atribuir custos sem perder despesas não classificadas
Uma tag Application pode ajudar a relacionar recursos e custos com um produto. Aplicar a tag e ativá-la para alocação de custos são passos diferentes. Confirma quem tem autoridade para a ativação, a disponibilidade nos relatórios e quais recursos estão cobertos. Uma análise por aplicação que ignora custos sem tag pode subestimar o total e atribuir falsa poupança. Define uma convenção simples com responsável e valores consistentes, sem colocar informação sensível nas tags. Quando consultares um relatório, verifica o período, os filtros e o tratamento de custos partilhados. O objetivo é explicar a despesa com evidência e permitir decisões, não produzir uma percentagem de recursos etiquetados sem utilidade para a equipa.
3. Ler o ciclo de vida dos recursos
Parar uma instância EC2 não equivale a eliminar todo o ambiente. No exemplo, uma instância On-Demand com raiz EBS fica stopped e não tem compromisso de consumo associado. A utilização dessa instância deixa de ser cobrada enquanto está parada, mas o volume EBS mantido continua a ter custo. Outros recursos ou compromissos também podem gerar encargos e exigem análise própria. Antes de desativar um ambiente de testes, identifica dados a preservar, dependências, volumes e condições de recuperação. A decisão deve combinar necessidade operacional e custo restante. Não concluas que uma fatura está errada apenas porque o servidor não está running; verifica quais recursos e períodos estão efetivamente a ser cobrados.
4. Comparar despesa e resultado produzido
Uma aplicação fictícia custa 1000 unidades monetárias para produzir 10000 relatórios. Noutro período, custa 1200 para 15000 relatórios comparáveis. O custo por relatório passa de 0,10 para 0,08, uma redução de 20%, apesar de a despesa total aumentar 20%. As duas observações são verdadeiras e respondem a perguntas diferentes. O orçamento pode precisar de revisão mesmo quando a eficiência unitária melhora. Confirma que os relatórios, a qualidade e o âmbito de custos são comparáveis antes de atribuir a diferença a uma mudança técnica. Este cálculo é uma ferramenta de leitura de um caso sintético, não uma funcionalidade automática de Cost Explorer nem prova causal de uma otimização.
5. Incluir transição e responsabilidades na comparação
Uma migração pode manter o sistema antigo e a cloud ativos em paralelo durante um período. Com 4000 por mês no sistema antigo, 3000 por mês na cloud e 5000 de migração uma vez, dois meses de coexistência custam 19000 nas condições fictícias indicadas. O custo posterior de operação não descreve sozinho o custo da transição. Acrescenta categorias relevantes, como licenças, rede, suporte e trabalho de mudança, quando forem aplicáveis. Um serviço gerido pode reduzir manutenção de infraestrutura e libertar capacidade para o produto, mas não elimina responsabilidades sobre dados e aplicação. Compara opções com o mesmo âmbito e apresenta pressupostos que podem alterar a decisão.
6. Preparar decisões de operação e fiabilidade
Uma proposta que baixa a fatura removendo redundância necessária não satisfaz o objetivo de disponibilidade acordado. Os pilares Well-Architected ajudam a discutir custo em conjunto com fiabilidade, segurança e outras dimensões. Para operação, AWS Health fornece informação sobre eventos relevantes de serviços e recursos; a equipa continua a avaliar impacto na sua aplicação. Usar CLI em vez de consola altera a interface de acesso, mas não concede permissões adicionais à mesma identidade e contexto. No exercício final, prepara uma nota com custo estimado, recursos mantidos, responsabilidades, eventos a acompanhar e requisitos que não podem ser esquecidos. O objetivo é uma conversa informada entre projeto, FinOps e produção, sem criar recursos AWS nem assumir controlos internos de uma instituição.
Exemplo fictício: 1000/10000 = 0,10 por relatório; 1200/15000 = 0,08. A despesa subiu e o custo unitário caiu. Reporta ambos e confirma comparabilidade de âmbito e qualidade.
Armadilhas comuns
Tratar orçamento como limite automático, ignorar custos sem tag, assumir custo zero em stopped, omitir coexistência e reduzir fiabilidade para melhorar apenas a fatura.
Tópicos relacionados: Cloud e responsabilidade partilhada · Regiões, zonas e resiliência
Uma comparação útil inclui âmbito, período, volume e requisitos. Estimativas precisam de pressupostos; decisões de custo precisam de preservar a capacidade que o negócio exige.
Referência: What is AWS Pricing Calculator? · CLF-C02