Qué es AWS y por qué se volvió el nombre de la nube
Publicado el 2026-09-12 por frfrand
De un experimento interno de una tienda de libros a la infraestructura de medio internet. Qué vende realmente, por qué su factura sorprende, y cuándo conviene y cuándo no.
En 2006 una tienda de libros por internet empezó a alquilar capacidad de sus servidores. Hoy esa división sostiene una parte enorme de internet y es una de las más rentables de su empresa.
La historia importa porque explica qué vende realmente AWS.
El producto nunca fue el servidor
Antes de la nube, conseguir un servidor era un proyecto: elegir el hardware, esperar semanas a que llegara, instalarlo en un centro de datos, configurarlo. Si te equivocabas en el dimensionamiento, ese error duraba años, porque el hardware ya estaba comprado.
Lo que AWS vendió fue tiempo: una máquina en un minuto, pagada por hora, y destruida cuando ya no hace falta.
Eso cambió una decisión de arquitectura en una decisión reversible. Y cuando una decisión es reversible, se puede probar.
Qué hay realmente adentro
Son cientos de servicios y la mayoría no los vas a usar nunca. Los que sostienen casi todo:
EC2 son máquinas virtuales. Es el servicio original y el más parecido a un VPS.
S3 es almacenamiento de objetos: archivos accesibles por HTTP, con durabilidad muy alta. Es probablemente el servicio más copiado de la historia reciente: casi todos los proveedores tienen uno compatible con su interfaz.
RDS son bases de datos administradas. Vos usás Postgres o MySQL; ellos se ocupan de las copias, las réplicas y las actualizaciones.
Lambda ejecuta funciones sin que administres servidores, y cobra por ejecución.
Y alrededor, una cantidad enorme de servicios especializados: colas, notificaciones, contenedores, aprendizaje automático, redes de distribución.
Por qué la factura sorprende
Esta es la queja más habitual y vale entender de dónde sale.
Se paga por lo que se olvida apagar. Como crear recursos es fácil, quedan máquinas de prueba, discos huérfanos y direcciones reservadas sin uso, cada uno sumando.
El tráfico de salida se cobra. Entrar datos es gratis, sacarlos no. Para una aplicación que sirve muchos archivos, eso puede superar el costo de cómputo.
Cada servicio tiene su propio modelo de precios, y componer diez servicios significa entender diez modelos.
La consecuencia práctica es que la nube es barata cuando la carga es variable (pagás los picos sólo cuando ocurren) y cara cuando es constante y previsible. Varias empresas conocidas se movieron de vuelta a servidores propios por exactamente ese motivo.
Cuándo conviene y cuándo no
Conviene cuando la carga varía mucho, cuando necesitás presencia en varias regiones del mundo, cuando querés servicios administrados para no operar bases ni colas, o cuando un requisito de cumplimiento te pide certificaciones que ellos ya tienen.
No conviene cuando tu carga es estable y previsible (un servidor propio puede costar una fracción), cuando el equipo es chico y la complejidad operativa pesa más que la flexibilidad, o cuando lo que necesitás es un servidor y estás pagando por un catálogo de doscientos servicios que no usás.
El punto que más se subestima
El encierro. No por maldad: por gravedad.
Cuando tu aplicación usa cinco servicios propietarios, mudarse implica reescribir partes. Y el costo de salida crece con el tiempo, en silencio.
Hay una forma sana de convivir con eso: usar los servicios estándar (una máquina, un Postgres, almacenamiento compatible) y ser deliberado con cada servicio propietario que se agrega. Cada uno es una decisión que cuesta deshacer.
Es la misma razón por la que tiene sentido preguntarse, antes de elegir proveedor, qué tan fácil sería irse.