AWS Cloud explicado: qué son EC2, S3, bases de datos y serverless, y para qué se usan en proyectos reales
La nube dejó de ser “algo para empresas grandes” hace tiempo. Hoy, tanto una startup como un e-commerce, un periódico digital o un software interno pueden desplegarse con infraestructuras flexibles, escalables y con pago por uso. Dentro de ese escenario, Amazon Web Services se ha consolidado como uno de los ecosistemas más completos para construir soluciones: desde servidores tradicionales hasta arquitecturas modernas sin servidores (serverless), almacenamiento masivo y bases de datos administradas.
Cuando se habla de AWS en conversaciones técnicas, suelen aparecer cuatro conceptos clave: EC2, S3, bases de datos y serverless. No son “modas”: son piezas fundamentales que, combinadas, permiten crear casi cualquier tipo de sistema. Vamos a ver qué es cada una, para qué sirve y en qué casos tiene sentido.
EC2: “servidores en la nube” (cómputo bajo tu control)
EC2 (Elastic Compute Cloud) es, en esencia, la forma clásica de ejecutar aplicaciones en AWS: máquinas virtuales (instancias) que funcionan como servidores. Tú eliges el tamaño (CPU, RAM), el sistema operativo, el almacenamiento asociado y cómo se conecta a la red.
¿Para qué se usa EC2?
EC2 suele ser la opción cuando necesitas control y flexibilidad a nivel de sistema:
Aplicaciones web tradicionales (PHP, Node.js, Java, Python…) ejecutándose en un servidor.
APIs que requieren configuración específica del entorno.
Servicios que mantienen procesos en memoria (workers, colas, procesamiento continuo).
Software legacy que no está preparado para serverless o contenedores.
Entornos con requisitos especiales (librerías nativas, configuraciones del SO, tunning fino).
Ventajas típicas
Control sobre el sistema y el runtime.
Puedes ajustar potencia según la carga.
Encaja bien con arquitecturas “de servidor” conocidas.
Consideración importante
La contrapartida es clara: si usas EC2, también te ocupas (en mayor o menor medida) de la operación: parches, seguridad, escalado, monitorización y disponibilidad (aunque AWS te da herramientas, el “modelo servidor” exige más trabajo que un servicio totalmente administrado).
Bases de datos en AWS: del modelo administrado al NoSQL
Si EC2 es “cómputo”, las bases de datos son el corazón de casi cualquier producto digital. AWS no ofrece solo “una base de datos”, sino un abanico que cubre distintos patrones:
a) Bases de datos relacionales (SQL) administradas
Las más comunes en AWS suelen ser bases SQL administradas (por ejemplo, MySQL o PostgreSQL en servicios gestionados). La idea es sencilla: sigues usando SQL, pero AWS gestiona gran parte de la infraestructura: backups, parches, replicación (según configuración), etc.
Usos típicos
E-commerce (pedidos, productos, clientes).
CRMs, ERPs, backoffice.
Sistemas transaccionales donde consistencia y relaciones importan.
Por qué se eligen
Te olvidas de gran parte del mantenimiento “de servidor”.
Mejoran la disponibilidad y la resiliencia respecto a montártelo tú mismo.
b) NoSQL (por ejemplo, key-value/document)
En escenarios donde prima la velocidad, la simplicidad del modelo o el escalado masivo, se usan bases NoSQL.
Usos típicos
Sesiones de usuario, carritos, cachés persistentes.
Catálogos con lecturas muy rápidas.
Eventos, telemetría y datos semi-estructurados.
Aplicaciones con picos de tráfico impredecibles.
Punto clave
No es “mejor” que SQL: es diferente. Si tu aplicación necesita joins complejos y transacciones relacionales, SQL suele ganar. Si necesitas respuesta ultra rápida y escalado simple por patrón de acceso, NoSQL puede ser ideal.
c) Elegir bien evita costes y dolores futuros
Una decisión frecuente y costosa es usar una base de datos “porque es la que conozco” sin pensar el patrón de acceso. En AWS, elegir el tipo correcto:
mejora rendimiento,
reduce complejidad,
y a menudo reduce factura.
S3 y archivos estáticos: almacenamiento escalable para contenido y assets
S3 (Simple Storage Service) es el gran “almacén” de objetos de AWS. No es un disco duro tradicional: es un almacenamiento de objetos (archivos) con altísima durabilidad, pensado para escalar sin que tengas que “dimensionar” nada.
¿Qué son los “archivos estáticos”?
Son recursos que no cambian al generarse en cada petición:
imágenes, PDFs, vídeos,
CSS, JS,
fuentes,
backups,
ficheros exportados,
subidas de usuarios (avatares, adjuntos…).
¿Para qué se usa S3?
Hosting de archivos estáticos (por ejemplo, el front de una web).
Repositorio de assets de una aplicación (imágenes, documentos).
Data lake o almacenamiento de datos para analítica.
Backups y archivado a largo plazo.
Distribución de descargas (informes, catálogos, recursos).
Por qué es tan común
Escala “solo”.
Es muy fiable y durable.
Permite políticas de acceso, versionado, lifecycle (mover a almacenamiento más barato), etc.
Combinación típica: S3 + CDN
Aunque S3 puede servir archivos, lo habitual en proyectos con tráfico es usar una CDN delante (por ejemplo, para cachear y servir desde nodos cercanos al usuario). El resultado: mejor velocidad y, a menudo, menos coste de transferencia y carga en origen.
Serverless: cuando “no gestionas servidores” (y pagas por ejecución)
Serverless no significa que no haya servidores. Significa que no los gestionas tú: el proveedor se encarga de la infraestructura y tú subes funciones o piezas de lógica que se ejecutan bajo demanda.
El icono de AWS aquí suele ser Lambda: ejecutas una función cuando ocurre algo (una petición HTTP, un evento, un archivo subido, un mensaje en una cola…).
¿Para qué se usa serverless?
APIs y microservicios que crecen por demanda.
Automatizaciones y tareas event-driven (procesar un archivo al subirlo, enviar un email, convertir imágenes, generar PDFs).
Jobs puntuales (cron) sin mantener un servidor encendido.
Procesamiento por eventos (streaming, colas, integraciones).
Ventajas típicas
Pagas por ejecución (y recursos consumidos), no por “servidor encendido”.
Escala automáticamente en función del tráfico.
Reduce carga operativa: menos sysadmin, menos mantenimiento.
¿Cuándo NO es lo ideal?
Procesos muy largos o continuos.
Sistemas con dependencias complejas o necesidades finas del SO.
Workloads donde el coste por invocación y la latencia de arranque no encajan.
En la práctica, muchas arquitecturas modernas combinan serverless con servicios administrados (bases de datos, colas, storage) y evitan EC2 salvo que sea necesario.
Cómo encajan estas piezas en arquitecturas reales
Para aterrizarlo, aquí van patrones típicos (sin entrar en tutorial):
Patrón A: Web clásica optimizada
EC2 para la aplicación (backend).
Base de datos administrada para persistencia.
S3 para assets (imágenes, PDFs, subidas).
CDN delante de lo estático.
Ideal para migraciones desde hosting tradicional o apps que necesitan control del entorno.
Patrón B: Front estático + API moderna
Front (HTML/CSS/JS) servido desde S3 + CDN.
API en serverless (funciones) o contenedores.
Base de datos según patrón (SQL o NoSQL).
Muy común en productos modernos: rápido, escalable y con operación reducida.
Patrón C: Procesamiento de archivos y automatización
Usuario sube archivo a S3.
Evento dispara serverless para procesar (convertir, validar, extraer datos).
Resultado a base de datos + notificación.
Potente para flujos de negocio, integraciones y backoffice inteligente.
Evitar “gastos sorpresa”: de qué dependen los costes en AWS
El coste en AWS no es “mágico”, pero sí puede sorprender si no se entiende el modelo. Los gastos suelen venir de:
a) Tamaño y tiempo de cómputo
En EC2, pagas por instancias (y su uso).
En serverless, pagas por ejecuciones y recursos consumidos.
b) Almacenamiento y ciclo de vida
Guardar en S3 es barato, pero crece con volumen.
Versionado, logs y backups pueden multiplicar almacenamiento si no se controla.
Mover datos antiguos a “clases” más baratas reduce factura.
c) Transferencia de datos
La red (salida a internet, transferencias entre zonas/servicios) es una fuente clásica de sorpresas, especialmente en proyectos con mucho contenido (vídeo, imágenes, descargas, etc.).
d) Crecimiento sin límites por falta de límites
Si no hay alertas, presupuestos o etiquetado, es fácil que:
entornos de pruebas se queden encendidos,
logs crezcan sin rotación,
snapshots se acumulen,
y recursos “huérfanos” queden activos.
Qué hacen las empresas “bien”
Etiquetan recursos por proyecto/cliente/entorno.
Configuran presupuestos y alertas.
Diseñan storage con lifecycle.
Optimizan la entrega estática con CDN.
Dimensionan según demanda (y apagan lo que no se usa).
AWS no es un servicio, es un conjunto de piezas
Lo importante de AWS no es memorizar nombres, sino entender qué categoría resuelve cada servicio:
EC2: servidores cuando necesitas control.
Bases de datos: almacenamiento transaccional (SQL) o escalado por patrón (NoSQL).
S3: archivos, assets, backups y datos a gran escala.
Serverless: ejecución por eventos con operación mínima.
Combinadas, estas piezas permiten desde una web sencilla hasta plataformas complejas. Y si se diseñan bien desde el principio—especialmente en storage, transferencia y escalado—se puede conseguir una infraestructura rápida, robusta y con costes predecibles.