AWS Certified CloudOps Engineer - Associate

Right-sizing de EC2 e Compute Optimizer

Encontrar as instâncias do tamanho errado com os findings do Compute Optimizer, a métrica que o CloudWatch não enxerga sozinho, e o modelo de créditos que faz a família T se comportar diferente de todas as outras.

Intermediário 24 minutos 6 Objetivos de aprendizado

Explicar por que CPUUtilization sozinho não diz se uma instância tem o tamanho certo
Interpretar as classificações de finding do Compute Optimizer, os finding reasons e o performance risk
Calcular por quanto tempo uma instância burstable sustenta um nível de CPU antes de esgotar os créditos
Distinguir o modo standard do modo unlimited e prever o comportamento de cada um com o saldo em zero
Escolher entre Compute Optimizer, right sizing do Cost Explorer e Trusted Advisor conforme a pergunta do cenário
Executar uma mudança de tamanho numa instância viva sem perder dados nem configuração

Você herda uma conta com 40 servidores web em m5.2xlarge. Todas as instâncias estão saudáveis. Nenhum alarme disparou em oito meses. O CloudWatch mostra CPUUtilization com média de 8% e picos perto de 22%. A conta mensal de computação fica em torno de US$ 11.000, e uns US$ 8.000 disso compram capacidade que ninguém usa.

Nada aqui está quebrado, e é exatamente por isso que ninguém olha. Right-sizing é a parte do trabalho de CloudOps que não tem incidente anexado, e a prova cobra porque as habilidades envolvidas são as mesmas de quando algo está quebrado: ler métricas de utilização direito, saber qual métrica está faltando e saber qual ferramenta responde qual pergunta.

CPUUtilization é uma dimensão entre quatro

CPUUtilization é a métrica que todo mundo procura primeiro e, sozinha, é quase inútil para decidir tamanho.

Uma instância tem pelo menos quatro dimensões de capacidade que podem acabar de forma independente: CPU, memória, rede e I/O de armazenamento. O CloudWatch publica métricas de instância para três delas sem configuração nenhuma. Ele não publica memória, porque o hypervisor não enxerga dentro do convidado. Para a AWS, a memória do seu sistema operacional é opaca; só um agent rodando dentro da instância consegue reportar quanto dela está em uso.

Isso produz um formato de falha específico e muito comum: uma aplicação lenta com CPUUtilization em 12%. A instância está sem memória, o sistema operacional está fazendo swap, e todos os gráficos do console parecem calmos. Se um cenário descreve CPU baixa e desempenho ruim, memória é a primeira suspeita, e a ação que destrava o diagnóstico é instalar o unified CloudWatch agent para que memória vire uma métrica visível.

O mesmo ponto cego afeta as ferramentas construídas sobre essas métricas. O Compute Optimizer analisa utilização de memória apenas em recursos com o CloudWatch agent instalado. Sem ele, você recebe findings baseados em CPU, rede e I/O, e o serviço vai recomendar tranquilamente uma instância menor para uma carga que na verdade está presa em memória.

O que o Compute Optimizer faz

O AWS Compute Optimizer lê a configuração e as métricas de utilização do CloudWatch dos seus recursos e devolve uma configuração recomendada, com a utilização projetada caso você a adote.

Quatro fatos sobre como ele funciona moldam a maioria das questões de prova:

Você precisa fazer opt-in. Ele não faz nada até ser ativado para uma conta isolada, uma conta membro ou a management account de uma organização. Um cenário em que "o Compute Optimizer não mostra recomendação nenhuma" costuma terminar aqui.

A janela padrão é de 14 dias. Ele analisa os últimos 14 dias de métricas e atualiza as recomendações diariamente. Ativar enhanced infrastructure metrics, uma preferência de recomendação paga, estende a janela para 93 dias. Essa é a resposta sempre que a carga tem fechamento mensal, lote trimestral ou qualquer pico que uma janela de 2 semanas nunca veria.

Ele precisa de dados suficientes. As recomendações podem levar até 24 horas para aparecer depois do opt-in, e um recurso com histórico curto demais não recebe finding nenhum.

Ele cobre muito além do EC2. Instâncias EC2 e Auto Scaling groups, volumes EBS, funções Lambda, serviços ECS no Fargate, bancos RDS e Aurora, DynamoDB, ElastiCache, MemoryDB, DocumentDB, NAT gateways, WorkSpaces, SageMaker e licenças de software comercial. Se uma questão pergunta qual serviço único dá recomendações de right-sizing para computação e armazenamento e bancos de dados, é este.

Ler um finding

