La lección anterior terminó con una pregunta incómoda: si el grupo de Auto Scaling crea y destruye instancias de la tienda de MercadoFresco según el tráfico del viernes, ¿dónde viven los datos? Las fotos de producto que hoy están en /var/www/fotos del servidor de la oficina no pueden vivir dentro de un disco que desaparece cuando el ASG decide que sobra una máquina.

Esta lección responde a esa pregunta desde dos ángulos complementarios. Amazon EBS (Elastic Block Store) da a cada instancia discos que sobreviven a la máquina, se amplían en caliente y se copian solos. Amazon EFS (Elastic File System) da a varias instancias a la vez un sistema de archivos compartido, que es exactamente lo que el Auto Scaling necesita para que las cuatro máquinas del viernes vean las mismas fotos.

Y por el camino cerramos el problema 2 de MercadoFresco: las copias de seguridad no fiables. El disco duro externo que Marta conecta "cuando se acuerda" se sustituye por snapshots incrementales automatizados con Data Lifecycle Manager, con retención definida y copia a otra región.

1. Los tres modelos de almacenamiento: bloques, archivos y objetos
2. Qué es un volumen EBS y qué garantiza
3. Tipos de volumen EBS y cómo elegir
4. Dimensionar gp3: IOPS y rendimiento independientes del tamaño
5. Crear, adjuntar, formatear y montar un volumen
6. Ampliar un volumen en caliente, sin parar la tienda
7. Snapshots: qué son, cómo se cobran y cómo se restauran
8. Data Lifecycle Manager: el fin del problema 2
9. Cifrado de volúmenes
10. Instance store: rápido, local y efímero
11. Amazon EFS: un sistema de archivos para varias instancias
12. Montar EFS en las instancias de la tienda
13. Tabla final: EBS, EFS, instance store y S3

Antes de tocar ningún servicio hay que tener clara una distinción que ordena todo el capítulo del almacenamiento en la nube. No son tres productos que compiten: son tres modelos distintos de guardar datos, y cada uno resuelve un problema diferente.

La regla mental que conviene fijar:

• Bloques: cuando el software espera un disco. Un sistema operativo, PostgreSQL, un motor de base de datos. Nada de esto sabe hablar HTTP.
• Archivos: cuando varios servidores deben compartir los mismos ficheros y el software espera rutas del sistema de ficheros (/var/www/fotos). Es la vía de mínima modificación cuando migras una aplicación heredada.
• Objetos: cuando el dato es un fichero completo que se escribe una vez y se lee muchas. Es el más barato, el más duradero y el más escalable, pero exige que la aplicación use su API.

Para MercadoFresco, las fotos de producto podrían ir a EFS (sin tocar el código) o a S3 (cambiando el código, más barato y mejor a largo plazo). Veremos EFS aquí y S3 en la lección 02-03, donde quedará claro por qué esa es la decisión definitiva.

Un volumen EBS es un disco virtual que se conecta por red a una instancia EC2, pero que el sistema operativo ve exactamente como un disco local: aparece en lsblk, se formatea con mkfs y se monta con mount.

Sus propiedades esenciales:

• Es independiente de la instancia. Si terminas la instancia, el volumen puede sobrevivir (depende del atributo DeleteOnTermination). Puedes desconectarlo y conectarlo a otra máquina.
• Vive en una sola zona de disponibilidad. Un volumen de eu-west-1a no se puede conectar a una instancia de eu-west-1b. Para moverlo hay que hacer un snapshot y restaurarlo en la otra AZ.
• Está replicado dentro de su AZ. AWS mantiene varias copias en distintos servidores: un fallo de disco físico no te afecta. Pero un fallo de la AZ completa, sí. Por eso los snapshots importan.
• Se paga por GB provisionado, no por GB usado. Un volumen de 500 GiB con 3 GiB de datos cuesta como 500 GiB. Este es uno de los gastos ocultos más habituales.
• Se puede ampliar en caliente, pero no reducir. Dimensiona con cabeza.

Fíjate en el detalle importante del diagrama: mercadofresco-tienda-02 no puede conectarse al volumen de fotos de la otra AZ. Ese límite es precisamente el que empuja hacia EFS o S3.

