Que es Amazon Aurora PostgreSQL
Amazon Aurora PostgreSQL es una base de datos relacional administrada por AWS, totalmente compatible con PostgreSQL estandar. La diferencia fundamental respecto a RDS PostgreSQL convencional esta en la arquitectura: Aurora fue disenado como un servicio nativo de nube, con almacenamiento distribuido y replicacion integrada desde el inicio.
En la practica, esto significa que no es simplemente un PostgreSQL corriendo en una instancia EC2 administrada. AWS rediseno la capa de almacenamiento para aprovechar la infraestructura distribuida, lo que resulta en hasta 3x mas throughput que una instalacion PostgreSQL estandar en hardware equivalente.
Aurora acepta el mismo driver, las mismas extensiones y los mismos comandos SQL que ya usas con PostgreSQL. La migracion de codigo es, en la mayoria de los casos, transparente. La diferencia esta en como los datos se almacenan, replican y recuperan.
Arquitectura Interna de Aurora
Separacion de computo y almacenamiento
En RDS PostgreSQL tradicional, computo y almacenamiento estan acoplados en la misma instancia. Aurora separa estas dos capas: las instancias de base de datos procesan queries, mientras el almacenamiento vive en un cluster distribuido independiente.
Esta separacion tiene consecuencias importantes:
- Escalar lecturas no requiere duplicar almacenamiento. Las replicas de lectura comparten el mismo volumen de datos.
- El almacenamiento crece automaticamente de 10 GiB hasta 128 TiB, sin necesidad de aprovisionar disco manualmente.
- El failover es mas rapido porque la nueva instancia no necesita reconstruir datos locales.
Almacenamiento distribuido y tolerancia a fallos
Aurora mantiene 6 copias de los datos distribuidas en 3 Availability Zones. Este modelo tolera:
- Perdida de hasta 2 copias sin impacto en la capacidad de escritura
- Perdida de hasta 3 copias sin impacto en la capacidad de lectura
Cada operacion de escritura se confirma cuando 4 de las 6 copias responden (quorum de escritura). Para lectura, bastan 3 copias. Esto elimina la necesidad de configuraciones complejas de replicacion sincrona que serian necesarias para alcanzar un nivel similar de durabilidad en RDS.
Log-Based Storage
Una diferencia arquitectural significativa: Aurora envia unicamente los registros WAL (Write-Ahead Log) a la capa de almacenamiento. Las paginas de datos se materializan directamente en el storage distribuido, eliminando los checkpoints tradicionales.
En PostgreSQL estandar, los checkpoints son operaciones pesadas que pausan la escritura para sincronizar paginas sucias del buffer pool con el disco. Sin esta necesidad, Aurora mantiene un throughput mas estable, especialmente bajo carga intensa de escritura.
El resultado directo: las recuperaciones de crash son casi instantaneas y el lag de replicacion entre la instancia primaria y las replicas de lectura se mantiene tipicamente por debajo de 100ms, ya que las replicas consumen directamente del mismo volumen de almacenamiento. Todas las transacciones mantienen propiedades ACID completas.
Comparacion: Aurora PostgreSQL vs RDS PostgreSQL
| Aspecto | Aurora PostgreSQL | RDS PostgreSQL |
|---|---|---|
| Almacenamiento | Distribuido, 6 copias en 3 AZs, hasta 128 TiB | EBS por instancia, hasta 64 TiB |
| Replicacion | Mismo volumen, lag < 100ms | Basada en WAL, lag de segundos a minutos |
| Failover | Multi-AZ nativo, ~30 segundos | Multi-AZ opcional, 1-2 minutos |
| Replicas de lectura | Hasta 15 replicas | Hasta 5 replicas |
| Rendimiento | Sin checkpoints locales, hasta 3x mas throughput | PostgreSQL estandar, dependiente de tuning |
| Global Database | Soporte nativo, replicacion cross-region | No disponible |
| Backups | Continuos e incrementales en S3 | Snapshots diarios |
| Costo base | ~20% mas caro (instancia + I/O) | Mas economico para cargas predecibles |
El punto central de esta comparacion no es que Aurora sea universalmente superior. Resuelve problemas especificos — alta disponibilidad, replicacion masiva de lectura, failover rapido — que en RDS requeririan configuracion manual significativa y aun asi no alcanzarian el mismo nivel de confiabilidad.
Aurora Serverless v2
Aurora Serverless v2 elimina la necesidad de elegir y administrar clases de instancias. La base de datos escala automaticamente la capacidad de computo segun la demanda real.
Como funciona
La unidad de medida es el ACU (Aurora Capacity Unit). Cada ACU equivale a aproximadamente 2 GiB de RAM con CPU proporcional. El cluster escala continuamente entre los limites configurados:
- Minimo: 0.5 ACU
- Maximo: 128 ACUs
El escalado ocurre de forma granular, en incrementos de 0.5 ACU, con ajustes en sub-segundos y sin interrupcion de conexiones o queries en curso.
Pricing
La facturacion es por ACU-hora consumida. En la region de Sao Paulo (sa-east-1), el costo es aproximadamente $0.16 a $0.18 por ACU-hora.
Como referencia:
| Escenario | ACUs estimados | Costo mensual aproximado |
|---|---|---|
| Aplicacion liviana, horario comercial | 2-4 ACUs (8h/dia) | ~$80-150 |
| API con picos nocturnos | 4-16 ACUs (variable) | ~$300-700 |
| Workload constante y pesado | 16-32 ACUs (24/7) | ~$1.900-4.200 |
Serverless v2 es particularmente ventajoso para cargas impredecibles. Si la base de datos queda ociosa por la noche, se reduce al minimo configurado. Si un pico de trafico llega a las 3 de la manana, escala en segundos sin intervencion manual.
Serverless v2 vs instancias provisionadas
Para workloads con carga constante y predecible, las instancias provisionadas siguen siendo mas economicas. Serverless v2 compensa cuando la variabilidad de la carga es suficientemente alta para justificar pagar un premium por ACU a cambio de no mantener capacidad ociosa.
Escalabilidad
Escalabilidad vertical
Como en RDS, puedes cambiar la clase de instancia (db.r6g.large, db.r6g.xlarge, etc.) para aumentar CPU y memoria. Esta operacion causa un breve downtime, generalmente de pocos minutos.
Escalabilidad horizontal
Aurora soporta hasta 15 replicas de lectura en el mismo cluster. Todas comparten el mismo volumen de almacenamiento, asi que agregar una replica no duplica los datos.
Aurora Auto Scaling ajusta automaticamente el numero de replicas de lectura basandose en metricas como uso de CPU o cantidad de conexiones. Defines la capacidad minima y maxima, y Aurora crea o elimina replicas segun la demanda.
aws application-autoscaling register-scalable-target \
--service-namespace rds \
--resource-id cluster:mi-cluster-aurora \
--scalable-dimension rds:cluster:ReadReplicaCount \
--min-capacity 1 \
--max-capacity 8Aurora Global Database
Para aplicaciones con usuarios en multiples regiones, Aurora Global Database replica los datos entre regiones AWS con latencia inferior a 1 segundo. La region primaria procesa escrituras, mientras las regiones secundarias sirven lecturas locales con baja latencia.
En caso de desastre regional, la promocion de una region secundaria a primaria toma menos de 1 minuto — sin necesidad de restaurar backups.
Cuando Migrar a Aurora
Elige Aurora cuando
- La alta disponibilidad es critica: failover en ~30 segundos y replicacion con lag minimo son requisitos de negocio, no solo deseables.
- Lectura pesada: la aplicacion tiene muchas mas lecturas que escrituras y necesita mas de 5 replicas de lectura.
- Cargas variables: el trafico oscila significativamente (Serverless v2) o la base de datos crece rapidamente (auto-expansion de almacenamiento).
- Multi-region: usuarios en diferentes regiones necesitan lecturas con baja latencia (Global Database).
RDS PostgreSQL es suficiente cuando
- Workload pequeno y predecible: una aplicacion con pocos usuarios y carga constante no se beneficia de la arquitectura distribuida de Aurora.
- Presupuesto limitado: RDS es 10-20% mas barato para la misma clase de instancia. Si el costo mensual importa, RDS puede ser suficiente.
- El failover no es critico: si la aplicacion tolera 1-2 minutos de indisponibilidad durante failover, el Multi-AZ de RDS es adecuado.
- Compatibilidad estricta: en casos raros, extensiones o versiones especificas de PostgreSQL pueden estar disponibles en RDS antes que en Aurora.
Camino de migracion
AWS ofrece migracion nativa con downtime minimo:
- Crear un snapshot de la instancia RDS PostgreSQL
- Restaurar el snapshot como un cluster Aurora PostgreSQL
- Usar AWS DMS (Database Migration Service) para replicacion continua durante la transicion
- Redirigir la aplicacion al endpoint de Aurora
- Validar y dar de baja la instancia RDS original
Para bases de datos pequenas, el proceso completo puede tomar menos de 1 hora. Para bases de datos de cientos de GiB, planifica una ventana de mantenimiento adecuada.
Conclusion
Aurora PostgreSQL no es un reemplazo automatico para RDS. Es una opcion arquitectural que tiene sentido cuando los requisitos de disponibilidad, replicacion y escalabilidad justifican el costo adicional. Para la mayoria de las aplicaciones en etapa inicial o con carga moderada, RDS PostgreSQL sigue siendo la eleccion mas pragmatica y economica.
La recomendacion practica: comienza con RDS PostgreSQL. Monitorea las metricas de replicacion, failover y throughput. Cuando esos indicadores muestren que RDS esta alcanzando sus limites — o cuando la criticidad del negocio exija garantias mas fuertes — migra a Aurora con datos concretos que justifiquen la decision.