Amazon SAA-C03: Almacenamiento y Ciclo de Vida de Datos — Guía de estudio

By Laurynas Brazys · 15 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 costo/latencia

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

S3 Standard es el predeterminado: durabilidad de once nueves en tres o más AZs, latencia de milisegundos, sin tarifa de recuperación, el precio por GB más alto. Standard-IA y One Zone-IA reducen el costo de almacenamiento en aproximadamente un 40-50%, pero agregan 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 reduce los ahorros). One Zone-IA reduce aún más el costo al almacenar en una sola AZ, apropiado solo para copias secundarias reproducibles donde una pérdida de una sola AZ es tolerable.

S3 Intelligent-Tiering es la opción correcta cuando los patrones de acceso son desconocidos, impredecibles o cambiantes en un gran corpus. Migra automáticamente objetos entre niveles frecuentes, infrecuentes, de archivo instantáneo, de archivo y de archivo profundo según el acceso observado, cobrando una pequeña tarifa de monitoreo por objeto. Debido a que no hay cargos de recuperación entre los niveles frecuentes e infrecuentes y no hay una duración mínima, es el valor predeterminado más seguro para data lakes y cargas de trabajo mixtas con objetos ≥128 KB. Es la opción incorrecta cuando ya sabe que los objetos están permanentemente activos (costo de monitoreo adicional) o permanentemente fríos 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 menos frecuencia (imágenes médicas, PDFs de cumplimiento que deben producirse inmediatamente cuando se solicitan). Glacier Flexible Retrieval ofrece recuperación en minutos u horas. Glacier Deep Archive es el nivel más barato en AWS, aproximadamente $1/TB/mes, con recuperación estándar de 12 horas (o 48 horas a granel) y un mínimo de 180 días, 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 a largo plazo que rara vez se leen quema dinero porque Standard no tiene un descuento de precio de 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 exceden los ahorros cuando los objetos aún están activos. 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 HTTP GET 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 la edad, la etiqueta o el prefijo. Las transiciones se evalúan una vez al día y solo se activan después de alcanzar la edad especificada; una transición de Days: 30 significa que se aplican tarifas estándar 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 la sobrecarga 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 está activa durante 30 días, fría a partir de entonces, que necesita acceso inmediato en todo momento, retenida durante cuatro años, con la 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 versionado, 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 facturando. Las versiones no actuales requieren sus propias NoncurrentVersionTransitions y NoncurrentVersionExpiration explícitas. De manera similar, incluya siempre AbortIncompleteMultipartUpload: las partes multipart huérfanas son invisibles en la lista de la consola y acumulan almacenamiento indefinidamente.

Para patrones combinados, por ejemplo, telemetría de IoT que está activa para el entrenamiento de ML el primer mes, luego se consulta trimestralmente durante un año, luego se archiva, la respuesta correcta es Intelligent-Tiering durante el primer año (dejando que la clase se optimice automáticamente entre ráfagas de entrenamiento y días inactivos) seguido de una transición programada a Deep Archive el día 365.

Versionado, eliminación con MFA y bloqueo de objetos

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

La verdadera inmutabilidad requiere S3 Object Lock, que requiere versionado y generalmente debe habilitarse en la creación del bucket. Tiene dos modos que a menudo se confunden:

La retención se puede aplicar por objeto (Retain-Until-Date) o mediante una retención legal (Legal Hold), que no tiene vencimiento. Para los registros contables que requieren un año activo, nueve años archivados y ninguna eliminación durante diez años, el patrón correcto es Object Lock en modo Cumplimiento con una retención de diez años, combinado con una transición de ciclo de vida a Deep Archive el día 365. La gobernanza no es un sustituto aceptable de un mandato legal; un regulador no aceptará “alguien con permisos podría haber eliminado esto” como inmutabilidad.

Para aplicar la retención a un corpus existente de PDF en un solo trabajo, use S3 Batch Operations impulsado por un manifiesto de S3 Inventory. Batch Operations es la respuesta administrada para mutaciones a gran escala (retención, etiquetado, re-cifrado de copia PUT, invocación de Lambda) en miles de millones de claves; los scripts de iteración escritos a mano no son el patrón correcto.

