O problema
A capacidade das famílias de instâncias GPU do EC2 como P5, P4d, G7, G6 e G5 pode ser escassa, principalmente em períodos de alta demanda. Quando você para uma instância, ela volta para o pool compartilhado, e não há garantia de que ela estará disponível quando você quiser ligá-la de novo.
Isso transforma uma manutenção rotineira em aposta. No instante em que você para uma instância GPU para atualizar um driver, trocar uma AMI, redimensionar o volume raiz ou aplicar uma atualização de SO, aquela capacidade fica livre para qualquer outro cliente da AWS.
Se a demanda estiver alta, você pode receber um erro de InsufficientInstanceCapacity ao tentar subir a instância de novo, e sua "janela de manutenção de 10 minutos" vira horas de tentativas em loop — ou, pior, uma indisponibilidade enquanto você espera capacidade liberar.
O que uma On-Demand Capacity Reservation faz de verdade
Uma EC2 On-Demand Capacity Reservation (ODCR) reserva capacidade de computação para um tipo específico de instância, em uma Availability Zone específica, enquanto você mantiver a reserva ativa. A característica principal é que essa capacidade fica retida para você, tendo ou não uma instância em execução no momento.
É justamente esse último ponto que faz das ODCRs a ferramenta certa para manutenção. Quando você para uma instância que está usando uma reserva, a capacidade reservada continua disponível para você. A AWS mantém essa capacidade alocada exclusivamente para a sua conta. Quando você inicia a instância de novo, a AWS garante que a capacidade reservada estará disponível.
Algumas características importantes
Apesar do que o nome sugere, uma Capacity Reservation imediata não é um compromisso de longo prazo. Ela apenas garante que a capacidade EC2 de que você precisa esteja disponível na hora certa. Se seus planos mudarem ou você não precisar mais dessa capacidade reservada, dá para cancelar a reserva a qualquer momento. Não há taxas de cancelamento nem períodos mínimos de compromisso.
O custo de uma Capacity Reservation é o mesmo de rodar uma instância EC2 On-Demand. Se você tiver um Savings Plans aplicável ou Reserved Instances, a tarifa com desconto continua valendo para a Capacity Reservation. A única diferença é que você continua pagando pela capacidade reservada mesmo com a instância parada, até cancelar a Capacity Reservation ou iniciar a instância.
Por que isso importa especificamente na manutenção
Ironicamente, a manutenção costuma ser o momento em que você está mais exposto. Assim que você para a instância, a capacidade dela volta para o pool compartilhado da AWS. Se outro cliente da AWS subir uma instância equivalente na mesma Availability Zone antes de você religar a sua, ele pode consumir a capacidade que sustentava a sua instância, transformando uma janela de manutenção planejada em uma indisponibilidade inesperada.
Operações de stop/start
Muitas tarefas de manutenção exigem stop/start completo, e não apenas um reboot:
- Migrar para uma nova AMI
- Modificar certos atributos da instância
Cada uma dessas operações devolve a instância ao pool de capacidade compartilhado.
Manutenção rolling em uma fleet
Se você aplica patches em uma fleet nó a nó, normalmente drena e para uma instância de cada vez. Sem capacidade reservada, cada nó que você derruba pode não voltar, e você acaba com uma fleet permanentemente menor do que quando começou.
Eventos de hardware planejados
A AWS eventualmente agenda manutenção no host subjacente (por exemplo, hardware degradado ou desativação do host). Ter uma Capacity Reservation garante computação na hora de parar e iniciar a instância para migrar do host afetado.
Como usar na prática
No Console do EC2, crie uma On-Demand Capacity Reservation aberta correspondente a:
- Tipo de instância
- Availability Zone
- Sistema operacional (Platform)
Dimensione a Capacity Reservation para cobrir o total de instâncias do mesmo tipo (por exemplo, g7.xlarge) que você tem naquela Availability Zone durante a operação de manutenção rolling.
Confirme que suas instâncias estão consumindo a reserva. Por padrão, instâncias EC2 usam automaticamente uma Capacity Reservation aberta sempre que houver uma reserva correspondente disponível. Verifique se as Capacity Reservations que você criou estão mesmo sendo utilizadas pelas suas instâncias.
As Capacity Reservations também atendem casos de uso mais avançados, como reservas direcionadas para workloads específicos. Esses cenários estão fora do escopo deste artigo.
Faça a manutenção como de costume:
- Pare a instância.
- Aplique as alterações necessárias.
- Inicie a instância de novo.
Como a capacidade continua reservada, a instância sobe sem disputar capacidade de GPU disponível.
Quando terminar a manutenção, cancele a Capacity Reservation caso não precise mais dela. Suas instâncias continuam rodando normalmente.
Quanto custou?
Para ver exatamente quanto você pagou pela capacidade reservada enquanto suas instâncias estavam paradas, aguarde cerca de 48 horas após o fim da manutenção. Os dados do AWS Billing não são em tempo real, e pode levar até dois dias para essas cobranças aparecerem.
Assim que os dados de billing forem atualizados:
- Abra AWS Billing → Bills.
- Pesquise por "Unused Reservation".
Você vai ver um item de linha mostrando:
- O tipo de instância
- O valor cobrado pela Capacity Reservation enquanto ela não estava sendo usada por uma instância em execução
Essa é uma forma simples de medir o custo de garantir capacidade durante a sua janela de manutenção.
No meu caso, a manutenção levou menos de 30 minutos. Sem uma Capacity Reservation, eu poderia ter ficado horas esperando capacidade de GPU aparecer de novo.
Conclusão
Escassez de capacidade é parte inevitável de rodar workloads em um ambiente de nuvem compartilhado. Felizmente, a AWS oferece um jeito simples de eliminar essa incerteza justamente quando ela mais pesa.
Se você está planejando manutenção em instâncias GPU, ou em qualquer tipo de instância EC2 com capacidade escassa, uma Capacity Reservation temporária pode ser a diferença entre uma janela de manutenção tranquila e horas de downtime inesperado.