Existen dos categorías: SSD, optimizados para operaciones por segundo (IOPS) y acceso aleatorio, y HDD, optimizados para rendimiento secuencial (MB/s) y coste por GB.

Los precios son orientativos y cambian; consúltalos siempre en la calculadora de AWS. Lo que no cambia es el orden de magnitud entre ellos.

Cuatro criterios de decisión:

1. Empieza siempre por gp3. Es más barato que gp2 en un ~20 % y da 3.000 IOPS de base aunque el volumen sea de 1 GiB.
2. Sube a io2 solo si has medido que necesitas más de 16.000 IOPS o si el negocio exige la durabilidad de cinco nueves. Es caro.
3. HDD (st1/sc1) solo para acceso secuencial. Si la carga hace muchas lecturas pequeñas y aleatorias, un HDD dará un rendimiento pésimo aunque el precio por GB sea tentador.
4. Los HDD no pueden ser volúmenes de arranque. El disco raíz siempre es SSD.

Migrar de gp2 a gp3 es gratis, en caliente y ahorra dinero. Si heredas una cuenta con volúmenes gp2, este es el ahorro más fácil que existe:

Aquí está la mejora conceptual de gp3 frente a gp2, y merece detenerse porque explica muchas decisiones de arquitectura.

Con gp2, el rendimiento estaba atado al tamaño: 3 IOPS por GiB. Si querías 3.000 IOPS, tenías que provisionar 1.000 GiB, aunque solo usaras 40. Se compraba espacio para comprar velocidad.

Con gp3, los tres parámetros se contratan por separado:

Comparación para el caso de MercadoFresco, que necesita 100 GiB y 3.000 IOPS:

Un factor 12 de diferencia por conocer el tipo correcto de volumen. Y si más adelante la base de datos necesitara 6.000 IOPS, se añaden sin tocar el tamaño:

Un límite práctico que hay que conocer: la instancia también tiene un techo. Un t3.micro no podrá aprovechar 16.000 IOPS por mucho que las contrates, porque su ancho de banda hacia EBS está limitado. Para cargas de disco intensivas se usan instancias "optimizadas para EBS" de tamaño suficiente. Sirve de poco un volumen rapidísimo colgado de una instancia diminuta.

Vamos a darle a mercadofresco-tienda-01 un disco dedicado de 20 GiB para las fotos de producto, separado del disco de sistema. Separar datos de sistema es una buena práctica: puedes reinstalar la máquina sin tocar los datos, y hacer snapshots solo de lo que importa.

• --encrypted activa el cifrado en reposo con la clave gestionada por AWS. Cuesta lo mismo que sin cifrar y no se puede añadir después, así que se pone siempre desde el principio.
• El Componente es catalogo, porque son las fotos de producto, no la tienda en sí. El esquema de etiquetado permite luego imputar el coste al equipo correcto.

Un detalle que despista: pides /dev/sdf pero Amazon Linux con kernel moderno y NVMe lo mostrará como /dev/nvme1n1. El nombre que pides es una etiqueta; el que ves dentro depende del sistema. Por eso nunca se monta por nombre de dispositivo en /etc/fstab, sino por UUID.

Sin este paso, el montaje se pierde en el siguiente reinicio y la tienda arranca con el directorio de fotos vacío.

La opción nofail no es decorativa. Sin ella, si el volumen no está disponible al arrancar, la instancia se queda bloqueada en el arranque y no podrás entrar ni por SSH. Es una de las formas más frecuentes de "perder" una instancia en EC2. Ejecuta siempre sudo mount -a antes de reiniciar para comprobar que la línea de fstab es correcta.

En noviembre, con la campaña de Navidad, las fotos del catálogo llenan los 20 GiB. Ampliar es una operación en dos mitades: primero el volumen en AWS, después el sistema de archivos dentro de la instancia. Si haces solo la primera, df -h seguirá mostrando 20 GiB y pensarás que no ha funcionado.

Restricciones importantes:

• No se puede reducir un volumen. La única vía es crear uno más pequeño, copiar los datos y eliminar el grande.
• Entre dos modificaciones del mismo volumen deben pasar al menos 6 horas.
• La ampliación es transparente para la aplicación: no hace falta parar nginx ni desmontar.

