RDS MySQL 8.0 ya cobra Extended Support: qué hacer

En pocas palabras: Desde el 1 de agosto de 2026, AWS cobra Extended Support en cada base RDS MySQL 8.0 que lo tenga activado, porque el soporte estándar terminó el 31 de julio. En Frankfurt cuesta US$0,122 por vCPU-hora; una db.m6g.large Multi-AZ paga unos US$356 más por mes.

Desde el 1 de agosto de 2026, AWS cobra RDS MySQL 8.0 Extended Support en cada base que lo tiene activado, porque el soporte estándar terminó el 31 de julio. En una db.m6g.large Multi-AZ de Frankfurt son unos US$356 más por mes, según el análisis de CODELEVEL.

RDS Extended Support es un servicio pago de Amazon RDS que deja seguir usando una versión mayor de un motor de base de datos después de que termina su soporte estándar. Incluye parches para vulnerabilidades críticas y altas, correcciones de bugs críticos y casos de soporte dentro del SLA estándar, hasta 3 años después, según la documentación de AWS. Al 8 de octubre de 2026, el recargo afecta a RDS for MySQL 8.0. Aurora MySQL 3 tiene soporte estándar hasta el 30 de abril de 2028.

¿Qué es RDS MySQL 8.0 Extended Support y cuándo empezó a cobrarse?

Es el esquema pago que AWS aplica cuando una versión mayor pierde el soporte estándar. En MySQL 8.0 eso pasó el 31 de julio de 2026 y el cargo corre desde el 1 de agosto. Según CODELEVEL, la API, la CLI y Terraform lo activan por defecto, mientras que en la consola hay que tildarlo a mano. Ya figura en las facturas de agosto y septiembre.

La documentación de AWS confirma el mecanismo general: si inscribiste la base al crearla o restaurarla, RDS la anota en Extended Support al vencer el soporte estándar, sin cambiar el motor ni afectar el uptime. Ese detalle del “por defecto” en API y Terraform sale de la fuente secundaria, no de la página de AWS. Mi lectura: si tenés bases viejas creadas con Terraform, empezá a buscar por ahí.

¿Cuánto cuesta Extended Support de RDS para MySQL 8.0?

En Frankfurt, con la lista de precios de AWS del 6 de octubre de 2026 que cita CODELEVEL, son US$0,122 por vCPU-hora durante los primeros dos años, unos US$89 por vCPU al mes. Desde el 1 de agosto de 2028 la tarifa se duplica a US$0,244 (unos US$178 por vCPU al mes, cuenta mía). Los precios son netos.

• El standby se cobra. En Multi-AZ, primario y standby se facturan por separado, porque cada uno tiene el mismo tipo de instancia y los mismos vCPU, como explica el blog de bases de datos de AWS.
• Un caso concreto. Una db.m6g.large Multi-AZ tiene 2 vCPU, pero se facturan 4. La instancia sale unos US$264 al mes y Extended Support suma US$356. En agosto y septiembre, unos US$714 extra.
• Las Reserved Instances no ayudan. Según CODELEVEL, sus descuentos no aplican a Extended Support.

Ojo con extrapolar. El mismo blog de AWS muestra para us-east-1 una db.r5.xlarge Single-AZ de 4 vCPU a US$292 al mes en los años 1 y 2, o sea US$73 por vCPU. No es comparable de forma directa (otra región, otra fuente), pero confirma que la tarifa cambia según la región. No hay datos acá para otras regiones, así que no los invento. Ya lo cubrimos antes en la guía para migrar a MySQL 8.4 LTS.

¿Cómo ver el cargo en la factura y qué bases lo pagan?

En Cost Explorer, escribí ExtendedSupport en el filtro Usage Type y seleccioná todos los resultados. El cargo es una línea aparte, junto a las horas de instancia y el almacenamiento. En Frankfurt, el usage type de MySQL 8.0 es EUC1-ExtendedSupport:Yr1-Yr2:MySQL8.0.

Ese filtro también atrapa versiones más viejas. MySQL 5.7 se factura a la tarifa del tercer año desde el 1 de marzo de 2026, según la misma fuente. Para saber qué bases pagan, corré esto en cada región:

aws rds describe-db-instances --region eu-central-1 --query "DBInstances[?Engine=='mysql'].[DBInstanceIdentifier,EngineVersion,MultiAZ,EngineLifecycleSupport]" --output table

Una fila 8.0.x con open-source-rds-extended-support en la última columna es una base con recargo. Esa consulta cubre instancias de MySQL. Para Aurora y clusters Multi-AZ, la documentación indica que el parámetro se maneja a nivel cluster.

Propuesta editorial para verificar (no es de ninguna de las fuentes): sumá los vCPU facturables de las bases listadas, standby incluido, y multiplicalos por la tarifa de tu región. Si el total no se parece a lo que muestra Cost Explorer, buscá bases en otras regiones o réplicas que se te pasaron. Te puede servir nuestra cobertura del bug de MySQL 8.0.38 en cPanel.

¿Qué pasa si desactivo Extended Support en una base MySQL 8.0?

RDS la actualiza sola a la siguiente versión mayor soportada, que acá es 8.4. Lo dice la documentación de AWS para bases que ya pasaron su fin de soporte estándar. El cambio del parámetro EngineLifecycleSupport se aplica de inmediato, pero la actualización de motor que dispara tiene un riesgo: es posible que la aplicación no esté probada contra 8.4.

Es el típico “ahorro” que sale caro si lo hacés un viernes. El cargo se corta recién cuando la base llega a una versión soportada, así que el flag solo sirve como parte de un plan de migración, nunca como atajo.

¿Cómo migrar RDS MySQL 8.0 a 8.4 sin romper la aplicación?

Con un blue/green deployment hacia MySQL 8.4, que es lo que recomienda AWS. El destino no es negociable: según CODELEVEL, las versiones más nuevas solo existen en el entorno Database Preview, que AWS no permite en producción. A octubre de 2026, la página de versiones de AWS lista 9.5, 9.6, 9.7 y 26.7 como preview.

Blue/green: la ruta recomendada

RDS crea una copia, replica los cambios de producción en ella y vos la subís a 8.4 para probar. El green es de solo lectura y tiene que seguir así: si escribís ahí, rompés la replicación y esos datos pueden llegar a producción tras el switch-over. Las pruebas con escritura van contra una base restaurada de un snapshot.

El corte tarda menos de un minuto según CODELEVEL, y menos de cinco segundos según AWS (RDS corta las conexiones existentes mientras tanto). Después, la base vieja queda como …-old1 en 8.0 y AWS sigue cobrando la instancia y Extended Support. Borrala cuando ya no necesites la vuelta atrás. Más contexto en las últimas actualizaciones de SQL Server en RDS.

In-place: más simple, con corte

Dura unos 10 minutos con la base caída. CODELEVEL dice que la documentación no describe vuelta a 8.0 tras un upgrade exitoso, y AWS aclara que RDS toma un snapshot previo que podés usar si algo sale mal. En Multi-AZ se actualizan primario y standby a la vez.

Qué revisar antes de subir a 8.4

• Prechecks. Leé PrePatchCompatibility.log en la copia. RDS cancela el upgrade si falla alguno, pero solo valida objetos de la base, no la lógica de tu aplicación.
• Autenticación. Las fuentes no coinciden en el matiz. CODELEVEL dice que los usuarios nuevos usan caching_sha2_password y los existentes conservan mysql_native_password. AWS dice que mysql_native_password queda deshabilitado por defecto en 8.4. Auditá tus cuentas y probá conectar con drivers reales.
• Claves foráneas. restrict_fk_on_non_standard_key viene activo y bloquea claves sobre índices no únicos o parciales. Mirá tus migraciones de esquema.
• Replicación. SHOW MASTER STATUS pasa a SHOW BINARY LOG STATUS, así que revisá scripts y monitoreo.
• Defaults de InnoDB. Por ejemplo, innodb_adaptive_hash_index pasa de ON a OFF, según AWS. Comparar los tiempos de tus consultas más pesadas es la prueba que más vale.

