São Políticas Alternativas De Capacidade Exceto

Entendendo as opções de capacidade na AWS

Quando você trabalha com infraestrutura na nuvem e precisa garantir que seus recursos estejam disponíveis, existem várias formas de estruturar isso. A maioria das pessoas conhece o On-Demand, mas existe um leque de alternativas que mudam completamente o custo e a confiabilidade do seu ambiente. O tema é sério porque errar na escolha pode custar fortunas ou causar downtime em momentos ruins. Além das instâncias sob demanda, a AWS oferece três modelos principais: Reserva de Capacidade, Instâncias Reservadas e Instâncias Spot. Cada um resolve um problema diferente. A Reserva de Capacidade garante que o hardware exista no datacenter quando você precisar. As Instâncias Reservadas oferecem desconto em troca de um compromisso de uso. O Spot permite usar capacidade ociosa por uma fração do preço, mas com a ressalva de que a AWS pode retomar o recurso a qualquer momento. Ninguém fala sobre isso com clareza, então vou explicar como funciona na prática, não na documentação.

Reserva de Capacidade: a solução para planejamento

A Reserva de Capacidade é basicamente um voucher que garante que, quando você ligar uma instância em um Availability Zone específico, ela vai subir. Sem reserva, você pode tentar lançar uma instância e receber um erro de capacidade. Isso acontece mais do que deveria, especialmente em regiões novas ou durante picos de demanda. O custo é fixo, independente da instância que você realmente usar. Se você reservar 10 instâncias t3.large e só usar 4, você paga por 10 mesmo assim. Já vi essa situação acontecer porque a equipe de infraestrutura não atualizou a reserva quando o trabalho foi reduzido, e a conta mensal veio com um diferencial surpreendente. A workaround que eu uso é monitorar o uso mensal e ajustar a reserva no próximo ciclo. Não adianta deixar uma reserva ativa por seis meses sem revisar o que realmente está rodando.

Instâncias Reservadas: desconto com compromisso

Aqui o modelo é simples: você se compromete a usar uma instância por um período, normalmente 1 ou 3 anos, e em troca recebe um desconto que pode variar de 30% a 70% em relação ao preço sob demanda. O problema é que instâncias Reservadas são atreladas a uma região e tipo de instância específicos. Se você migra para outro tipo, o desconto não acompanha. Uma nuance importante que quase ninguém menciona: as Savings Plans são mais flexíveis. Elas aceitam mudanças de família de instâncias, regiões e até serviços diferentes dentro de um mesmo plano. Se sua carga de trabalho tem alguma variabilidade, Savings Plans geralmente compensam mais do que Instâncias Reservadas tradicionais. Eu tenho um caso específico aqui: uma vezreservei Instâncias Reservadas para workloads que depois migraram para Graviton. O desconto foi totalmente perdido porque o novo tipo de instância não era compatível com a reserva original. A migração para Savings Plans foi o que salvou o orçamento naquele projeto.

Spot Instances: economia com risco controlado

Spot Instances usam capacidade ociosa do datacenter. O preço flutua conforme a oferta e a procura, e a AWS pode encerrar uma instância Spot com apenas dois minutos de aviso. Para workloads stateless, batch jobs e processamento de dados, isso é extremamente eficiente. Um cluster de processamento que custaria R$5 mil por mês no On-Demand pode custar menos de R$800 com Spot. O ponto que ninguém destaca é a importância de usar Spot Fleet com diversificação de tipos de instância. Se você solicitar apenas um tipo e aquele tipo estiver escasso, sua taxa de interrupção dispara. Quanto mais diversidade de, mais estável o cluster. Um problema real que eu enfrentei: um job de ETL que precisava de 4 horas para completar, mas as interrupções Spot chegavam a cada 45 minutos em média. A solução foi implementar checkpointing no código do job e usar o EC2 Auto Recovery com múltiplos tipos de instância no Spot Fleet. O tempo total do job aumentou, mas ele finalmente completava sem depender de uma única instância rodando até o fim.

Quando usar cada política

Baseado no que eu vejo sendo feito errado todos os dias: Use Reserva de Capacidade quando você tem workloads críticos que precisam estar online e não podem falhar por falta de capacidade no datacenter. É seguro, mas caro se você superdimensionar. Use Instâncias Reservadas para workloads estáveis que vão rodar exatamente no mesmo tipo de instância por pelo menos um ano. Se houver qualquer chance de mudança, vá de Savings Plans.

Use Spot Instances para qualquer coisa que seja tolerante a falhas: processamento em lote, renderização, testes, ML training. O risco vale a pena quando o desconto é real. Mantenha uma pequena base de instâncias On-Demand como fallback. Nunca confie 100% em nenhuma política alternativa. O dia em que a AWS tiver uma restrição de capacidade em larga escala, você vai agradecer por ter aquela rede de segurança. A combinação ideal que eu recomendo para a maioria dos cenários é: On-Demand para a base crítica, Reserva de Capacidade onde o risco de falta de hardware é real, e Spot para tudo o resto. O custo total cai drasticamente e a confiabilidade permanece aceitável. A chave é revisar essa combinação todo mês, porque o que funcionou em janeiro provavelmente não funciona em julho.