Amazon SAA-C03: Almacenamiento y ciclo de vida de los datos — Guía de estudio

By Laurynas Brazys · 16 July 2026 · #amazon #saa-c03 #certification #exam-prep #study-guide

Forma parte de la AWS SAA-C03 — Guía de estudio completa. Practica con respuestas verificadas en el centro de exámenes de Amazon, o realiza tests cronometrados en ExamRoll.io.

Clases de almacenamiento de S3 y el espectro de costo/latencia

Las clases de almacenamiento de S3 existen en un espectro que equilibra la latencia de recuperación, la duración mínima de almacenamiento y las tarifas de recuperación por GB frente al costo de almacenamiento por GB. Elegir correctamente es la palanca más importante para la optimización de costos en el almacenamiento de objetos.

S3 Standard es la clase predeterminada: once nueves de durabilidad en tres o más AZ, latencia de milisegundos, sin tarifa de recuperación y el precio por GB más alto. Standard-IA y One Zone-IA reducen el costo de almacenamiento en aproximadamente un 40–50 %, pero añaden una tarifa de recuperación por GB, una duración mínima facturable de 30 días y un tamaño mínimo de objeto de 128 KB (los objetos más pequeños se facturan como 128 KB, lo que erosiona los ahorros). One Zone-IA reduce aún más el costo al almacenar en una única AZ, lo que es apropiado solo para copias secundarias reproducibles donde la pérdida de una única AZ es tolerable.

S3 Intelligent-Tiering es la elección correcta siempre que los patrones de acceso sean desconocidos, impredecibles o cambiantes en un gran corpus de datos. Migra automáticamente los objetos entre los niveles de acceso frecuente, poco frecuente, de archivo instantáneo, de archivo y de archivo profundo basándose en el acceso observado, cobrando una pequeña tarifa de monitoreo por objeto. Debido a que no hay cargos de recuperación entre los niveles de acceso frecuente y poco frecuente y no hay una duración mínima, es la opción predeterminada más segura para lagos de datos y cargas de trabajo mixtas con objetos ≥128 KB. Es la elección incorrecta cuando ya se sabe que los objetos son permanentemente de acceso frecuente (costo de monitoreo adicional) o permanentemente de acceso esporádico durante una década (Deep Archive es mucho más barato).

Glacier Instant Retrieval proporciona acceso en milisegundos a precios de archivo para datos a los que se accede trimestralmente o con menor frecuencia: imágenes médicas, PDF de cumplimiento que deben presentarse inmediatamente cuando se solicitan. Glacier Flexible Retrieval ofrece una recuperación de minutos a horas. Glacier Deep Archive es el nivel más barato de AWS, a aproximadamente 1 $/TB/mes, con una recuperación estándar de 12 horas (o masiva de 48 horas) y un mínimo de 180 días; es la respuesta correcta para la retención regulatoria de 7 a 10 años y el reemplazo de cintas.

Las dos trampas de costos dominantes son errores opuestos. Seleccionar Standard para datos leídos con poca frecuencia y a largo plazo es un derroche de dinero porque Standard no tiene una reducción de precio para el almacenamiento en frío: un conjunto de datos de 5 TB mantenido durante años en Standard cuesta varias veces más que los mismos datos en Deep Archive. Por el contrario, pasar objetos nuevos directamente a Standard-IA o Glacier es una trampa porque los cargos mínimos de 30/90/180 días más las tarifas de recuperación superan los ahorros cuando los objetos todavía son de acceso frecuente. Glacier Flexible o Deep Archive también son completamente incompatibles con cualquier carga de trabajo que espere una lectura síncrona: un usuario que espera un GET HTTP no puede tolerar un SLA de recuperación de minutos a 12 horas. Glacier Instant Retrieval es el único nivel de Glacier compatible con el acceso inmediato.

Políticas de ciclo de vida y manejo de versiones

La configuración del ciclo de vida es un JSON/YAML declarativo adjunto a un bucket que transiciona o expira objetos según su antigüedad, etiqueta o prefijo. Las transiciones se evalúan una vez al día y solo se activan después de que se alcanza la antigüedad especificada: una transición de Days: 30 significa que se aplican las tarifas de Standard durante los primeros 30 días. Las transiciones deben moverse a niveles progresivamente más fríos, y los objetos de menos de 128 KB no se transicionan de Standard a IA porque el costo adicional por objeto supera los ahorros; consolide primero los objetos pequeños mediante tar/zip o S3 Batch Operations.