Cifrado: SSE-S3, SSE-KMS y claves de bucket

Cada bucket tiene cifrado predeterminado. 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 de KMS, lo que permite auditorías de CloudTrail por clave, políticas de acceso a claves basadas en IAM y control de rotación de claves, a costa de los cargos de la API de KMS y, lo que es más crítico, la limitación de solicitudes de KMS que puede estrangular las cargas de trabajo de lectura de alto rendimiento. Elija SSE-KMS cuando realmente necesite esos controles (certificación regulatoria, separación de funciones, uso compartido de claves entre cuentas). Establecer SSE-KMS como predeterminado “para estar seguro” agrega costos y complejidad innecesarios cuando SSE-S3 satisface el requisito.

Las claves de bucket de S3 abordan el costo de las solicitudes de SSE-KMS. S3 genera una clave de nivel de bucket de corta duración a partir de la CMK y deriva claves de datos por objeto localmente, evitando una llamada GenerateDataKey/Decrypt de KMS por 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 claves de bucket satisfacen los objetivos de cumplimiento y costo sin abandonar KMS.

Habilitar el cifrado predeterminado del bucket garantiza que todas las cargas futuras estén cifradas (las PUT no cifradas se cifran de forma transparente). Para rechazar las PUT no cifradas por completo, deniegue las escrituras que carecen del encabezado:

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

El cifrado predeterminado no afecta a los objetos no cifrados existentes. Vuelva a cifrarlos mediante S3 Inventory + Batch Operations ejecutando un trabajo Copy que sobrescribe cada clave en su lugar, el patrón estándar de re-cifrado masivo.

El cifrado del lado del cliente ad-hoc es inferior al cifrado predeterminado más KMS: dispersa la administración de claves entre los equipos de aplicaciones, no se puede auditar centralmente a través de los eventos de KMS de CloudTrail y no puede usar claves de bucket.

Replicación entre regiones y claves KMS multiregión

La replicación entre regiones (CRR) copia objetos de forma asíncrona a un bucket en una región diferente por motivos de cumplimiento, DR o latencia. La replicación dentro de la misma región (SRR) sirve para la separación de cumplimiento, la agregación de registros y las copias entre cuentas. Ambas requieren el versionado en el origen y el destino, y un rol de IAM que asuma el bucket de origen. CRR es la respuesta de bajo esfuerzo siempre que un bucket deba replicarse en otra región: la creación de scripts aws s3 sync, la conexión de Lambdas en ObjectCreated o la ejecución de copias por lotes programadas introducen sobrecarga operativa, condiciones de carrera y fallas silenciosas. Ni CRR ni SRR replican objetos existentes por defecto; use la replicación por lotes de S3 para las retroalimentaciones.

Las interacciones de cifrado son donde los diseños comúnmente fallan:

• Los objetos SSE-S3 se replican de forma transparente.
• Los objetos SSE-KMS no se replican por defecto; debe optar explícitamente por ellos, especificar una clave KMS de destino en la región de destino y otorgar al rol de replicación kms:Decrypt en la clave de origen y kms:Encrypt en la clave de destino. Una clave de una sola región no puede cifrar objetos en otra región.
• Los objetos cifrados 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 administrar dos CMK independientes se resuelve con las claves multiregión de AWS KMS, que presentan el mismo material de clave e ID de clave (con un prefijo de región) en varias regiones. Un objeto replicado puede descifrarse en la región de destino sin llamadas KMS entre regiones y sin volver a envolver la clave de datos. Este es el patrón canónico para buckets cifrados y replicados que deben permanecer utilizables en caso de conmutación por error regional.

