Em 31 de março de 2026, a AWS lançou o AWS Sustainability Console: um console independente, gratuito, com API pública e modelo IAM próprio para rastreamento de emissões de carbono no uso dos serviços AWS.
Semanas antes desse lançamento, eu estava no AWS User Group Goiânia apresentando uma palestra chamada “GreenOps: por que suas decisões na nuvem impactam o planeta mesmo sem você perceber”. Quando a AWS lançou o console logo depois, não foi coincidência de timing. Foi confirmação de que o tema deixou de ser especulativo. GreenOps está virando prática de engenharia da mesma forma que FinOps virou nos últimos anos.
Quero detalhar o que esse console representa, o que ele entrega de concreto, e onde os gaps ainda existem. Porque eles existem, e ser honesta sobre isso faz parte da análise.
O que existia antes e qual era o problema real
Os dados de pegada de carbono na AWS ficavam dentro do Customer Carbon Footprint Tool (CCFT), embutido no console de Billing. Isso criava uma restrição a informação já que para consultar emissões, você precisava de acesso às permissões financeiras da conta que normalmente é restrita a um time específico.
O resultado era que a visualização que poderia trazer ações ou impacto relacionados a GreenOps fica restrito a um publico específico.
O AWS Sustainability Console resolve exatamente isso ao desacoplar o acesso ao IAM. Qualquer profissional com a política correta pode consultar dados de emissão sem envolver o time financeiro. Na prática, resolve essa centralização da informação.
Vale atenção: o CCFT será descontinuado em 30 de junho de 2026. A janela de migração é curta.
O que o console entrega na prática
Quatro mudanças concretas em relação ao que existia antes.
Acesso desacoplado do billing. Já detalhei acima. É a mudança mais imediata para quem já trabalha com sustentabilidade mas não tinha visibilidade dos dados.
API e SDK públicos. Entendendo que, a mudança com maior impacto estratégico. Pela primeira vez, é possível integrar dados de emissão de carbono em pipelines de dados, dashboards operacionais e workflows de compliance de forma programática. Emissões deixam de ser um relatório mensal e passam a ser uma métrica de engenharia consultável por código, ao lado de latência, custo e disponibilidade. É o que eu defendo quando falo sobre GreenOps como prática de engenharia, não como pauta de marketing.
Relatórios CSV configuráveis. É possível construir relatórios customizados com escolha de campos, granularidade temporal e filtros. Também é possível configurar o início do ano fiscal, o que facilita o alinhamento com ciclos de auditoria ESG das organizações.
Escopos 1, 2 e 3 consolidados com MBM e LBM. Os dados são calculados pelos métodos market-based (MBM) e location-based (LBM), segmentados por região AWS, serviço e escopo de emissão. O Scope 3, que cobre emissões indiretas como fabricação de servidores e construção de data centers, já estava disponível no CCFT. Agora está consolidado com visualizações aprimoradas e acessível via API.
GreenOps e FinOps: o paralelo que o console torna operacional
Na palestra do UG Goiânia, dediquei um bloco à relação entre FinOps e GreenOps, que chamei de irmãos de otimização.
FinOps trabalha com otimização de custos: mede gastos mensais, ROI e budget, com o objetivo de fazer mais com menos dinheiro. GreenOps trabalha com otimização de carbono, mede emissões de CO₂ e consumo energético, com o objetivo de fazer mais com menos impacto ambiental. Os princípios são os mesmos: medição contínua, otimização baseada em dados, responsabilidade compartilhada em toda a equipe.
O AWS Sustainability Console torna essa conexão operacional. Organizações que já têm pipelines de FinOps, como integrações do Cost Explorer com dashboards internos, agora podem adicionar a camada de emissões no mesmo fluxo de dados. Não precisa ser um processo separado. Pode e deve ser integrado ao mesmo ciclo de decisão onde você já discute custo e performance.
Quando você otimiza para GreenOps, com frequência otimiza para FinOps também. Right-sizing de instâncias, uso de serviços gerenciados, arquiteturas serverless, ambientes de desenvolvimento com ciclos de liga e desliga automáticos. Todas essas decisões reduzem custo e emissão ao mesmo tempo. A entrega principal, o novo console agora oferece o instrumento de medição para comprovar isso com dados.
O que ainda não foi resolvido
Valido pontuar que segundo análises, ainda existem gaps reais que a AWS ainda não endereçou com essa atualização.
A metodologia de cálculo continua sendo proprietária e não auditável externamente. A AWS define como estima emissões de Scope 1, 2 e 3, incluindo fatores de emissão e proporção de energia renovável, mas não publica os dados de forma que auditores externos possam verificar de forma independente. Para organizações sujeitas a regulações ESG mais exigentes, como a CSRD europeia, isso pode ser um problema real nos próximos ciclos de auditoria.
A granularidade ainda é por serviço, não por recurso individual. Não é possível saber a emissão associada a uma função Lambda específica ou a uma instância EC2 em particular. Para organizações com centenas de workloads, isso ainda exige cruzamento com outras ferramentas para uma atribuição mais precisa.
O console não gera relatórios em formatos padronizados de compliance como GHG Protocol, CDP ou TCFD. A API resolve isso parcialmente, mas transfere a responsabilidade de formatação para o time de engenharia. Nem todo time tem capacidade de absorver isso agora.
Por fim, a latência dos dados não é detalhada pela AWS. Para times que querem GreenOps em ciclos curtos de decisão, tipo sprint a sprint, ainda não está claro com que frequência uma otimização feita hoje aparece como redução de emissão no console.
O que vale fazer agora
Se você trabalha com arquitetura de soluções na AWS, há três ações que fazem sentido a partir desse lançamento.
Primeiro: crie uma política IAM dedicada para o AWS Sustainability Console e compartilhe o acesso com quem cuida de sustentabilidade, ESG ou relatórios ambientais na sua organização. O recurso na política deve ser configurado como "Resource": "*".
Segundo: se você já tem pipelines de FinOps ou dashboards de custo, avalie a integração da API de sustentabilidade nesse mesmo fluxo. É a forma mais eficiente de transformar GreenOps em prática operacional, não em relatório pontual.
Terceiro: se você ainda usa o CCFT, planeje a migração antes de 30 de junho de 2026. Não é urgente agora, mas deixar para a última semana é o que gera incidente.
Por que esse lançamento é um sinal, não só uma ferramenta
Quando eu disse na palestra do UG Goiânia que GreenOps não é o futuro, é o presente, estava falando sobre mentalidade. O AWS Sustainability Console é uma confirmação prática disso. A AWS não lança um console independente, com API pública e modelo IAM próprio, para um tema que considera secundário.
A ferramenta tem limitações reais, que detalhei acima. Mas o movimento de tornar emissões de carbono uma métrica de engenharia acessível por API é, para mim, o sinal mais claro de que a indústria está tratando sustentabilidade com a seriedade devida.
Cada decisão arquitetural que tomamos tem uma consequência ambiental. Agora temos mais um instrumento para medir, monitorar e otimizar essa consequência. Cabe a nós, arquitetos de soluções, usar esse instrumento.
Links: