Semana 3 · Módulo 3 de 11

Almacenamiento: S3 a fondo, EFS, FSx, Backup e híbrido

Amazon S3 de arriba abajo (clases, ciclo de vida, cifrado, permisos, rendimiento), almacenamiento de ficheros con EFS y FSx, copias con AWS Backup y todas las vías para llevar datos a AWS. Es el bloque que más puntos reparte entre rendimiento (3.1), coste (4.1) y seguridad de datos (1.3).

Reparto de la semana

Por qué importa

El almacenamiento aparece en los cuatro dominios del examen. Lo preguntan de tres maneras:

1. Rendimiento y escalado (task 3.1): «¿qué servicio de almacenamiento cumple esta latencia, este throughput y este crecimiento?».
2. Coste (task 4.1): «¿cuál es la opción MOST cost-effective para datos a los que se accede una vez al trimestre y deben estar disponibles en milisegundos?». Aquí se decide la clase de S3, las reglas de ciclo de vida y la forma más barata de mover datos.
3. Seguridad y retención (task 1.3): cifrado, retención legal (WORM, write once, read many: escribir una vez y leer muchas), copias, replicación y quién puede leer qué.

Además, la task 2.2 pide conocer la durabilidad y la replicación de cada opción, y la 3.5, los servicios de transferencia (DataSync, Storage Gateway).

Bloque, fichero y objeto

Antes de ver servicios, fija los tres modelos de almacenamiento. El examen los llama block, file y object storage.

Ideas que conviene tener claras:

• EBS vive en una AZ. Para llevarlo a otra AZ haces un snapshot (que se guarda de forma regional) y creas un volumen nuevo. Los tipos de EBS (gp3, io2, st1, sc1…) se estudian en el módulo 02; aquí basta recordar: SSD (gp3, io2) para IOPS y latencia; HDD (st1 para throughput secuencial, sc1 para datos fríos) para lo barato y secuencial.
• Instance store es disco físico local: rapidísimo, pero efímero (se pierde al parar o terminar la instancia).
• Objeto no es fichero: no puedes «montar» S3 como un disco POSIX con bloqueos y escrituras parciales. Si el enunciado pide «sistema de ficheros compartido POSIX», la respuesta no es S3 (Mountpoint for Amazon S3 existe, pero está pensado para cargas de lectura masiva y no ofrece semántica POSIX completa).

Amazon S3: fundamentos

Amazon S3 (Simple Storage Service) guarda objetos en buckets.

• Bucket: contenedor con nombre único global que vive en una región. Los datos no salen de esa región salvo que tú los copies o repliques.
• Objeto: clave (fotos/2026/playa.jpg), datos, metadatos, etiquetas (tags) y un identificador de versión si activas el versionado.
• Prefijo: la parte de la clave antes del último /. No hay carpetas reales; la consola las simula con prefijos.
• Tamaño máximo de un objeto: con multipart upload, hasta 48,8 TiB (10.000 partes de 5 MiB a 5 GiB). Una sola operación PUT admite hasta 5 GB. AWS recomienda multipart a partir de unos 100 MB.
• Consistencia: S3 ofrece consistencia fuerte de lectura tras escritura (strong read-after-write consistency) para PUT y DELETE. Si escribes y lees justo después, lees lo nuevo.
• Durabilidad: todas las clases están diseñadas para 99,999999999 % (11 nueves). La disponibilidad sí cambia entre clases.

Hay dos tipos de bucket:

• General purpose bucket (el de siempre): todas las clases salvo Express One Zone.
• Directory bucket: para S3 Express One Zone (una sola AZ que eliges tú, latencia de milisegundos de un dígito y autorización por sesión con CreateSession). Se usa para ML, analítica interactiva o cualquier carga muy sensible a la latencia, colocando el bucket en la misma AZ que el cómputo.

Clases de almacenamiento de S3

Esta tabla es de las más rentables del examen. Cifras de la documentación oficial (consultada el 30/09/2026).

Detalles que el examen explota:

• One Zone-IA y Express One Zone son las únicas que no sobreviven a la pérdida de una AZ. One Zone-IA encaja para datos que puedes regenerar (miniaturas, transcodificaciones) o como destino de una réplica entre regiones.
• Reduced Redundancy Storage (RRS) existe todavía en la API, pero AWS no la recomienda: Standard es más barata y más duradera. Si aparece como opción, casi siempre es un distractor.
• Los 40 KB de Glacier Flexible Retrieval y Deep Archive se reparten así: 8 KB facturados a precio de Standard (nombre y metadatos) y 32 KB al precio de la clase de archivo. Por eso archivar millones de objetos pequeños sale caro: agrúpalos antes (por ejemplo, en un .tar).
• Duración mínima: si borras, sobrescribes o transicionas un objeto antes de tiempo, pagas los días que faltan.

Tiempos de recuperación de Glacier

Glacier Instant Retrieval se lee con un GET normal. Flexible Retrieval y Deep Archive exigen restaurar antes (RestoreObject), lo que crea una copia temporal durante los días que indiques (pagas el archivo más esa copia al precio de Standard).

• Con S3 Batch Operations, las restauraciones Standard de Flexible Retrieval empiezan en minutos y acaban en 3-5 horas; las de Deep Archive, en 9-12 horas.
• Provisioned capacity: compras capacidad para garantizar que las recuperaciones Expedited se aceptan en picos de demanda. Cada unidad da al menos 3 recuperaciones Expedited cada 5 minutos y hasta 300 MB/s.

S3 Intelligent-Tiering por dentro

Intelligent-Tiering mueve cada objeto entre niveles según su uso, sin cargos de recuperación:

• Frequent Access: donde empieza todo.
• Infrequent Access: tras 30 días sin acceso.
• Archive Instant Access: tras 90 días sin acceso (sigue en milisegundos).
• Archive Access (opcional, lo activas tú): tras un mínimo de 90 días; acceso asíncrono (minutos a horas).
• Deep Archive Access (opcional): tras un mínimo de 180 días; horas.

Si un objeto se vuelve a leer, regresa a Frequent Access. Cuándo elegirla: patrón de acceso desconocido o cambiante y objetos grandes (más de 128 KB). Cuándo no: si conoces el patrón exacto, una regla de ciclo de vida hacia la clase concreta suele salir más barata que pagar la monitorización.

Ciclo de vida, versionado y replicación

S3 Lifecycle

Una lifecycle configuration es un conjunto de reglas por bucket (filtradas por prefijo, etiqueta o tamaño) con dos tipos de acción:

• Transition: mover objetos a otra clase tras N días desde su creación.
• Expiration: borrar objetos (o versiones antiguas, o multipart uploads incompletos) tras N días.

Las transiciones siguen un modelo en cascada (waterfall): solo bajan hacia clases más frías. Por ejemplo, Standard → Standard-IA → Glacier Instant Retrieval → Glacier Flexible Retrieval → Deep Archive. No puedes subir con una regla: para sacar un objeto de Glacier Flexible Retrieval o Deep Archive a otra clase, lo restauras y lo copias.

Restricciones que salen en preguntas:

• Desde septiembre de 2024, por defecto los objetos de menos de 128 KB no se transicionan a ninguna clase (el coste de la transición superaría el ahorro). Puedes cambiarlo con un filtro de tamaño.
• No puedes crear una regla que saque objetos de una clase antes de su duración mínima (por ejemplo, Glacier Instant Retrieval el día 4 y Deep Archive el día 20: la segunda transición debe ser, como pronto, el día 94).
• Cada transición es una petición que se paga.
• Buena práctica casi siempre correcta: una regla que aborta multipart uploads incompletos (AbortIncompleteMultipartUpload) tras unos días. Las partes huérfanas se facturan y no se ven en un listado normal.

Ejemplo de regla (logs: a IA a los 30 días, a Deep Archive a los 180, borrar a los 7 años):

{
  "Rules": [
    {
      "ID": "logs-retencion-7-anios",
      "Filter": { "Prefix": "logs/" },
      "Status": "Enabled",
      "Transitions": [
        { "Days": 30, "StorageClass": "STANDARD_IA" },
        { "Days": 180, "StorageClass": "DEEP_ARCHIVE" }
      ],
      "Expiration": { "Days": 2555 },
      "AbortIncompleteMultipartUpload": { "DaysAfterInitiation": 7 }
    }
  ]
}

Para decidir cuándo transicionar, S3 Storage Class Analysis observa el patrón de acceso de un bucket o prefijo y recomienda cuándo pasar a Standard-IA. S3 Storage Lens da visibilidad de uso y actividad a nivel de organización.

Versionado

El versionado (versioning) guarda todas las versiones de cada objeto. Un bucket está en uno de tres estados: sin versionar (por defecto), Enabled o Suspended (una vez activado, no se puede volver a «sin versionar»).

• Un DELETE sin versión no borra: añade un delete marker que oculta el objeto. Para «recuperar» un borrado basta con eliminar el delete marker.
• Un DELETE con versionId borra esa versión para siempre.
• Las versiones antiguas se pagan: usa reglas NoncurrentVersionTransition y NoncurrentVersionExpiration.
• MFA Delete: exige MFA (solo con el usuario raíz) para borrar versiones permanentemente o cambiar el estado del versionado. Protección extra frente a borrados maliciosos.

El versionado es requisito para replicación y Object Lock.

Replicación (CRR y SRR)

La replicación copia objetos de forma asíncrona a uno o varios buckets de destino, de la misma cuenta o de otra.

• Cross-Region Replication (CRR): a otra región. Cumplimiento que exige distancia geográfica, menor latencia para usuarios lejanos, DR.
• Same-Region Replication (SRR): en la misma región. Agregar logs de varios buckets, copiar producción a una cuenta de pruebas, soberanía del dato (varias cuentas, sin salir del país).

Requisitos y comportamiento:

• Versionado activado en origen y destino, y un rol de IAM que S3 asume para replicar.
• Solo replica objetos nuevos tras configurar la regla. Para los existentes (o los que fallaron) usa S3 Batch Replication.
• Por defecto no replica los delete markers (puedes activar delete marker replication), nunca replica los borrados de una versión concreta (protección frente a borrados maliciosos), no replica acciones de ciclo de vida ni objetos que ya están en Glacier Flexible Retrieval o Deep Archive.
• No es transitiva: si A replica a B y B a C, los objetos de A no llegan a C (salvo con Batch Replication).
• Puedes elegir otra clase de almacenamiento en el destino (por ejemplo, réplica en Glacier Deep Archive o One Zone-IA) y cambiar el propietario de la réplica a la cuenta de destino (owner override).
• S3 Replication Time Control (S3 RTC): replica el 99,99 % de los objetos nuevos en 15 minutos, con SLA. Es la respuesta cuando el enunciado pide un RPO de replicación predecible.
• S3 Multi-Region Access Points: un único punto de acceso global que enruta al bucket más cercano y permite conmutar entre regiones; se combina con replicación bidireccional.

Protección y retención de datos

S3 Object Lock

Object Lock aplica el modelo WORM: una versión de objeto no puede sobrescribirse ni borrarse durante un tiempo. Requiere versionado. Tiene dos mecanismos independientes:

• Retention period (periodo de retención) con dos modos:
  • Governance mode: casi nadie puede borrar, pero los usuarios con el permiso s3:BypassGovernanceRetention (y la cabecera x-amz-bypass-governance-retention:true) sí pueden. Útil para probar o para una protección «con llave maestra».
  • Compliance mode: nadie puede borrar ni acortar la retención, ni siquiera el usuario raíz. La única forma de eliminar antes de tiempo es cerrar la cuenta. Es lo que piden normativas como SEC 17a-4, CFTC o FINRA (Cohasset Associates evaluó Object Lock para ellas).
• Legal hold: bloqueo sin fecha de caducidad; se mantiene hasta que alguien con s3:PutObjectLegalHold lo quite. Para auditorías o litigios de duración desconocida.

La retención se puede ampliar pero no acortar en compliance. Un DELETE sin versión sobre un objeto bloqueado simplemente añade un delete marker; la versión protegida sigue ahí.

Recuperación de datos: resumen

Seguridad de S3

Cifrado en reposo

Desde el 5 de enero de 2023, todos los objetos nuevos se cifran automáticamente con SSE-S3 sin coste. Hay cuatro opciones de cifrado en el servidor (server-side encryption), mutuamente excluyentes por objeto:

Novedades y detalles:

• SSE-C bloqueado por defecto: desde abril de 2026, los buckets de uso general nuevos (y los existentes en cuentas sin objetos SSE-C) rechazan las escrituras con SSE-C. Si lo necesitas, lo habilitas explícitamente con PutBucketEncryption (BlockedEncryptionTypes a NONE). SSE-C exige HTTPS y, si pierdes la clave, pierdes el objeto.
• S3 Bucket Keys: con SSE-KMS, S3 genera una clave de bucket de vida corta y reduce drásticamente las llamadas a KMS (y su coste y el riesgo de throttling, porque KMS tiene cuotas de peticiones por segundo).
• Cambiar el cifrado por defecto del bucket no recifra lo existente; para eso, S3 Batch Operations (copia sobre sí mismo).
• Cifrado en el cliente (client-side encryption): cifras tú antes de subir (por ejemplo, con el AWS Encryption SDK). AWS nunca ve el dato en claro.

La política de claves, la rotación y el envelope encryption se estudian a fondo en el módulo 07.

Cifrado en tránsito

S3 admite HTTP y HTTPS. Para obligar a TLS, deniega en la bucket policy las peticiones con aws:SecureTransport igual a false:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "SoloHTTPS",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": [
        "arn:aws:s3:::mi-bucket-seguro",
        "arn:aws:s3:::mi-bucket-seguro/*"
      ],
      "Condition": { "Bool": { "aws:SecureTransport": "false" } }
    }
  ]
}

