AWS Well-Architected Framework: Sustainability Pillar Deep Dive

O AWS Well-Architected Framework organiza boas práticas de arquitetura em seis pilares: Excelência Operacional, Segurança, Confiabilidade, Eficiência de Performance, Otimização de Custos e Sustentabilidade. O último foi incorporado em novembro de 2021. O foco dele é diferente dos demais: não é sobre o que o sistema faz, mas sobre o custo ambiental de fazê-lo, medido em consumo de energia e de recursos físicos.

Para quem já trabalha com os outros cinco pilares, a notícia boa é que muito do que o pilar de Sustentabilidade pede converge com o que o pilar de Otimização de Custos já cobra. Recursos superdimensionados e ociosos custam dinheiro e energia ao mesmo tempo. A diferença está no enquadramento: aqui o objetivo explícito é reduzir o impacto ambiental, e existem práticas específicas que vão além do simples corte de custos.

Responsabilidade compartilhada de sustentabilidade

A AWS define um modelo de responsabilidade compartilhada para sustentabilidade análogo ao que já existe para segurança. A distinção é entre "da nuvem" e "na nuvem".

A AWS é responsável pela sustentabilidade da nuvem: eficiência energética dos data centers, uso de energia renovável, resfriamento, hardware dos servidores e infraestrutura física de rede. O cliente não tem visibilidade nem controle sobre essa camada.

O cliente é responsável pela sustentabilidade na nuvem: como os recursos são provisionados, quanto ficam ociosos, quais serviços são escolhidos e como o software foi escrito. Essa é a parte acionável do pilar, e é onde as práticas concretas se aplicam.

AWS Customer Carbon Footprint Tool

Para acompanhar o impacto do lado do cliente, a AWS disponibiliza a Customer Carbon Footprint Tool, acessível pelo console de Billing. Ela mostra as emissões estimadas de carbono por serviço e por região, com histórico mensal, refletindo o consumo energético dos recursos utilizados e a proporção de energia renovável em cada região.

A ferramenta não oferece granularidade por workload individual, mas serve para estabelecer uma linha de base, medir o efeito de otimizações ao longo do tempo e alimentar relatórios corporativos de ESG.

Maximizar utilização dos recursos

O princípio central do pilar é: o recurso mais sustentável é o que não existe. Quando um recurso precisa existir, o objetivo é que ele trabalhe na maior taxa de utilização possível.

Na prática, isso começa pelo right-sizing: ajustar o tipo e o tamanho da instância ao que a carga realmente demanda, sem margem especulativa. Instâncias com utilização crônica de 5-10% de CPU são comuns em ambientes que cresceram por provisionamento manual sem revisão periódica.

Auto-scaling é o passo seguinte: em vez de dimensionar para o pico e manter capacidade ociosa nas outras 22 horas do dia, a capacidade sobe e desce com a demanda real. Esse padrão reduz tanto o consumo de energia quanto o custo, e é uma das recomendações mais diretas do pilar.

Recursos completamente ociosos, como instâncias paradas mas não terminadas, volumes EBS sem anexo e load balancers sem tráfego, devem ser identificados e removidos. Ferramentas como o AWS Compute Optimizer e o Cost Explorer ajudam a localizar esses casos.

Hardware mais eficiente: instâncias Graviton

A escolha do tipo de instância tem impacto direto na eficiência energética. As instâncias baseadas em processadores AWS Graviton (arquitetura ARM) entregam melhor desempenho por watt do que as equivalentes x86, segundo a AWS. A geração atual, Graviton3, cobre tipos como C7g, M7g e R7g e é suportada pela maioria dos workloads Linux.

Serviços gerenciados e serverless contribuem pelo mesmo motivo: a AWS consolida cargas de múltiplos clientes no mesmo hardware físico, aumentando a utilização agregada. Uma função Lambda compartilha infraestrutura de forma mais eficiente do que uma instância EC2 dedicada com baixa ocupação.

Storage: tiering e retenção seletiva

Dados armazenados consomem energia continuamente, independente de serem acessados. A prática recomendada é mover dados para camadas mais frias à medida que o acesso diminui, em vez de mantê-los indefinidamente no mesmo storage de alta performance.

No S3, o S3 Intelligent-Tiering automatiza essa decisão: ele monitora os padrões de acesso e move objetos entre camadas (Frequent Access, Infrequent Access, Archive) sem necessidade de configuração manual por objeto. Para dados com padrão de acesso previsível, as políticas de lifecycle permitem definir transições automáticas para S3 Glacier ou Glacier Deep Archive após um período determinado.

Além de tiering, o pilar questiona a retenção em si: logs obsoletos, snapshots sem política de expiração e dados de teste que nunca foram deletados são casos comuns. Definir políticas de retenção explícitas reduz armazenamento sem impacto funcional.

Padrões de uso e transferência de dados

Ajustar a capacidade à demanda real vai além do auto-scaling em tempo real. Para cargas não críticas, como jobs de processamento em batch ou relatórios noturnos, agendar a execução fora dos horários de pico permite que a AWS aloque recursos em momentos de menor demanda agregada.

Transferência de dados entre regiões e entre zonas de disponibilidade consome energia na rede. Arquitetar workloads para minimizar tráfego cross-region desnecessário, usar cache onde faz sentido e colocar recursos que se comunicam frequentemente na mesma região reduz esse consumo. Em arquiteturas de multi-region ativa-ativa, a análise precisa pesar latência, resiliência e impacto de rede.

Software eficiente

O pilar cobre também o que acontece dentro do código. Algoritmos ineficientes, consultas que retornam mais dados do que o necessário, loops que repetem trabalho já feito, e serviços que acordam periodicamente sem nada para processar: tudo isso se traduz em ciclos de CPU gastos sem resultado. A revisão do código sob o ângulo de "qual trabalho computacional esse trecho está fazendo que não precisaria fazer?" costuma revelar oportunidades que passam despercebidas quando o critério é só a funcionalidade.

Como aplicar na prática: a lente de sustentabilidade

A AWS disponibiliza a Sustainability Lens como extensão da Well-Architected Tool. Ao conduzir uma revisão de workload na ferramenta, é possível incluir essa lente junto às perguntas padrão dos seis pilares.

A lente apresenta perguntas estruturadas em áreas como seleção de hardware, utilização de serviços, padrões de acesso a dados e eficiência de software. Para cada resposta, a ferramenta identifica riscos de alto e médio impacto e gera um plano de melhoria. O momento mais natural para aplicá-la é durante uma revisão de Well-Architected já agendada, como parte do processo regular de governança de workloads.

Na maioria dos casos, workloads mais eficientes sob a ótica ambiental também têm menor custo de operação. Right-sizing, remoção de recursos ociosos, uso de Graviton e tiering de storage beneficiam as duas métricas ao mesmo tempo. O pilar de Sustentabilidade fornece vocabulário e estrutura de revisão para tomar essas decisões de forma deliberada, não só como efeito colateral de uma iniciativa de redução de custos.