Toda instância analisada cai em uma de três classificações:

Finding	Significado
Under-provisioned	Pelo menos uma especificação não atende aos requisitos da carga. Risco para o desempenho.
Over-provisioned	Pelo menos uma especificação pode ser reduzida, e nada está under-provisioned. Risco para a fatura.
Optimized	Toda especificação atende aos requisitos e nada está superdimensionado. O Compute Optimizer ainda pode sugerir uma geração mais nova.

A classificação diz que algo está errado. O finding reason diz o quê, e é específico: CPU over-provisioned, Memory under-provisioned, EBS throughput under-provisioned, EBS IOPS over-provisioned, Network bandwidth under-provisioned, Network PPS under-provisioned, Disk IOPS, Disk throughput e os equivalentes de GPU. Cada um nomeia a métrica de onde saiu, então você pode ir verificar: razões de EBS IOPS vêm de VolumeReadOps e VolumeWriteOps, largura de banda de rede de NetworkIn e NetworkOut, network PPS de NetworkPacketsIn e NetworkPacketsOut.

Repare na separação que pega as pessoas: razões de Disk se referem a volumes instance store (DiskReadOps, DiskWriteBytes), enquanto razões de EBS se referem a volumes EBS anexados. Hardware diferente, correção diferente. Um finding de disco se resolve trocando o tipo da instância; um finding de EBS muitas vezes se resolve modificando o volume, e a lição depois da próxima cobre isso em detalhe.

Cada recomendação também carrega um performance risk de very low a very high (0 a 4 na API). É o maior score de risco entre todas as especificações analisadas, e responde "qual a chance de esse tipo menor me decepcionar?". Very low significa que o tipo deve sempre ter capacidade suficiente. Qualquer coisa acima disso é um convite a testar sob carga real antes.

Instâncias burstable seguem outras regras

Tudo acima parte do princípio de que uma instância pode usar 100% da CPU quando quiser. Instâncias T não podem, e este é o pedaço mais cobrado de conhecimento sobre dimensionamento de EC2.

Uma instância burstable é vendida com um nível baseline de CPU que ela sustenta para sempre, mais um balde de créditos de CPU que a deixam rodar acima do baseline por um tempo. Um crédito de CPU equivale a um vCPU a 100% por um minuto. Abaixo do baseline, a instância ganha mais do que gasta e o balde enche. Acima do baseline, ela gasta mais do que ganha e o balde esvazia.

Veja uma t3.large, que tem 2 vCPUs, ganha 36 créditos por hora, tem baseline de 30% e acumula até 864 créditos (um dia inteiro de ganho):

A demanda sobe para 55% de CPU de forma constante.
Créditos gastos por minuto = vCPUs x utilização = 2 x 0,55 = 1,1, ou seja 66 por hora.
Créditos ganhos por hora = 36.
Dreno líquido = 30 créditos por hora. Partindo dos 864 cheios, o saldo zera em cerca de 29 horas.

O que acontece no zero depende do modo de configuração de crédito:

Modo standard: a instância é trazida para o baseline. A CPU fica travada em 30% e a aplicação fica lenta, sem erro, sem alarme e sem causa aparente. É o padrão para T2 e para T3 em Dedicated Host.
Modo unlimited: a instância continua acima do baseline gastando créditos excedentes. Se a média de CPU nas últimas 24 horas ficar no baseline ou abaixo, o excedente é coberto pelo preço normal por hora. Se não ficar, você paga uma taxa adicional fixa por vCPU-hora. É o padrão para T3, T3a e T4g.

O engano que precisa ser dito em voz alta: as pessoas leem "burstable" como bônus e supõem que a instância pode segurar CPU alta indefinidamente. Ela não pode, em nenhum dos dois modos, sem consequência. No modo standard a consequência é um penhasco de desempenho cerca de um dia depois do aumento de carga. No modo unlimited a consequência é uma linha na fatura que ninguém esperava. A métrica que prevê os dois casos é CPUCreditBalance, não CPUUtilization, então uma frota de instâncias T precisa de alarme no saldo de créditos caindo em direção a zero. CPUSurplusCreditsCharged é a métrica do lado da fatura.

Mais alguns fatos de crédito que vale segurar:

O limite de acúmulo é sempre o equivalente a 24 horas de ganho. Uma t3.micro ganha 12 por hora e acumula 288; uma t3.2xlarge ganha 192 por hora e acumula 4.608.
Os percentuais de baseline são por vCPU e batem com o que o CloudWatch mostra. Uma t3.large no baseline aparece como 30% no console.
Em T3, T3a e T4g, os créditos acumulados sobrevivem a um stop por 7 dias. Em T2 eles são perdidos no instante em que você para a instância.
Launch credits existem só para T2 em modo standard. T3 em diante nascem em modo unlimited, então já conseguem fazer burst desde o primeiro minuto.