Una política canónica para una carga de trabajo que es de acceso frecuente durante 30 días, de acceso esporádico después, que necesita acceso inmediato en todo momento, retenida durante cuatro años, con una higiene adecuada:

Rules:
  - ID: archive-and-clean
    Status: Enabled
    Transitions:
      - Days: 30
        StorageClass: STANDARD_IA
      - Days: 180
        StorageClass: DEEP_ARCHIVE
    NoncurrentVersionTransitions:
      - NoncurrentDays: 30
        StorageClass: GLACIER
    NoncurrentVersionExpiration:
      NoncurrentDays: 365
    Expiration:
      Days: 1460
    AbortIncompleteMultipartUpload:
      DaysAfterInitiation: 7

Una trampa frecuente en el manejo de versiones: en un bucket con versionamiento, una regla de ciclo de vida que expira objetos actuales simplemente inserta marcadores de eliminación; las versiones anteriores se acumulan silenciosamente y continúan facturándose. Las versiones no actuales requieren sus propias NoncurrentVersionTransitions y NoncurrentVersionExpiration explícitas. Del mismo modo, incluya siempre AbortIncompleteMultipartUpload: las partes de cargas multiparte huérfanas son invisibles en el listado de la consola y acumulan costos de almacenamiento indefinidamente.

Para patrones mixtos —por ejemplo, telemetría de IoT que es de acceso frecuente para entrenamiento de ML el primer mes, luego se consulta trimestralmente durante un año y después se archiva— la respuesta correcta es Intelligent-Tiering durante el primer año (permitiendo que la clase se autooptimice entre los picos de entrenamiento y los días de inactividad) seguida de una transición programada a Deep Archive en el día 365.

Control de versiones, MFA Delete y Object Lock

Una vez habilitado, el control de versiones solo puede suspenderse; no se puede desactivar. Cada PUT crea un nuevo ID de versión; un DELETE inserta un marcador de eliminación en lugar de eliminar los datos. El control de versiones protege contra la sobrescritura accidental, pero no es inmutabilidad: cualquier principal con permisos s3:DeleteObjectVersion puede eliminar permanentemente una versión específica. MFA Delete añade el requisito de que la cuenta raíz presente un token MFA para eliminar versiones permanentemente o cambiar el estado del control de versiones, cerrando la brecha de eliminación accidental para buckets de alto valor, pero sin impedir que un actor autorizado destruya los datos.

La verdadera inmutabilidad requiere S3 Object Lock, que necesita el control de versiones y generalmente debe habilitarse en el momento de la creación del bucket. Tiene dos modos que se confunden con frecuencia:

La retención se puede aplicar por objeto (Retain-Until-Date) o mediante una Legal Hold (retención legal), que no tiene fecha de vencimiento. Para registros contables que requieren un año en almacenamiento hot, nueve años archivados y sin eliminación durante diez años, el patrón correcto es Object Lock en modo Compliance con una retención de diez años, combinado con una transición de ciclo de vida a Deep Archive en el día 365. El modo Governance no es un sustituto aceptable para un mandato legal; un regulador no aceptará como inmutabilidad la excusa de que «alguien con permisos podría haberlo eliminado».

Para aplicar la retención a un corpus existente de archivos PDF en un solo trabajo, utiliza S3 Batch Operations impulsado por un manifiesto de S3 Inventory. Batch Operations es la solución administrada para mutaciones a gran escala (retención, etiquetado, recifrado mediante PUT-copy, invocación de Lambda) a través de miles de millones de claves; los scripts de iteración manuales no son el patrón adecuado.

Cifrado: SSE-S3, SSE-KMS y Bucket Keys

