Esta primera lección tiene dos objetivos. El primero es presentarte MercadoFresco, la empresa ficticia que nos acompañará durante todo el curso: verás su situación real de partida, sus problemas concretos y por qué necesita la nube. El segundo es entender qué es la computación en la nube y qué es AWS, no como una lista de nombres de servicios, sino como un modelo distinto de comprar, operar y hacer crecer la infraestructura de una aplicación.

Es importante empezar por aquí porque casi todas las decisiones técnicas que tomarás en AWS (qué servicio usar, en qué región, con qué tamaño, cuánto va a costar) solo tienen sentido si entiendes el modelo económico y de responsabilidades que hay debajo. Muchos equipos migran a la nube y acaban con una factura enorme y una arquitectura frágil precisamente porque se saltaron esta parte.

1. MercadoFresco: la empresa y su servidor único
2. Los cuatro problemas concretos de MercadoFresco
3. Qué es la computación en la nube
4. Servidor propio frente a nube: CapEx, OpEx, elasticidad y aprovisionamiento
5. Modelos de servicio: IaaS, PaaS y SaaS
6. Modelos de despliegue: pública, privada e híbrida
7. Qué es AWS: historia, escala y familias de servicios
8. El modelo de responsabilidad compartida
9. Precios de pago por uso y la capa gratuita
10. La arquitectura destino de MercadoFresco

MercadoFresco es una tienda online española de producto fresco: fruta, verdura, pescado y carne comprados a proveedores locales, con reparto a domicilio en 24 horas. Empezó como un proyecto pequeño en una sola ciudad y hoy sirve varios miles de pedidos al mes. Su dominio es mercadofresco.example.

El equipo técnico es diminuto:

Toda la plataforma vive hoy en un único servidor físico alojado en un armario de la oficina:

En ese servidor conviven:

• El monolito: una aplicación PHP que sirve la tienda y el panel de administración, más varios scripts Python que generan las rutas de reparto y los informes de Sara.
• La base de datos relacional con clientes, productos, stock y pedidos.
• Las fotos de producto guardadas directamente en el disco local, en /var/www/fotos.

No hay entorno de pruebas: Luis prueba en su portátil y despliega por FTP al mismo servidor que usan los clientes.

No vamos a migrar a la nube "porque es moderno". Vamos a migrar porque hay cuatro problemas medibles que el servidor único no puede resolver.

El pico de pedidos se concentra entre las 17:00 y las 21:00 del viernes, cuando la gente organiza la compra del fin de semana. En ese tramo el tráfico es entre 8 y 10 veces el de un martes por la mañana. El servidor agota la memoria, la base de datos empieza a rechazar conexiones y la web devuelve errores durante 20 o 30 minutos. Marta lo resuelve reiniciando servicios a mano.

El problema de fondo: la capacidad es fija y está dimensionada para el pico. O compras un servidor caro que va al 8 % de uso el 90 % del tiempo, o compras uno barato que se cae en el momento en que más dinero entra.

Existe un disco USB conectado al servidor y un script cron que hace un volcado de la base de datos por las noches. Nadie ha probado nunca a restaurar ese volcado. Las fotos de producto no se copian en ningún sitio. Un incendio, un robo o un fallo de disco en la oficina se llevaría por delante todo el catálogo.

Abrir en una segunda y tercera ciudad significa más catálogo, más pedidos simultáneos y más rutas de reparto que calcular. Con la arquitectura actual, crecer implica comprar hardware, esperar semanas a que llegue, montarlo y migrar durante una noche entera. Y todo eso lo tendría que hacer Marta, que es una sola persona.

Sin entorno de pruebas ni forma de volver atrás, cada cambio de Luis puede tumbar la tienda. El equipo despliega los martes por la mañana "por si acaso" y evita tocar nada en toda la semana.

Guarda estos cuatro problemas en la cabeza: cada módulo del curso resuelve uno o varios de ellos, y al final habremos construido una plataforma donde ninguno de los cuatro existe.

La computación en la nube (cloud computing) es el suministro de recursos de tecnología de la información —servidores, almacenamiento, bases de datos, redes, software— bajo demanda a través de internet y con pago por uso.

