1. Introducción
El almacenamiento es una pieza crítica de cualquier arquitectura cloud: aplicaciones, imágenes, vídeos, PDFs, logs, copias de seguridad y datos históricos dependen de él.
En cloud, el almacenamiento se consume como servicio. El proveedor gestiona infraestructura física y resiliencia base; el cliente elige el tipo correcto según uso, coste, rendimiento, frecuencia de acceso y requisitos de seguridad/compliance.
La idea clave: no todo almacenamiento sirve para lo mismo.
2. Concepto clave
Existen distintos modelos de almacenamiento según cómo se guardan y consumen datos.
| Tipo | Servicio AWS | Uso principal |
|---|---|---|
| Objetos | Amazon S3 | Archivos estáticos, backups, logs |
| Bloques | Amazon EBS | Discos para EC2 |
| Ficheros | Amazon EFS | Sistema de archivos compartido |
| Archivado | S3 Glacier | Conservación a largo plazo |
Esquema general
Servicios de almacenamiento en la nube │ ├── Objetos -> Amazon S3 ├── Bloques -> Amazon EBS ├── Ficheros -> Amazon EFS └── Archivado -> S3 Glacier
Almacenamiento de objetos (S3)
S3 guarda datos como objetos dentro de buckets.
Casos típicos:
- imágenes,
- vídeos,
- PDF,
- estáticos web,
- backups,
- logs,
- exportaciones.
Bucket: campus-virtual │ ├── apuntes/tema7.pdf ├── imagenes/diagrama.png ├── videos/intro.mp4 └── backups/copia.sql
Ventajas: escalable, durable, bajo mantenimiento, integración con CDN/Lambda.
Limitaciones: no es disco de SO, no sustituye a EBS para BBDD en EC2, acceso por red/API.
Almacenamiento de bloques (EBS)
EBS es el disco virtual persistente de EC2.
Casos típicos:
- disco de sistema,
- aplicaciones instaladas en VM,
- base de datos dentro de EC2,
- workloads con baja latencia de bloque.
EC2 ├── Sistema operativo ├── Aplicación └── Volumen EBS ├── /var/log └── /datos
Ventajas: rendimiento, persistencia, snapshots.
Limitaciones: ligado a AZ, no se comparte fácilmente entre múltiples instancias.
Almacenamiento de ficheros (EFS)
EFS es un filesystem compartido por varias instancias EC2.
EC2 A ─┐ EC2 B ─┼── Amazon EFS (mismo filesystem) EC2 C ─┘
Útil cuando varias instancias necesitan leer/escribir el mismo contenido.
No es sustituto universal: suele costar más que S3 para almacenamiento masivo de estáticos.
Archivado (S3 Glacier)
Diseñado para datos de acceso infrecuente y retención larga:
- backups antiguos,
- expedientes históricos,
- logs de auditoría,
- evidencias legales.
S3 Standard -> Standard-IA -> Glacier -> Deep Archive
Ventaja principal: coste bajo a largo plazo.
Limitación principal: recuperación más lenta (y potencial coste de restauración).
Clases de almacenamiento S3
| Clase | Cuándo usar |
|---|---|
| S3 Standard | acceso frecuente |
| S3 Standard-IA | acceso poco frecuente |
| S3 One Zone-IA | IA en una sola zona |
| Glacier Instant Retrieval | archivado con acceso rápido |
| Glacier Flexible Retrieval | archivado minutos/horas |
| Glacier Deep Archive | archivado muy largo plazo |
Ciclo de vida
Políticas automáticas para mover objetos entre clases y optimizar costes.
Ejemplo:
- Día 0: Standard
- Día 30: Standard-IA
- Día 180: Glacier
- Año 5: Deep Archive o borrado
3. Ejemplo mínimo
Para una web educativa:
| Necesidad | Servicio |
|---|---|
| Imágenes / PDF | S3 |
| Disco de EC2 | EBS |
| BBDD en EC2 | EBS |
| Compartir archivos entre varias EC2 | EFS |
| Backups antiguos | Glacier |
Web educativa │ ├── S3 (imágenes/PDF) ├── EC2 + EBS (SO + datos locales) └── Glacier (backups históricos)
4. Ejemplo completo
Caso: AulaStorage Cloud con web, entregas, materiales, varias instancias, backup y archivado.
AulaStorage Cloud │ ├── S3: materiales, entregas, imágenes, vídeos, exportaciones ├── EBS: discos de EC2 ├── EFS: ficheros compartidos entre EC2 ├── BBDD gestionada: almacenamiento propio del servicio └── Glacier: backups/logs/expedientes antiguos
Flujo típico de entrega:
Alumno -> app web -> bucket S3 entregas (objeto privado + metadatos)
Flujo de archivado:
Datos activos -> backup S3 -> transición Glacier -> Deep Archive.
5. Errores frecuentes
- Usar S3 como si fuera disco local de sistema.
- Usar EBS para compartir archivos entre muchas EC2.
- Guardar todo en clase frecuente sin lifecycle.
- No considerar tiempos/costes de recuperación en Glacier.
- No cifrar.
- Buckets públicos accidentalmente.
- Permisos excesivos.
- No monitorizar crecimiento y coste.
- No documentar dónde vive cada dato y su retención.
6. Buenas prácticas
- Elegir almacenamiento por patrón de uso real.
- S3 para objetos y estáticos.
- EBS para discos de EC2.
- EFS solo cuando realmente hay acceso compartido.
- Glacier para históricos.
- Lifecycle policies obligatorias en datos de larga vida.
- Versionado donde aporte recuperación.
- Cifrado en reposo y tránsito.
- Bloquear acceso público por defecto.
- Separar buckets por función y entorno.
- Etiquetar recursos para control de costes.
- Revisar periódicamente almacenamiento y recuperación.
7. Ejercicio propuesto
Caso: CloudStorage Aula.
Tareas:
- Explicar objetos/bloques/ficheros/archivado.
- Diseñar buckets y estructura lógica.
- Justificar EBS para EC2 y cuándo no usar S3.
- Explicar cuándo usar EFS.
- Diseñar estrategia Glacier para históricos.
- Completar tabla necesidad -> servicio.
- Definir lifecycle para entregas.
- Definir controles de seguridad del almacenamiento.
- Enumerar errores críticos a evitar.
Solución orientativa
cloudstorage-aula ├── materiales/ -> S3 Standard ├── entregas/ -> Standard -> IA -> Glacier ├── imagenes/ -> S3 + CDN ├── backups/ -> S3 -> Glacier └── logs/ -> S3 -> Deep Archive
EC2 discos -> EBS Compartido EC2 -> EFS Históricos -> Glacier
Conclusión
El almacenamiento cloud no es “subir archivos y ya”. Es diseñar dónde, cómo, cuánto tiempo y con qué protección se guarda cada dato.
Una estrategia madura combina:
- tipo correcto de almacenamiento,
- clases y lifecycle,
- seguridad por defecto,
- gobernanza de acceso y costes,
- y políticas de recuperación probadas.
Guardar datos bien en cloud significa equilibrar rendimiento, coste, seguridad y cumplimiento de forma intencional.