El SAP-C02 evalúa la selección del almacenamiento correcto para cada workload, incluyendo las características avanzadas de S3 (clases, replicación, Object Lambda), los tipos de EBS, y cuándo usar EFS vs FSx para sistemas de archivos compartidos.
Contenido
| Clase | Latencia recuperación | Costo almac. | Mejor para |
|---|---|---|---|
| S3 Standard | ms | $$$$ | Datos de acceso frecuente. Sitios web, apps activas. |
| S3 Standard-IA | ms | $$$ | Acceso infrecuente pero necesita recuperación rápida. Backups recientes. |
| S3 One Zone-IA | ms | $$ | Acceso infrecuente + tolerante a pérdida de AZ. Replicas de datos. 20% más barato que Standard-IA. |
| S3 Intelligent-Tiering | ms – min | $$$ | Patrones de acceso impredecibles. Mueve automáticamente entre tiers sin overhead. |
| Glacier Instant Retrieval | ms | $$ | Archivos médicos, datos de cumplimiento que se acceden raramente pero necesitan ms de latencia. |
| Glacier Flexible Retrieval | 1–12h (Expedited: min) | $ | Archivos y backups con acceso ocasional. Expedited para emergencias. |
| Glacier Deep Archive | 12–48h | $ (más barato) | Archivado a largo plazo (7-10 años). Cumplimiento, datos históricos nunca accedidos. |
| S3 Reduced Redundancy (legacy) | ms | $$$ | DEPRECADO — usar Standard-IA. Solo mencionado en preguntas antiguas. |
S3 Lifecycle Policies
Transiciones automáticas entre clases y expiración de objetos basadas en tiempo o versiones.
S3 Replication
S3 Object Lambda — transforma datos al vuelo
S3 Object Lambda intercepta solicitudes GET de S3 y llama a una Lambda function para transformar el objeto antes de devolverlo al solicitante. Sin copias separadas de los datos. Casos de uso: redactar PII (número de tarjeta → ****), convertir formatos (XML → JSON), enriquecer con metadatos de DynamoDB, resize de imágenes al vuelo.
S3 Transfer Acceleration
Acelera uploads hacia S3 usando los edge locations de CloudFront. El cliente sube al edge más cercano, luego el dato viaja por la backbone de AWS (más rápida que internet público) hasta S3.
S3 Multipart Upload
Divide objetos grandes en partes que se suben en paralelo. Recomendado para archivos mayores a 100 MB, obligatorio para mayores a 5 GB.
S3 prefix performance — no es un anti-patrón usar muchos prefixes
S3 escala automáticamente a 3,500 PUT/COPY/POST/DELETE y 5,500 GET/HEAD requests por segundo POR PREFIX. Si tienes un bucket con millones de objetos y necesitas mayor throughput, distribuir los objetos en múltiples prefixes da N × 3,500/5,500 req/seg. La limitación es por prefix, no por bucket.
| Tipo | IOPS máx | Throughput máx | Mejor para |
|---|---|---|---|
| gp3 (SSD general) | 16,000 IOPS (independiente de tamaño) | 1,000 MB/s | Boot volumes, apps generales, dev/test. Reemplaza gp2. IOPS/throughput configurables independientemente. |
| gp2 (SSD legacy) | 3 IOPS/GB, max 16,000 | 250 MB/s | Legacy. Migrar a gp3 para menor costo y mayor flexibilidad. |
| io2 Block Express | 256,000 IOPS | 4,000 MB/s | Bases de datos críticas que necesitan latencia sub-ms y alta durabilidad (99.9999%). |
| io1/io2 | 64,000 IOPS | 1,000 MB/s | DBs Oracle, SQL Server, Cassandra con alto IOPS. IOPS provisionados independientes del tamaño. |
| st1 (HDD throughput) | 500 IOPS | 500 MB/s | Data warehouses, log processing, streaming. Alto throughput secuencial, bajo costo. |
| sc1 (HDD cold) | 250 IOPS | 250 MB/s | Datos de acceso infrecuente. El más barato de EBS. Backups fríos. |
EBS Multi-Attach — io1/io2 únicamente
EBS Multi-Attach permite que un volumen io1 o io2 se adjunte a hasta 16 instancias EC2 en la MISMA AZ simultáneamente. La aplicación debe gestionar la concurrencia de escrituras (ej: clustering con Oracle RAC). No sirve para compartir archivos entre instancias — para eso usa EFS.
Características clave
EFS vs EBS — cuándo usar cada uno
¿Múltiples instancias EC2 acceden al mismo filesystem?
→ EFS — compartido multi-instancia nativo
¿Sistema operativo Windows o aplicaciones Windows?
→ EBS o FSx for Windows (EFS solo Linux)
¿Boot volume de una instancia EC2?
→ EBS — EFS no puede ser boot volume
¿Máximo rendimiento de disco (base de datos OLTP)?
→ EBS io2 — menor latencia y mayor IOPS que EFS
¿Home directories compartidos en múltiples AZs?
→ EFS — acceso desde cualquier AZ de la región
¿Contenedores ECS Fargate con estado compartido?
→ EFS — único almacenamiento compartido para Fargate
FSx for Windows File Server
SMB/CIFS gestionado, compatible con Windows nativo. Integración con Active Directory. Para apps Windows que requieren file shares (DFS, SQL Server log shipping, home directories Windows).
FSx for Lustre
Sistema de archivos de alto rendimiento para HPC, ML training y procesamiento de video. Integración nativa con S3 para lazy loading de datos.
FSx for NetApp ONTAP
Funcionalidades ONTAP gestionadas en AWS: NFS, SMB, iSCSI. Migración de workloads NetApp on-premises sin cambios. Multi-AZ nativo.
FSx for OpenZFS
OpenZFS gestionado. NFS v3/v4 de alta disponibilidad con snapshotting nativo, compresión y deduplicación. Para workloads Linux/Unix que usan ZFS.
¿Objetos sin estructura de directorio (imágenes, backups, data lake)?
→ S3
¿Disco para una sola instancia EC2 (OS, base de datos, app data)?
→ EBS (gp3 para general, io2 para alto IOPS)
¿Filesystem NFS compartido entre múltiples Linux EC2/ECS?
→ EFS
¿SMB/CIFS para apps Windows o Active Directory?
→ FSx for Windows File Server
¿HPC, ML training, máximo throughput de filesystem?
→ FSx for Lustre
¿Migrar workloads NetApp ONTAP on-premises a AWS?
→ FSx for NetApp ONTAP
¿Archivado de datos de acceso muy infrecuente (7-10 años)?
→ S3 Glacier Deep Archive
Trampa: "EFS funciona con Windows EC2"
Realidad: FALSO. EFS solo soporta Linux/Unix (protocolo NFS). Para sistemas de archivos compartidos en Windows, usa FSx for Windows File Server.
Trampa: "S3 Standard-IA cobra por acceso — nunca usarlo para datos frecuentes"
Realidad: Correcto que cobra por retrieval, pero Standard-IA es perfecto para datos que se acceden menos de una vez al mes. Si se accede más frecuentemente, Standard es más barato en total.
Trampa: "EBS puede compartirse entre instancias en diferentes AZs"
Realidad: FALSO. EBS es zonal — solo puede adjuntarse a instancias en la misma AZ. Para compartir entre AZs usa EFS. Para compartir entre instancias en la misma AZ usa EBS Multi-Attach (solo io1/io2).
Trampa: "Glacier Deep Archive es igual que Glacier pero más barato solo en almacenamiento"
Realidad: La diferencia clave es el tiempo de recuperación: Glacier Instant Retrieval = ms, Glacier Flexible = 1-12h, Glacier Deep Archive = 12-48h. No es solo diferencia de precio — es diferencia funcional.
¿Entendiste este tema?
Pon a prueba lo que acabas de aprender
Una empresa tiene una aplicación de renderizado de video que corre en 500 instancias EC2 Linux en un Auto Scaling Group. Todas las instancias necesitan acceso simultáneo de lectura/escritura a los mismos archivos de proyecto de video (varios TB). Las instancias se crean y destruyen frecuentemente. ¿Qué solución de almacenamiento es la más apropiada?
Inicia sesión para llevar tu progreso.