La idea clave no es "los servidores están en otro sitio". Eso ya existía con el hosting tradicional. La idea clave son tres propiedades combinadas:

1. Autoservicio bajo demanda: pides un servidor con una llamada a una API y lo tienes en segundos, sin hablar con un comercial ni firmar nada.
2. Elasticidad: puedes tener 2 servidores el martes y 20 el viernes a las 18:00, y volver a 2 a las 22:00, pagando solo por las horas que los tuviste.
3. Pago por consumo: no compras el activo, alquilas su uso medido (horas de CPU, gigabytes almacenados, peticiones atendidas).

Una analogía útil: es la diferencia entre comprar un generador eléctrico y enchufarte a la red. El generador es tuyo, lo mantienes tú, lo dimensionas para tu pico y se te queda pequeño o grande. La red eléctrica está siempre ahí, das al interruptor, y pagas los kilovatios que consumes.

Dos conceptos financieros que conviene tener claros, porque cambian cómo se toman las decisiones:

• CapEx (Capital Expenditure, gasto de capital): compras un activo por adelantado. El servidor de MercadoFresco costó 6.000 € de golpe y se amortiza en 4 o 5 años. Es una decisión difícil de revertir: si te equivocas de tamaño, ya lo has pagado.
• OpEx (Operational Expenditure, gasto operativo): pagas por el uso, mes a mes, como la luz o el teléfono. Si dejas de usarlo, dejas de pagarlo. Es una decisión reversible.

La nube convierte CapEx en OpEx. Esto tiene una consecuencia práctica enorme: el coste de equivocarse baja muchísimo, y por tanto puedes experimentar. Probar una base de datos distinta ya no significa comprar una máquina; significa arrancarla, medirla durante tres días y apagarla.

Un matiz honesto, porque este curso no es un folleto publicitario: la nube no siempre es más barata. Una carga de trabajo constante, predecible y bien dimensionada durante cinco años puede salir más económica en hardware propio. La nube gana cuando hay variabilidad, cuando necesitas velocidad de cambio, o cuando el equipo es pequeño y no puede dedicarse a mantener hierro, que es exactamente el caso de MercadoFresco.

Los servicios en la nube se clasifican según cuánto gestionas tú y cuánto gestiona el proveedor.

Para MercadoFresco esta clasificación es una guía de decisión constante. Ejemplo real que veremos: la base de datos.

• Si la instalan ellos en una máquina EC2 (IaaS), Marta sigue siendo responsable de parchear MySQL, configurar la replicación y programar las copias.
• Si usan Amazon RDS (PaaS), AWS se ocupa de parches, copias automáticas y conmutación por error, y el equipo solo diseña el esquema y escribe consultas.

La regla práctica que usaremos en todo el curso: cuanto más gestionado, mejor, salvo que tengas una razón concreta para lo contrario. Cada pieza que gestionas tú es tiempo que Marta y Luis no dedican a vender fruta.

Existe además el término multinube (usar AWS y otro proveedor a la vez), habitual en empresas grandes por negociación comercial o por resiliencia. Para un equipo de tres personas es casi siempre una mala idea: multiplica la complejidad y el conocimiento necesario sin aportar valor.

MercadoFresco irá a nube pública en AWS, con una fase corta de convivencia híbrida durante la migración (el servidor de la oficina seguirá encendido unas semanas hasta comprobar que todo funciona).

Amazon Web Services (AWS) es la plataforma de computación en la nube de Amazon. Nació de un problema interno: a principios de los 2000, Amazon.com tardaba meses en aprovisionar infraestructura para cada nuevo proyecto, así que construyeron una capa de servicios comunes con APIs. En 2006 decidieron venderla al público.

Hitos que conviene conocer porque explican por qué el catálogo tiene la forma que tiene:

Fíjate en el orden: primero almacenamiento y cómputo crudos (IaaS), después servicios gestionados (PaaS), después abstracciones sin servidor. Ese mismo orden es, más o menos, el que sigue este curso.