Un snapshot es una copia puntual de un volumen guardada en Amazon S3 (en un espacio gestionado por AWS, no en un bucket tuyo). Es la base de las copias de seguridad en EC2 y la respuesta al problema 2 de MercadoFresco.

Tres propiedades que hay que entender bien, porque casi todo el mundo las malinterpreta:

1. Son incrementales, pero cada uno es completo. El primer snapshot copia todos los bloques usados. El segundo copia solo los bloques que han cambiado desde el primero. Sin embargo, restaurar el segundo devuelve el volumen entero, no un diferencial. AWS gestiona las referencias internamente.
2. Borrar un snapshot intermedio es seguro. Si borras el snapshot 2, AWS conserva los bloques que el snapshot 3 todavía necesita. Nunca se corrompe una cadena por borrar un eslabón.
3. Se cobran por GB de datos únicos almacenados (≈0,05 USD/GB-mes), no por el tamaño del volumen. Un volumen de 50 GiB con 8 GiB de datos que apenas cambian genera snapshots muy baratos.

Coherencia de los datos. Un snapshot captura lo que hay en el disco, no lo que la aplicación tiene en memoria. Para ficheros estáticos como las fotos es suficiente. Para una base de datos hay que congelar el sistema de archivos o, mucho mejor, usar las copias nativas del motor —que es exactamente lo que hace RDS y veremos en la lección 02-04.

Un snapshot no se restaura sobre el volumen original: crea un volumen nuevo. Este es el mecanismo que permite mover datos entre zonas de disponibilidad, algo que un volumen EBS no puede hacer por sí solo.

Copiar snapshots entre regiones tiene coste de transferencia de datos y de almacenamiento en destino, pero es la protección real contra el fallo de una región entera.

Hasta ahora las copias de MercadoFresco eran "Marta conecta el disco externo cuando se acuerda": sin calendario, sin verificación y sin copia fuera de la oficina. Eso es el problema 2. Un snapshot manual como el anterior no lo arregla, porque también depende de que alguien se acuerde.

Amazon Data Lifecycle Manager (DLM) ejecuta snapshots según una política: a qué recursos aplica (seleccionados por etiquetas), con qué frecuencia, cuántos conservar y adónde copiarlos. Aquí se ve por qué el esquema de etiquetado de MercadoFresco no era burocracia: es el mecanismo de selección de la política.

Primero, el rol que DLM necesita para actuar en tu nombre (IAM se detalla en 04-01):

Y la política, guardada en politica-dlm.json:

Qué hace exactamente esta política, línea a línea:

• TargetTags: se aplica a todos los volúmenes etiquetados Proyecto=mercadofresco. Cualquier volumen nuevo que Luis cree con la etiqueta correcta entra automáticamente en el plan de copias, sin que nadie tenga que acordarse. Ese es el cambio cultural.
• Programación diaria: cron(0 2 * * ? *) = todos los días a las 02:00 UTC. Conserva los últimos 7; al crear el octavo, borra el más antiguo, así que el coste se estabiliza.
• Programación semanal: domingos a las 03:00 UTC, conserva 4 y copia cada uno a eu-central-1 cifrado. Un mes de historia fuera de la región principal.
• CopyTags: true: los snapshots heredan las etiquetas del volumen, con lo que el coste de las copias también queda imputado a su CentroCoste.

Con esto, el problema 2 queda resuelto en su parte de disco:

Falta un matiz honesto: una copia no probada no es una copia. Marta apunta en el calendario una prueba de restauración trimestral: crear un volumen desde el último snapshot, montarlo en una instancia de pruebas y verificar que las fotos están. La parte de la base de datos de este problema se cerrará en la lección 02-04, con las copias automáticas y el PITR de RDS.

El cifrado de EBS es transparente: se cifran los datos en reposo, los datos en tránsito entre la instancia y el volumen, y todos los snapshots derivados. No hay que cambiar nada en la aplicación y el impacto en rendimiento es despreciable.

Puntos prácticos:

