Por Que a AWS É Tão Cara (E Por Que Quase Nunca É Culpa da AWS)

Se você está lendo isto, a conta da AWS provavelmente surgiu em uma conversa onde não costumava aparecer. Uma reunião de conselho. Uma pergunta do CFO. Uma revisão de orçamento que pesou mais do que o esperado.

O instinto é olhar para a AWS. O preço, a margem, o lock-in.

Vale ser direto sobre isso. Os preços da AWS são públicos. São amplamente competitivos com os outros hyperscalers. A economia unitária de rodar computação, armazenamento e rede em escala não é o motivo da sua conta ser o que é.

O motivo é outro, e geralmente é desconfortável de nomear.

Custo de nuvem não é um problema de tecnologia. É um problema de processo.

A maioria das organizações de engenharia tem processos bem definidos para performance, confiabilidade, segurança e qualidade de código. Custo raramente tem o mesmo. Não há revisão de design para gastos. Nenhum modelo de alocação que responsabilize uma equipe pelos recursos que criou. Nenhuma etapa de estimativa antes de provisionar infraestrutura. Nenhuma reavaliação periódica dos recursos depois que existem.

A conta é a soma de cada decisão tomada dentro dessa lacuna.

Vale percorrer onde essa lacuna mais aparece.

1. Os custos não são visíveis no nível do recurso

Abra o console da AWS. Olhe o EC2. Não há coluna de custo. Olhe o RDS. Sem coluna de custo. Olhe o ECS. Sem coluna de custo.

A visão do Cost Explorer, que é o padrão da maioria das organizações de engenharia, agrega no nível de serviço e conta. EC2 em produção: £X. RDS em staging: £Y. Essa granularidade é útil para uma equipe financeira. Não é acionável para uma equipe de engenharia tentando entender qual workload está gerando o número.

Dados de custo no nível do recurso existem. Eles vivem no Cost and Usage Report (CUR) ou, cada vez mais, na exportação FOCUS. Ambos precisam ser explicitamente habilitados e enviados para o S3. A maioria das organizações não os ativou, ou ativou sem construir a camada de análise que os torna úteis.

O efeito downstream disso é estrutural. Sem visibilidade no nível do recurso, toda conversa sobre custo acontece na altitude errada. A liderança pergunta por que a conta subiu. A equipe de plataforma responde no nível de serviço porque é a granularidade que tem. A conversa termina sem ninguém conseguir apontar para um recurso, workload ou padrão específico.

Você não pode gerenciar o que não pode ver, e a experiência padrão da AWS é construída para não ver.

2. Os custos não são estimados antes dos recursos existirem

Na maioria das organizações, recursos de nuvem são provisionados sem um valor de custo vinculado à decisão.

Mudanças de infraestrutura como código são revisadas quanto à correção, segurança e risco operacional. Raramente são revisadas quanto ao custo. O PR é aprovado. O recurso é criado. A primeira vez que alguém vê o preço é na conta do mês seguinte, momento em que o recurso está em produção e removê-lo não é mais uma conversa de code review. É um projeto.

Isso é o inverso de como todo outro recurso restrito é tratado. Latência tem orçamentos, definidos antecipadamente, debatidos em design docs. Memória tem orçamentos, aplicados em testes. Segurança tem limites, aplicados em pipelines. Custo raramente tem qualquer um desses, o que significa que se acumula no único lugar possível: em produção, retroativamente, como um número que precisa ser explicado.

A ausência de uma etapa de estimativa é um dos maiores impulsionadores isolados de crescimento de custo inexplicado, e é o mais facilmente ignorado porque não há evento que o torne visível. Nada alerta quando o loop está faltando. A conta simplesmente cresce.

3. Os recursos são dimensionados uma vez e não revisitados

O ciclo padrão de um recurso de nuvem é: provisionado no início de um projeto, dimensionado para a carga projetada, raramente reavaliado.

Há boas razões para isso. Equipes de engenharia são medidas por entregas, não por otimização de custos. Reavaliar um recurso que está “funcionando bem” parece uma distração do roadmap. O custo de deixá-lo superdimensionado é invisível. O custo de quebrar produção subdimensionando-o não é.

O resultado, observado na maioria dos ambientes, é que recursos dimensionados dois ou três anos atrás ainda estão rodando no mesmo formato hoje, contra padrões de workload que mudaram significativamente. A utilização diminui. Famílias de instâncias evoluem. Novas classes de computação aparecem. Nada disso aparece como problema até alguém ir procurar.

O fator agravante: rightsizing é a etapa que precisa acontecer antes de qualquer desconto baseado em compromisso (Reserved Instances, Savings Plans). Travar um compromisso de três anos em uma frota superdimensionada é uma das poucas decisões de custo de nuvem que é genuinamente irreversível. Também é uma das mais comuns, porque o compromisso é posicionado como economia e a etapa de rightsizing que deveria precedê-lo é pulada.

4. Ambientes de não-produção custam o mesmo que produção

Quase toda organização tem uma versão desse problema, e quase nenhuma tem um processo estabelecido para lidar com ele.

Staging, UAT, desenvolvimento, QA. Esses ambientes são tipicamente criados replicando o padrão de infraestrutura de produção. Os formatos de instância são copiados. A configuração de disponibilidade é copiada. A redundância é copiada. As horas de execução são copiadas.

O que não é copiado é a justificativa. Produção funciona assim porque tem um SLA, porque serve tráfego real, porque não pode ter downtime. Ambientes de não-produção não têm. Eles servem um pequeno número de engenheiros por uma parte do dia útil, sem compromisso externo, e ainda assim frequentemente rodam a 80-95% do custo de produção.

