Summary

  • Uma reserva futura RDS em scheduled foi aceita pela AWS, ainda não tem cobrança e já não pode ser cancelada. Depois de ativa, precisa cumprir o compromisso para permitir o cancelamento comum.
  • Reservas futuras exigem pelo menos 14 dias e 32 vCPU em cada zona de disponibilidade; a família X exige 12 semanas. Um exemplo mínimo de duas zonas com db.r7g.large representa 32 posições de capacidade de banco de dados.

A compra começa antes do medidor

Um gerente consegue mover o lançamento na agenda da equipe. A reserva de capacidade segue o estado e as datas do serviço. No anúncio de 21 de outubro, a AWS levou On-Demand Capacity Reservations ao Aurora e ao RDS em suas regiões comerciais. A oferta guarda capacidade de computação com atributos definidos para operações como criação, restauração, início e mudança de potência de instâncias.

Para uma migração marcada, ter lugar disponível pode valer dinheiro. A pergunta de compras é quando o cliente deixa de poder desistir. O guia de estados chama de scheduled uma solicitação futura aceita e informa que ainda não há cobrança. O guia de cancelamento fecha o cancelamento nesse mesmo estado.

Há, portanto, uma etapa em que o gasto corrente é zero e a saída já está fechada. O projeto pode seguir discutindo sua data enquanto a infraestrutura tem um compromisso definido. Quem aprova o evento precisa ver esse segundo calendário antes da aceitação.

O mínimo cresce com as zonas

A reserva para uso imediato não exige compromisso temporal e pode ser cancelada conforme a necessidade. A futura pode ser marcada de cinco a 120 dias antes e exige ao menos 14 dias de compromisso. Para a família X, o mínimo é de 12 semanas. O piso de 32 vCPU vale para cada zona de disponibilidade escolhida.

A documentação apresenta db.r7g.large como unidade de duas vCPU. Em um exemplo construído no piso com duas zonas, são necessárias 16 unidades por zona, totalizando 32 posições reservadas por pelo menos 14 dias. Esse total conta lugares de computação nas duas zonas, incluindo os necessários ao lado de espera de uma implantação Multi-AZ.

Uma campanha curta pode justificar essa janela maior de proteção. A quantidade e a duração precisam entrar na aprovação da campanha. Pedir apenas espaço para a migração deixa implícita uma compra cujo tamanho tem regra própria.

A saída depende do estado do fornecedor

Durante assessing, a AWS ainda avalia a entrega futura e permite cancelamento. Em scheduled, a reserva permanece até a data de início. Quando fica ativa, o cancelamento aguarda o fim do compromisso. O guia permite cancelamento imediato em delayed quando a AWS não entrega a capacidade na data pedida. Essa exceção acompanha o atraso da entrega pelo fornecedor. A mudança de agenda do cliente, sozinha, não altera o estado da reserva.

O risco transferido ao comprador é o do calendário do próprio negócio. A AWS organiza a oferta de capacidade para uma data e o cliente limita sua liberdade de saída. O responsável por adiar o evento deve conhecer também o compromisso que continua em infraestrutura.

Desligar o banco deixa a vaga ocupada na compra

O guia de cobrança inicia a cobrança quando a capacidade é provisionada na conta. Uma unidade ativa e ociosa custa o equivalente à tarifa On-Demand. Quando uma instância correspondente usa a unidade, o cliente paga pela instância e aquela capacidade não tem cobrança de reserva separada.

Parar a instância transforma sua parte em reserva ociosa, mantendo o custo da reserva. Cancelar quando permitido, ou chegar à data final, encerra essa cobrança. Armazenamento, operações de entrada e saída e demais recursos seguem a cobrança habitual. Os descontos aplicáveis podem vir de Reserved DB Instances ou Database Savings Plans.

O operador pode concluir a tarefa de parar o banco e deixar intacta a compra do lugar. A liberação dessa capacidade é outra decisão, com condições de saída próprias.

O orçamento tem que encontrar o identificador

As regras de uso exigem apontar explicitamente o nome ou identificador da reserva. Motor, classe de instância, modelo de licença aplicável e zona devem corresponder, com capacidade disponível. Em Multi-AZ, é preciso ter lugar tanto na zona do primário quanto na de espera. O gasto compra proteção útil quando a implantação realmente chega à capacidade reservada.

Quando a saída se torna permitida, a API de cancelamento mantém o banco existente funcionando sem modificá-lo e libera a capacidade reservada. Uma movimentação posterior de hardware pode encontrar capacidade insuficiente. A decisão de manter a reserva também deve considerar o próximo movimento, além do evento que motivou a compra.

Históricos e cobranças de clientes não estão disponíveis; eles mostrariam o custo efetivo de compromissos ociosos. A regra pública já coloca a assinatura no ponto certo: antes de scheduled. O fornecedor vende capacidade antecipada e o comprador financia o risco de mudar sua data depois de perder a saída. Quando o medidor começa, uma parte da negociação já virou compromisso.

Fontes