Escala: AWS opera decenas de regiones geográficas, cada una con varios centros de datos independientes, y una red privada de fibra propia que las conecta. Es el proveedor de nube con mayor cuota de mercado y su catálogo supera los 200 servicios. No necesitas conocerlos todos: con unos 25 bien entendidos se construye la práctica totalidad de las aplicaciones.

Este es probablemente el concepto más importante de la lección, y el que más malentendidos causa. AWS no se hace responsable de tu seguridad entera. La responsabilidad se reparte:

• AWS es responsable de la seguridad de la nube: los centros de datos, el hardware, la red física, el hipervisor y el software de los servicios gestionados.
• Tú eres responsable de la seguridad en la nube: tus datos, quién accede a ellos, el cifrado que activas, la configuración de tus redes, los parches de tus sistemas operativos y el código de tu aplicación.

La frontera se mueve según el servicio que uses, y esto es clave:

Casi todos los incidentes de seguridad que aparecen en prensa como "filtración en AWS" son en realidad fallos del cliente: un bucket S3 abierto al público por configuración, una clave de acceso subida a GitHub, un grupo de seguridad con el puerto de la base de datos expuesto a internet. Ninguno de esos tres es responsabilidad de AWS. Los tres los evitaremos explícitamente en este curso.

El principio general es simple: pagas por lo que consumes, sin compromiso mínimo. Las tres dimensiones que casi siempre se facturan son:

1. Cómputo: por segundo u hora que una máquina está encendida.
2. Almacenamiento: por gigabyte y mes que guardas datos.
3. Transferencia de datos: por gigabyte que sale de AWS hacia internet. La entrada (ingress) es normalmente gratuita; la salida (egress) no.

Sobre esa base hay descuentos por compromiso (Savings Plans, instancias reservadas, módulo 11) y opciones más baratas a cambio de menos garantías (instancias spot).

Una idea realista de órdenes de magnitud, para que dejes de ver los precios como un misterio. Son cifras aproximadas de la región de Irlanda, útiles para razonar, no para presupuestar:

Dos avisos que te ahorrarán dinero desde hoy:

• Hay recursos que cobran aunque no los uses: un disco EBS desconectado, una IP elástica sin asociar, un balanceador sin tráfico, una instantánea antigua. Se cobran por existir.
• Apagar no siempre es dejar de pagar: una instancia EC2 parada no cobra cómputo, pero su disco EBS sigue facturando.

AWS ofrece una capa gratuita (Free Tier) con tres modalidades que veremos en detalle en la lección 01-02, al crear la cuenta:

• 12 meses gratis desde el alta (por ejemplo, 750 horas al mes de t2.micro/t3.micro).
• Siempre gratis, sin caducidad (por ejemplo, el primer millón de peticiones de Lambda al mes).
• Pruebas de corta duración para servicios concretos.

Con la capa gratuita puedes hacer prácticamente todos los ejercicios de este curso con un coste de cero o unos pocos euros, siempre que borres los recursos al terminar. Cada vez que un ejercicio pueda generar gasto, te lo avisaremos y te indicaremos cómo eliminar lo creado.

Para que sepas hacia dónde vamos, este es el destino aproximado que construiremos a lo largo de los once módulos. No hace falta que entiendas cada caja todavía; vuelve a este diagrama al terminar cada módulo y verás cómo se van encendiendo las piezas.

Comprueba cómo cada problema inicial queda resuelto:

• Creer que "migrar a la nube" es copiar el servidor tal cual. Levantar una única instancia EC2 con todo dentro (el famoso lift and shift mal hecho) reproduce exactamente los mismos problemas, pero pagando más. La nube aporta valor cuando se aprovecha su elasticidad y sus servicios gestionados.
• Ignorar la responsabilidad compartida. "Está en AWS, luego está seguro" es falso. Un bucket S3 mal configurado es público en internet en cinco segundos y la responsabilidad es tuya.
• Olvidar la transferencia de salida. Es la partida de la factura que más sorprende a los equipos nuevos. Servir fotos de producto directamente desde una instancia puede costar mucho más que servirlas desde S3 con CloudFront.
• Dejar recursos encendidos "por si acaso". Adquiere desde hoy la costumbre de borrar lo que creas para practicar. Al final de cada ejercicio de este curso te recordaremos cómo hacerlo.
• Intentar aprender los 200 servicios. No los necesitas. Domina los ~25 del temario y sabrás leer la documentación del resto cuando te haga falta.
• Consejo: cuando dudes entre gestionarlo tú o usar un servicio gestionado, pregúntate cuánto vale una hora de Marta. Casi siempre gana el servicio gestionado.