• No se puede cifrar un volumen existente. El procedimiento es: snapshot → copia del snapshot con --encrypted → crear volumen nuevo desde esa copia → intercambiar.
• Se puede activar el cifrado por defecto en la región, y es muy recomendable:

A partir de ahí, todo volumen nuevo en eu-west-1 nace cifrado aunque nadie lo pida.

• Las claves las gestiona AWS KMS. Puedes usar la clave gestionada por AWS (aws/ebs, gratis) o una clave propia que te dé control de la rotación y de quién puede descifrar. KMS es la lección 04-02; por ahora basta con saber que el cifrado se activa con una casilla.

Algunas familias de instancias (las que llevan d en el nombre, como m6id.large, y las familias i y d) incluyen discos NVMe físicamente conectados al servidor anfitrión. Es el instance store.

Es efímero por diseño: al parar la instancia, AWS la moverá a otro host físico al arrancarla, y ese host tiene otros discos. Un reinicio (reboot) sí conserva los datos, porque no cambia de host; un stop/start, no.

Usos legítimos: cachés, ficheros temporales, datos intermedios de un proceso de cálculo, scratch de compilación. Para MercadoFresco no aplica hoy, pero conviene reconocerlo para no elegir por error una instancia d pensando que el disco incluido es un ahorro.

Volvemos al problema que abrió la lección. El grupo de Auto Scaling levanta 4 instancias el viernes. Cada una tiene su volumen EBS. Si Luis sube una foto de producto nueva a la instancia 1, las otras tres no la ven. Y ninguna instancia de eu-west-1b puede ni siquiera conectarse al volumen de fotos que vive en eu-west-1a.

Amazon EFS resuelve exactamente esto: un sistema de archivos NFS v4.1 gestionado que se monta simultáneamente en miles de instancias, en varias AZ, y que crece y decrece solo.

Sus características diferenciales:

• Elástico de verdad: no se provisiona tamaño. Pagas por los GB que realmente guardas (≈0,30 USD/GB-mes en Standard, unas 3,4 veces más caro que EBS gp3).
• Regional: se accede desde cualquier AZ de la región mediante "objetivos de montaje" (mount targets), uno por subred.
• Compartido: lectura y escritura concurrente desde todas las instancias montadas.
• Semántica POSIX: permisos, propietarios, enlaces. Para la aplicación es un directorio normal.

La gestión del ciclo de vida es automática: se configura "mueve a IA lo que lleve 30 días sin tocarse" y EFS lo hace solo. Para el catálogo de MercadoFresco encaja perfectamente, porque las fotos de los productos de temporada dejan de consultarse fuera de su época.

En la práctica: General Purpose + Elastic salvo que midas que no te llega.

El grupo de seguridad sg-efs-mercadofresco debe permitir el puerto 2049 (NFS) desde el grupo de seguridad de las instancias de la tienda. Es el fallo número uno al montar EFS y se explica a fondo en la lección 03-02.

Dentro de la instancia:

Ese tamaño de "8.0E" (8 exabytes) es la forma que tiene NFS de decir "ilimitado": no hay tamaño que provisionar.

La línea correspondiente iría en el user data de la plantilla de lanzamiento que creamos en 02-01, para que cada instancia nueva del ASG monte las fotos automáticamente al arrancar. Con eso, el diagrama del principio deja de tener el problema:

Aviso de coste y honestidad técnica. EFS resuelve el problema sin tocar el código de MercadoFresco, y por eso es la respuesta correcta cuando migras una aplicación heredada con prisa. Pero para servir fotos de producto a navegadores es caro (≈3,4× EBS, ≈13× S3 Standard), sigue consumiendo CPU y ancho de banda de las instancias, y no aprovecha ninguna red de distribución. En la lección 02-03 moveremos /var/www/fotos a S3, que es la decisión definitiva de MercadoFresco, y en 03-04 pondremos CloudFront delante.

