Cerramos el módulo anterior con MercadoFresco preparado: cuenta segura, región elegida, consola dominada y CLI configurada con el perfil mercadofresco-dev. Todo eso era el andamio. Ahora empieza la obra. En esta lección levantamos el primer servidor real de MercadoFresco en la nube con Amazon EC2 (Elastic Compute Cloud), el servicio que proporciona máquinas virtuales bajo demanda y la pieza sobre la que se apoya buena parte de lo que viene después.

EC2 es el servicio con el que casi todo el mundo entra en AWS, y también donde más dinero se tira por descuido. Por eso no vamos a hacer un paseo por la pantalla de creación: vamos a entender qué es realmente una instancia, cómo se elige el tamaño sin adivinar, qué son los créditos de CPU (que serán decisivos para el pico de los viernes), cómo se automatiza el arranque del servidor con user data, y cómo un grupo de Auto Scaling convierte el problema 1 de MercadoFresco —las caídas de los viernes— en un problema resuelto por configuración.

1. Qué es una instancia EC2 y qué problema resuelve
2. AMI: la plantilla de la que nace la instancia
3. Familias y tipos de instancia: cómo leer t3.micro
4. Cómo elegir el tamaño sin adivinar
5. Instancias burstable y créditos de CPU
6. Modelos de compra: bajo demanda, spot, reservadas y Savings Plans
7. Ciclo de vida de una instancia: parar no es terminar
8. Acceso a la instancia: pares de claves, SSH, Instance Connect y Session Manager
9. user data: que la instancia se instale sola
10. Metadatos de instancia e IMDSv2
11. Crear la instancia por consola, paso a paso
12. Crear la instancia por CLI con el esquema de etiquetado
13. Plantillas de lanzamiento y Auto Scaling: la solución al pico de los viernes
14. Apagar y borrar todo para no gastar

Una instancia EC2 es una máquina virtual que se ejecuta sobre la infraestructura física de AWS. Tiene CPU, memoria, red, un disco de arranque y un sistema operativo completo: para tu software es indistinguible de un servidor de verdad. Puedes instalar lo que quieras, abrir una sesión SSH, mirar los logs y reiniciarla.

La diferencia con el servidor de la oficina de MercadoFresco no está en lo que la máquina es, sino en cómo se obtiene y se devuelve:

Esa última fila es la clave conceptual de todo el módulo: en AWS, crear y destruir son operaciones simétricas y baratas. Cuando Marta necesite cuatro servidores de tienda el viernes a las 17:00 y uno solo el sábado por la mañana, eso deja de ser una fantasía para convertirse en una línea de configuración.

Nota sobre lo que EC2 no cubre en esta lección. Toda instancia vive dentro de una red virtual (VPC) y está protegida por un grupo de seguridad, que es su cortafuegos. Aquí usaremos la VPC por defecto y crearemos un grupo de seguridad mínimo, sin entrar en detalle: las redes son el módulo 3 completo (03-01 VPC, 03-02 grupos de seguridad y NACL). El disco de la instancia se gestiona con EBS, que es la lección 02-02.

Una AMI (Amazon Machine Image) es una imagen de disco congelada: sistema operativo, paquetes instalados, configuración y ficheros. Cuando lanzas una instancia, AWS copia la AMI a un volumen nuevo y arranca la máquina desde ahí. La AMI es la plantilla; la instancia es la copia viva.

Hay cuatro orígenes posibles:

Para MercadoFresco usaremos Amazon Linux 2023: es gratuita, está optimizada para EC2, incluye la AWS CLI v2 preinstalada y el agente de Systems Manager ya activo (importante para Session Manager, más abajo).

Un detalle que confunde al principio: el identificador de una AMI es distinto en cada región. La misma Amazon Linux 2023 tiene un ami-0abc… en eu-west-1 y otro diferente en eu-central-1. Por eso nunca se escribe a mano en un script; se consulta. La forma robusta es preguntar al almacén de parámetros público de AWS:

Salida (ejemplo; el tuyo será distinto):

Desglose del comando:

• aws ssm get-parameter: Systems Manager Parameter Store guarda pares clave/valor. AWS publica ahí los IDs de sus AMIs para que no tengas que buscarlos.
• --query 'Parameter.Value': JMESPath, tal como vimos en 01-05, para quedarnos solo con el valor.
• --output text: sin comillas, listo para meterlo en una variable de shell.

Guárdalo en una variable, porque lo usaremos varias veces:

El tipo de instancia define cuánta CPU, memoria, red y disco tiene la máquina. AWS ofrece cientos, pero el nombre es un código legible que se descifra por partes:

Otro ejemplo: m6g.large = familia m (equilibrada), generación 6, g de Graviton (procesador ARM de AWS), tamaño large.

Las familias que necesitas conocer:

Y los tamaños, que en general duplican recursos y precio en cada escalón:

Esta linealidad tiene una consecuencia importante y contraintuitiva: dos instancias large cuestan lo mismo que una xlarge, pero dos instancias sobreviven a la caída de una zona de disponibilidad y una xlarge no. Es el primer argumento del diseño multi-AZ que vimos en 01-03, y una de las razones por las que preferiremos escalar horizontalmente (más máquinas) antes que verticalmente (máquinas mayores).

El método profesional no es intuir, es medir. Para MercadoFresco:

1. Parte del dato conocido. Una instancia de la tienda soporta 600 pedidos/hora. El pico de los viernes es de 900 pedidos/hora. Con una sola máquina, el 33 % de los pedidos del pico se pierde: eso son las caídas del problema 1.
2. Empieza pequeño. En la nube, cambiar de tamaño cuesta un reinicio. Empezar grande "por si acaso" cuesta dinero cada hora, para siempre.
3. Mide con CloudWatch (lección 05-01): CPU, memoria (requiere el agente), red y latencia durante al menos una semana completa, incluyendo un viernes.
4. Aplica la regla del 40-60 %. Si la CPU media está por debajo del 40 %, sobra máquina. Si supera el 70 % de forma sostenida, falta.
5. Consulta Compute Optimizer, el servicio gratuito de AWS que analiza tus métricas y recomienda tipo y tamaño.

Para nuestro punto de partida elegimos t3.micro por dos razones: entra en la capa gratuita (750 horas al mes durante 12 meses) y su comportamiento burstable nos permite explicar los créditos de CPU, que son justamente lo que hace fracasar a mucha gente en su primer pico de tráfico.

Aquí está el concepto que más disgustos da a quien empieza, y el que más importa para el viernes de MercadoFresco.

Las instancias de la familia T no te dan la CPU entera todo el tiempo. Te dan una línea base —un porcentaje del núcleo— y acumulan créditos de CPU cuando consumes menos de esa línea. Cuando necesitas más, gastas créditos para llegar al 100 %. Si se te acaban, la instancia se estrangula (throttling) y baja bruscamente a la línea base, aunque la CPU física esté libre.

Un crédito = un minuto de un vCPU al 100 %.

Hagamos el cálculo real de MercadoFresco. Un t3.micro acumula 12 créditos/hora, con un máximo de 288 (equivalente a 24 horas de acumulación). El pico de los viernes dura de 17:00 a 21:00, cuatro horas, y en ese rato la tienda estaría al 100 % de CPU con sus 2 vCPU:

Es decir: el t3.micro aguanta menos de tres horas del pico y luego se estrangula al 10 % de CPU. La tienda no se cae por falta de servidor, se cae por falta de créditos, y en el panel de CloudWatch la CPU aparece plana y baja, lo que despista muchísimo si no conoces el mecanismo.

Hay dos salidas, y conviene entender que solo una es buena:

• Modo unlimited (activado por defecto en T3): cuando se acaban los créditos, AWS deja que sigas al 100 % y te cobra un extra por cada vCPU-hora sobrante. Evita la caída, pero la factura se dispara si el pico es habitual. Se puede forzar el modo standard para que nunca cobre de más, a cambio de aceptar el estrangulamiento.
• Escalar horizontalmente: añadir instancias durante el pico. Es la solución correcta, y la veremos al final de esta lección con Auto Scaling.

Consultar el saldo de créditos (métrica CPUCreditBalance, en CloudWatch):

Regla práctica. Las instancias T son excelentes para cargas irregulares con valles largos (desarrollo, entornos de pruebas, servicios internos). Para una carga sostenida y predecible, una M sale más barata y más previsible que una T en modo unlimited.

La misma instancia puede costar cuatro precios distintos según el compromiso que adquieras. Aquí solo los comparamos para que sepas que existen y cuándo se usa cada uno; el análisis económico completo, con cálculos de amortización, es la lección 11-05.

Tres ideas para quedarte:

• Spot no es "barato y peor": es exactamente la misma máquina, con la condición de que AWS puede recuperarla. Solo sirve para cargas que toleran ser interrumpidas y reintentadas.
• Reservadas y Savings Plans no son máquinas, son descuentos de facturación que se aplican automáticamente al consumo que ya tienes.
• No compres compromisos hasta tener tres meses de datos reales. Marta no reservará nada hasta el módulo 11.

Una instancia pasa por estados bien definidos, y confundir dos de ellos —stopped y terminated— es el error más caro y más irreversible de EC2.

Qué ocurre exactamente en cada transición:

Los cuatro matices que hay que memorizar:

1. Parar no borra nada. El volumen EBS raíz sigue existiendo y sigue costando dinero (unos 0,08 USD por GB y mes con gp3). Una instancia parada es casi gratis, pero no del todo.
2. Terminar es definitivo. No hay papelera. El volumen raíz se elimina salvo que hayas desactivado DeleteOnTermination. Si guardabas datos ahí, se han ido.
3. La IP pública automática se pierde al parar. Al arrancar de nuevo recibes otra distinta. Si necesitas una IP estable, se usa una Elastic IP (módulo 3) o, mejor, un nombre DNS (03-05).
4. La IP privada sí se conserva mientras la instancia exista.

Para producción, Marta activará siempre la protección contra terminación:

Para volver a permitir el borrado hay que ejecutar el comando con --no-disable-api-termination. Es una fricción deliberada: dos pasos conscientes en lugar de un clic irreversible.

Un par de claves es una pareja de claves criptográficas. AWS guarda la pública y la coloca dentro de la instancia al arrancar (en ~/.ssh/authorized_keys); tú te quedas la privada en un fichero .pem. AWS no guarda copia de la clave privada: si la pierdes, no hay recuperación posible por soporte.

Notas del comando:

• --key-type ed25519 es más moderno y corto que RSA; ambos sirven, pero ed25519 es la elección por defecto hoy (Windows con instancias antiguas puede requerir rsa).
• La salida de KeyMaterial solo se muestra una vez. Si no rediriges a fichero, la has perdido.

Conexión, una vez la instancia esté en running:

El usuario por defecto depende de la AMI: ec2-user en Amazon Linux, ubuntu en Ubuntu, admin en Debian. Conectarse como root está deshabilitado a propósito.

Existen dos alternativas que evitan gestionar ficheros .pem, y conviene conocerlas:

Session Manager (parte de AWS Systems Manager) es la opción que usará MercadoFresco en producción: la instancia no necesita IP pública ni puerto SSH abierto, porque es ella la que inicia la conexión saliente hacia AWS. Menos superficie de ataque y auditoría completa de quién entró y qué tecleó.

Los permisos IAM que esto requiere se detallan en la lección 04-01; los grupos de seguridad que controlan el puerto 22, en la 03-02.

El campo user data es un script que la instancia ejecuta como root, una sola vez, en su primer arranque. Es la diferencia entre "he creado un servidor" y "he creado un servidor que ya está sirviendo la tienda".

Este es el script de MercadoFresco. Guárdalo como user-data-tienda.sh:

Cómo se comporta y cómo se depura:

• Se ejecuta solo en el primer arranque. Si paras y arrancas la instancia, no se repite.
• La salida completa queda en /var/log/cloud-init-output.log dentro de la instancia. Cuando algo "no funciona y no sé por qué", ese fichero es la primera parada.
• Debe ser idempotente y sin interacción: nada de apt install sin -y, nada de esperar una pulsación de tecla.
• Nunca metas credenciales en user data: cualquiera con acceso a la instancia puede leerlo con curl a los metadatos. Para secretos se usa Secrets Manager (lección 04-03).

Cada instancia puede preguntarse a sí misma quién es, consultando una dirección especial que solo responde desde dentro: 169.254.169.254. Ahí viven los metadatos de instancia: su ID, su tipo, su AZ, sus IPs, sus etiquetas (si lo habilitas) y —muy importante— las credenciales temporales del rol IAM asociado.

Esa última parte explica por qué la seguridad de este endpoint importa tanto. La versión 1 (IMDSv1) respondía a cualquier GET, lo que permitía que una vulnerabilidad de tipo SSRF en la aplicación web hiciera que el propio servidor filtrara sus credenciales. IMDSv2 exige obtener antes un token por PUT, algo que un SSRF simple no puede hacer.

Rutas útiles en el día a día:

Política de MercadoFresco: exigir IMDSv2 siempre. Se fuerza al lanzar la instancia con --metadata-options "HttpTokens=required", como haremos en el comando de creación.

Haremos primero el camino visual, porque enseña el vocabulario, y después el mismo resultado por CLI, que es el que se automatiza.

1. Consola → busca EC2 → comprueba arriba a la derecha que la región es Irlanda (eu-west-1). Esta comprobación no es opcional: es la trampa que vimos en 01-04.
2. Instancias → Lanzar instancias.
3. Nombre y etiquetas: mercadofresco-tienda-01. Pulsa Agregar etiquetas adicionales y completa el esquema obligatorio del proyecto:
   • Proyecto = mercadofresco
   • Entorno = desarrollo
   • Componente = tienda
   • Propietario = luis
   • CentroCoste = operaciones
4. Imagen (AMI): Amazon Linux 2023, arquitectura x86_64. Fíjate en la etiqueta Apto para la capa gratuita.
5. Tipo de instancia: t3.micro.
6. Par de claves: selecciona mercadofresco-tienda (el que creaste antes) o créalo aquí y descarga el .pem.
7. Configuración de red: deja la VPC por defecto y crea un grupo de seguridad llamado sg-mercadofresco-tienda con dos reglas de entrada: HTTP (80) desde 0.0.0.0/0 y SSH (22) desde Mi IP. Nunca SSH abierto al mundo. El detalle de esto es la lección 03-02.
8. Almacenamiento: 8 GiB gp3, el valor por defecto. Los discos son la lección 02-02.
9. Detalles avanzados → despliega hasta el final y pega el contenido de user-data-tienda.sh en el campo Datos de usuario. En el mismo bloque, verifica que Versión de IMDS esté en V2 obligatorio.
10. Revisa el panel de resumen a la derecha y pulsa Lanzar instancia.

En 30-60 segundos el estado pasará a running y las comprobaciones de estado (2/2) se pondrán en verde. Copia la IP pública y ábrela en el navegador: verás la página de MercadoFresco con el ID de la instancia y su zona de disponibilidad.

Aviso de coste. Un t3.micro está dentro de la capa gratuita durante los 12 primeros meses (750 h/mes). Si ya la has agotado, cuesta del orden de 0,01 USD/hora en eu-west-1. El apartado final explica cómo borrarlo todo.

El mismo resultado, en un solo comando reproducible. Primero el grupo de seguridad mínimo (se detalla en 03-02; aquí es solo instrumental):

Y ahora la instancia:

Parámetro a parámetro, porque cada uno tiene su porqué:

• --user-data file://…: el prefijo file:// es obligatorio; sin él, la CLI enviaría la cadena literal user-data-tienda.sh como script. La CLI v2 codifica el fichero en base64 por ti.
• --metadata-options HttpTokens=required: fuerza IMDSv2. HttpPutResponseHopLimit=1 impide que un contenedor dentro de la instancia alcance los metadatos del host.
• --credit-specification CpuCredits=standard: en pruebas preferimos que la instancia se estrangule antes que generar cargos inesperados por unlimited.
• --tag-specifications: se pasa dos veces, una para la instancia y otra para el volumen. Este es el error de etiquetado más frecuente: se etiqueta la instancia, se olvida el disco, y en el módulo 11 aparece un gasto de EBS que no se sabe a quién imputar.

Comprobar el resultado con una consulta legible:

Ya tenemos un servidor. Pero un servidor no resuelve el problema 1: los viernes de 17:00 a 21:00 llegan 900 pedidos/hora y una instancia soporta 600. Y comprar una máquina más grande "para el viernes" significa pagarla las 168 horas de la semana para usarla 4.

La respuesta de AWS son dos piezas que trabajan juntas.

Es la receta versionada de cómo debe ser una instancia de la tienda: AMI, tipo, par de claves, grupo de seguridad, user data, etiquetas. Deja de haber "la instancia que montó Luis a mano"; hay una definición que cualquiera puede reproducir idéntica.

Las plantillas son versionadas: al cambiar el user data creas la versión 2 y puedes volver a la 1 si algo sale mal. Esa capacidad de revertir es el primer paso hacia el problema 4 (despliegues arriesgados), que se resolverá del todo en el módulo 8.

Un ASG mantiene un número de instancias sanas repartidas entre varias zonas de disponibilidad, y lo ajusta según la demanda. Tiene tres números:

El dimensionado sale de las cifras reales:

