Cuando un equipo decide llevar su base de datos a AWS, la pregunta aparece casi de inmediato: ¿Amazon RDS o Amazon Aurora? Las dos son bases de datos relacionales administradas, las dos liberan a tu equipo de parchar servidores y administrar backups, y las dos aparecen juntas en la consola. La diferencia no está en “cuál es mejor”, sino en qué problema resuelve cada una — y elegir sin criterio se paga después en costo, en disponibilidad o en una modernización que se vuelve más difícil.
Esta guía compara ambas opciones con criterios de decisión para gerentes de tecnología, no solo para DBAs.
Qué es cada una, en una frase
- Amazon RDS (Relational Database Service) es el servicio administrado de AWS para correr motores de base de datos conocidos: PostgreSQL, MySQL, MariaDB, SQL Server, Oracle y Db2. El motor es el mismo que usarías en tu propio servidor; AWS opera la infraestructura.
- Amazon Aurora es un motor de base de datos construido por AWS, compatible con PostgreSQL y MySQL, con una arquitectura de almacenamiento distinta: los datos se replican en seis copias distribuidas en tres zonas de disponibilidad, y el almacenamiento crece automáticamente según lo que uses.
La confusión es comprensible: Aurora se administra desde RDS y comparte gran parte de la operación. Pero por debajo son arquitecturas diferentes, y esa diferencia es la que decide.
Los criterios que realmente deciden
1. El motor que tu aplicación necesita
Este criterio filtra antes que cualquier otro. Si tu aplicación corre sobre SQL Server, Oracle, Db2 o MariaDB y no está en tus planes cambiarla, la decisión ya está tomada: Amazon RDS es el camino administrado para esos motores. Aurora solo habla PostgreSQL y MySQL.
La excepción importante es SQL Server, porque ahí existe una tercera vía: Babelfish for Aurora PostgreSQL, una capacidad incluida en Aurora que entiende T-SQL y el protocolo de SQL Server. Con Babelfish, muchas aplicaciones escritas para SQL Server pueden conectarse a Aurora PostgreSQL con cambios mínimos — y esa ruta convierte una decisión técnica en una decisión financiera, porque el licenciamiento comercial deja de crecer con tu negocio. En Caleidos es una de las rutas de modernización que más evaluamos.
2. Disponibilidad: cuánto te cuesta un minuto caído
RDS resuelve alta disponibilidad con despliegues Multi-AZ: una instancia de respaldo en otra zona de disponibilidad que toma el control si la principal falla, con un failover que típicamente toma uno a dos minutos.
Aurora parte de otra base: como el almacenamiento ya vive replicado en seis copias sobre tres zonas, las réplicas comparten el mismo volumen de datos y el failover típico toma menos de un minuto — con réplicas disponibles, suele bajar de 30 segundos. Además admite hasta 15 réplicas de lectura con retraso mínimo, que también sirven como destino de failover.
Para un sistema interno con tolerancia a una pausa breve, Multi-AZ en RDS es suficiente y más simple. Para un canal digital donde cada minuto caído es venta perdida — banca, retail, pagos —, la arquitectura de Aurora justifica su lugar.
3. Rendimiento y patrón de carga
AWS documenta que Aurora puede entregar hasta cinco veces el throughput de MySQL estándar y hasta tres veces el de PostgreSQL estándar sobre hardware equivalente. Si tu base ya está cerca del límite de su instancia en RDS, Aurora es la vía de crecimiento natural antes de particionar o rediseñar.
El patrón de carga también pesa: para demanda variable o impredecible — picos estacionales, multi-tenant, productos en crecimiento —, Aurora Serverless v2 ajusta la capacidad de forma automática y granular, y evita pagar capacidad ociosa. RDS, en cambio, se dimensiona por instancia: simple y predecible para cargas planas.
4. Costo: tarifa unitaria vs costo de la carga completa
Comparar el precio por hora de una instancia Aurora contra su equivalente RDS lleva a una conclusión incompleta. Aurora suele costar más por instancia, pero entrega más rendimiento por instancia, escala almacenamiento sin sobreaprovisionar y sus réplicas no duplican el volumen de datos. En cargas intensivas en operaciones de lectura/escritura, la configuración Aurora I/O-Optimized elimina el cobro por operaciones de E/S y vuelve el costo predecible.
La comparación correcta es el costo total de tu carga con el nivel de disponibilidad que tu negocio exige — y esa cuenta cambia según el caso. Es el mismo enfoque que aplicamos en FinOps: medir sobre la carga real, no sobre la lista de precios.
Aurora vs RDS: la tabla de decisión
| Criterio | Amazon RDS | Amazon Aurora |
|---|---|---|
| Motores | PostgreSQL, MySQL, MariaDB, SQL Server, Oracle, Db2 | Compatible con PostgreSQL y MySQL |
| Alta disponibilidad | Multi-AZ, failover típico de 1–2 minutos | 6 copias en 3 zonas, failover típico < 1 minuto |
| Réplicas de lectura | Réplicas con su propia copia de datos | Hasta 15 réplicas sobre el mismo volumen |
| Almacenamiento | Se aprovisiona y se ajusta | Crece automáticamente con el uso |
| Escalado a demanda | Por cambio de instancia | Serverless v2 granular y automático |
| Ruta desde SQL Server | Motor SQL Server nativo (licencia comercial) | Babelfish: T-SQL sobre PostgreSQL |
| Perfil típico | Cargas estables, motores comerciales, simplicidad | Alto throughput, disponibilidad exigente, demanda variable |
Cuándo conviene cada una
Elige Amazon RDS cuando tu carga es estable y de tamaño moderado, cuando dependes de un motor que Aurora no soporta (SQL Server, Oracle, Db2, MariaDB) sin planes de cambiarlo, o cuando la predictibilidad y la simplicidad operativa pesan más que el rendimiento máximo.
Elige Amazon Aurora cuando la disponibilidad es crítica para el negocio, cuando el throughput de tu base ya es una limitante, cuando tu demanda es variable y Serverless v2 evita capacidad ociosa, o cuando quieres dejar atrás el licenciamiento de SQL Server usando Babelfish como puerta de modernización.
Y recuerda que no es una decisión irreversible: si hoy estás en RDS con MySQL o PostgreSQL, la ruta a Aurora está pavimentada — snapshot o réplica que se promueve, sin reescribir la aplicación.
Cómo lo abordamos en Caleidos
En Caleidos, como AWS Advanced Tier Services Partner, esta decisión es parte de nuestra práctica de datos y analítica y de modernización: dimensionamos la carga real, calculamos el costo total de cada escenario con el nivel de disponibilidad que el negocio exige, y cuando hay licenciamiento comercial de por medio evaluamos Babelfish y las rutas de conversión antes de aceptar ese costo como fijo. Si quieres entender primero la base tecnológica, profundizamos en Amazon RDS.
¿Evaluando dónde correr tu base de datos en AWS?
Conversemos sobre tu caso: en 30 minutos te damos una lectura concreta de si tu carga encaja mejor en RDS, en Aurora, o en una ruta de modernización con Babelfish.