• Crear el volumen en una AZ distinta a la de la instancia. El attach-volume fallará. Consulta siempre Placement.AvailabilityZone de la instancia antes de crear el disco.
• Olvidar /etc/fstab y descubrir tras un reinicio que la tienda sirve un directorio vacío. Y al revés: poner una línea mal en fstab sin nofail y dejar la instancia sin arrancar. Ejecuta sudo mount -a antes de cada reinicio.
• Ampliar el volumen en AWS y no extender el sistema de archivos. df -h no cambia y parece que la ampliación no ha funcionado. Faltan growpart y/o xfs_growfs/resize2fs.
• Creer que se puede reducir un volumen. No se puede. Provisiona con criterio y amplía cuando haga falta.
• Volúmenes huérfanos. Al terminar instancias quedan volúmenes en estado available que se siguen pagando y que nadie mira. Revísalo cada mes:

  aws ec2 describe-volumes --filters Name=status,Values=available \\
    --query 'Volumes[].{ID:VolumeId,GB:Size,Creado:CreateTime}' --output table \\
    --profile mercadofresco-dev --region eu-west-1
  

• Snapshots que se acumulan para siempre. Cientos de snapshots manuales sin política de retención son un goteo constante en la factura. Por eso todo debe pasar por DLM.
• Confiar en una copia que nunca se ha restaurado. Prueba la restauración cada trimestre.
• Seguir usando gp2. Migrar a gp3 es gratis, en caliente y más barato.
• Montar EFS sin abrir el puerto 2049. El mount se queda colgado sin mensaje claro. Revisa el grupo de seguridad del EFS.
• Usar EFS para todo por comodidad. Es la opción cara. Úsalo cuando necesites semántica POSIX compartida; para ficheros que se sirven por HTTP, S3.
• No cifrar desde el principio. Cuesta lo mismo y no se puede añadir después sin recrear el volumen. Activa enable-ebs-encryption-by-default en la región y olvídate.

La base de datos de pedidos de MercadoFresco necesita 200 GiB de espacio y, medido durante el pico de los viernes, 5.000 IOPS sostenidas con un rendimiento de 200 MB/s.

1. ¿Qué tipo de volumen elegirías y con qué configuración exacta?
2. Calcula el coste mensual aproximado con los precios de la tabla (0,088 USD/GB-mes, 0,006 USD por IOPS extra, 0,048 USD por MB/s extra).
3. ¿Cuánto costaría lo mismo con gp2? ¿Y por qué gp2 obligaría además a otra decisión?

Marta quiere una política de copias que cumpla estos requisitos de negocio:

• Copia cada 12 horas de todos los volúmenes de producción, conservando 14 días.
• Copia mensual conservada 12 meses y replicada a eu-central-1.
• Los volúmenes de desarrollo solo necesitan copia diaria con 3 días de retención.
• Las copias deben poder imputarse al centro de coste correcto en la factura.

Explica cómo estructurarías las políticas de DLM y qué etiquetas hacen posible cada selección.

Para cada situación de MercadoFresco, elige entre EBS, EFS, instance store o S3, y justifica en dos frases:

• A) El disco de arranque de las instancias de la tienda.
• B) Un directorio /var/www/uploads donde los clientes suben fotos de incidencias con su pedido, y que las 4 instancias del ASG deben ver por igual, sin poder tocar el código PHP.
• C) Los ficheros temporales del proceso nocturno que recomprime 40.000 fotos del catálogo.
• D) Las 40.000 fotos del catálogo servidas a los navegadores de los clientes.

Solución 1.

1. gp3, 200 GiB, con 5.000 IOPS y 200 MB/s provisionados. No hace falta io2: el límite de gp3 es 16.000 IOPS y 1.000 MB/s, muy por encima de lo pedido, y io2 es bastante más caro. Un detalle adicional: hay que comprobar que la instancia admite ese rendimiento hacia EBS (un t3.micro no; haría falta un tipo optimizado para EBS de tamaño adecuado).

2. Coste gp3:

   Almacenamiento: 200 GB × 0,088          = 17,60 USD
   IOPS extra:     (5.000 − 3.000) × 0,006 = 12,00 USD
   Rendimiento extra: (200 − 125) × 0,048  =  3,60 USD
   ------------------------------------------------------
   Total                                    ≈ 33,20 USD/mes
   