• --vpc-zone-identifier: dos subredes en dos AZ distintas (eu-west-1a y eu-west-1b), tal como decidimos en 01-03. Sustituye los IDs por los de tu VPC por defecto.
• --health-check-grace-period 120: da 2 minutos al user data antes de juzgar si la instancia está sana. Sin esta espera, el ASG mata instancias que aún se estaban instalando.
• PropagateAtLaunch=true: las etiquetas se copian a cada instancia nueva. Sin esto, las máquinas creadas por el ASG aparecerían sin etiquetar en la factura.

Y la política que hace el trabajo automáticamente:

El target tracking es la política recomendada: declaras el objetivo y AWS calcula solo cuándo añadir y cuándo quitar máquinas. Alternativas: escalado por pasos (umbrales manuales) y escalado programado, que para MercadoFresco tiene mucho sentido porque el pico es a hora conocida:

El flujo completo:

Falta una pieza para que esto funcione de verdad: algo que reparta el tráfico entre las instancias. Ese es el Elastic Load Balancing, la lección 03-03. Aquí hemos montado el motor; en el módulo 3 le conectaremos la dirección.

Regla de oro del curso: lo que creas en una lección, lo borras al terminarla.

Si quieres conservar la instancia para la lección siguiente sin pagar cómputo, párala en lugar de terminarla (seguirás pagando solo el volumen de 8 GiB, unos 0,64 USD al mes):

Y recuerda revisar el presupuesto presupuesto-mensual-mercadofresco que configuraste en 01-02: es tu red de seguridad si algo se queda encendido.

• Terminar creyendo que se para. El error irreversible por excelencia. Activa siempre --disable-api-termination en cualquier instancia con datos.
• Perder el fichero .pem. AWS no tiene copia. Si lo pierdes, la única salida es desconectar el volumen y montarlo en otra instancia. Guárdalo en el gestor de contraseñas y ten habilitado Session Manager como plan B.
• Abrir el puerto 22 a 0.0.0.0/0. Recibirás intentos de acceso automatizados en cuestión de minutos. Siempre <tu-ip>/32, o mejor, ningún puerto SSH y Session Manager.
• Sorprenderse porque la CPU se queda plana al 10 %. Son los créditos burstable agotados. Mira la métrica CPUCreditBalance antes de culpar a la aplicación.
• Olvidar file:// en --user-data. La instancia arranca "bien" pero no instala nada. Si el servidor web no responde, entra y lee /var/log/cloud-init-output.log.
• Etiquetar la instancia y no el volumen. Pasa --tag-specifications para instance y para volume, siempre.
• Esperar que user data se ejecute en cada arranque. Solo corre la primera vez. Para tareas de cada arranque, usa una unidad de systemd creada por el propio user data.
• Confundir la IP pública con algo estable. Cambia al parar y arrancar. Usa DNS (03-05).
• Dejar el ASG con min-size alto "por si acaso". Es la forma más silenciosa de multiplicar la factura: cada instancia del mínimo se paga 24×7.
• Consejo de oro: empieza pequeño y mide. Es infinitamente más barato subir de tamaño una instancia infradimensionada que descubrir en el módulo 11 que llevas seis meses pagando el doble.

MercadoFresco quiere abrir en dos ciudades más (problema 3). La previsión es que el pico de los viernes pase de 900 a 2.100 pedidos/hora. Cada instancia sigue soportando 600 pedidos/hora y la política de Marta exige que el servicio siga funcionando aunque caiga una zona de disponibilidad completa.

Calcula el mínimo, el deseado y el máximo del ASG, justificando cada número, y escribe el comando aws autoscaling update-auto-scaling-group correspondiente.

Luis lanza una instancia con el script de la lección, la instancia aparece running con 2/2 comprobaciones en verde, pero al abrir la IP pública el navegador se queda esperando indefinidamente (no da "conexión rechazada", simplemente no responde).

Enumera, en orden de coste creciente de investigación, los pasos que darías y qué comprobarías en cada uno. Indica cuál es la causa más probable dada la pista del "se queda esperando".

Para cada una de estas tres cargas de MercadoFresco, elige familia, tamaño aproximado y modelo de compra, y justifica en una frase:

• A) Servidor de la tienda en producción, tráfico sostenido las 24 horas, 4 GiB de RAM suficientes, CPU al 55 % de media.
• B) Proceso nocturno que recomprime las 40.000 fotos del catálogo; tarda 3 horas, satura la CPU, y si se interrumpe puede reanudarse desde donde iba.
• C) Entorno de desarrollo de Luis, encendido de 9:00 a 18:00 de lunes a viernes, casi siempre inactivo con ráfagas al compilar.