Cada bucket tiene cifrado por defecto. SSE-S3 (AES-256, claves administradas por S3) es gratuito y no requiere administración de claves. SSE-KMS utiliza una clave maestra de cliente (CMK) de KMS, lo que permite pistas de auditoría de CloudTrail por clave, políticas de acceso a claves basadas en IAM y control de la rotación de claves, a costa de los cargos de la API de KMS y, lo que es más crítico, de la limitación de solicitudes de KMS que puede crear cuellos de botella en cargas de trabajo de lectura de alto rendimiento. Elige SSE-KMS cuando realmente necesites esos controles (atestación regulatoria, separación de funciones, uso compartido de claves entre cuentas). Usar SSE-KMS por defecto «para estar más seguro» añade un costo y una complejidad innecesarios cuando SSE-S3 satisface el requisito.

S3 Bucket Keys aborda el costo de las solicitudes de SSE-KMS. S3 genera una clave de corta duración a nivel de bucket a partir de la CMK y deriva localmente las claves de datos por objeto, evitando una llamada a GenerateDataKey/Decrypt de KMS por cada objeto y reduciendo los costos de solicitud de KMS hasta en un 99 %:

"ServerSideEncryptionConfiguration": {
  "Rules": [{
    "ApplyServerSideEncryptionByDefault": {
      "SSEAlgorithm": "aws:kms",
      "KMSMasterKeyID": "arn:aws:kms:..."
    },
    "BucketKeyEnabled": true
  }]
}

Cambiar a SSE-S3 para «evitar los costos de KMS» es la solución incorrecta cuando el requisito exige KMS; las Bucket Keys satisfacen tanto los objetivos de cumplimiento como los de costo sin abandonar KMS.

Habilitar el cifrado por defecto del bucket asegura que todas las cargas futuras estén cifradas (los PUT sin cifrar se cifran de forma transparente). Para rechazar de plano los PUT sin cifrar, deniega las escrituras que carezcan de la cabecera:

{
  "Effect": "Deny",
  "Principal": "*",
  "Action": "s3:PutObject",
  "Resource": "arn:aws:s3:::my-bucket/*",
  "Condition": {
    "StringNotEquals": {
      "s3:x-amz-server-side-encryption": "AES256"
    }
  }
}

El cifrado por defecto no afecta a los objetos existentes sin cifrar. Vuelve a cifrarlos mediante S3 Inventory + Batch Operations ejecutando un trabajo de Copy que sobrescribe cada clave en su lugar; este es el patrón estándar de recifrado masivo.

El cifrado del lado del cliente ad-hoc es inferior al cifrado por defecto más KMS: dispersa la gestión de claves entre los equipos de aplicación, no puede ser auditado centralmente a través de los eventos de KMS en CloudTrail y no puede usar Bucket Keys.

Replicación entre regiones y claves KMS multirregionales

Cross-Region Replication (CRR) copia objetos de forma asíncrona a un bucket en una Región diferente para fines de cumplimiento, recuperación ante desastres (DR) o latencia. Same-Region Replication (SRR) sirve para la separación por cumplimiento, la agregación de logs y las copias entre cuentas. Ambas requieren el control de versiones en el origen y el destino, y un rol de IAM que el bucket de origen asume. CRR es la respuesta de bajo esfuerzo siempre que un bucket deba replicarse en otra Región; crear scripts con aws s3 sync, conectar Lambdas a eventos ObjectCreated o ejecutar copias por lotes programadas introduce sobrecarga operativa, condiciones de carrera y fallos silenciosos. Ni CRR ni SRR replican objetos existentes por defecto; utiliza S3 Batch Replication para rellenar los datos históricos (backfills).

Las interacciones con el cifrado son donde los diseños suelen fallar:

• Los objetos con SSE-S3 se replican de forma transparente.
• Los objetos con SSE-KMS no se replican por defecto; debes habilitarlo explícitamente, especificar una clave KMS de destino en la Región de destino y otorgar al rol de replicación los permisos kms:Decrypt sobre la clave de origen y kms:Encrypt sobre la clave de destino. Una clave de una sola Región no puede cifrar objetos en otra Región.
• Los objetos con cifrado del lado del cliente se replican como texto cifrado opaco; la Región de destino no gana nada a menos que el material de la clave del cliente esté disponible allí.