3. Con gp2, el rendimiento va ligado al tamaño a razón de 3 IOPS/GiB, así que para 5.000 IOPS harían falta 1.667 GiB:

   1.667 GB × 0,11 ≈ 183 USD/mes
   

   Más de 5 veces el coste, y con la decisión forzada de provisionar 1.667 GiB para usar 200: pagas 1.467 GiB de espacio vacío solo para comprar velocidad. Este es el argumento definitivo para no usar gp2 en nada nuevo.

Solución 2.

Se crean tres políticas de DLM, todas seleccionando por etiquetas, que es lo que hace que funcione sin mantenimiento:

Claves del diseño:

• TargetTags con dos etiquetas actúa como un Y lógico: solo entran los volúmenes que llevan ambas. Por eso el esquema de etiquetado obligatorio del proyecto es lo que hace viable la automatización: un volumen nuevo bien etiquetado queda protegido sin que nadie intervenga.
• CopyTags: true propaga CentroCoste, Componente y Propietario a cada snapshot, con lo que el coste de las copias aparece correctamente repartido en Cost Explorer (lección 11-03).
• La retención se expresa en número de snapshots, no en días: hay que traducir la frecuencia. A 2 copias diarias, 14 días son 28 snapshots.
• Se pueden agrupar las dos primeras en una sola política con dos Schedules (DLM admite hasta cuatro por política); separarlas es igual de válido y más legible.

Solución 3.

Has aprendido a distinguir los tres modelos de almacenamiento —bloques, archivos y objetos— y a reconocer por la forma del problema cuál toca en cada caso: si el software espera un disco, bloques; si varios servidores comparten ficheros con rutas POSIX, archivos; si el dato es un fichero completo servido por HTTP, objetos.

En EBS sabes que un volumen vive en una sola AZ, que se paga por GB provisionado y no usado, y que se amplía pero nunca se reduce. Sabes elegir entre gp3, gp2, io2, st1 y sc1, y has calculado con números por qué gp3 es la opción por defecto: al desacoplar tamaño, IOPS y rendimiento, evita el absurdo de gp2 de comprar 1.667 GiB para conseguir 5.000 IOPS. Has recorrido el ciclo completo de un disco de datos: create-volume, attach-volume, lsblk, mkfs, mount, la línea de /etc/fstab por UUID y con nofail, y la ampliación en caliente en sus dos mitades, modify-volume en AWS y xfs_growfs dentro de la máquina.

Has entendido los snapshots de verdad: incrementales en el cobro pero completos en la restauración, seguros de borrar en cualquier punto de la cadena, capaces de mover datos entre AZ y entre regiones. Y con Data Lifecycle Manager has convertido esa capacidad en un plan de copias que se ejecuta solo, selecciona por etiquetas y retiene lo justo: siete diarias, cuatro semanales replicadas a eu-central-1. Con eso, la parte de disco del problema 2 de MercadoFresco —las copias que dependían de que alguien se acordara— está cerrada, con la advertencia de que una copia sin prueba de restauración no cuenta como copia.

Conoces además el cifrado transparente de EBS y por qué se activa por defecto en la región, y sabes qué es el instance store y por qué su velocidad no compensa su volatilidad salvo para datos desechables. Por último, EFS te ha dado la primera solución real al problema que dejó abierto el Auto Scaling: un sistema de archivos NFS regional, elástico y montado a la vez en las cuatro instancias del viernes, con sus clases de almacenamiento y sus modos de rendimiento.

Pero cerramos con una decisión pendiente y deliberada. EFS resuelve el problema de las fotos sin tocar el código, y por eso es la respuesta correcta con prisa. No es la respuesta correcta a largo plazo: es unas trece veces más caro que la alternativa, obliga a que el tráfico de imágenes pase por las instancias y no aprovecha la escala global de AWS. En la lección 02-03, «Amazon S3», migraremos de verdad /var/www/fotos con aws s3 sync, conoceremos los once nueves de durabilidad, las clases de almacenamiento con reglas de ciclo de vida que abaratan las fotos antiguas del catálogo, el versionado que protege de los borrados accidentales, las URLs prefirmadas con las que Sara descargará sus informes sin credenciales, y los eventos que más adelante dispararán una función Lambda para generar las miniaturas.