Solución 1.

• Mínimo = 2. En valle no hace falta más, pero nunca menos de 2 para tener una instancia en cada AZ y no depender de una sola.
• Deseado = 2. Es el punto de partida; la política de seguimiento de objetivo lo subirá sola. Se puede combinar con una acción programada que lo lleve a 4 los viernes a las 16:45.
• Máximo = 8. Cubre las 4 necesarias más el margen para que, si cae una AZ, las 4 restantes puedan lanzarse en la que sigue en pie. El máximo también actúa como tope de gasto: si un ataque o un error dispara la CPU, nunca se pasará de 8 instancias.

Solución 2.

El matiz clave: "se queda esperando" ≠ "conexión rechazada". Si nginx estuviera caído pero la red llegase, el sistema operativo devolvería un rechazo inmediato. Un tiempo de espera agotado indica que los paquetes no llegan a la instancia, es decir, un problema de red, no de software.

Pasos por coste creciente:

1. Grupo de seguridad (30 segundos, sin entrar en la máquina): comprobar que existe una regla de entrada TCP 80 desde 0.0.0.0/0. Esta es la causa más probable.

   aws ec2 describe-security-groups --group-ids "$SG_ID" \\
     --query 'SecurityGroups[].IpPermissions' \\
     --profile mercadofresco-dev --region eu-west-1
   

2. IP pública: verificar que la instancia tiene una (PublicIpAddress no nulo) y que estás usando esa y no la privada 172.31.x.x.
3. Subred pública: la subred debe tener ruta a una puerta de enlace de internet (esto se entiende del todo en 03-01).
4. Entrar por Session Manager (no requiere puerto 22, útil precisamente cuando la red falla) y:

   sudo systemctl status nginx
   sudo tail -50 /var/log/cloud-init-output.log
   curl -s localhost   # si esto responde, el servidor está bien y el problema es de red
   

Solución 3.

MercadoFresco ya tiene su primer servidor en AWS, y sobre todo tiene el vocabulario y los mecanismos para razonar sobre él. Sabes que una AMI es la plantilla y la instancia la copia viva, y que el ID de una AMI cambia con la región, por lo que se consulta y no se copia. Sabes descifrar t3.micro y elegir entre las familias T, M, C y R en función de si la carga es irregular, equilibrada, intensiva en CPU o intensiva en memoria. Has visto por dentro el mecanismo de los créditos de CPU y has calculado que un t3.micro no sobrevive a las cuatro horas del pico de los viernes: un dato concreto, no una intuición.

Conoces los cuatro modelos de compra y en qué caso encaja cada uno, y dominas el ciclo de vida con la distinción que más cara sale: parar conserva el disco, terminar lo destruye para siempre. Sabes acceder a la máquina con un par de claves y también sin él, mediante EC2 Instance Connect o Session Manager, que es la opción que MercadoFresco usará en producción por no requerir ningún puerto abierto. Has automatizado la instalación completa de la tienda con user data, sabes dónde leer su log cuando falla, y has protegido los metadatos exigiendo IMDSv2. Has creado la instancia por consola y por CLI aplicando el esquema de etiquetado del proyecto tanto a la instancia como a su volumen.

Y, sobre todo, has puesto la primera pieza real contra el problema 1: una plantilla de lanzamiento versionada y un grupo de Auto Scaling de 2 a 4 instancias con seguimiento de objetivo y escalado programado, dimensionado con las cifras reales de MercadoFresco (900 pedidos/h frente a 600 por instancia). Falta el balanceador que reparta el tráfico entre ellas, y eso es la lección 03-03.

Antes de eso hay una pregunta que el Auto Scaling deja al descubierto: si las instancias nacen y mueren solas, ¿dónde viven los datos? Las fotos de producto que hoy están en /var/www/fotos no pueden estar dentro de un disco que se destruye con la máquina. En la lección 02-02, «Almacenamiento de bloques y de archivos: EBS y EFS», veremos los volúmenes que sobreviven a la instancia, cómo se amplían en caliente, cómo se comparten entre varias máquinas y cómo los snapshots automatizados con Data Lifecycle Manager cierran de una vez el problema 2 de MercadoFresco: las copias de seguridad que nunca fueron fiables.