Sobre el orden: empezá por la base con más vCPU, standby incluido, porque el cargo escala con eso. Ejemplo hipotético: una base Single-AZ de 8 vCPU paga unos US$712 al mes de recargo (8 × US$89), el doble que la db.m6g.large Multi-AZ del ejemplo, así que va primera. CODELEVEL sugiere hacerlo en octubre de 2026, porque cada mes de demora cuesta unos US$356 en el caso testigo. Aurora MySQL 3 tiene hasta el 30 de abril de 2028 y conviene pasarlo a 8.4 durante 2027. Y si alguna base chica está en RDS solo por costumbre, tal vez valga mirar hosting y servidores en Argentina, como los de donweb.com.

¿Qué está confirmado y qué no?

• Confirmado por AWS. Extended Support dura hasta 3 años después del fin del soporte estándar, se puede cambiar con EngineLifecycleSupport y desactivarlo en una base vencida la actualiza a la siguiente versión mayor. El soporte estándar de 8.0 vence el 31 de julio de 2026.
• Reportado solo por CODELEVEL. Los precios de Frankfurt, el default en API y Terraform, el recargo en las facturas de agosto y septiembre, la exclusión de las Reserved Instances y el 31 de julio de 2029 para 8.4.
• Sin confirmar. Tarifas de otras regiones y tu monto real. Si el techo de 3 años cuenta desde el 31 de julio de 2026, sería julio de 2029 (inferencia mía, verificala en la tabla de AWS).

Errores comunes

• Apagar el flag sin probar. Corregilo: hacé primero el blue/green y recién ahí actualizá.
• Contar solo el primario. El standby paga igual. Calculá sobre todos los vCPU.
• Dejar vivo el …-old1. Sigue facturando instancia y recargo. Borralo cuando cierres el plan de vuelta atrás.
• Revisar una sola región. El comando de CLI corre por región, así que repetilo en cada una.

Preguntas Frecuentes

¿Cuánto cuesta RDS Extended Support para MySQL 8.0?

En Frankfurt cuesta US$0,122 por vCPU-hora los primeros dos años, unos US$89 por vCPU al mes, y US$0,244 desde el 1 de agosto de 2028. En Multi-AZ se facturan los vCPU del primario y del standby. Otras regiones tienen tarifas distintas.

¿Cómo veo el cargo de Extended Support en Cost Explorer?

Filtrá Usage Type por ExtendedSupport y seleccioná todos los resultados. En Frankfurt, MySQL 8.0 aparece como EUC1-ExtendedSupport:Yr1-Yr2:MySQL8.0. El filtro también muestra versiones viejas, como MySQL 5.7.

¿Cómo desactivo Extended Support en RDS?

Modificá EngineLifecycleSupport con la CLI o la API de RDS; el cambio es inmediato. En una base 8.0 vencida, RDS la actualiza a 8.4, así que antes probá la aplicación en una copia.

¿Cuándo termina el soporte estándar de MySQL 8.0 en Amazon RDS?

Terminó el 31 de julio de 2026, según AWS. Los parches de seguridad siguen solo bajo Extended Support, con versiones como 8.0.46-RDS.20260908.

¿Cómo actualizo RDS de MySQL 8.0 a 8.4?

Usá un blue/green deployment: subí la copia green a 8.4, probá tu aplicación contra ella y hacé el switch-over. Revisá PrePatchCompatibility.log y los cambios de autenticación, claves foráneas y replicación.

Conclusión

El recargo es real, está documentado en su mecanismo y crece: se duplica en agosto de 2028. Con los datos disponibles no podés concluir tu monto exacto ni el de otras regiones, pero sí qué hacer. Listá las bases afectadas, calculá el costo con vCPU de primario y standby, y migrá primero la más grande a 8.4 con blue/green. Cada mes de espera suma costo sin sumar nada a cambio.

Fuentes

• Amazon RDS Extended Support – documentación oficial de AWS
• MySQL on Amazon RDS versions – fechas y versiones, documentación de AWS
• Upgrade strategies for Amazon RDS for MySQL 8.0 to 8.4 – blog de AWS
• RDS has been charging extra for MySQL 8.0 since August – análisis de CODELEVEL