Quién puede acceder: IAM, bucket policies y ACL

Dentro de una misma cuenta, basta con que IAM o la bucket policy permitan (y nadie deniegue). Entre cuentas hacen falta ambos lados: la política de IAM en la cuenta que llama y la bucket policy en la cuenta del bucket. Un Deny explícito siempre gana. SCP y RCP de AWS Organizations pueden limitar aún más (módulo 01).

Ejemplo de bucket policy que da lectura a un rol de otra cuenta y solo desde un VPC endpoint concreto:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "LecturaDesdeCuentaAnalitica",
      "Effect": "Allow",
      "Principal": { "AWS": "arn:aws:iam::111122223333:role/analitica" },
      "Action": ["s3:GetObject"],
      "Resource": "arn:aws:s3:::datos-ventas/*",
      "Condition": { "StringEquals": { "aws:SourceVpce": "vpce-0abc1234def567890" } }
    }
  ]
}

Object Ownership

S3 Object Ownership decide quién es el dueño de los objetos que suben otras cuentas y si las ACL están activas:

• Bucket owner enforced (por defecto en buckets nuevos): ACL desactivadas; el propietario del bucket posee todos los objetos y el acceso se controla solo con políticas. Es lo recomendado.
• Bucket owner preferred: ACL activas; el propietario del bucket posee los objetos subidos con la ACL bucket-owner-full-control.
• Object writer: ACL activas; quien sube es el dueño.

Trampa clásica: «otra cuenta sube objetos a nuestro bucket y luego no podemos leerlos» → con ACL activas y Object writer, el objeto es del que lo subió. Solución moderna: Bucket owner enforced.

Block Public Access

S3 Block Public Access son cuatro ajustes (a nivel de cuenta y de bucket) que impiden el acceso público vía ACL o bucket policy, aunque alguien lo configure por error. Vienen activados por defecto en buckets nuevos. Actívalo a nivel de cuenta salvo que tengas un bucket público justificado (y aun así, mejor sirve el contenido con CloudFront y Origin Access Control, módulo 06).

Presigned URLs

Una presigned URL da acceso temporal a un objeto concreto (descarga o subida) sin tocar políticas. Se firma con las credenciales de quien la genera y hereda sus permisos.

• Duración: en la consola, de 1 minuto a 12 horas; con CLI o SDK, hasta 7 días si la firma un usuario de IAM (SigV4).
• Si la firmas con credenciales temporales (rol, perfil de instancia EC2, STS), caduca cuando caducan esas credenciales aunque pidas más.
• Caso de examen: «usuarios de una app móvil suben fotos directamente a S3 sin pasar por nuestros servidores» → la app pide al backend una presigned URL de PUT.

aws s3 presign s3://mi-bucket/informes/q3.pdf --expires-in 3600

Access Points y otras formas de acceso

• S3 Access Points: puntos de acceso con nombre, cada uno con su propia política y, si quieres, restringido a una VPC. Simplifican buckets compartidos por muchos equipos (en vez de una bucket policy gigantesca).
• Multi-Region Access Points: un endpoint global para buckets replicados en varias regiones.
• VPC gateway endpoint para S3: acceso privado desde la VPC sin NAT ni Internet y sin coste (módulo 05). Muy típico en preguntas de coste.
• S3 Access Grants: concede acceso a prefijos a identidades de un directorio corporativo (IAM Identity Center).

Gobierno y clasificación

• Amazon Macie descubre datos sensibles (PII) en S3 (módulo 07).
• Etiquetas de objeto para clasificar y usar en políticas de IAM y de ciclo de vida.
• AWS CloudTrail data events para auditar GetObject/PutObject; server access logs como alternativa barata.
• IAM Access Analyzer for S3 avisa de buckets compartidos fuera de la cuenta o públicos.

Rendimiento de S3

S3 escala solo, pero hay que conocer sus reglas:

• Por prefijo: al menos 3.500 PUT/COPY/POST/DELETE y 5.500 GET/HEAD por segundo por prefijo particionado. No hay límite de prefijos: 10 prefijos permiten unas 55.000 lecturas por segundo. El escalado es gradual; mientras tanto puedes ver errores 503 Slow Down (reintenta con backoff exponencial).
• Multipart upload: divide un objeto en partes que se suben en paralelo y se reintentan por separado. Recomendado desde unos 100 MB, obligatorio por encima de 5 GB. La CLI (aws s3 cp) lo hace automáticamente.
• Byte-range fetches: descargar rangos (Range: bytes=…) en paralelo acelera descargas grandes y permite leer solo la cabecera de un fichero.
• S3 Transfer Acceleration: los clientes suben a la edge location de CloudFront más cercana y el tráfico viaja por la red de AWS hasta el bucket. Para clientes lejanos que suben ficheros grandes a un bucket centralizado. Tiene coste por GB y se usa el endpoint bucket.s3-accelerate.amazonaws.com.
• Caché: para lecturas repetidas con baja latencia, CloudFront delante de S3 (o ElastiCache para metadatos).
• SSE-KMS a mucha escala: cada objeto implica llamadas a KMS; usa S3 Bucket Keys para no chocar con las cuotas de KMS.
• S3 Express One Zone: cuando necesitas latencia de milisegundos de un dígito y muchas peticiones pequeñas (entrenamiento de ML, analítica interactiva).