Se uma instância T vive acima do baseline de forma consistente, ela é a instância errada para aquela carga. Isso é um achado de right-sizing, não um problema de tuning, e o Compute Optimizer desenha a linha de baseline burstable no gráfico de CPU justamente para você enxergar.

Redimensionar uma instância viva

Com o finding na mão, a mudança em si é mecânica, e a prova se importa com a ordem e com os efeitos colaterais.

Numa instância EBS-backed, trocar o tipo exige a instância parada:

aws ec2 stop-instances --instance-ids i-0abc123def4567890
aws ec2 wait instance-stopped --instance-ids i-0abc123def4567890

aws ec2 modify-instance-attribute \
  --instance-id i-0abc123def4567890 \
  --instance-type "{\"Value\": \"m5.xlarge\"}"

aws ec2 start-instances --instance-ids i-0abc123def4567890

A instância mantém o ID, os volumes EBS, os security groups e a IAM role. Três coisas não sobrevivem ao stop e start:

Dados em volumes instance store, porque a instância migra para outro hardware.
O IP público IPv4, a menos que exista um Elastic IP associado.
O saldo de créditos de CPU numa instância T2.

Tags fazem a metade organizacional desse trabalho. Right-sizing em escala de frota significa conseguir responder "quem é dono desta instância e em que ambiente ela está" antes de redimensionar, e é por isso que a Skill 1.3.1 do guia da prova cita resource tags ao lado de métricas de desempenho. Um conjunto consistente de tags Environment, Owner e Application é o que transforma uma lista de 400 findings em 12 conversas.

Para instâncias em Auto Scaling group, não redimensione instância por instância. Atualize o launch template com o novo tipo e inicie um instance refresh, para que a mudança seja durável e o grupo substitua instâncias de forma controlada.

Qual ferramenta responde qual pergunta

Três serviços produzem conselhos que soam parecidos, e as questões são escritas para separá-los.

Ferramenta	O que a dirige	O que ela entrega
Compute Optimizer	Métricas de utilização do CloudWatch em 14 (ou 93) dias	Um tipo recomendado por recurso, com utilização projetada e performance risk
Rightsizing do Cost Explorer	O mesmo motor do Compute Optimizer, apresentado contra seu gasto	Candidatos a redução e instâncias ociosas com economia estimada, dentro de uma visão de custo
Trusted Advisor	Limites fixos contra uma checklist	Sinalizações de instâncias ociosas e subutilizadas, além de checks de segurança, cotas e tolerância a falhas

A pista: "recomendar um tipo de instância com base na utilização medida" é Compute Optimizer. "Mostre oportunidades de economia junto da minha fatura" é Cost Explorer. "Verifique minha conta contra uma lista de boas práticas" é Trusted Advisor.

Dicas para a prova

CPU baixa com aplicação lenta significa memória. A ação que destrava é instalar o CloudWatch agent, porque memória não é métrica padrão do CloudWatch e o Compute Optimizer não consegue analisá-la sem o agent.
"Job mensal", "pico trimestral" ou "carga sazonal" junto de Compute Optimizer aponta para enhanced infrastructure metrics e sua janela de 93 dias. Os 14 dias padrão nunca veriam o pico.
Uma instância T que fica lenta depois de cerca de um dia de carga elevada é questão de esgotamento de crédito. A métrica é CPUCreditBalance; a correção é modo unlimited (aceitando a cobrança do excedente) ou uma família não burstable.
Preste atenção em qual padrão a questão implica. T2 nasce em modo standard e faz throttling; T3, T3a e T4g nascem em unlimited e cobram.
Não confunda razões de Disk (instance store) com razões de EBS (volumes anexados). Elas levam a remediações diferentes.
Trocar o tipo de instância exige a instância parada, e parar destrói dados de instance store e libera um IP público que não seja Elastic.

O hábito para levar: antes de mudar o tamanho de qualquer instância, saiba qual das quatro dimensões de capacidade está de fato restrita. CPU é a que você enxerga por padrão, memória é a que você precisa ir buscar, e em instâncias T a restrição nem é uma dimensão, é um saldo de créditos. A próxima lição pega a terceira dimensão, rede, e mostra por que uma instância pode estar longe da largura de banda anunciada e ainda assim sofrer throttling.