AWS no es la nube: IaaS, PaaS y Serverless existen fuera de Amazon

1. IaaS, PaaS y FaaS: de qué estamos hablando

Antes de entrar en ejemplos concretos, vale la pena aclarar tres modelos clave que vas a escuchar todo el tiempo cuando se habla de nube:

• IaaS (Infrastructure as a Service)
  Aquí básicamente te alquilan “máquinas” y redes.
  Tú te encargas de casi todo: sistema operativo, runtime, despliegues, seguridad básica.

  • Ejemplos: EC2 en AWS, VPS clásicos como DigitalOcean, Linode, Hetzner, OVH, Contabo, etc.

• PaaS (Platform as a Service)
  En lugar de pensar en servidores, piensas en aplicaciones.
  Subes tu código o conectas tu repositorio y la plataforma se encarga de servidores, escalado básico, certificados SSL, etc.

  • Ejemplos: Heroku, Render, Railway, Fly.io, DigitalOcean App Platform, Supabase, e incluso cosas de AWS como Elastic Beanstalk o App Runner.

• FaaS (Function as a Service) / Serverless
  Aquí no gestionas servidores ni aplicaciones completas, sino funciones que se ejecutan bajo demanda.
  Pagas por invocaciones y tiempo de ejecución, y el proveedor se encarga de toda la infraestructura detrás.

  • Ejemplos: AWS Lambda, Cloudflare Workers, Vercel Functions, Netlify Functions, Google Cloud Functions, Azure Functions, etc.

En este video me voy a centrar en mostrarte que todos estos modelos (IaaS, PaaS y FaaS) existen tanto dentro de AWS como fuera de AWS. Es decir, casi todo lo que harías en AWS tiene equivalentes en otros proveedores, muchas veces más simples de usar y con costos más predecibles.

Y ahora sí, empecemos por la base de todo: los VPS, es decir, el mundo IaaS más clásico.

Otros modelos además de IaaS, PaaS y FaaS

Además de IaaS, PaaS y FaaS, a veces vas a ver:

• SaaS (Software as a Service)
  Ya no despliegas nada: simplemente usas una aplicación lista.

  • Ejemplos: Gmail, Slack, Notion, GitHub, Stripe Dashboard, etc.
  • En vez de montar tu propio sistema de tickets, usas un SaaS tipo Zendesk.
  • En vez de montar tu propio servidor de correos, usas un SaaS como Google Workspace.

• BaaS (Backend as a Service)
  Es una mezcla de PaaS + servicios listos tipo “backend genérico”: auth, base de datos, storage, funciones, etc.

  • Ejemplos: Firebase, Supabase, Appwrite, AWS Amplify.
  • Tú te concentras en el frontend y en un poco de lógica, y el proveedor te da:
    • Autenticación de usuarios
    • Base de datos
    • Almacenamiento de archivos
    • Funciones serverless

• CaaS (Containers as a Service)
  En lugar de trabajar con máquinas virtuales o solo código, trabajas con contenedores (Docker) y el proveedor gestiona el clúster.

  • Ejemplos: AWS ECS/Fargate, Google Cloud Run, Azure Container Apps, Kubernetes gestionado (EKS, GKE, AKS, DO Kubernetes, etc.).
  • Tú defines la imagen Docker, y el servicio se encarga de ejecutar y escalar esos contenedores.

• (Menos comunes en el día a día, pero existen como términos de marketing)

  • DBaaS (Database as a Service): Neon, PlanetScale, RDS, Supabase DB, etc.
  • STaaS (Storage as a Service): S3, Backblaze B2, Wasabi, etc.

Para tu video, si quieres mantenerlo simple, puedes mencionar algo como:

“En el mundo cloud se habla mucho de IaaS, PaaS y FaaS. Existen otros términos como SaaS, BaaS o CaaS, pero para este video me voy a centrar principalmente en la parte de infraestructura donde normalmente uno piensa en AWS: servidores, plataformas para desplegar código y funciones serverless.”

Así no te vas por demasiadas ramas, pero demuestras que conoces el contexto completo.

2. VPS (Compute básico: EC2 vs otros)