Estrategias de subida y coste de peticiones

La task 4.1 menciona «batch uploads frente a subidas individuales». Idea clave: cada PUT, COPY, transición o GET cuesta. Con millones de ficheros diminutos, el coste de peticiones (y de transiciones de ciclo de vida) puede superar al de almacenamiento.

• Agrupa ficheros pequeños en objetos grandes antes de subir o archivar.
• Sube ficheros grandes con multipart y en paralelo.
• Para operar sobre millones de objetos existentes (copiar, etiquetar, restaurar, recifrar), usa S3 Batch Operations en vez de scripts propios.
• Para moverlos desde on-premises de forma programada y verificada, DataSync.

Otras funciones de S3 que salen en el examen

• Event notifications: al crear, borrar o restaurar objetos, S3 envía eventos a Amazon SNS, Amazon SQS, AWS Lambda o Amazon EventBridge. EventBridge permite filtrar mejor y enviar a muchos destinos. Patrón típico: subir una imagen dispara una Lambda que genera la miniatura (módulo 08).
• Static website hosting: sirve HTML, CSS y JS desde un bucket. El endpoint de sitio web es solo HTTP; para HTTPS y dominio propio, pon CloudFront delante (y Route 53 para el DNS).
• Requester Pays: el solicitante paga las peticiones y la transferencia de datos; el propietario paga el almacenamiento. Para compartir grandes conjuntos de datos con terceros sin pagar su descarga. Las peticiones deben ser autenticadas (nada de acceso anónimo) e incluir la cabecera de aceptación x-amz-request-payer.
• CORS (Cross-Origin Resource Sharing): configuración del bucket para que un navegador de otro dominio pueda pedir objetos.
• S3 Select e S3 Object Lambda están en maintenance (no admiten clientes nuevos desde julio de 2024 y noviembre de 2025, respectivamente). Si aparecen, piensa en Amazon Athena para consultar datos con SQL en S3.

Amazon S3 Glacier: estado actual

Cuando el temario dice «Amazon S3 Glacier» se refiere hoy, en la práctica, a las tres clases de almacenamiento de S3 vistas arriba, gestionadas con ciclo de vida y restauraciones desde S3. El servicio antiguo de vaults y su API propia («Amazon Glacier» en la consola nueva) está en maintenance desde el 07/10/2025 y S3 Glacier Select desde el 25/07/2024. En el examen puede aparecer Glacier Vault Lock (bloqueo WORM de un vault) en material antiguo: el equivalente moderno es S3 Object Lock.

Amazon EFS

Amazon Elastic File System es un sistema de ficheros NFS (NFSv4.0 y 4.1) totalmente gestionado para Linux, que crece y decrece solo (pagas por lo que guardas) y que pueden montar a la vez miles de instancias EC2, contenedores de ECS/EKS, funciones Lambda y servidores on-premises (vía Direct Connect o VPN).

• Tipos: Regional (recomendado; datos en varias AZ, disponibilidad 99,99 %) o One Zone (una AZ, más barato, no resiste la pérdida de la AZ). Durabilidad de diseño en ambos: 11 nueves.
• Mount targets: uno por AZ, con su IP en una subred y un security group que permita TCP 2049 desde los clientes.
• Clases de almacenamiento:

• Lifecycle management: mueve ficheros a IA o Archive tras N días sin acceso y, opcionalmente, los devuelve a Standard al primer acceso. Leer de IA/Archive tiene cargo por GB.
• Performance mode: General Purpose (por defecto y recomendado siempre) o Max I/O (generación anterior, más latencia; no disponible con One Zone ni con Elastic throughput).
• Throughput mode:
  • Elastic (por defecto y recomendado): escala solo; pagas por lo leído y escrito. Para cargas impredecibles o con picos.
  • Provisioned: fijas un throughput independiente del tamaño. Para cargas conocidas y sostenidas.
  • Bursting: el throughput crece con el tamaño en Standard (50 KiB/s por GiB de base) y funciona con créditos.
