Pilares de otimização de custos e sustentabilidade

O pilar de Otimização de custos concentra-se em evitar custos desnecessários e obter o máximo valor dos seus gastos com a AWS. Ele costuma ser o pilar de impacto mais imediato, pois é fácil provisionar recursos de nuvem em excesso. Princípios fundamentais de design: implementar o gerenciamento financeiro da nuvem — tratar o custo como uma métrica de primeira classe. Adotar um modelo de consumo — pagar apenas pelo que usar. Medir a eficiência geral — acompanhar o custo por unidade de valor comercial. Reduzir os gastos com tarefas pesadas indiferenciadas — usar serviços gerenciados em vez de gerenciar a infraestrutura.

O ajuste de tamanho é a ação de optimização de custos com maior impacto — identificar e eliminar recursos superdimensionados. Um padrão comum é iniciar grandes instâncias durante o provisionamento inicial e nunca reavaliá-las. O AWS Compute Optimizer analisa as métricas de utilização e recomenda o tipo de instância ideal. Uma descoberta comum: uma m5.4xlarge utilizando 5% de CPU deveria ser uma t3.medium, economizando 80% do custo de computação. O ajuste de tamanho aplica-se a EC2, Lambda (memória), RDS e volumes EBS.

Para cargas de trabalho estáveis, o preço sob demanda é a opção mais cara. É possível obter economias significativas por meio de: Reserved Instances (1 ou 3 anos) — até 72% de economia para cargas de trabalho previsíveis. Savings Plans — compromisso flexível (até 66% de economia) que se aplica a diferentes famílias de instâncias e regiões. Spot Instances — até 90% de economia para cargas de trabalho interrompíveis (processamento em lote, CI/CD e sem estado). Uma frota com custos optimizados normalmente combina as três opções: Savings Plans para a capacidade básica, Spot para os picos e sob demanda para casos excepcionais.

Spot Instances utilizam capacidade ociosa da AWS com um desconto de até 90%, mas podem ser interrompidas com um aviso de 2 minutos quando a AWS precisar recuperar a capacidade. Spot funciona bem para: processamento em lote (com criação de pontos de verificação e retomada), agentes de compilação de CI/CD, servidores Web sem estado (por trás de ALB; ELB redirecciona o tráfego, evitando as instâncias interrompidas) e nós de trabalho do EMR e EKS. Utilize Spot Fleet ou ASG com vários tipos de instância e AZs para distribuir a carga entre diferentes grupos e reduzir o risco de interrupção.

Os custos de armazenamento do S3 podem ser reduzidos drasticamente utilizando a classe de armazenamento adequada e automatizando as transições. O S3 Intelligent-Tiering move automaticamente os objetos entre níveis de acesso com base nos padrões de acesso — ideal quando esses padrões são desconhecidos. As regras de ciclo de vida fazem a transição dos objetos segundo um cronograma: de Standard → Standard-IA após 30 dias → Glacier após 90 dias → Deep Archive após 180 dias. Considere também o S3 Select para recuperar apenas o subconjunto necessário dos dados do objeto, reduzindo os custos de transferência e processamento de dados.

Sem uma marcação adequada, é impossível entender quanto cada equipa ou projeto está a gastar. As tags de alocação de custos permitem detalhar os custos por equipa, projeto, ambiente ou qualquer dimensão que definir. Active as tags na consola de faturação e, em seguida, utilize o AWS Cost Explorer para filtrar e agrupar os custos por tag. Exija a marcação com políticas de tags no AWS Organizations e utilize regras do AWS Config para detectar recursos sem tags. Isso permite o showback (visibilidade) e o chargeback (atribuição de custos) a equipas individuais.

O pilar Sustainability (adicionado em 2021) concentra-se em minimizar o impacto ambiental das cargas de trabalho na nuvem, reduzindo o consumo de energia e aumentando a eficiência. Princípios de design: entender o seu impacto — medir a pegada de carbono das suas cargas de trabalho. Estabelecer metas de sustentabilidade. Maximizar a utilização — ajustar o tamanho para evitar recursos ociosos. Antecipar e adoptar hardware mais eficiente — utilizar as gerações mais recentes de instâncias. Utilizar serviços geridos — a AWS opera centros de dados com mais eficiência do que a maioria das organizações.

Os processadores AWS Graviton (baseados em ARM) oferecem até 60% mais eficiência energética e uma relação preço/desempenho 20-40% melhor em comparação com instâncias x86. As instâncias Graviton3/4 (famílias c7g, m7g, r7g e t4g) estão disponíveis para a maioria das cargas de trabalho de EC2, Lambda e Fargate. A migração de x86 para Graviton melhora simultaneamente os pilares Sustainability e Cost Optimisation — menos watts por computação e preços de instância mais baixos. A maioria das cargas de trabalho (Linux, aplicações em contentores e JVM) pode ser migrada com alterações mínimas.

Uma fonte importante de custos desnecessários e desperdício de energia são os recursos ociosos — instâncias EC2 a utilizar 1% de CPU, volumes EBS não associados, IPs elásticos não utilizados e ambientes de desenvolvimento/teste esquecidos a funcionar 24 horas por dia, 7 dias por semana. Implemente um agendamento de paragem/arranque para ambientes que não sejam de produção utilizando regras do EventBridge e a automatização do Systems Manager — pare as instâncias de desenvolvimento às 18h e inicie-as às 8h. Utilize o AWS Trusted Advisor e o Cost Explorer para identificar instâncias ociosas, volumes EBS não utilizados e Reserved Instances subutilizadas.

Armazenar dados indefinidamente desperdiça energia. O pilar Sustainability recomenda implementar políticas de ciclo de vida dos dados para eliminar ou arquivar automaticamente os dados que já não são necessários. Utilize regras de ciclo de vida do S3 com datas de expiração para eliminar objetos após um período de retenção. Utilize o TTL do DynamoDB para expirar automaticamente registos antigos. Utilize políticas de retenção do CloudWatch Logs para eliminar grupos de registos após um período definido. A eliminação de dados desnecessários reduz tanto os custos de armazenamento como a energia necessária para os armazenar e arrefecer.

A Cost Optimisation por vezes entra em conflito com outros pilares. O RDS Multi-AZ duplica o custo da base de dados, mas é necessário para o pilar Reliability. A replicação entre regiões melhora a fiabilidade, mas aumenta os custos de armazenamento e transferência. Uma arquitectura multi-região activa-activa reduz a latência (Performance Efficiency), mas custa 2 a 3 vezes mais. O Well-Architected Framework não afirma que deve escolher sempre a opção mais barata — afirma que deve fazer compromissos conscientes entre os pilares e documentar a justificação. O exame testa a sua capacidade de seleccionar a solução mais económica que ainda cumpra os requisitos indicados.

Teste a sua compreensão dos conceitos de AWS Solutions Architect (SAA-C03) desta lição.

Nesta lição, aprendeu que: Cost Optimisation combina o ajuste de tamanho, modelos de aquisição (Reserved/Savings Plans/Spot) e gestão do ciclo de vida do S3; Sustainability concentra-se em maximizar a utilização, utilizar instâncias Graviton e implementar políticas de ciclo de vida dos dados; e os compromissos de custos com outros pilares devem ser feitos conscientemente, com base nos requisitos do negócio. As tags de custos permitem o showback e o chargeback entre equipas. A seguir, exploraremos o Well-Architected Tool e o processo de revisão.