Cuando alguien piensa en “servidores en la nube”, normalmente piensa en EC2 de AWS. Pero EC2 no es más que un tipo de VPS: una máquina virtual donde instalas tu sistema operativo, tu runtime y tu aplicación.

Un VPS (Virtual Private Server) es básicamente:

• Una computadora virtual que corre en un datacenter.
• Tú decides el sistema operativo, los paquetes, cómo despliegas tu código.
• Pagas típicamente por mes o por hora, según CPU, RAM y disco.

En AWS esto lo harías con EC2, pero hay muchos proveedores que ofrecen exactamente lo mismo, a veces con menos complejidad y a menor precio.

Ejemplos de alternativas a EC2 / VPS de AWS:

• DigitalOcean Droplets
• Linode / Akamai
• Vultr
• Hetzner Cloud
• OVH, Contabo, y muchos otros

La idea es la misma: eliges un plan (por ejemplo, 2 vCPU y 4 GB de RAM), haces un clic para crear el servidor y en minutos tienes una máquina lista con Linux, SSH y una IP pública. Desde ahí puedes:

• Desplegar un backend en Node, Python, Go, PHP, etc.
• Montar un frontend con NGINX o Caddy.
• Instalar una base de datos en el mismo servidor o en otro VPS.

¿Cuándo tiene sentido usar VPS fuera de AWS?

• Cuando quieres algo simple y predecible: una o pocas máquinas que lo corren casi todo.
• Cuando tu proyecto es pequeño o mediano, y no necesitas una arquitectura distribuida enorme.
• Cuando te importa tener una factura clara y barata, sin decenas de servicios distintos.
• Cuando prefieres una interfaz muy sencilla y documentación directa, sin toda la complejidad del ecosistema AWS.

Para la mayoría de aplicaciones web normales, un par de VPS en un proveedor cualquiera puede ser suficiente, sin necesidad de meterte en EC2, VPCs, security groups y toda la maquinaria de AWS.

3. Bases de datos (RDS/Aurora vs alternativas fuera de AWS)

Cuando piensas en bases de datos en AWS, seguramente piensas en RDS, Aurora o DynamoDB. Es decir: bases de datos gestionadas donde Amazon se encarga de backups, parches y alta disponibilidad.

Lo importante es entender que ese modelo de “base de datos administrada” no es exclusivo de AWS.
Hay un montón de servicios fuera de AWS que te dan algo muy parecido: un endpoint de Postgres/MySQL (u otro motor), con backups automáticos, métricas y escalado básico.

3.1. Dos enfoques: gestionadas vs autoadministradas

Para tu infraestructura tienes dos caminos:

1. Bases de datos gestionadas (DBaaS)
   Pagas a un proveedor para que:

   • Haga backups automáticos
   • Aplique actualizaciones y parches de seguridad
   • Gestione alta disponibilidad / réplicas
   • Te dé métricas, panel, usuarios, etc.

2. Bases de datos autoadministradas en un VPS
   Levantas un servidor (Hetzner, DigitalOcean Droplet, Linode, OVH, etc.) e instalas tú mismo Postgres, MySQL, Mongo, etc.
   Tú te encargas de:

   • Backups y recuperación
   • Actualizaciones, configuración y tuning
   • Alta disponibilidad (si la necesitas)

En esta sección vamos a enfocarnos sobre todo en el primer modelo: servicios gestionados alternativos a RDS/Aurora.

3.2. Alternativas gestionadas a RDS/Aurora (SQL)

Todos estos servicios te dan PostgreSQL o MySQL administrados, muy similares a usar RDS, pero fuera de AWS:

• DigitalOcean Managed Databases

  • Postgres, MySQL, Redis.
  • Panel muy simple, backups automáticos, escalado con pocos clics.

• Railway

  • Ofrece PostgreSQL y MySQL gestionados.
  • Muy integrado con su PaaS: conectas app + DB en un par de clicks.

• Render Managed PostgreSQL

  • Postgres administrado, integrado con sus servicios de apps.
  • Ideal para monolitos o microservicios sencillos.

• Koyeb Databases (PostgreSQL)

  • PostgreSQL gestionado dentro de la misma plataforma donde corres tus servicios.
  • Pensado para desarrolladores que quieren algo serverless pero sin meterse en AWS.

