Costes ocultos del soporte extendido de AWS y cómo detectarlos

Amazon Web Services ha cambiado su estrategia para los servicios gestionados antiguos, moviendo las versiones sin soporte a una categoría de pago llamada Soporte Extendido, en lugar de forzar actualizaciones inmediatas. Este cambio, detallado en una guía técnica de noviembre de 2026, afecta a servicios populares como EKS, RDS, Aurora y ElastiCache. Para muchos equipos de ingeniería, la transición es silenciosa, lo que resulta en partidas inesperadas en las facturas mensuales sin ninguna interrupción del servicio ni alertas de fallo.

El problema principal es que la inscripción en este nivel de soporte premium suele ser automática. Cuando una versión específica de software alcanza el fin de su soporte estándar, AWS mantiene el recurso activo pero aplica un recargo significativo. Esto crea un centro de costes oculto que puede persistir durante meses si los equipos no monitorizan activamente las versiones de su infraestructura frente a las fechas de ciclo de vida de AWS.

Qué ha ocurrido

Cuando expira la versión de un servicio gestionado, AWS no apaga el clúster o la base de datos. En su lugar, transiciona el recurso al Soporte Extendido, añadiendo una tarifa sobre el precio de uso estándar. No se crea ningún ticket, no hay fallos de despliegue y no se envían alertas a los ingenieros de guardia. La primera indicación de este cambio suele ser un pico en el gráfico de Cost Explorer, notado solo durante revisiones financieras rutinarias.

Este silencio es intencional. El recurso continúa funcionando con normalidad, por lo que las herramientas de monitorización operativa no ven ninguna anomalía. Sin embargo, el impacto en la facturación es inmediato. Por ejemplo, un clúster de EKS que ejecuta una versión obsoleta incurre en un coste adicional de $0.50 por hora de clúster. Para un único clúster, esto supone aproximadamente $365 extra al mes. En configuraciones multi-entorno con clústeres de desarrollo, preproducción y producción en la misma versión antigua, el desperdicio mensual puede superar los $1,000.

El problema se agrava por la configuración predeterminada. Los clústeres de EKS se inscriben por defecto en el soporte extendido, y las instancias de RDS creadas vía API también están inscritas por defecto. Aunque la consola de AWS pueda mostrar la casilla de verificación como desactivada, el comportamiento subyacente de la API a menudo la habilita, llevando a estados inconsistentes entre equipos. Además, las advertencias se envían mediante correos electrónicos de AWS Health a los contactos de la cuenta, que frecuentemente son ignorados en buzones compartidos dentro de grandes organizaciones.

Detalles clave

• Recargo de EKS: Cuesta $0.50 adicionales por hora de clúster, sumando un total de $0.60 por hora. El soporte extendido dura 12 meses antes de una actualización automática forzada.
• RDS y Aurora: Cobra $0.10 adicionales por vCPU-hora durante los dos primeros años, aumentando a $0.20 por vCPU-hora en el tercer año. Esto se aplica a instancias primarias, réplicas en espera (standbys) y réplicas de lectura.
• ElastiCache: Añade un recargo del 80% sobre el precio bajo demanda (On-Demand) del nodo durante los dos primeros años, aumentando al 160% en el tercer año. Los descuentos por reservas no se aplican a esta prima.
• Inscripción Automática: Muchos servicios optan por incluirse por defecto vía API, lo que significa que los recursos se cobran incluso si el equipo tenía la intención de actualizarlos o retirarlos.
• Transición Silenciosa: No se disparan alertas operativas. La única notificación es a través de correos electrónicos de AWS Health, que a menudo se pasan por alto en configuraciones multi-cuenta.
• Próximas Fechas Límite: A partir de noviembre de 2026, EKS 1.34 entra en Soporte Extendido el 2 de diciembre, y RDS PostgreSQL 14 sigue el 28 de febrero de 2027.

Contexto

El Soporte Extendido es una fase del ciclo de vida que cubre la brecha entre el fin del soporte estándar y el retiro obligatorio. Históricamente, los proveedores de nube podrían haber forzado actualizaciones o dejado a los usuarios vulnerables. AWS ahora ofrece un período de gracia pagado, permitiendo a los equipos más tiempo para planificar migraciones. Sin embargo, esta conveniencia tiene un precio elevado. Los recargos están diseñados para incentivar actualizaciones rápidas, pero dependen de que los clientes noten el cambio en la facturación.

Entender la distinción entre soporte estándar y extendido es crítico para la presupuestación. El soporte estándar incluye parches regulares y actualizaciones menores. El soporte extendido proporciona únicamente correcciones críticas de seguridad. Una vez finalizado el soporte extendido, AWS realiza una actualización automática según su propio calendario, lo que puede introducir cambios incompatibles (breaking changes) si la aplicación no está lista. Esto hace que la gestión proactiva sea esencial para evitar tanto el desperdicio financiero como el riesgo operativo.

Por qué importa

Para los equipos que alojan sus propios servidores o gestionan infraestructuras cloud complejas, estos costes ocultos erosionan la eficiencia del presupuesto. Una sola instancia de RDS olvidada con múltiples réplicas de lectura puede generar cientos de dólares en cuotas mensuales innecesarias. Al escalar esto a decenas de servicios y cuentas, estos cargos se convierten en una fuga significativa del gasto en la nube. Los líderes de TI e ingenieros DevOps deben tratar la higiene de versiones como un control financiero, no solo como una tarea técnica.

Además, depender de las actualizaciones automáticas al final del período extendido es arriesgado. AWS actualiza el plano de control o el motor en su cronograma, lo cual puede no alinearse con su ciclo de lanzamientos. Esto puede llevar a problemas de compatibilidad con el código de la aplicación o dependencias. Al ignorar estas fechas límite, los equipos intercambian ventanas de mantenimiento predecibles por migraciones forzadas caóticas bajo presión, pudiendo causar tiempos de inactividad (downtime).

Qué puede hacer

• Ejecute un Script de Auditoría: Utilice un script Python de solo lectura con boto3 para escanear todas las regiones y cuentas. Identifique recursos en Soporte Extendido y calcule el recargo mensual para cada uno.
• Compruebe la Preparación para Actualizar EKS: Ejecute aws eks list-insights para identificar APIs obsoletas que bloquean las actualizaciones. Actualice complementos (add-ons) y planos de control una versión menor a la vez.
• Exclúyase Si Es Necesario: Para entornos no críticos, deshabilite el Soporte Extendido vía API para forzar una actualización automática en lugar de pagar tarifas. Use --engine-lifecycle-support open-source-rds-extended-support-disabled para RDS.
• Configure Alertas de EventBridge: Cree una regla para tipos de evento AWS_*_PLANNED_LIFECYCLE_EVENT. Dirija estos eventos a un tema SNS para notificar a su equipo vía Slack o correo electrónico antes de que lleguen las fechas.
• Considere Valkey para ElastiCache: Si actualizar Redis es complejo, considere migrar a Valkey, que actualmente está fuera del ciclo de Soporte Extendido y ofrece precios de lista más bajos.
• Revise los Costes Multi-AZ: Recuerde que los recargos se aplican a cada réplica y standby. Inclúyalos en sus cálculos de costes al planificar las actualizaciones.