Dimensionamento adequado e Compute Optimizer

Um dos erros mais comuns e dispendiosos na arquitetura de nuvem é o provisionamento excessivo — alocar mais recursos do que a carga de trabalho realmente precisa. As equipes de IT frequentemente provisionam recursos em excesso devido a hábitos do ambiente local (comprar capacidade para a carga de pico), ao receio de degradação do desempenho ou simplesmente por nunca revisarem as decisões iniciais de dimensionamento. Na AWS, instâncias EC2, volumes EBS e funções Lambda provisionados em excesso desperdiçam dinheiro a cada minuto em que permanecem em execução. O dimensionamento adequado é o processo sistemático de identificar e eliminar esse desperdício.

O AWS Compute Optimizer analisa métricas históricas de utilização do CloudWatch e usa aprendizado de máquina para recomendar recursos de computação ideais da AWS. Ele abrange instâncias EC2, grupos de escalonamento automático do EC2, volumes EBS, funções Lambda e Amazon ECS no Fargate. O Compute Optimizer exige pelo menos 30 dias de histórico de métricas para gerar recomendações confiáveis. Sua ativação é gratuita, e ele fornece recomendações com a economia mensal estimada e uma classificação de risco para a alteração.

O Compute Optimizer analisa a utilização da CPU do EC2, a utilização da memória (por meio do agente do CloudWatch), a vazão da rede e as IOPS do EBS nos últimos 3, 14 ou mais de 30 dias. Em seguida, recomenda uma das quatro descobertas: Optimized (o tamanho atual é adequado), Over-provisioned (pode ser reduzido), Under-provisioned (deve ser aumentado) ou NOT optimized (dados insuficientes). Sempre analise o risco de desempenho — o Compute Optimizer atribui risco VeryLow, Low, Medium, High a cada recomendação.

As funções Lambda são cobradas por milissegundo de tempo de execução multiplicado pela memória alocada. Alocar mais memória do que o necessário desperdiça dinheiro, mas mais memória também significa mais CPU — portanto, o equilíbrio correto é a configuração de memória que minimiza o custo por invocação. O Compute Optimizer analisa a duração das invocações do Lambda, a taxa de erros e as métricas de tempo limite para recomendar a configuração ideal de memória. A ferramenta de código aberto ajuste de potência do Lambda também pode invocar sua função com diferentes configurações de memória para encontrar empiricamente a configuração de custo ideal.

Os volumes EBS frequentemente são provisionados em excesso tanto em relação ao tamanho (espaço em disco não utilizado) quanto às IOPS (IOPS provisionadas que nunca são consumidas). O Compute Optimizer analisa as métricas VolumeReadOps, VolumeWriteOps, VolumeReadBytes, VolumeWriteBytes. Uma recomendação comum é migrar de gp2 para gp3 (que separa o tamanho das IOPS) — você pode dimensionar as IOPS de forma independente, muitas vezes economizando 20%. Identifique também volumes EBS não anexados (instâncias encerradas, mas com os volumes deixados para trás) e crie snapshots ou exclua-os.

O Compute Optimizer analisa a utilização do ASG em todas as instâncias do grupo e recomenda alterações no modelo de execução para o tipo de instância. Se todas as instâncias de um ASG estiverem constantemente provisionadas em excesso, mudar para um tipo de instância menor reduz o custo em escala. Por exemplo, se um ASG tiver em média 10 instâncias de m5.large, mudar para m5.medium economiza 50% por instância. O Compute Optimizer também recomenda instâncias baseadas em Graviton quando o software for compatível, proporcionando melhoria de desempenho e redução de custos.

O AWS Trusted Advisor é outra ferramenta que fornece insights de otimização de custos, além de verificações de segurança, desempenho, tolerância a falhas e limites de serviço. Principais verificações de custos: instâncias EC2 com baixa utilização (menos de 10% de CPU por 4 ou mais dias), endereços IP elásticos não associados (cobrados quando não estão anexados), volumes EBS subutilizados, balanceadores de carga ociosos (sem destinos íntegros) e instâncias reservadas não utilizadas. As verificações básicas do Trusted Advisor são gratuitas; o conjunto completo exige o AWS Business Support ou Enterprise Support.

A AWS lança regularmente novas gerações de instâncias EC2 mais eficientes, que oferecem melhor desempenho a um custo menor ou equivalente. Passar da 5ª geração (m5, c5, r5) para a 7ª geração (m7g, c7g, r7g) pode proporcionar 40% mais desempenho de computação a um custo semelhante ou menor. O Compute Optimizer identifica especificamente oportunidades de atualização para gerações mais recentes, incluindo instâncias baseadas em Graviton. As atualizações de instâncias costumam ser a ação mais simples de dimensionamento adequado — mesma configuração, hardware mais novo, melhor desempenho e menor custo.

As instâncias RDS são caras e frequentemente provisionadas em excesso. Use métricas do CloudWatch para avaliar a utilização do RDS: CPUUtilization, FreeableMemory, ReadIOPS e WriteIOPS. Se a CPU permanecer abaixo de 20% e a memória continuar consistentemente alta, considere reduzir o tamanho. Para bancos de dados de produção com Multi-AZ, o dimensionamento adequado duplica a economia, pois tanto a instância primária quanto a de espera são alteradas. Considere também mudar de RDS MySQL/PostgreSQL para Aurora, que frequentemente oferece melhor desempenho a um custo semelhante e é mais eficiente em termos de custo em escala.

O dimensionamento adequado deve ser um processo contínuo, não uma atividade pontual. Estabeleça uma periodicidade de revisão mensal ou trimestral: obtenha as recomendações do Compute Optimizer, avalie quais podem ser aplicadas com segurança, implemente as alterações em uma janela de manutenção e meça a economia. Automatize os ganhos fáceis: a limpeza de volumes EBS não anexados, a liberação de endereços IP elásticos não utilizados e a remoção de balanceadores de carga ociosos podem ser feitas por meio de scripts. Crie um painel de otimização de custos no CloudWatch que acompanhe os gastos mensais por serviço e destaque aumentos incomuns.

O dimensionamento adequado resolve o provisionamento excessivo nas arquiteturas existentes, mas às vezes o problema está na própria arquitetura. Uma única instância EC2 grande executando várias aplicações pode exigir decomposição arquitetural (microsserviços no Fargate), em vez de apenas uma instância menor. Um banco de dados monolítico pode precisar de fragmentação ou Caching, em vez de apenas uma redução no tamanho da instância. O dimensionamento adequado é o primeiro passo e o mais rápido. A otimização da arquitetura (sem servidor, contêineres e Caching) proporciona economias mais profundas e duradouras, mas exige mais esforço. O pilar Cost Optimisation recomenda buscar ambas as abordagens.

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

Nesta lição, você aprendeu que: o AWS Compute Optimizer usa aprendizado de máquina sobre métricas do CloudWatch para recomendar recursos de computação com dimensionamento adequado, o dimensionamento adequado se aplica a EC2, Lambda, EBS, ASGs e ECS no Fargate e a atualização para gerações mais recentes de instâncias (especialmente Graviton) proporciona melhorias de custo e desempenho. Torne o dimensionamento adequado uma prática recorrente, não uma atividade pontual. A seguir, exploraremos Reserved Instances, Savings Plans e modelos de aquisição Spot.