El uso compartido de instantáneas y objetos entre cuentas bajo una clave KMS administrada por el cliente requiere que las entidades principales de la cuenta de destino tengan kms:Decrypt, kms:CreateGrant, kms:DescribeKey y kms:ReEncrypt* en la clave de origen a través de la política de claves, además de los permisos de IAM correspondientes. Las claves administradas por AWS (por ejemplo, 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.

Bloquear el acceso público y restringir el acceso a CloudFront

S3 Block Public Access (BPA) tiene cuatro configuraciones (bloquear nuevas ACL públicas, ignorar ACL públicas existentes, bloquear nuevas políticas de bucket públicas, restringir políticas de bucket públicas) configurables 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 de bucket por sí solas son frágiles: un nuevo bucket puede lanzarse sin una; el BPA a nivel de cuenta falla cerrado.

Para evitar que un administrador en una cuenta miembro deshabilite el BPA, aplique una política de control de servicios en la OU o raíz de Organizations:

{
  "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 proteja la política del bucket en 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 (caducidad de carga/descarga), genere una URL prefirmada cuya firma incrustada hereda los permisos de la entidad principal firmante.

Rutas de red privadas: puntos de conexión de puerta de enlace

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 la puerta de enlace de Internet o la puerta de enlace NAT, lo que genera cargos por procesamiento de datos NAT y expone el tráfico a Internet. Un punto de conexión de VPC de puerta de enlace para S3 (y DynamoDB) es gratuito, se agrega como una ruta de lista de prefijos en las tablas de rutas especificadas y mantiene el tráfico en la red de AWS. También existen puntos de conexión de interfaz (PrivateLink) para S3 y son facturables, útiles cuando el acceso se origina en las instalaciones a través de Direct Connect. Empareje el punto de conexión con una condición aws:SourceVpce de política de bucket para garantizar que el bucket solo sea accesible desde puntos de conexión de VPC aprobados, 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 GET/HEAD/LIST para que el objeto devuelto al llamador se transforme en tiempo de lectura. Esto evita duplicar datos para cada variante (redactada, redimensionada, reformateada) y mantiene una única fuente de verdad en el bucket subyacente. Usos típicos: redacción de PII para analistas frente a datos completos para auditores, marca de agua de imágenes por usuario, conversión de XML a JSON para clientes heredados. Las políticas de IAM y de bucket aún protegen el objeto subyacente; la función Lambda solo ve lo que permite su rol de ejecución.

Notificaciones de eventos

S3 emite eventos (s3:ObjectCreated:*, s3:ObjectRemoved:*, eventos de replicación y 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 canalizaciones de un solo destino, como la generación de miniaturas al cargar. Las notificaciones son al menos una vez, por lo que los consumidores deben ser idempotentes.

Optimización del rendimiento: carga multiparte y aceleración de transferencia

Para objetos de más de 100 MB, la carga multiparte es la mejor práctica; para más de 5 GB, es obligatoria. Las partes se cargan en paralelo, las partes fallidas se reintentan de forma independiente y el rendimiento escala con la concurrencia. Las solicitudes GET de rango de bytes proporcionan el paralelismo equivalente en las descargas. Como se señaló, siempre adjunte una regla de ciclo de vida AbortIncompleteMultipartUpload para evitar la facturación de partes huérfanas.

La aceleración de transferencia de S3 enruta las cargas a través del borde de CloudFront más cercano a través de la red troncal de AWS; úsela para clientes distribuidos globalmente que cargan en un solo bucket. Para las descargas, coloque S3 delante de CloudFront para almacenar en caché en el borde. La aceleración de transferencia está orientada a la carga; CloudFront está orientada a la descarga; resuelven problemas relacionados pero distintos.

EBS: Tipos de volumen, cifrado y snapshots

Los volúmenes EBS son dispositivos de bloque con alcance de AZ adjuntos 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 de sub-milisegundos para bases de datos sensibles a la latencia. st1 y sc1 están respaldados por HDD para cargas de trabajo secuenciales orientadas al rendimiento y frías. Multi-Attach en io1/io2 existe, pero está limitado a 16 instancias en la misma AZ ejecutando un sistema de archivos compatible con clústeres — una excepción limitada, no un patrón general de “EBS compartido”. Intentar adjuntar EBS ampliamente a través de 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 visibles al actualizar, otros no” porque cada volumen es un dispositivo de bloque privado.

Los volúmenes EBS se cifran en reposo con AES-256 utilizando claves de datos envueltas en KMS. El cifrado es transparente — sin penalización de rendimiento, sin cambios en la aplicación. Una vez que un volumen está cifrado, los snapshots y volúmenes derivados se cifran; no se puede descifrar en el mismo lugar. Habilite el cifrado de EBS por defecto por Región para que cada nuevo volumen y snapshot se cifre independientemente de la memoria del desarrollador:

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 existentes no cifrados no se cifran retroactivamente — la remediación requiere un snapshot, una copia con cifrado y la creación de 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 gratuitas (se paga por los bloques modificados retenidos), no desaparecen cuando se elimina el volumen de origen y no se eliminan cuando se anula el registro de una AMI que los referencia. Envejézcalos en el nivel EBS Snapshots Archive (75% más barato, restauración de 24 a 72 horas) a través de aws ec2 modify-snapshot-tier, Amazon Data Lifecycle Manager (DLM) o AWS Backup. Fast Snapshot Restore (FSR) precalienta un snapshot en AZs específicas para que las instancias lanzadas desde él ofrezcan un rendimiento completo de inmediato — habilítelo para AMIs detrás de grupos de autoescalado que deben manejar una rápida expansión.

La Papelera de reciclaje captura los snapshots de EBS y las AMIs eliminadas en una ventana de restauración (de 1 día a 1 año). Sin ella, 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 de cumplimiento a largo plazo es un error arquitectónico común — los snapshots tienen un precio más cercano al almacenamiento en caliente y requieren transiciones de archivo explícitas.

Amazon EFS: POSIX compartido para flotas Linux

EFS es un sistema de archivos NFSv4.1 totalmente administrado, elástico y compatible con POSIX que se puede montar simultáneamente desde miles de clientes EC2, ECS, EKS o Lambda en múltiples AZs en una Región, y desde hosts locales a través de Direct Connect o VPN. La propiedad definitoria es que el mismo sistema de archivos, con identificadores de archivo y semántica a nivel de byte idénticos, es visible para cada cliente a la vez. Por lo tanto, EFS es la respuesta correcta siempre que una flota Linux detrás de un balanceador de carga deba compartir un conjunto común de archivos — cargas de usuarios, configuración, directorios de inicio compartidos.

Los destinos de montaje residen en cada subred de AZ que configure. El asistente amazon-efs-utils habilita TLS en tránsito y la autorización de montaje de IAM:

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

Las clases de almacenamiento de EFS abarcan dos dimensiones. La gestión del ciclo de vida clasifica 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 al acceso. Las clases One Zone almacenan en una sola AZ por ~47% menos — apropiado para desarrollo/pruebas o datos reproducibles, nunca para datos cuya pérdida durante una falla de AZ sea inaceptable. Una medida de ajuste 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 (establecido en la creación): General Purpose tiene la latencia más baja y es correcto para el servicio web con muchos metadatos; Max I/O es una opción heredada superada por Elastic. Modo de rendimiento: Bursting escala con el tamaño (50 KB/s por GB de línea base, créditos de ráfaga cuando está por debajo de la línea base), Provisioned paga por un MB/s fijo independientemente del tamaño, y Elastic — el valor predeterminado actual — se autoescala a más de 10 GB/s sin planificación de capacidad. Un sistema de archivos pequeño bajo carga sostenida puede agotar los créditos de ráfaga y limitarse a una línea base baja, por lo que las cargas de trabajo de E/S pesadas con huellas pequeñas deben usar Elastic o Provisioned.

EFS no es un sustituto del almacenamiento en bloque de altas IOPS. Cada E/S de EFS es un RPC de NFS a través de la red, por lo que las cargas de trabajo de un solo escritor, de sub-milisegundos, de estilo de registro de transacciones pertenecen a EBS io2 Block Express — un solo volumen ofrece 256,000 IOPS con latencia de sub-milisegundos, lo que EFS no puede igualar por operación. EFS también es excesivamente caro para datos fríos en comparación con Deep Archive; mantener datos de cumplimiento en EFS “porque es fácil” es indefendible.

FSx: Windows, Lustre, ONTAP, OpenZFS

FSx es una familia de sistemas de archivos administrados seleccionados por protocolo y carga de trabajo:

FSx for Windows File Server ofrece SMB 2.0/3.1.1 nativo con ACL de NTFS, espacios de nombres DFS, copias de sombra y Kerberos sobre Active Directory. Multi-AZ implementa un servidor de archivos activo en una AZ con un servidor en espera replicado sincrónicamente en otra y un único nombre DNS de conmutación por error. La integración con AD no es opcional: FSx debe unirse a AWS Managed Microsoft AD o a un AD autoadministrado accesible, y los clientes se autentican como usuarios de dominio contra los SIDs de dominio. Omitir AD, o apuntar a los clientes a un sistema de archivos en un bosque no confiable sin una confianza entre bosques, produce el clásico síntoma de acceso denegado a pesar de que el recurso compartido es visible. FSx for Windows es el objetivo directo para la migración 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, metadatos de sub-ms. Su característica crítica de AWS es la asociación de repositorio de datos con S3: las claves de objeto aparecen como archivos en el espacio de nombres de Lustre y se cargan de forma diferida en el primer acceso (o se precargan a través de hsm_restore); los archivos nuevos/modificados se exportan de nuevo a S3 según un cronograma o bajo demanda. El patrón canónico de HPC es:

1. Copiar conjuntos de datos on-prem en S3 (a través de DataSync o Storage Gateway).
2. Crear Lustre vinculado a ese bucket.
3. Montar en todos los workers de Spot; leer entradas, escribir salidas a velocidad de línea.
4. Exportar resultados a S3, que sigue siendo el repositorio duradero a largo plazo.
5. Eliminar el sistema de archivos Lustre cuando finaliza el trabajo.

Las implementaciones de Lustre Scratch no tienen replicación y pierden datos en caso de fallo de hardware — son las más baratas y rápidas, apropiadas para datos de trabajos transitorios. Las implementaciones Persistent se replican dentro de una AZ para una mayor durabilidad. El rendimiento 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 en los mismos datos, con instantáneas, replicación SnapMirror, FlexClones y deduplicación. Elija ONTAP al consolidar recursos compartidos mixtos de Linux NFS y Windows SMB que necesitan acceso multiprotocolo con redundancia Multi-AZ, o al migrar desde NetApp on-prem. FSx for OpenZFS cubre un nicho para cargas de trabajo de Linux que necesitan características de ZFS (instantáneas, clones) sobre NFS. No confunda la fortaleza multiprotocolo de ONTAP con las otras variantes.

Elija mal y fallará limpiamente: 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 todos inadecuados — 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 datos.

Para una aplicación de renderizado que movió su biblioteca de medios a S3 pero aún necesita lecturas de baja latencia on-prem, S3 File Gateway es la solución — acceso NFS/SMB, caché local, objetos fríos obtenidos de S3 bajo demanda. FSx File Gateway es la respuesta para sucursales: caché SMB a velocidad de LAN de un recurso compartido central de FSx en la nube, no una solución para acceso compartido entre instancias EC2 (que deberían montar FSx directamente). Volume Gateway se aplica cuando la carga de trabajo utiliza iSCSI de bloque en lugar de semántica de archivos. Tape Gateway reemplaza las bibliotecas 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 agentes para NFS, SMB, HDFS y almacenes de objetos a S3, EFS o FSx — 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 menos sobrecarga es DataSync a FSx for Windows: SMB se conserva, las ACL/marcas de tiempo intactas, el rendimiento de archivos pequeños se maneja a través de transferencias paralelas, sin 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 las listas de archivos pequeños en prefijos profundos y los clientes SMB no pueden montar buckets.

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

AWS Transfer Family expone SFTP, FTPS, FTP y AS2 respaldados por S3 o EFS — 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 en EBS, EFS, FSx, RDS, DynamoDB, S3 y más. Un plan de backup define el cronograma, la retención en caliente, la transición a almacenamiento en frío y las acciones de copia entre regiones/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 en frío requiere al menos 90 días de retención en caliente más al menos 90 días en frío; los ciclos de vida mal configurados son rechazados. Para una verdadera retención regulatoria de varios años, combínelo con AWS Backup Vault Lock (WORM), que impide incluso a los administradores acortar la retención, lo que satisface la SEC 17a-4 y mandatos similares. La copia entre regiones aborda la DR regional; la copia entre cuentas aborda escenarios de ransomware y amenazas internas al aislar los backups del radio de impacto de la cuenta de producción.

Hoja de trucos de selección

← 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 →