Summary

  • Una reserva futura RDS aceptada en estado scheduled todavía no genera cargos y ya tiene cerrada la cancelación. Cuando se activa, debe terminar su período de compromiso para permitir la cancelación ordinaria.
  • La reserva futura exige al menos 14 días y 32 vCPU en cada zona de disponibilidad; la familia X tiene un mínimo de 12 semanas. Un ejemplo mínimo en dos zonas con db.r7g.large ocupa 32 plazas de capacidad de base de datos.

La fecha que importa antes de la factura

El equipo de un lanzamiento puede mover una fecha en su plan de trabajo. La reserva de capacidad lleva otro calendario. AWS anunció el 21 de octubre las reservas On-Demand para Aurora y RDS en sus regiones comerciales. Permiten guardar capacidad de cómputo con atributos concretos para crear, restaurar, iniciar o cambiar la potencia de instancias.

El comprador obtiene un lugar para una operación futura. La condición decisiva aparece al aceptar AWS la solicitud. Su guía de estados llama scheduled a una reserva futura aceptada y dice que aún no se aplican cargos. La guía de cancelación impide cancelarla en ese estado.

Así puede haber una compra vinculante detrás de un panel de gasto sin movimiento. Esperar al primer cargo para revisar el compromiso llega tarde a una parte de la decisión. El responsable que puede aplazar el lanzamiento necesita conocer esa salida antes de aceptar la reserva.

La capacidad futura tiene un tamaño mínimo

Las reservas de uso inmediato carecen de compromiso temporal y se pueden cancelar según las necesidades. Las futuras se solicitan entre cinco y 120 días antes, con un compromiso mínimo de 14 días. Para la familia X son 12 semanas. Además, cada zona de disponibilidad seleccionada requiere al menos 32 vCPU.

La documentación usa db.r7g.large como unidad de dos vCPU. En un ejemplo construido al mínimo con dos zonas, cada una necesita 16 unidades: el total es de 32 plazas de capacidad durante al menos 14 días. Son unidades reservadas entre dos zonas, incluidas las plazas que un despliegue Multi-AZ necesita para su lado de espera.

Un evento breve puede justificar esa protección más larga. La decisión debe llevar la cantidad y la duración completas al presupuesto del evento. Pedir «sitio para la migración» sin mirar el mínimo deja al equipo financiero una cifra que el calendario del proyecto nunca llegó a aprobar.

La salida sigue el estado de AWS

Mientras la solicitud está en assessing, AWS evalúa si puede entregarla y el comprador puede cancelarla. Una vez scheduled, permanece hasta su inicio. Después de activarse, la cancelación espera al final del compromiso. La documentación abre una salida inmediata en delayed cuando AWS no entrega a tiempo la capacidad solicitada. Esa excepción corresponde al retraso del proveedor; aplazar una campaña del cliente no cambia por sí solo el estado de AWS.

La diferencia asigna un riesgo concreto. El proveedor organiza capacidad anticipada y el comprador acepta que la fecha de su propio negocio puede cambiar. La persona con autoridad sobre el lanzamiento debe ver también la fecha de fin del compromiso de infraestructura. Los dos calendarios pertenecen a la misma compra.

Apagar la base conserva la reserva

La facturación oficial comienza cuando la capacidad queda provisionada en la cuenta. Las unidades activas sin uso se cobran a la tarifa On-Demand equivalente. Si una instancia correspondiente ocupa una unidad, se cobra la instancia y esa unidad carece de cargo de reserva separado.

Detener la instancia convierte su capacidad en reserva sin uso y mantiene el coste de la reserva. La cancelación admisible o la fecha de fin detiene esos cargos. Almacenamiento, operaciones de entrada y salida y otros recursos conservan su facturación habitual. Pueden aplicarse los descuentos correspondientes de Reserved DB Instances o Database Savings Plans.

La tarea de detener una base y la decisión de soltar su lugar tienen condiciones diferentes. Terminar la primera puede dejar activa la segunda compra.

Usar el lugar y decidir cuándo devolverlo

Las instrucciones de colocación exigen indicar expresamente el nombre o identificador de la reserva. Deben coincidir motor, clase de instancia, modelo de licencia cuando corresponda y zona, con capacidad disponible. Multi-AZ requiere sitio en las zonas del primario y de la instancia de espera. La compra protege la operación cuando el despliegue apunta a la capacidad adquirida.

Al llegar una salida permitida, soltarla tiene otra consecuencia. La API de cancelación deja la base existente en funcionamiento sin modificarla, pero libera la capacidad reservada. Un movimiento posterior a otro hardware puede encontrar capacidad insuficiente. Conservar la reserva tiene valor para esa próxima operación además del evento inicial.

No están disponibles los historiales ni los cargos de reservas de clientes; permitirían calcular el coste real de compromisos vacíos. La decisión publicada ya es precisa: acceso anticipado a una capacidad definida a cambio de limitar la libertad de salida. Compras debe aprobar ese riesgo cuando AWS aún está evaluando la solicitud. El contador se enciende después de que una parte del trato haya quedado fijada.

Fuentes