Isso raramente é resultado de uma decisão explícita. É resultado de nenhuma decisão. Os ambientes foram criados no momento em que o projeto precisou deles, e revisitar o modelo operacional raramente foi definido como responsabilidade de alguém. Na maioria das organizações, nenhuma equipe é dona do modelo operacional para ambientes de não-produção. Então o modelo fica como “o mesmo que produção” e permanece assim.

Nos nossos engajamentos, essa categoria é consistentemente onde o maior achado único aparece. Não por causa de uma decisão subótima. Porque o processo para revisitar o ambiente não estava implementado.

5. O custo não é alocado, então ninguém é dono do número

Essa é a lacuna de processo que torna todas as outras lacunas mais difíceis de fechar.

Sem alocação no nível do recurso, nenhuma equipe é dona de qualquer porção da conta. A conversa segue assim: o CFO pergunta ao CTO por que a AWS subiu. O CTO pergunta ao VP de Engenharia. O VP de Engenharia pergunta ao Head de Plataforma. O Head de Plataforma abre o Cost Explorer, vê que o EC2 subiu, e reporta que o EC2 subiu. Ninguém consegue atribuir o aumento a uma equipe, um produto ou uma feature, porque os dados para isso não estão implementados.

O princípio de alocação é simples. Todo recurso deve ser atribuível a um dono, um ambiente e uma linha de negócio. A execução é mais difícil do que parece. Esquemas de alocação se degradam. Novas contas são criadas fora do padrão. Recursos criados por automação pulam o caminho de tagging. Dezoito meses de aplicação parcial produzem um dataset de alocação que parece completo no dashboard mas é pouco confiável na prática.

Até que a alocação esteja genuinamente implementada, a conversa de custo não avança. A liderança fica presa fazendo perguntas genéricas porque os dados só suportam respostas genéricas. Uma vez que a alocação está implementada, a pergunta muda de “por que a AWS é cara” para “qual workload subiu, quanto, de qual equipe, e por quê.” Essa é a conversa que a engenharia consegue agir. A primeira não é.

6. Decisões de arquitetura sobrevivem à sua justificativa

A camada mais profunda de custo está na própria arquitetura.

Uma escolha de modelo de computação, uma escolha de caminho de egress, uma escolha de como os serviços se comunicam, uma escolha de onde cachear e onde não cachear. Essas decisões são tomadas cedo na vida de um sistema, frequentemente corretas para o contexto da época, e moldam a curva de custo de tudo que vem depois.

Arquiteturas raramente são reavaliadas contra sua forma de custo. Equipes de engenharia revisitam arquitetura quando algo quebra, quando a escala exige, ou quando uma migração importante força. Revisitá-la porque a forma de custo não se encaixa mais no workload é uma categoria de trabalho para a qual quase nenhuma organização tem um processo.

O resultado são ambientes onde a forma de custo subjacente é definida por decisões tomadas anos atrás, em condições que não se aplicam mais, e que ninguém foi solicitado a avaliar desde então. Identificar quais dessas decisões são agora o principal impulsionador de gastos, neste ambiente específico, nesta magnitude específica, é o trabalho de maior alavancagem e menos realizado em gestão de custos de nuvem.

O resumo honesto

A AWS não é cara por causa da AWS.

A AWS é cara porque a maioria das organizações tem:

• Nenhuma visibilidade no nível do recurso sobre onde o gasto cai
• Nenhuma etapa de estimativa antes dos recursos serem provisionados
• Nenhum ciclo de reavaliação para recursos que já existem
• Nenhum modelo operacional para ambientes de não-produção
• Nenhuma alocação, então nenhuma equipe é dona de nenhum número
• Nenhum processo de revisão para decisões arquiteturais que impulsionam a curva de custo

Cada um desses é um problema de processo, não de tecnologia. Nenhum é resolvido por um dashboard, porque a ausência de processo é a lacuna que o dashboard não consegue preencher sozinho.

Isso também é por que é corrigível. Problemas de processo respondem a mudanças de processo. A questão é quem é dono do trabalho, e a maioria das organizações de engenharia não tem ninguém cuja descrição de cargo inclua isso.

Como a Koritsu Aborda Isso

A Koritsu é um serviço de FinOps de nível de engenharia. A plataforma existe, e faz trabalho real, mas a plataforma não é a oferta. A oferta é uma equipe de engenheiros que entra no seu ambiente e executa os processos que estão faltando.

A forma como a maioria dos engajamentos começa é com um relatório de Oportunidade de Economia em modelo de taxa de sucesso.

Sem custo inicial. Sem compromisso de assinatura. Acesso IAM somente leitura, com escopo restrito. Nossa equipe e a Kori, nossa analista de FinOps com IA, percorrem o ambiente recurso por recurso, identificam onde as lacunas de processo estão aparecendo, e entregam um relatório contra seus dados reais de faturamento. Três meses de acesso à plataforma são incluídos gratuitamente durante o engajamento.

Se encontrarmos economias e elas forem realizadas, cobramos uma porcentagem do que aparece na conta nos dois primeiros meses. Se não encontrarmos, você não paga nada.

Descubra se a AWS é realmente a parte cara.

Analisamos seu ambiente recurso por recurso, no contexto de como seu negócio realmente opera. Os padrões de workload. O perfil de tráfego. As equipes por trás de cada serviço. As oportunidades de otimização que identificamos são aquelas que você pode agir sem comprometer o que produção precisa fazer.

Acesso somente leitura, com escopo restrito. Três meses de plataforma incluídos. Taxa de sucesso sobre o que é realizado na conta.

Comece com um relatório de Oportunidade de Economia