Tipos y tamaños de instancias RDS: cómo elegir la clase

Para elegir el tamaño de una instancia de Amazon RDS, confirma primero qué clases admite tu motor, su versión y tu Región de AWS. Luego identifica el límite de la carga —CPU, memoria, almacenamiento o conexiones— y compara clases con métricas de un período representativo. No hay un tamaño universal para «desarrollo», «pruebas» o «producción»: la carga, el motor y el nivel de disponibilidad cambian la decisión.

Qué significan el tipo y el tamaño

Una clase de instancia de base de datos combina un tipo de clase y un tamaño. Por ejemplo, en db.r6g.2xlarge, db.r6g identifica el tipo y 2xlarge el tamaño. El tipo indica el perfil de cómputo; el tamaño define la capacidad disponible dentro de esa familia. La clase influye en CPU y memoria, además de los límites de rendimiento de red y de E/S.

La clase y el almacenamiento son decisiones relacionadas, pero distintas. Elegir una instancia más grande no aumenta automáticamente los GB asignados, las IOPS aprovisionadas ni el rendimiento del volumen. A la vez, una clase puede limitar cuánto aprovecha la base de datos del almacenamiento que configuraste. Confirma ambas partes antes de cambiar una.

Los nombres de familia que aparecen abajo son una orientación, no un catálogo de compatibilidad. Las clases disponibles cambian según motor, versión y, en algunos casos, edición del motor, Región y modalidad de despliegue. La documentación de AWS sobre clases de RDS explica su formato; la tabla de compatibilidad por motor detalla las excepciones.

Si estás empezando por el servicio, la grabación Introducción a Amazon RDS de AWS User Group CreaTicas repasa sus conceptos básicos.

En una pantalla pequeña, desliza la tabla hacia los lados para ver todas las columnas.

Tipo de clase	Cuándo conviene evaluarlo	Qué revisar
`db.m*`, uso general	Si buscas un equilibrio entre CPU y memoria para una carga relacional variada.	El consumo sostenido y los picos de la carga real.
`db.r*`, optimizada para memoria	Si la memoria es el límite: por ejemplo, cuando el conjunto de trabajo no cabe bien en memoria y aumenta la lectura desde disco.	Memoria disponible, actividad de E/S y rendimiento de consultas; no la elijas solo porque la base guarda muchos GB.
`db.c*`, optimizada para cómputo	Si la base necesita CPU sostenida y esa familia está disponible para el motor y despliegue que usas.	Compatibilidad exacta, licencias cuando correspondan y si el problema está en CPU o en consultas ineficientes.
`db.t*`, ampliable o burstable	Si la carga suele ser baja y tiene picos breves que pueden usar créditos de CPU.	La duración de los picos, el saldo de créditos y los cargos por créditos excedentes.

Algunas clases basadas en AWS Graviton usan procesadores Arm; por ejemplo, en ciertos tipos el sufijo g identifica esa plataforma. Amazon RDS administra el servidor de base de datos: la aplicación cliente sigue conectándose mediante el protocolo del motor y no necesita usar un procesador Arm por esa elección. La clase basada en Graviton debe estar disponible para la combinación concreta de motor, versión y Región, así que compruébala igual que cualquier otra. RDS no da acceso directo al host en las instancias estándar; consulta la nota sobre instancias de base de datos RDS si necesitas distinguirlas de RDS Custom.

Cómo elegir una clase paso a paso

Fija el motor, la versión y la Región. La disponibilidad de una familia no se deduce de su nombre ni de que exista en otra Región. Incluye la edición de Db2, Oracle o SQL Server cuando corresponda, y comprueba las restricciones del despliegue.
Mide una carga representativa. Observa un período que incluya la actividad habitual y los picos. Si recién comienzas, usa un entorno de prueba con datos y consultas que se parezcan a los del uso previsto; vuelve a medir antes de aplicar la elección en producción.
Busca el recurso que limita la base. CPU alta, falta de memoria, espera por disco y exceso de conexiones apuntan a causas distintas. Antes de sumar capacidad, examina consultas lentas, bloqueos, esperas y patrones de conexión.
Compara tamaños de la misma familia y después familias distintas. Cambia una variable por vez cuando hagas una comparación. Registra latencia, errores, conexiones y costo de la configuración completa bajo una carga comparable.
Decide el almacenamiento y la disponibilidad por separado. Una réplica de lectura, una implementación Multi-AZ y un volumen con IOPS aprovisionadas responden a objetivos distintos y tienen costo propio.
Planifica el cambio. Cambiar la clase de RDS puede producir una interrupción. Confirma cuándo se aplicará el cambio, el efecto sobre tus conexiones y cómo recuperará el servicio la aplicación. La tabla de cambios de configuración indica el efecto esperado por ajuste.

Para comprobar qué combinaciones están disponibles, puedes usar la consola de RDS o la operación de solo lectura describe-orderable-db-instance-options. Este ejemplo consulta PostgreSQL en us-east-1; cambia el motor y la Región por los tuyos:

aws rds describe-orderable-db-instance-options \
  --engine postgres \
  --region us-east-1 \
  --query 'OrderableDBInstanceOptions[].{Version:EngineVersion,Class:DBInstanceClass,Storage:StorageType}' \
  --output table

Sin –engine-version, la salida puede incluir varias versiones compatibles. Agrega ese parámetro con la versión exacta que planeas usar para acotar la consulta. La operación enumera opciones disponibles; no modifica recursos ni calcula su precio. Consulta la guía de AWS para verificar la compatibilidad regional y la referencia del comando de AWS CLI. La consola y la consulta describen opciones compatibles; no reemplazan una prueba de carga.

Para practicar la creación y configuración de una base RDS para MySQL, puedes seguir Práctica #5: Laboratorio práctico de Amazon RDS MySQL, de AWS User Group Caracas. Es un ejercicio con el servicio; consulta la compatibilidad actual de clases en la documentación de AWS.

Usa las métricas para encontrar el límite

Las métricas de CloudWatch ayudan a decidir qué comparar, pero un valor aislado no es una recomendación automática de cambio. Mira tendencias y picos junto con las consultas y esperas de la base. AWS publica métricas de RDS en CloudWatch; para analizar la carga de base de datos y filtrarla por esperas o sentencias SQL, consulta la guía actual de CloudWatch Database Insights para RDS.

Señal durante la carga	Qué puede indicar	Qué probar
CPU alta durante períodos prolongados o muchas sesiones esperando CPU en Database Insights	Límite de cómputo o consultas que consumen demasiado.	Revisa consultas y esperas. Si la CPU sigue siendo el límite, compara un tamaño mayor o una clase optimizada para cómputo compatible.
Poca memoria disponible, especialmente junto con intercambio o lecturas frecuentes desde disco	El motor puede estar dedicando demasiado tiempo a traer a memoria los datos consultados.	Revisa el conjunto de trabajo y compara una clase optimizada para memoria. Valida el resultado con latencia y consultas.
Aumentan la latencia y la cola de disco mientras la CPU tiene margen	El volumen o los límites de E/S pueden ser el cuello de botella.	Comprueba IOPS y rendimiento configurados, tipo de almacenamiento y límite de EBS de la clase. Aumentar la clase por sí solo no siempre resuelve el límite del volumen.
Se agotan créditos de CPU o aparecen cargos por créditos excedentes en una clase `db.t*`	Los picos duran más que lo que permite su nivel de rendimiento de referencia.	Compara la carga y el costo con una clase no burstable. Revisa `CPUCreditBalance` y `CPUSurplusCreditsCharged`.
Muchas conexiones, pero sin saturación clara de CPU, memoria o E/S	El patrón de conexión de la aplicación puede ser el problema.	Revisa límites del motor, concurrencia y conexión agrupada antes de aumentar el tamaño.

DBLoad representa sesiones activas, incluidas sesiones que esperan por recursos; por eso, no significa automáticamente que la CPU esté saturada. En Database Insights, desglosar la carga por CPU, espera y consulta ayuda a separar falta de capacidad de una consulta o un bloqueo. No cambies de clase a partir de un único promedio si la aplicación sufre en un pico breve.

Las clases burstable no son siempre la opción más económica

Las clases db.t3 y db.t4g ofrecen un nivel de rendimiento de referencia y pueden usar créditos para aumentarlo temporalmente. RDS configura ambas familias en modo Unlimited: si el uso sostenido supera los créditos que la instancia acumula, puede consumir créditos de CPU excedentes y generar cargos por esa capacidad adicional. AWS recomienda reservar las clases T para desarrollo, pruebas u otros servidores que no se usen en producción.

Antes de usar una clase burstable, mide si la base permanece con carga baja suficiente entre los picos. Revisa las métricas de créditos —se publican cada cinco minutos— y estima el costo si la carga deja de ser esporádica. Una clase T pequeña puede costar más de lo esperado si necesita sostener CPU alta. El sufijo g identifica una clase con procesador AWS Graviton; eso no cambia el modelo de créditos ni elimina la necesidad de revisar su compatibilidad.

El almacenamiento tiene su propio perfil de rendimiento

El almacenamiento de RDS es otra parte del dimensionamiento. La capacidad en GB sirve para alojar datos; IOPS y rendimiento de lectura/escritura describen operaciones. Según el motor y el tamaño del volumen, puedes elegir entre SSD de uso general y SSD de IOPS aprovisionadas:

gp3 es la opción de uso general recomendada por AWS para muchos casos. Permite configurar capacidad y rendimiento por separado dentro de los límites compatibles con el motor y el volumen.
io2 y io1 se orientan a cargas con necesidades sostenidas de I/O, baja latencia o IOPS aprovisionadas. Verifica si esa opción encaja con el patrón de E/S y si la clase puede aprovechar lo que configures.
gp2 es una generación anterior. El almacenamiento magnético está obsoleto para nuevas instancias; no lo uses como opción nueva.

