Resumen

  • El almacenamiento asignado a una instancia RDS no se puede reducir en esa misma instancia. Liberar espacio puede mejorar la ocupación sin modificar la capacidad facturada.
  • Una implantación azul/verde compatible ofrece una base sustituta más pequeña. La copia, el cambio de producción y la conservación del entorno anterior determinan cuándo se materializa el ahorro.

La resta que no hace la factura

Supongamos una base con 500 GiB asignados y una ocupación del 50%. Hay 250 GiB en uso. La tentación de convertir la otra mitad en ahorro es comprensible. La factura no comparte esa prisa: en RDS for MySQL, la capacidad provisionada sigue siendo de 500 GiB.

Es un ejemplo de tamaños, sin cliente ni importe inventados. La página de precios de MySQL explica que AWS cobra el almacenamiento por capacidad provisionada y prorratea los cambios que se produzcan durante el mes. La ocupación y la asignación son dos magnitudes distintas. Incluso una limpieza que libere espacio real en el sistema de archivos deja intacta la compra si no cambia la capacidad asignada.

La ampliación automática de RDS aumenta esa asignación cuando se cumplen las condiciones de falta de espacio. No la reduce después. Tampoco permite hacerlo una modificación manual de la misma instancia. Desactivar la función detiene futuras ampliaciones automáticas, pero conserva las que ya se hicieron.

La función aporta algo valioso: una base a punto de llenarse puede recibir espacio sin una intervención apresurada del equipo. El error llega cuando la empresa da por resuelto también el problema presupuestario. El sistema sabe responder a la escasez; decidir qué hacer con el exceso posterior es otro trabajo.

Un pico temporal puede convertirse así en el nuevo tamaño habitual de la compra. La nube recuerda la última ampliación aunque el negocio ya haya pasado de página.

Un destino menor necesita su propio sitio

AWS describe una vía de reducción mediante una implantación azul/verde para los motores compatibles. Se prepara un entorno verde más pequeño a partir del azul que está en producción, se mantiene sincronizado y, cuando está listo, asume el servicio. Otra vía consiste en crear una instancia menor, migrar manualmente los datos y cambiar los puntos de conexión.

En ambos casos hay una base sustituta. El entorno anterior no se contrae en su propio sitio. Esta diferencia explica por qué una petición financiera de reducir capacidad termina en la agenda de cambios de los ingenieros.

Según las instrucciones de creación, al reducir almacenamiento la capacidad objetivo debe superar en al menos un 20% el uso actual. En el ejemplo inicial, 250 GiB ocupados multiplicados por 1,2 dan un mínimo calculado de 300 GiB. Después hay que comprobar la configuración admitida y dejar margen para el crecimiento durante la preparación. La fórmula dimensiona un posible destino; no calcula el dinero que quedará en caja.

La reducción inicia una actualización de la configuración de almacenamiento. Es una operación intensiva en entrada y salida que puede alargar la creación del entorno. Antes de pasar a producción, quedan datos que copiar, comportamiento que comprobar y una transición que organizar.

El caso concreto de este artículo es una instancia RDS for MySQL apta para azul/verde. La lista de compatibilidad incluye también versiones determinadas de MariaDB y PostgreSQL; Db2, SQL Server y Oracle no están admitidos para esta función. Elegir el camino requiere mirar el motor y la configuración, no solo el nombre comercial del servicio.

La dirección sigue; el pasado se queda atrás

El cambio controlado de producción comprueba, entre otras cosas, la salud y el retraso de la replicación. RDS interrumpe nuevas escrituras, corta conexiones, espera a que el verde se sincronice y cambia los nombres de las instancias y de sus puntos de conexión. Después permite conexiones y escrituras en la nueva producción. Promover manualmente la instancia verde por separado rompe la relación de replicación de la implantación: no sustituye a ese procedimiento.

La aplicación puede recuperar su dirección conocida mientras detrás funciona otro recurso. Cada instancia mantiene su identificador permanente. La diferencia se vuelve tangible al intentar recuperar una fecha anterior.

Las consideraciones de azul/verde indican que la nueva instancia de producción no hereda el historial de restauración a un momento concreto de la antigua. Su propio historial empieza cuando se creó el verde. La instancia azul conserva el suyo y sus copias automáticas hasta que se elimina.

Si la empresa necesita mantener esa posibilidad de recuperación, debe planificar cuánto tiempo conservará el entorno anterior. AWS advierte que una instancia azul retenida en ejecución sigue generando costes de cómputo y almacenamiento. La base nueva puede ser menor y, aun así, el gasto total transitorio puede crecer por la convivencia de ambas.

Tampoco basta con eliminar la implantación azul/verde: esa operación no afecta al entorno azul. Desaparece la relación de despliegue, no necesariamente el recurso que cobra. Detener una instancia MySQL conserva igualmente sus costes de almacenamiento.

Faltan los precios reales del cliente, las duraciones, el trabajo de migración y las necesidades de recuperación para calcular un ahorro neto. Lo que sí puede exigirse es una cuenta completa del recorrido. El menor tamaño del destino describe una oportunidad; el inventario final de recursos y su tiempo de conservación dicen cuánto se aprovechó. Vaciar estanterías es útil. Devolver superficie alquilada requiere acabar la mudanza.