Decisiones de almacenamiento con impacto directo en factura, rendimiento y seguridad. Foco en saber elegir, no solo en saber configurar. Y en S3 — el servicio que mejor encarna la potencia y los peligros de AWS — bajamos al detalle de la seguridad, donde más brechas se producen en cuentas reales.
Objetivos de aprendizaje
Elegir el tipo de volumen EBS adecuado por workload (gp3, io2, st1, sc1).
Diseñar una política de snapshots y restauración.
Usar S3 con criterio: clases, lifecycle, versionado y replicación cross-region.
Configurar la seguridad de S3 sin dejar buckets expuestos.
Decidir cuándo EFS es la solución correcta y cuándo no.
Diseñar una estrategia de backup centralizada con AWS Backup.
4.1 EBS en profundidad
Ya vimos en el Módulo 2 que EBS es el disco de bloques de una EC2. Aquí entramos en el detalle de elección y rendimiento.
Tipo
IOPS
Throughput
€/GB·mes (orientativo)
Caso
gp3 (SSD)
3.000 base, hasta 16.000
125 MB/s base, hasta 1.000
~0,08 €
Defecto moderno. IOPS y throughput configurables sin cambiar de tipo.
io2 / io2 Block Express (SSD)
Hasta 256.000
Hasta 4.000 MB/s
~0,12 € + IOPS
Bases de datos con SLA estricto, latencia crítica.
st1 (HDD)
Throughput optimizado
500 MB/s
~0,04 €
Cargas secuenciales: logs, big data, ETL.
sc1 (HDD cold)
Bajo
250 MB/s
~0,02 €
Archivo poco accedido cuando aún hace falta tenerlo accesible.
Migración recomendada: si tienes volúmenes gp2 antiguos, migra a gp3. Cuesta menos por GB y da más IOPS y throughput por defecto. La migración se hace en caliente (modify-volume) sin parada.
Snapshots: copias incrementales y baratas
Un snapshot copia solo los bloques cambiados desde el snapshot anterior — el primer snapshot es completo, el resto son baratos. Se almacenan en S3 (no lo ves directamente). Cifrado KMS heredado del volumen.
Buenas prácticas: usar Data Lifecycle Manager (DLM) para automatizar snapshots por etiqueta (p.ej. todos los volúmenes con Backup=daily) y aplicar retención (mantener 7 diarios + 4 semanales + 6 mensuales).
4.2 S3: el almacenamiento más versátil
Amazon S3 es el servicio de almacenamiento de objetos. Pensado para archivos completos (no bloques), accesibles por HTTP(S), con escalabilidad prácticamente ilimitada y durabilidad 99,999999999% (once nueves).
Usos típicos en una consultora: backups, distribución de assets estáticos, data lake, logs centralizados, intercambio de archivos con clientes. Es el servicio en el que más termina viviendo cualquier organización con AWS.
Conceptos básicos
Bucket: contenedor de objetos. Nombre único globalmente.
Objeto: archivo + metadata + clave (la "ruta").
Versionado: opcional, conserva versiones anteriores al sobrescribir/borrar.
Replicación: copia automática entre buckets (misma o distinta región).
4.3 Clases de S3 y lifecycle
S3 tiene varias clases de almacenamiento con precio y latencia distintos. Elegir bien es lo que diferencia una factura razonable de una factura sorprendente.
Clase
Acceso
Coste por GB·mes
Caso
Standard
Inmediato
~0,022 €
Datos activos y muy consultados.
Intelligent-Tiering
Inmediato (mueve automáticamente)
~0,022 € + coste de monitorización
Patrones de acceso impredecibles. AWS optimiza por ti.
Standard-IA (infrequent)
Inmediato
~0,012 € + coste por GET
Backup activo, snapshots, datos consultados <1/mes.
One Zone-IA
Inmediato (1 sola AZ)
~0,010 €
Datos recreables que no exigen alta disponibilidad.
Glacier Instant Retrieval
Inmediato
~0,004 € + restore
Archivo accedido pocas veces al año.
Glacier Flexible
Minutos a horas
~0,0036 €
Archivo regulatorio, compliance.
Glacier Deep Archive
Horas (hasta 12h)
~0,001 €
El más barato. Archivo a 7-10 años.
Lifecycle policies: el ahorro automático
Una lifecycle policy mueve objetos entre clases según su antigüedad, o los elimina pasado un plazo. Es el mecanismo que reduce sin esfuerzo la factura de S3 sin perder datos.
S3 lifecycle — terminal
Practica · empareja caso con clase de S3
Pulsa un caso y luego la clase adecuada. Después, "Comprobar".
Assets de la web pública (imágenes, CSS, JS) servidos constantemente
Backups diarios consultados muy pocas veces al mes
Logs históricos auditables, consultados un par de veces al año
Documentación legal a 10 años, prácticamente nunca consultada
S3 Standard
S3 Standard-IA
S3 Glacier Flexible
S3 Glacier Deep Archive
4.4 Seguridad en S3: la frontera más sensible
S3 es el servicio donde se concentra el mayor número de filtraciones de datos en AWS. Casi todas tienen el mismo origen: un bucket que se hizo público sin querer. Por eso AWS ha endurecido los defectos a lo largo de los años — y por eso conviene entender la pila de controles.
Las cuatro capas de control
Block Public Access (BPA) — el cinturón de seguridad. Activado por defecto a nivel cuenta desde 2023. Impide configuraciones públicas, incluso si alguien lo intenta. Déjalo activado salvo necesidad muy justificada.
Bucket policy — JSON con quién puede hacer qué sobre el bucket. La forma estándar moderna de dar acceso (a otra cuenta, a un rol, a un servicio).
IAM policies — permisos a usuarios/roles. Para acceso desde dentro de tu cuenta.
ACL — el sistema antiguo, granularidad por objeto. AWS recomienda no usarlo (desactivado por defecto en buckets nuevos).
Anti-patrón clásico que cuesta brechas: dar permiso público "para que la web cargue las imágenes". Lo correcto es: bucket privado + CloudFront (CDN) delante con una Origin Access Identity. Así el bucket nunca se expone y tú controlas qué se sirve y cómo.
Cifrado en reposo
Activado por defecto en todos los buckets nuevos desde 2023 (SSE-S3). Si tienes requisitos de cumplimiento que exigen tus propias claves: SSE-KMS (gestionado por AWS KMS con tu clave) o SSE-C (claves que aportas tú).
4.5 EFS para POSIX compartido
Amazon EFS es un sistema de archivos NFS gestionado, montable simultáneamente desde varias instancias EC2 (incluso entre AZ). Cumple POSIX — soporta permisos, locking y la semántica de un filesystem clásico.
EBS
S3
EFS
Modelo
Bloques
Objetos
Archivos (NFS)
Acceso
1 instancia (mismo AZ)
HTTPS, ilimitado
N instancias en N AZ
Caso típico
Disco de servidor
Backups, web, data lake
Carpeta compartida entre servidores
Coste relativo
Bajo
Muy bajo
Alto (3-4× S3)
Cuándo NO usar EFS: si tu necesidad es "guardar archivos a los que acceder por API", usa S3 — EFS es caro y aporta complejidad. Reserva EFS para casos que exigen filesystem POSIX compartido: WordPress en cluster, herramientas legacy que escriben en una carpeta común, render farms.
4.6 Estrategia de backup centralizada
Cuando creces, gestionar snapshots de EBS, copias de RDS y exportaciones de DynamoDB cada uno por su lado se vuelve insostenible. AWS Backup centraliza todo en un solo plan: defines la política, el servicio decide.
Conceptos
Backup plan: regla (cada cuánto y cuánto se retiene).
Backup vault: dónde se guardan los backups. Se puede cifrar con KMS y aislar por cuenta.
Resource assignment: a qué recursos aplica (por etiquetas o IDs).
Cross-region / cross-account copies: para DR real.
Patrón sólido: AWS Backup en la cuenta del cliente con copia automática a un backup vault en otra cuenta (cuenta de "vault" centralizada) y en otra región. Si pasa lo peor (cuenta comprometida, ransomware, error humano), el backup sigue intacto en una cuenta separada con permisos mínimos.
Práctica del módulo
Ejercicio 4.1 · Diseña el storage de un cliente
Para una pyme con: (a) una web pública con muchas imágenes; (b) una base de datos PostgreSQL en EC2 con 50 GB y SLA estricto; (c) 2 TB de logs históricos auditables; (d) backups diarios del último año. Diseña qué servicio y qué clase usarías para cada uno, y por qué.
Pista: (a) S3 Standard tras CloudFront, sin acceso público al bucket; (b) EBS io2 con cifrado KMS y snapshots diarios; (c) S3 con lifecycle 30d Standard-IA → 90d Glacier → 7y Deep Archive; (d) AWS Backup, vault cifrado, copia cross-region.
Ejercicio 4.2 · Lab guiado · Política de logs en S3
En tu sandbox: (1) crea un bucket privado logs-test-<tu nombre> con Block Public Access activado; (2) sube tres ficheros ficticios bajo logs/; (3) aplica una lifecycle policy con las transiciones del ejemplo del módulo; (4) verifica con aws s3api get-bucket-lifecycle-configuration; (5) borra el bucket y los objetos.
Test de comprensión
1. Tienes un volumen gp2 antiguo en producción. ¿Qué hace AWS recomendado?
Mantenerlo, gp2 es lo más nuevo.
Migrarlo a gp3 en caliente: más barato y con más IOPS/throughput por defecto.
Convertirlo a HDD st1.
Convertirlo a S3.
Respuesta correcta: B. gp3 es el sustituto moderno de gp2, sin parada y mejor relación coste/rendimiento.
2. Necesitas servir imágenes públicas de una web sin exponer el bucket. ¿Cuál es el patrón correcto?
Hacer el bucket público.
Desactivar Block Public Access y dar GetObject a todo el mundo.
Bucket privado + CloudFront delante con Origin Access Identity.
Usar EFS.
Respuesta correcta: C. Bucket nunca expuesto; CloudFront sirve y tú controlas qué se cachea y cómo.
3. Tienes 5 TB de logs que se consultan 1-2 veces al año por auditoría. ¿Qué clase de S3 es óptima?
S3 Standard
S3 Standard-IA
S3 Glacier Flexible o Deep Archive (vía lifecycle)
EFS
Respuesta correcta: C. Para acceso muy esporádico, Glacier (sobre todo Deep Archive) reduce drásticamente el coste de almacenamiento.
4. ¿Cuándo tiene sentido usar EFS en vez de S3?
Siempre, es más moderno.
Cuando varias EC2 necesitan acceder simultáneamente a un filesystem POSIX compartido (locking, permisos).
Para reducir el coste de S3.
Para almacenar imágenes de web.
Respuesta correcta: B. EFS es 3-4× más caro que S3 y solo se justifica cuando hace falta filesystem POSIX entre instancias.
Resumen del módulo
EBS: gp3 por defecto, io2 para bases de datos exigentes, st1/sc1 para HDD. Snapshots incrementales en S3, cifrado KMS.