La fricción histórica de gestionar dos CMK independientes se resuelve con las claves multirregionales de AWS KMS, que presentan el mismo material de clave y el mismo ID de clave (con un prefijo de Región) en múltiples Regiones. Un objeto replicado puede entonces ser descifrado en la Región de destino sin llamadas de KMS entre Regiones y sin volver a encapsular (re-wrapping) la clave de datos. Este es el patrón canónico para buckets cifrados y replicados que deben permanecer utilizables en caso de una conmutación por error (failover) Regional.

El uso compartido de snapshots y objetos entre cuentas bajo una clave KMS administrada por el cliente requiere que los principales de la cuenta de destino tengan los permisos kms:Decrypt, kms:CreateGrant, kms:DescribeKey y kms:ReEncrypt* sobre la clave de origen a través de la política de clave, además de los permisos de IAM correspondientes. Las claves administradas por AWS (p. ej., aws/ebs, aws/s3) no se pueden compartir entre cuentas, por lo que las claves administradas por el cliente son obligatorias para los flujos de trabajo entre cuentas.

Bloqueo de acceso público y restricción de acceso a CloudFront

S3 Block Public Access (BPA) tiene cuatro configuraciones —bloquear nuevas ACL públicas, ignorar las ACL públicas existentes, bloquear nuevas políticas de bucket públicas, restringir las políticas de bucket públicas— que se pueden configurar por bucket y, lo que es más importante, a nivel de cuenta. El BPA a nivel de cuenta anula cualquier política de bucket que otorgaría acceso público y es el control correcto para “ningún objeto en esta cuenta puede ser público”. Las políticas a nivel de bucket por sí solas son frágiles: un nuevo bucket puede lanzarse sin una; el BPA a nivel de cuenta es un mecanismo de fallo seguro (fails closed).

Para evitar que un administrador en una cuenta miembro deshabilite el BPA, aplique una Service Control Policy en la OU de Organizations o en la raíz:

{
  "Effect": "Deny",
  "Action": "s3:PutAccountPublicAccessBlock",
  "Resource": "*",
  "Condition": {
    "Bool": { "aws:PrincipalIsAWSService": "false" }
  }
}

Para servir contenido de S3 solo a través de CloudFront, adjunte un Origin Access Control (OAC) —el reemplazo moderno del OAI heredado— a la distribución y condicione la política del bucket con el ARN de la distribución:

{
  "Effect": "Allow",
  "Principal": { "Service": "cloudfront.amazonaws.com" },
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::my-bucket/*",
  "Condition": {
    "StringEquals": {
      "AWS:SourceArn": "arn:aws:cloudfront::111122223333:distribution/E123"
    }
  }
}

El BPA permanece habilitado en el bucket. Para el acceso por tiempo limitado a objetos privados por parte de un usuario específico (expiración de carga/descarga), genere una URL prefirmada (presigned URL) cuya firma incrustada hereda los permisos de la entidad principal que la firma.

Rutas de red privadas: Gateway Endpoints

El tráfico de EC2 a S3 dentro de una VPC no utiliza automáticamente la red troncal privada de AWS. Sin configuración, las llamadas a la API de S3 se resuelven en puntos de conexión públicos y atraviesan el internet gateway o el NAT gateway, incurriendo en cargos por procesamiento de datos de NAT y exponiendo el tráfico a internet. Un gateway VPC endpoint para S3 (y DynamoDB) es gratuito, se añade como una ruta de lista de prefijos (prefix-list) en las tablas de rutas especificadas y mantiene el tráfico en la red de AWS. También existen los interface endpoints (PrivateLink) para S3, que son facturables y útiles cuando el acceso se origina desde entornos locales (on-premises) a través de Direct Connect. Combine el endpoint con una condición aws:SourceVpce en la política del bucket para forzar que el bucket solo sea accesible desde los VPC endpoints aprobados; este es el patrón estándar para cargas de trabajo reguladas.

Object Lambda para transformación sobre la marcha

S3 Object Lambda inserta una función Lambda en la ruta de las solicitudes GET/HEAD/LIST para que el objeto devuelto a quien lo solicita se transforme en el momento de la lectura. Esto evita duplicar datos para cada variante (redactada, redimensionada, reformateada) y mantiene una única fuente de verdad (single source of truth) en el bucket subyacente. Usos típicos: redacción de PII para analistas frente a datos completos para auditores, adición de marcas de agua a imágenes por usuario, conversión de XML a JSON para clientes heredados. Las políticas de IAM y del bucket siguen controlando el acceso al objeto subyacente; la función Lambda solo ve lo que su rol de ejecución le permite.

Notificaciones de eventos

S3 emite eventos (s3:ObjectCreated:*, s3:ObjectRemoved:*, eventos de replicación y de ciclo de vida) a Lambda, SQS, SNS o EventBridge. Se prefiere EventBridge cuando se necesitan múltiples destinos, filtrado por metadatos de objetos o enrutamiento entre cuentas; las notificaciones directas son más simples y económicas para pipelines con un solo destino, como la generación de miniaturas al cargar un objeto. Las notificaciones se entregan al menos una vez (at-least-once), por lo que los consumidores deben ser idempotentes.

Optimización del rendimiento: Multipart Upload y Transfer Acceleration

Para objetos de más de 100 MB, la carga multiparte (multipart upload) es la mejor práctica; para más de 5 GB, es obligatoria. Las partes se cargan en paralelo, las partes que fallan se reintentan de forma independiente y el rendimiento (throughput) escala con la concurrencia. Las solicitudes GET por rango de bytes (byte-range GETs) proporcionan un paralelismo equivalente en las descargas. Como se ha señalado, adjunte siempre una regla de ciclo de vida AbortIncompleteMultipartUpload para evitar la facturación de partes huérfanas.

S3 Transfer Acceleration enruta las cargas a través del borde de CloudFront más cercano sobre la red troncal de AWS; úselo para clientes distribuidos globalmente que cargan archivos a un único bucket. Para las descargas, ponga CloudFront delante de S3 para almacenar en caché en el borde. Transfer Acceleration está orientado a la carga; CloudFront está orientado a la descarga; resuelven problemas relacionados pero distintos.

EBS: Tipos de volúmenes, cifrado y snapshots

Los volúmenes de EBS son dispositivos de bloque con alcance de Zona de Disponibilidad (AZ) que se adjuntan a una única instancia EC2. gp3 es el SSD de propósito general predeterminado; su ventaja crítica sobre gp2 es que las IOPS (hasta 16,000) y el rendimiento (hasta 1,000 MiB/s) se aprovisionan independientemente de la capacidad, eliminando el antipatrón de gp2 de sobreaprovisionar almacenamiento solo para alcanzar los objetivos de rendimiento. io2 Block Express ofrece hasta 256,000 IOPS con latencia por debajo del milisegundo para bases de datos sensibles a la latencia. st1 y sc1 están respaldados por HDD para cargas de trabajo secuenciales y frías orientadas al rendimiento. La función Multi-Attach en io1/io2 existe, pero está limitada a 16 instancias en la misma AZ que ejecuten un sistema de archivos compatible con clústeres; es una excepción muy específica, no un patrón general de “EBS compartido”. Intentar adjuntar un volumen EBS a múltiples instancias (por ejemplo, detrás de un balanceador de carga) es un error de categoría que produce exactamente el síntoma de “algunos documentos son visibles al actualizar, y otros no”, porque cada volumen es un dispositivo de bloque privado.

Los volúmenes de EBS se cifran en reposo con AES-256 usando claves de datos envueltas por KMS. El cifrado es transparente: sin penalización de rendimiento ni cambios en la aplicación. Una vez que un volumen está cifrado, los snapshots y volúmenes derivados también se cifran; no se puede descifrar un volumen existente. Habilita el cifrado de EBS por defecto por Región para que cada nuevo volumen y snapshot se cifre sin depender de que el desarrollador lo recuerde:

aws ec2 enable-ebs-encryption-by-default --region us-east-1
aws ec2 modify-ebs-default-kms-key-id \
  --kms-key-id arn:aws:kms:us-east-1:111122223333:key/abcd-...

Los volúmenes no cifrados existentes no se cifran retroactivamente; la remediación requiere crear un snapshot, copiarlo con cifrado y crear un volumen a partir del snapshot cifrado.

Los snapshots son copias de seguridad incrementales a nivel de bloque almacenadas en infraestructura gestionada por S3, pero no son gratuitos (se paga por los bloques modificados que se conservan), no desaparecen cuando se elimina el volumen de origen y no se eliminan cuando una AMI que los referencia es desregistrada. Transfiéralos con el tiempo a la clase de almacenamiento EBS Snapshots Archive (75% más barata, restauración en 24–72 horas) mediante aws ec2 modify-snapshot-tier, Amazon Data Lifecycle Manager (DLM) o AWS Backup. Fast Snapshot Restore (FSR) precalienta un snapshot en AZ específicas para que las instancias lanzadas a partir de él ofrezcan el máximo rendimiento de inmediato; habilítalo para las AMIs detrás de grupos de autoescalado que deban gestionar un escalado horizontal rápido.

Recycle Bin captura los snapshots de EBS y las AMIs eliminadas en una ventana de restauración (de 1 día a 1 año). Sin esta función, la eliminación de snapshots es inmediata y permanente:

aws rbin create-rule \
  --retention-period RetentionPeriodValue=30,RetentionPeriodUnit=DAYS \
  --resource-type EBS_SNAPSHOT \
  --description "30-day snapshot recovery"

Confiar únicamente en los snapshots diarios de EBS para la retención a largo plazo por cumplimiento normativo es un error de arquitectura común; los snapshots tienen un precio más cercano al almacenamiento tibio (warm storage) y requieren transiciones explícitas de archivado.

Amazon EFS: POSIX compartido para flotas de Linux

EFS es un sistema de archivos NFSv4.1 totalmente gestionado, elástico y compatible con POSIX, que puede ser montado simultáneamente desde miles de clientes EC2, ECS, EKS o Lambda a través de múltiples AZ en una Región, y desde hosts on-premises a través de Direct Connect o VPN. La propiedad que lo define es que el mismo sistema de archivos, con identificadores de archivo (file handles) y semántica a nivel de byte idénticos, es visible para todos los clientes a la vez. Por lo tanto, EFS es la respuesta correcta siempre que una flota de instancias Linux detrás de un balanceador de carga deba compartir un conjunto común de archivos, como cargas de usuarios, configuraciones o directorios de inicio compartidos.

Los destinos de montaje (mount targets) residen en cada subred de AZ que configures. La utilidad amazon-efs-utils habilita TLS en tránsito y la autorización de montaje con IAM:

sudo mount -t efs -o tls,iam fs-0123456789abcdef0:/ /mnt/shared

Las clases de almacenamiento de EFS abarcan dos dimensiones. La administración del ciclo de vida (Lifecycle management) mueve los archivos no accedidos durante 7 a 90 días de Standard a Infrequent Access y, opcionalmente, a Archive, reduciendo el costo de almacenamiento hasta en un 92%; Intelligent-Tiering los devuelve a la clase superior al ser accedidos. Las clases One Zone almacenan los datos en una única AZ por un costo ~47% menor, lo cual es adecuado para desarrollo/pruebas o datos reproducibles, pero nunca para datos cuya pérdida durante un fallo de AZ sea inaceptable. Una medida de optimización de costos para una carga de trabajo que ya está en EFS Standard-IA es cambiar a EFS One Zone-IA sin ningún cambio en la aplicación.

El rendimiento tiene dos controles independientes. Modo de rendimiento (Performance mode) (se establece en la creación): General Purpose es el de menor latencia y el correcto para el servicio web con uso intensivo de metadatos; Max I/O es una opción heredada y superada por Elastic. Modo de rendimiento (Throughput mode): Bursting (en ráfagas) escala con el tamaño (línea base de 50 KB/s por GB, con créditos de ráfaga cuando está por debajo de la línea base), Provisioned (aprovisionado) paga por una cantidad fija de MB/s independientemente del tamaño, y Elastic (elástico) —el predeterminado actual— autoescala hasta más de 10 GB/s sin necesidad de planificación de capacidad. Un sistema de archivos pequeño bajo una carga sostenida puede agotar los créditos de ráfaga y ser limitado (throttling) a una línea base baja, por lo que las cargas de trabajo con uso intensivo de E/S y poco tamaño deben usar el modo Elastic o Provisioned.

EFS no es un sustituto del almacenamiento en bloque de altas IOPS. Cada operación de E/S en EFS es una llamada a procedimiento remoto (RPC) de NFS a través de la red, por lo que las cargas de trabajo de tipo log de transacciones, con un único escritor y latencia por debajo del milisegundo, deben usar EBS io2 Block Express; un único volumen ofrece 256,000 IOPS con latencia sub-milisegundo, algo que EFS no puede igualar por operación. EFS también tiene un precio excesivamente alto para datos fríos en comparación con Deep Archive; mantener datos de cumplimiento normativo en EFS “porque es fácil” es indefendible.

FSx: Windows, Lustre, ONTAP, OpenZFS

FSx es una familia de sistemas de archivos gestionados que se seleccionan según el protocolo y la carga de trabajo:

FSx for Windows File Server ofrece SMB 2.0/3.1.1 nativo con ACL de NTFS, espacios de nombres DFS, shadow copies y Kerberos sobre Active Directory. Los despliegues Multi-AZ instalan un servidor de archivos activo en una AZ con una réplica en espera (standby) sincronizada en otra y un único nombre DNS para la conmutación por error (failover). La integración con AD no es opcional: FSx debe unirse a un AWS Managed Microsoft AD o a un AD autogestionado accesible, y los clientes se autentican como usuarios del dominio contra los SID del dominio. Omitir AD, o apuntar los clientes a un sistema de archivos en un bosque no confiable sin una relación de confianza entre bosques (cross-forest trust), produce el clásico síntoma de acceso denegado a pesar de que el recurso compartido es visible. FSx for Windows es el destino ideal (drop-in) para migraciones directas (lift-and-shift) de recursos compartidos de archivos de Windows.

FSx for Lustre es un sistema de archivos POSIX paralelo para HPC, entrenamiento de ML, EDA y genómica: miles de clientes, cientos de GB/s de rendimiento y metadatos con latencia de sub-milisegundos. Su característica crítica en AWS es la asociación de repositorio de datos con S3: las claves de los objetos aparecen como archivos en el espacio de nombres de Lustre y se cargan de forma diferida (lazy loading) en el primer acceso (o se precargan mediante hsm_restore); los archivos nuevos/modificados se exportan de vuelta a S3 según una programación o bajo demanda. El patrón canónico de HPC es:

1. Copiar los conjuntos de datos on-premise a S3 (mediante DataSync o Storage Gateway).
2. Crear un sistema de archivos Lustre vinculado a ese bucket.
3. Montarlo en todos los workers de Spot; leer las entradas y escribir las salidas a la máxima velocidad de la red.
4. Exportar los resultados a S3, que permanece como el repositorio duradero a largo plazo.
5. Eliminar el sistema de archivos Lustre cuando finaliza el trabajo.

Los despliegues de Lustre de tipo Scratch no tienen replicación y pierden datos en caso de fallo de hardware; son los más económicos y rápidos, apropiados para datos de trabajos transitorios. Los despliegues de tipo Persistent se replican dentro de una AZ para una mayor durabilidad. El rendimiento (throughput) se aprovisiona en MB/s por TiB (50/125/250/500/1000), desacoplando la capacidad del rendimiento.

FSx for NetApp ONTAP es la respuesta multiprotocolo: NFS, SMB e iSCSI simultáneamente sobre los mismos datos, con snapshots, replicación SnapMirror, FlexClones y deduplicación. Elija ONTAP al consolidar recursos compartidos mixtos de Linux (NFS) y Windows (SMB) que necesiten acceso multiprotocolo con redundancia Multi-AZ, o al migrar desde un sistema NetApp on-premise. FSx for OpenZFS cubre un nicho para cargas de trabajo de Linux que necesitan características de ZFS (snapshots, clones) sobre NFS. No confunda la fortaleza multiprotocolo de ONTAP con las otras variantes.

Si elige mal, fallará de forma evidente: usar EBS para una carga de trabajo compartida, EFS para un recurso compartido SMB de Windows, o Lustre para un recurso compartido de Windows integrado con AD son todas opciones inadecuadas. Primero, haga coincidir el protocolo y el patrón de acceso.

Storage Gateway: Acceso Híbrido

Storage Gateway presenta el almacenamiento en la nube como si fuera local. Esto es distinto de DataSync, que mueve los datos.

Para una aplicación de renderizado que movió su biblioteca de medios a S3 pero aún necesita lecturas de baja latencia on-premise, S3 File Gateway es la solución ideal: acceso NFS/SMB, caché local y los objetos de acceso esporádico se obtienen de S3 bajo demanda. FSx File Gateway es la respuesta para las sucursales: una caché SMB a velocidad de LAN de un recurso compartido central de FSx en la nube, no una solución para el acceso compartido entre instancias EC2 (que deberían montar FSx directamente). Volume Gateway se aplica cuando la carga de trabajo utiliza iSCSI a nivel de bloque en lugar de semántica de archivos. Tape Gateway reemplaza las librerías de cintas físicas bajo el software de copia de seguridad existente.

Transferencia y Migración de Datos

AWS DataSync es una migración en línea basada en agente para NFS, SMB, HDFS y almacenes de objetos hacia S3, EFS o FSx. Es hasta 10 veces más rápido que las herramientas de código abierto, con cifrado, verificación de integridad, programación y preservación de metadatos POSIX y ACL de NTFS. Para una migración SMB a gran escala con millones de archivos pequeños y jerarquías profundas, la respuesta con menor sobrecarga es DataSync hacia FSx for Windows: se preserva el protocolo SMB, las ACL y las marcas de tiempo permanecen intactas, el rendimiento con archivos pequeños se gestiona mediante transferencias paralelas y no se requieren cambios en la aplicación. Migrar un conjunto de datos de este tipo directamente a S3 es una trampa: el almacenamiento de objetos maneja mal el listado de archivos pequeños en prefijos profundos y los clientes SMB no pueden montar buckets.

AWS Snow Family envía dispositivos físicos para la transferencia sin conexión (offline): Snowcone (hasta 8 TB, rugerizado para el borde), Snowball Edge (hasta ~80 TB utilizables, con opciones de cómputo) y Snowmobile (escala de exabytes). Regla general: si la transferencia por red tardaría más de una semana, Snowball es más barato y más rápido.

AWS Transfer Family expone SFTP, FTPS, FTP y AS2 respaldados por S3 o EFS. Es la respuesta correcta cuando los socios externos deben seguir utilizando protocolos estándar de transferencia de archivos.

AWS Backup, copia entre regiones y Vault Lock

AWS Backup centraliza las políticas para EBS, EFS, FSx, RDS, DynamoDB, S3 y más. Un plan de copias de seguridad define la programación, la retención en almacenamiento warm, la transición a almacenamiento cold y las acciones de copia entre regiones o entre cuentas:

BackupPlan:
  Rules:
    - RuleName: DailyWithDRCopy
      TargetBackupVault: prod-vault
      ScheduleExpression: "cron(0 5 * * ? *)"
      Lifecycle:
        MoveToColdStorageAfterDays: 30
        DeleteAfterDays: 2555        # 7 years
      CopyActions:
        - DestinationBackupVaultArn: arn:aws:backup:eu-west-1:...:backup-vault:dr-vault
          Lifecycle:
            MoveToColdStorageAfterDays: 30
            DeleteAfterDays: 2555

La transición a almacenamiento cold requiere al menos 90 días de retención en almacenamiento warm más al menos 90 días en almacenamiento cold; los ciclos de vida mal configurados se rechazan. Para una verdadera retención regulatoria de varios años, combínelo con AWS Backup Vault Lock (WORM), que impide que incluso los administradores acorten la retención, cumpliendo así con la norma SEC 17a-4 y mandatos similares. La copia entre regiones aborda la recuperación ante desastres (DR) regional; la copia entre cuentas aborda escenarios de ransomware y amenazas internas al aislar las copias de seguridad del radio de impacto de la cuenta de producción.

Guía de referencia rápida

← Arquitecturas serverless y basadas en eventos · Todos los dominios · Transferencia y migración de datos →

Practica estas preguntas → · Práctica cronometrada en ExamRoll.io →

Explorar Amazon →