• Seguridad: cifrado en reposo con KMS (se elige al crear), cifrado en tránsito con TLS (con el cliente amazon-efs-utils), EFS Access Points (punto de entrada con usuario POSIX y directorio raíz forzados, ideal por aplicación) y políticas de sistema de ficheros con IAM.
• Protección: integración con AWS Backup (las copias automáticas vienen activadas por defecto al crear desde la consola) y EFS Replication a otra región o AZ con RPO y RTO de minutos.

Amazon FSx

Amazon FSx ofrece sistemas de ficheros de terceros totalmente gestionados. Regla de oro de AWS: elige el que más se parezca a lo que ya tienes.

Palabras clave:

• «SMB», «Active Directory», «Windows», «DFS» → FSx for Windows File Server.
• «HPC», «Lustre», «cientos de GB/s», «procesar datos de S3 con un sistema de ficheros de alto rendimiento», «almacenamiento temporal de cálculo» → FSx for Lustre (scratch si es temporal y barato; persistent si debe durar).
• «NetApp», «multiprotocolo NFS + SMB», «iSCSI», «SnapMirror» → FSx for NetApp ONTAP.
• «ZFS», «NFS de baja latencia desde Linux con snapshots» → FSx for OpenZFS.

Árbol de decisión: ¿qué almacenamiento elijo?

flowchart TD
    A["¿Cómo accede la aplicación?"] --> B["Disco de UNA instancia"]
    A --> C["Sistema de ficheros compartido"]
    A --> D["API HTTP / objetos"]
    B --> B1{"¿Datos temporales y máximo rendimiento?"}
    B1 -- Sí --> B2["Instance store"]
    B1 -- No --> B3["Amazon EBS (gp3 por defecto; io2 si IOPS altas; st1/sc1 si HDD barato)"]
    C --> C1{"¿Qué protocolo o sistema?"}
    C1 -- "NFS en Linux, elástico" --> C2["Amazon EFS"]
    C1 -- "SMB / Windows / AD" --> C3["FSx for Windows File Server"]
    C1 -- "HPC / ML / S3 como origen" --> C4["FSx for Lustre"]
    C1 -- "Multiprotocolo / NetApp" --> C5["FSx for NetApp ONTAP"]
    C1 -- "ZFS / NFS baja latencia" --> C6["FSx for OpenZFS"]
    D --> D1{"¿Con qué frecuencia se lee?"}
    D1 -- "A menudo" --> D2["S3 Standard (Express One Zone si latencia mínima)"]
    D1 -- "Desconocida" --> D3["S3 Intelligent-Tiering"]
    D1 -- "Mensual, en ms" --> D4["S3 Standard-IA (One Zone-IA si es recreable)"]
    D1 -- "Trimestral, en ms" --> D5["S3 Glacier Instant Retrieval"]
    D1 -- "Anual, minutos-horas" --> D6["S3 Glacier Flexible Retrieval"]
    D1 -- "Casi nunca, horas" --> D7["S3 Glacier Deep Archive"]

Y para el escalado futuro (task 3.1, «scale to accommodate future needs»):

Dimensionar el almacenamiento: ¿cuánto aprovisiono?

La task 4.1 pide determining the correct storage size for a workload y determining when storage auto scaling is required. La pregunta clave es si el servicio cobra por lo que aprovisionas o por lo que usas:

Regla práctica: si el servicio crece solo (S3, EFS, Aurora, DynamoDB), no hay que dimensionar capacidad; si cobra por lo aprovisionado (EBS, FSx, RDS), dimensiona para el corto plazo, mide y amplía con autoscaling (RDS) o en caliente (EBS, FSx). Storage auto scaling is required cuando el crecimiento es impredecible y quedarse sin espacio tumbaría la aplicación.

Almacenamiento híbrido y transferencia de datos

AWS Storage Gateway

Storage Gateway es un dispositivo (máquina virtual en VMware, Hyper-V, KVM o Nutanix; appliance físico; o instancia EC2) que se instala on-premises y presenta almacenamiento local respaldado por AWS, con caché local para lo más usado.

AWS DataSync

DataSync es el servicio online para mover o sincronizar grandes volúmenes de ficheros u objetos, de forma programada y verificada.

• Orígenes: NFS, SMB, HDFS, almacenamiento de objetos propio, otras nubes (Google Cloud Storage, Azure Blob y Azure Files, entre otras) y los propios servicios de AWS.
• Destinos en AWS: S3 (cualquier clase, incluidas Glacier Flexible Retrieval y Deep Archive), EFS y los cuatro tipos de FSx.
• On-premises necesita un agente (máquina virtual) cerca del origen.
• Cifra en tránsito, valida la integridad de los datos, conserva permisos y metadatos entre servicios de ficheros, solo transfiere cambios (incremental), admite VPC endpoints y programar tareas. Una tarea puede usar un enlace de 10 Gbps.
• Se paga por GB transferido.