• Neon (serverless PostgreSQL)

  • Postgres serverless, separa compute y storage.
  • Escala a cero, ideal para proyectos que no están activos 24/7.

• Supabase (PostgreSQL)

  • Postgres administrado + autenticación + storage + funciones.
  • Excelente opción tipo BaaS para apps web y móviles.

• PlanetScale (MySQL/Vitess)

  • MySQL gestionado sobre Vitess, muy enfocado en escalabilidad y ramas de esquemas.
  • Bueno para SaaS que pueden crecer mucho.

• Aiven

  • Ofrece PostgreSQL, MySQL, Redis y varios más, todos gestionados.
  • Se preocupa mucho por seguridad, backups y observabilidad.

• Crunchy Bridge (Crunchy Data)

  • PostgreSQL gestionado con foco fuerte en producción y compliance.
  • Interesante para entornos más “serios” que un simple side‑project.

• ElephantSQL

  • PostgreSQL gestionado muy sencillo, con planes pequeños para proyectos ligeros.

• Timescale Cloud

  • PostgreSQL administrado optimizado para series temporales (métricas, IoT, logs).
  • Vale mencionarlo si hablas de analítica o monitoreo.

• Heroku Postgres

  • Uno de los clásicos: Postgres gestionado, súper integrado con apps en Heroku.

• Google Cloud SQL (PostgreSQL, MySQL)

  • El equivalente a RDS en Google Cloud, pero puedes usarlo desde apps que no estén necesariamente “todo” en GCP.

• Azure Database for PostgreSQL / MySQL

  • Lo mismo pero en Azure: motores SQL administrados con backup, HA y escalado.

3.3. Alternativas gestionadas NoSQL / especializadas (opcional)

Si quieres mencionar también que NoSQL gestionado tampoco es exclusivo de AWS:

• MongoDB Atlas → MongoDB gestionado.
• Upstash → Redis y Kafka serverless, muy usado con funciones y edge.
• DataStax Astra DB → Cassandra como servicio, orientado a grandes volúmenes.

No hace falta entrar al detalle en el video, pero sirve para reforzar la idea de que el modelo gestionado existe en muchos proveedores, no sólo Dynamodb o DocumentDB.

3.4. ¿Cuándo usar estas bases gestionadas fuera de AWS?

Tiene sentido elegir alguno de estos servicios cuando:

• Quieres olvidarte del rol de “DBA”: no quieres estar pendiente de backups, parches y ajustes finos.
• Tu proyecto es un SaaS pequeño/mediano, MVP o startup, y prefieres pagar un poco más por simplicidad.
• Estás usando un PaaS como Railway, Render, Supabase, Koyeb, Heroku, etc., y te viene bien tener la base en el mismo ecosistema.
• No necesitas toda la maquinaria enterprise de AWS, pero sí quieres:
  • Alta disponibilidad razonable
  • Backups automáticos
  • Escalado relativamente fácil

En otras palabras, todo lo que normalmente intentarías resolver con RDS o Aurora lo puedes resolver igual con:

DigitalOcean Managed Databases, Railway, Render, Koyeb, Neon, Supabase, PlanetScale, Aiven, Crunchy Bridge, ElephantSQL, Timescale, Heroku Postgres, Cloud SQL, Azure Database…

sin necesidad de casarte con AWS.

3.5. ¿Y las bases autoadministradas en VPS?

Como contraste rápido, puedes cerrar la sección diciendo:

• Si quieres máximo control y pagar lo mínimo posible,
  puedes montar tu base de datos en un VPS clásico (Hetzner, DO Droplet, Linode, OVH, Contabo, etc.) y autogestionarla tú.

• Si prefieres ahorrarte tiempo y dolores de cabeza,
  usas alguno de estos servicios gestionados (Supabase, Neon, DO Managed DB, Railway, etc.) y dejas que ellos se encarguen de la parte aburrida.

La decisión al final no es “¿uso RDS o no?”, sino:

“¿Quiero que mi proveedor gestione la base de datos por mí, y cuál me da la mejor relación simplicidad / precio / región sin obligarme a irme a AWS?”