AWS aclara que una clase puede impedir aprovechar todas las IOPS o todo el rendimiento provisionado del volumen si sus propios límites son menores. Revisa los límites de la clase y del motor junto con las métricas de lectura, escritura y cola; la guía de almacenamiento de RDS mantiene las opciones y restricciones actuales.

Alta disponibilidad y lecturas no son lo mismo

Una implementación Multi-AZ tradicional de una instancia RDS mantiene una réplica en espera para alta disponibilidad y failover. Esa instancia en espera no atiende consultas de lectura. Si el objetivo es quitarle consultas a la instancia principal, evalúa réplicas de lectura o un clúster Multi-AZ compatible con el motor. Las réplicas de lectura pueden tener retraso y se facturan como instancias de base de datos; no son un reemplazo idéntico para el failover síncrono.

Comprueba qué despliegue tienes antes de tomar una decisión: la opción denominada Multi-AZ no identifica por sí sola una topología que escale lecturas. Revisa la guía de despliegues Multi-AZ de instancia, clústeres Multi-AZ y réplicas de lectura.

Compara el costo de la configuración completa

El precio de una clase depende, entre otros factores, de la Región, el motor, su edición y la opción de licencia. A la tarifa de cómputo de cada instancia se suman los cargos aplicables por almacenamiento, IOPS o rendimiento aprovisionados, Multi-AZ, réplicas, copias de seguridad y transferencia de datos. No compares clases con precios de otra Región ni asumas que una clase con menos CPU siempre cuesta menos para completar la misma carga.

Usa los valores actuales de precios de Amazon RDS y la Calculadora de precios de AWS para estimar tu configuración. Selecciona el motor y la Región, e incluye la clase, el almacenamiento y las opciones de disponibilidad que comparas. La estimación refleja los parámetros que ingreses; valida el resultado con el uso y la factura reales. Para investigar cambios de gasto, consulta la guía de Cost Explorer. Si necesitas un panel propio con datos detallados de facturación, la guía de CUR 2.0, Athena y QuickSight muestra otro recorrido y sus requisitos.

Amazon Aurora se dimensiona por separado

Aurora forma parte de Amazon RDS, pero usa una arquitectura de clúster. En Aurora provisionado eliges clases para las instancias de escritura y lectura del clúster. Aurora Serverless v2 usa la clase db.serverless y un rango de capacidad en Aurora Capacity Units (ACU); no es una instancia db.t*, db.m* o db.r* con escalado automático.

La compatibilidad y los rangos de capacidad de Serverless v2 dependen de la versión del motor y de la Región. Compara el costo y el comportamiento de escalado con la carga que esperas: ni Aurora provisionado ni Serverless v2 son siempre más rápidos o más económicos que una instancia RDS. La guía de AWS detalla Aurora Serverless; para elegir entre los motores relacionales, sigue la comparación de Amazon RDS y Aurora.

Grupos, canales y encuentros

Puedes aprender con grabaciones prácticas y contrastar decisiones con grupos generales de AWS. No todos los grupos se especializan en bases de datos; revisa su agenda, modalidad y condiciones de inscripción antes de participar.

El grupo de Telegram de AWS User Group Caracas sirve para conversar sobre AWS con esa comunidad; es un canal comunitario general, no el soporte oficial de AWS.
Si estás en México, la agenda de AWS User Group Ciudad de México incluye encuentros generales sobre arquitectura, datos y otros temas. En Argentina, puedes ver las actividades del AWS User Group Córdoba. El portal de AWS User Group Perú reúne grupos locales, talleres, grupos de estudio y recursos; AWS Women Colombia publica encuentros y materiales en español de la comunidad.
Si prefieres buscar un grupo de otro país, consulta el directorio de AWS User Groups de AWS Builder Center.
Al momento de esta revisión, AWS Student Builder Group del Higher Technological Institute of Atlixco anunció el encuentro presencial Amazon RDS: Bases de datos administradas, para el 29 de octubre de 2026, de 12:00 a 14:00 (hora de Atlixco). La ficha describe la creación y configuración de una base SQL. Consulta allí los requisitos, el costo, los cupos y la ubicación exacta, que pueden cambiar.

Preguntas frecuentes

¿Cómo sé si me falta CPU, memoria o rendimiento de almacenamiento?

Correlaciona CloudWatch, Database Insights y la latencia que observa la aplicación. Una CPU alta sostenida, memoria baja o espera por disco orientan la prueba, pero también pueden señalar consultas, bloqueos o concurrencia que conviene corregir. Repite la comparación bajo una carga parecida antes de decidir.

¿Multi-AZ sirve para atender más lecturas?

No en el despliegue tradicional Multi-AZ de instancia: su standby sirve para failover, no para consultas. Para distribuir lecturas, comprueba compatibilidad de réplicas de lectura o del clúster Multi-AZ con tu motor y versión.

¿Puedo cambiar el tamaño después?

Sí. Puedes modificar la clase, pero el cambio puede causar una interrupción; define la ventana de aplicación, verifica la compatibilidad de la nueva clase y comprueba que la aplicación reconecte correctamente.