Diferencia con Storage Gateway: DataSync mueve datos (migración, replicación, archivo); Storage Gateway presenta almacenamiento de AWS a aplicaciones locales de forma continua.

AWS Transfer Family

Transfer Family ofrece servidores SFTP, FTPS, FTP y AS2 (y aplicaciones web de transferencia) totalmente gestionados, con destino en S3 o EFS. Mantienes los clientes, usuarios y flujos de tus socios sin montar servidores. Admite autenticación propia, con AWS Directory Service o con un proveedor de identidad a medida (Lambda, Amazon Cognito, Okta…). FTP (sin cifrar) solo se admite en endpoints dentro de una VPC.

Caso típico: «proveedores externos nos envían ficheros por SFTP y queremos que acaben en S3 para analizarlos, sin gestionar servidores» → AWS Transfer Family.

AWS Snow Family: estado real

La familia Snow (Snowcone, Snowball Edge, Snowmobile) servía para transferencias offline de TB a PB cuando la red no bastaba, y para cómputo en el borde desconectado. Estado a septiembre de 2026:

• Snowmobile: retirado (marzo de 2024).
• Snowcone: descatalogado (noviembre de 2024).
• Snowball Edge: ya no está disponible para clientes nuevos; AWS no ofrece ningún dispositivo Snow a clientes nuevos.
• Alternativas oficiales: DataSync (online, combinable con una conexión Direct Connect alquilada durante la migración), AWS Data Transfer Terminal (instalaciones físicas donde llevas tus propios discos para subirlos a alta velocidad) y soluciones de partners. Para cómputo en el borde, AWS Outposts.

¿Qué vía de migración elijo?

Calcula primero cuánto tardaría la red. Fórmula aproximada: días ≈ (TB × 8.000) / (Mbps efectivos × 86.400). Por ejemplo, 100 TB por un enlace de 1 Gbps aprovechado al 100 % tardan unos 9,3 días; al 50 % real, unos 19 días. Con 100 Mbps, más de 90 días.

AWS Backup

AWS Backup centraliza y automatiza las copias de muchos servicios: EC2, EBS, S3, EFS, los cuatro FSx, RDS, Aurora, DynamoDB, DocumentDB, Neptune, Redshift, Storage Gateway (volúmenes), EKS, VMware Cloud on AWS, CloudFormation, SAP HANA en EC2 y otros.

Conceptos:

• Backup plan: cuándo copiar (frecuencia, ventana), cuánto tiempo guardar (retención), cuándo pasar a cold storage (almacenamiento frío más barato, en los recursos que lo admiten) y a qué regiones o cuentas copiar.
• Resource assignment: qué recursos entran en el plan, normalmente por etiqueta (por ejemplo, backup=diario). Así, todo recurso nuevo etiquetado queda protegido sin tocar el plan.
• Backup vault: contenedor cifrado (con su propia clave KMS) y con política de acceso propia. Las copias sobreviven aunque borres el recurso original.
• AWS Backup Vault Lock: WORM para el vault; impide que nadie (tú incluido) borre copias o acorte la retención. Tiene modo governance y compliance, como Object Lock.
• Logically air-gapped vault: vault aislado, compartible con otras cuentas, pensado para recuperarse de ransomware.
• Copias entre regiones y entre cuentas (estas últimas dentro de AWS Organizations), y backup policies de Organizations para imponer planes a todas las cuentas.
• Backup Audit Manager: controles y informes de cumplimiento de las copias.
• Restore testing: pruebas de restauración programadas para demostrar que las copias sirven.
• Copias incrementales en los servicios que lo admiten.

Estrategias de backup y archivo (resumen de coste)

Gestión de costes del almacenamiento

La task 4.1 también pide conocer las herramientas de costes (se ven a fondo en el módulo 10). Aplicadas al almacenamiento:

• Cost allocation tags: etiqueta buckets y volúmenes por proyecto y actívalas en Billing para repartir costes.
• AWS Cost Explorer: analizar el gasto de S3 por tipo de uso (almacenamiento, peticiones, transferencia).
• AWS Budgets: avisos cuando el gasto en almacenamiento supere un umbral.
• AWS Cost and Usage Report (CUR) / Data Exports: el detalle línea a línea para analizar con Athena.
• Facturación consolidada de Organizations (multi-account billing): agrega el uso y aprovecha los tramos de precio por volumen.
• S3 Storage Lens y Storage Class Analysis: detectar buckets sin ciclo de vida, versiones antiguas acumuladas o multipart incompletos.
• Tamaño correcto (right sizing): EBS gp3 en vez de gp2 (IOPS y throughput independientes del tamaño), borrar snapshots y volúmenes huérfanos, no sobredimensionar FSx.