Sin usar todavía ningún servicio de AWS, elabora una tabla con los cuatro problemas de MercadoFresco. Para cada uno indica: (a) el impacto en el negocio en una frase, (b) si un servidor propio más grande lo resolvería, y (c) qué propiedad de la nube (elasticidad, servicios gestionados, distribución geográfica o pago por uso) ataca la causa raíz.

Clasifica cada uno de estos elementos como IaaS, PaaS o SaaS, y justifica en una línea quién gestiona el sistema operativo en cada caso:

1. Una máquina virtual Linux donde instalas tú mismo Nginx y MySQL.
2. Una base de datos MySQL gestionada por AWS a la que solo te conectas por un endpoint.
3. Un gestor de correo corporativo al que accedes por navegador.
4. Una función que ejecuta código Python cuando llega una petición HTTP, sin que exista servidor visible.

Marta propone una primera arquitectura mínima para MercadoFresco en AWS:

• 2 instancias t3.medium encendidas las 24 horas.
• 1 base de datos RDS pequeña.
• 1 balanceador de carga.
• 200 GB de fotos en S3.
• 300 GB de transferencia de salida a internet al mes.

Usando la tabla de órdenes de magnitud de esta lección, estima el coste mensual total y di qué dos partidas son las mayores. Después propón un cambio que reduzca el coste sin empeorar la disponibilidad los viernes.

Solución 1

Solución 2

1. IaaS. AWS te da la máquina virtual; el sistema operativo, los parches, Nginx y MySQL los gestionas tú (Amazon EC2).
2. PaaS. AWS gestiona el sistema operativo y el motor de base de datos, incluidas copias y parches; tú solo gestionas esquema y datos (Amazon RDS).
3. SaaS. No hay sistema operativo visible para ti; solo configuras usuarios y buzones (por ejemplo, Amazon WorkMail).
4. PaaS (en su variante serverless, a menudo llamada FaaS). No existe sistema operativo que tú administres; solo aportas el código (AWS Lambda).

Solución 3

Las dos partidas mayores son el cómputo EC2 (70 $) y la transferencia de salida (27 $).

Dos posibles mejoras:

• Servir las fotos a través de CloudFront delante de S3 (módulo 3): la salida desde la caché es más barata que desde la instancia y además descarga a los servidores.
• Sustituir las 2 instancias fijas por un grupo de escalado automático con 1 instancia como base que crezca a 3 o 4 los viernes por la tarde (módulos 2 y 3): baja el coste medio y mejora la disponibilidad justo en el pico.

Nótese que reducir de 2 instancias a 1 sin escalado sería más barato pero empeoraría la disponibilidad, así que no cumple el enunciado.

Ya tienes las dos bases sobre las que se apoya el resto del curso. Por un lado, MercadoFresco: una tienda de producto fresco atrapada en un servidor único, con caídas los viernes, copias de seguridad que nadie ha probado, imposibilidad de crecer y despliegues que dan miedo. Por otro, el modelo de la nube: recursos bajo demanda, pago por uso, CapEx convertido en OpEx, elasticidad real y servicios gestionados que liberan tiempo del equipo.

También has visto los tres marcos mentales que usarás constantemente: IaaS/PaaS/SaaS para decidir cuánto quieres gestionar, la responsabilidad compartida para saber qué parte de la seguridad es tuya, y el modelo de precios para que ninguna factura te sorprenda.

En la siguiente lección, 01-02 «Configuración de tu cuenta de AWS», Marta pasa de la teoría a la práctica: crea la cuenta de MercadoFresco, protege el usuario root con MFA, crea el usuario administrador con el que trabajaremos todo el curso y monta la primera red de seguridad económica para que la factura nunca se descontrole.