Trampas típicas del examen

• «Duradero» no es «disponible»: todas las clases de S3 tienen 11 nueves de durabilidad; lo que cambia es la disponibilidad y el número de AZ.
• One Zone-IA para la única copia de datos importantes: incorrecto. Solo para datos recreables o réplicas.
• Glacier Flexible Retrieval o Deep Archive cuando piden «acceso inmediato» o «milisegundos»: incorrecto. Glacier Instant Retrieval sí.
• Intelligent-Tiering para millones de objetos diminutos o con patrón conocido: suele no ser lo más barato.
• Ciclo de vida para objetos de pocos KB: la transición cuesta más de lo que ahorra (y por defecto ni se aplica bajo 128 KB).
• Replicación y objetos existentes: una regla nueva no copia lo que ya había → Batch Replication.
• Replicación como backup: si borras una versión, no se borra en el destino, pero los datos corruptos sí se replican. Para backup, versionado + Object Lock o AWS Backup.
• Governance vs compliance: «ni siquiera el root» = compliance.
• Bucket policy vs IAM: para dar acceso a otra cuenta o a un servicio, bucket policy (y, en la otra cuenta, IAM).
• ACL: en diseños nuevos, no. Bucket owner enforced + políticas.
• Acceso público: Block Public Access activado y CloudFront con OAC para servir contenido.
• Web estática con HTTPS: el endpoint de sitio web de S3 no tiene HTTPS → CloudFront.
• Subidas lentas desde otros continentes → Transfer Acceleration; descargas repetidas → CloudFront.
• 503 Slow Down → más prefijos y reintentos con backoff.
• EFS para Windows: no; FSx for Windows File Server. EFS Max I/O ya no es la recomendación: General Purpose + Elastic.
• FSx for Lustre scratch para datos que deben conservarse: no, scratch no replica.
• FSx File Gateway para un cliente nuevo: ya no se puede contratar.
• Snowmobile en una respuesta: retirado; en el examen, mira si otra opción encaja mejor.
• DataSync vs Storage Gateway: mover datos (DataSync) frente a acceso continuo con caché local (Storage Gateway).
• Requester Pays: el propietario sigue pagando el almacenamiento; el solicitante paga peticiones y descarga.

Resumen

• Bloque (EBS, una instancia, una AZ), fichero (EFS/FSx, compartido) y objeto (S3, API HTTP).
• Clases de S3: Standard → Intelligent-Tiering → Standard-IA / One Zone-IA → Glacier Instant (ms, 90 días) → Glacier Flexible (minutos-horas, 90 días) → Deep Archive (12-48 h, 180 días).
• Ciclo de vida en cascada, sin transiciones bajo 128 KB por defecto; aborta multipart incompletos.
• Versionado + replicación (CRR/SRR, RTC 15 min) + Object Lock (governance/compliance, legal hold) para recuperación y retención.
• Cifrado: SSE-S3 por defecto; SSE-KMS para control y auditoría; DSSE-KMS doble capa; SSE-C bloqueado por defecto desde abril de 2026.
• Acceso: IAM + bucket policy (entre cuentas, ambas), ACL desactivadas (Bucket owner enforced), Block Public Access, presigned URLs (hasta 7 días), Access Points.
• Rendimiento: 3.500 escrituras y 5.500 lecturas por segundo por prefijo, multipart, byte-range, Transfer Acceleration, Express One Zone.
• EFS (NFS, Linux, elástico, multi-AZ) frente a FSx (Windows/SMB, Lustre/HPC, ONTAP/multiprotocolo, OpenZFS/NFS).
• Híbrido: Storage Gateway (S3 File, Volume, Tape), DataSync, Transfer Family; Snow solo como concepto (no disponible para clientes nuevos).
• AWS Backup: planes por etiquetas, vaults, Vault Lock, copias entre regiones y cuentas.

Cobertura del temario

Practica lo aprendido

Documentación oficial para ampliar

• Understanding and managing Amazon S3 storage classes
• Understanding archive retrieval options (S3 Glacier)
• Protecting data with server-side encryption
• Controlling ownership of objects and disabling ACLs
• Best practices design patterns - optimizing Amazon S3 performance
• Replicating objects within and across Regions
• Locking objects with Object Lock
• Amazon EFS performance specifications
• Choosing an Amazon FSx file system
• What is AWS Backup?
• What is AWS DataSync?
• AWS Snowball Edge availability change