Amazon SAA-C03: Transferencia y Migración 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.

La decisión Ancho de banda vs. Envío

Toda migración comienza con aritmética. Calcule el tiempo de transferencia teórico antes de elegir una herramienta:

Transfer days = (Dataset size in bits) / (Usable bandwidth in bps × 86,400)
Usable bandwidth = Link speed × Allowed utilization %

Los números son implacables. A 100 Mbps sostenidos, 1 TB tarda aproximadamente 24 horas; a 1 Gbps, unas 2,5 horas. Un enlace de 15 Mbps limitado al 70% de utilización entrega solo ~113 GB por día, por lo que 20 TB necesitarían más de 175 días. Transferir 150 TB durante la noche (10 horas al 80% de 100 Mbps) produce ~360 GB por noche, o 10,5 TB por mes, lo que no se acerca a un plazo de 30 días. Incluso completamente saturado 24/7, 100 Mbps mueve solo ~1 TB/día, por lo que 150 TB necesitan un mínimo de 150 días. A escala de petabytes, la situación empeora: un enlace de 500 Mbps con eficiencia real entrega aproximadamente 5,4 TB/día de rendimiento teórico, lo que significa que 10 PB requerirían más de cinco años de transferencia continua, más tiempo del que tardan en aprovisionarse la mayoría de los circuitos de Direct Connect.

Una regla general razonable:

La respuesta incorrecta más común en escenarios de migración es elegir una transferencia WAN que matemáticamente no puede finalizar dentro del plazo. La trampa corolaria — “simplemente lo ejecutaremos todas las noches a través de la WAN” — no es simplemente más lenta. Consume ancho de banda de producción, arriesga transferencias parciales o corruptas que requieren nuevas cargas y, por lo general, cuesta más una vez que se cuentan los cargos de ancho de banda y el tiempo de ingeniería. Un cargo por unidad de Snowball más el envío es un elemento de línea fijo y predecible.

La familia Snow para transferencia masiva offline

Los dispositivos Snowball Edge vienen en dos variantes:

Snowcone es el formato pequeño (~8 TB SSD), robusto y que se puede enviar por mensajería, útil para sitios con espacio limitado y precargado con agentes DataSync para sincronización en el borde. Snowmobile, un contenedor de 45 pies que transporta hasta 100 PB, estaba dirigido a evacuaciones de centros de datos a escala de exabytes, pero ha sido desaprobado en favor de flotas paralelas de Snowball Edge en la mayoría de las regiones. Seleccionar Snowmobile para cualquier cosa por debajo de un petabyte es un distractor.

La variante Compute no es solo una unidad más grande. Ejecuta AMIs de EC2, funciones Lambda y cargas de trabajo de Greengrass localmente, lo que la convierte en la opción correcta cuando los datos deben transformarse, filtrarse o se debe redactar la PII antes de la ingesta, cuando una carga de trabajo debe reanudarse inmediatamente en AWS después de la ingesta, o cuando el sitio está desconectado o conectado intermitentemente (barcos, minería remota, despliegues tácticos, investigación remota). Elija Compute Optimized cuando se requiera procesamiento en el dispositivo; elija Storage Optimized cuando la carga de trabajo sea una copia masiva pura.

Cada dispositivo Snow realiza cifrado en reposo de 256 bits utilizando claves KMS que nunca salen de AWS. Los gabinetes son a prueba de manipulaciones con una etiqueta de envío E Ink y un Módulo de Plataforma Confiable de hardware. Los datos en el dispositivo se escriben utilizando el cliente Snowball, el endpoint compatible con S3 o un montaje NFS; TLS protege los datos en tránsito durante la ingesta y el intercambio del manifiesto de envío. Al regresar, el contenido se ingesta en S3 y el dispositivo se borra criptográficamente según NIST 800-88.

Para trabajos de petabytes por sitio, el paralelismo es el patrón. Una oficina con 1-2 Gbps de capacidad de enlace aún necesitaría meses de saturación continua para mover 1 PB en línea; una flota de ~13 dispositivos Storage Optimized por sitio (cada uno de 80 TB) enviados en paralelo cumple con un plazo de cuatro semanas mientras se ahorra el enlace de internet de la oficina. Para un trabajo de 600 TB en dos semanas en un enlace saturado de 100 Mbps, una pequeña flota paralela es la única respuesta correcta, incluso ignorando el costo, la física hace que DataSync o un nuevo Direct Connect sean imposibles.

DataSync para transferencia online, verificada e incremental

DataSync es la herramienta adecuada cuando el ancho de banda es suficiente, pero las características de la carga de trabajo (millones de archivos pequeños, árboles de directorios profundos, sincronizaciones incrementales continuas o migración entre sistemas de archivos) paralizarían las herramientas ingenuas. Un directorio de 20 millones de archivos de 4 KB copiados con aws s3 cp se ve limitado por la latencia de ida y vuelta, no por el rendimiento; cada PutObject incurre en un viaje de ida y vuelta TLS/HTTP y un cargo por solicitud de API. Agrupar en archivos funciona, pero renuncia a la direccionabilidad por archivo. El agente de DataSync se paraleliza en muchas transmisiones TCP, maneja los metadatos de forma nativa, verifica la suma de comprobación de cada archivo de extremo a extremo con SHA-256, reintenta de forma transparente e informa a CloudWatch, logrando hasta ~10 Gbps por agente con precios predecibles por GB.

Las fuentes y destinos abarcan NFS, SMB, HDFS, almacenes de objetos autogestionados, S3, EFS, FSx para Windows File Server, FSx para Lustre, FSx para OpenZFS y FSx para NetApp ONTAP. Las transferencias utilizan TLS 1.2 en tránsito y pueden atravesar endpoints de interfaz de VPC para mantenerse fuera de la internet pública.

Un detalle crítico: DataSync requiere un agente para fuentes NFS/SMB locales. El agente se ejecuta como una VM en VMware, Hyper-V o KVM, en EC2 o en Snowcone. Creer que DataSync no tiene agente para entornos locales es una trampa común: solo no tiene agente cuando ambos endpoints son servicios nativos de AWS.

Una implementación mínima:

# Activate the on-prem agent
aws datasync create-agent \
  --activation-key ABCDE-12345-FGHIJ-67890-KLMNO \
  --agent-name onprem-nfs-agent \
  --vpc-endpoint-id vpce-0a1b2c3d

# Define source (NFS) and destination (S3)
aws datasync create-location-nfs \
  --server-hostname 10.0.5.20 \
  --subdirectory /export/video \
  --on-prem-config AgentArns=arn:aws:datasync:...:agent/agent-0abc

aws datasync create-location-s3 \
  --s3-bucket-arn arn:aws:s3:::video-archive \
  --s3-config BucketAccessRoleArn=arn:aws:iam::111122223333:role/DataSyncS3Role

# Task with bandwidth cap, verification, and a nightly schedule
aws datasync create-task \
  --source-location-arn <nfs-arn> \
  --destination-location-arn <s3-arn> \
  --options VerifyMode=POINT_IN_TIME_CONSISTENT,BytesPerSecond=104857600,PreserveDeletedFiles=PRESERVE,PosixPermissions=PRESERVE \
  --schedule ScheduleExpression="cron(0 2 * * ? *)"

Dos características operativas importan. La limitación de ancho de banda (BytesPerSecond) evita saturar un enlace compartido, respondiendo directamente a patrones como “enlace de 1 Gbps compartido con otros departamentos”. El filtrado y la programación permiten sincronizaciones fuera de horario y la exclusión de archivos transitorios. En un Direct Connect de 10 Gbps con usuarios que continúan leyendo y escribiendo, la programación de tareas repetidas es el patrón canónico: el barrido inicial transfiere el grueso, las ejecuciones incrementales sucesivas detectan las diferencias, y 700 TB son alcanzables en menos de una semana incluso con una utilización parcial.

Una trampa más sutil se refiere a la fidelidad de los metadatos. DataSync conserva un conjunto seleccionado de atributos POSIX o SMB (UID/GID/modo/marcas de tiempo para NFS, propiedad y DACLs para SMB), pero no captura todos los atributos propietarios de NAS. Las ACLs específicas del proveedor, los atributos extendidos más allá de lo que expone el protocolo, las instantáneas y los metadatos de deduplicación quedan fuera de su alcance. Cuando el cumplimiento requiere una réplica exacta de NAS que incluya características del proveedor, DataSync por sí solo es insuficiente; se requiere una ruta consciente de NetApp, como FSx para ONTAP con SnapMirror, o un lift-and-shift a través de Storage Gateway.

DataSync también complementa a Snowball: Snowball mueve los 150 TB iniciales, y DataSync maneja el delta semanal continuo de un conjunto de trabajo de 500 GB a partir de entonces.

Storage Gateway: Presentación híbrida, no migración

Storage Gateway no es una herramienta de migración, es una capa de presentación híbrida. Las aplicaciones locales siguen utilizando NFS, SMB, iSCSI o iSCSI-VTL, mientras que los datos se almacenan en S3, S3 Glacier o instantáneas de EBS. Confundir Storage Gateway con DataSync es un error frecuente: File Gateway no está diseñado para mover 70 TB rápidamente, y DataSync no presenta un recurso compartido persistente a los clientes locales.

File Gateway es el caballo de batalla. Escribir \\gateway\share\reports\2024\report.pdf produce s3://bucket/reports/2024/report.pdf, consumible de forma nativa por Athena, Lambda, EMR o cualquier cliente de S3. Este mapeo uno a uno de archivo a objeto es una ventaja importante sobre los destinos de respaldo de “caja negra”. El almacenamiento en caché local significa que los archivos “calientes” se devuelven a la velocidad de la LAN; los archivos “fríos” se transmiten desde S3 bajo demanda.

La caché es el punto clave del dispositivo. Las lecturas de datos “calientes” se sirven localmente; las escrituras se almacenan primero en el disco local y se cargan asincrónicamente. Un error de diseño común es asumir que, al estar respaldado por S3, cada lectura incurre en la latencia de un viaje de ida y vuelta por Internet, lo cual no es cierto, siempre que el conjunto de trabajo quepa en la caché. Por el contrario, un tamaño de caché insuficiente produce constantes fallos de caché y la carga de trabajo parece “lenta”. Regla general: caché = 20% del conjunto de datos total o 100% del conjunto de trabajo “caliente”, lo que sea mayor.

La trampa de “en caché” vs. “almacenado” merece una atención especial. El modo en caché mantiene la copia primaria en S3 con bloques “calientes” locales —barato, elástico, pero un fallo de caché es un viaje de ida y vuelta por la WAN. El modo almacenado mantiene la copia primaria en el disco local con instantáneas asíncronas a S3 como instantáneas de EBS —cada lectura es local y de baja latencia, pero todo el conjunto de datos debe caber en el entorno local. Para un requisito de reemplazo de respaldo de “acceso local a todos los datos mientras se respaldan en AWS”, el modo almacenado es correcto; el modo en caché violaría el requisito. Elegir el modo en caché para una carga de trabajo que necesita todo el conjunto de datos con baja latencia anula el diseño; elegir el modo almacenado cuando el sitio no puede alojar el conjunto de datos completo es imposible por definición.

Tape Gateway responde a un objetivo muy específico: retirar una biblioteca de cintas físicas manteniendo intactos los flujos de trabajo de Veeam, NetBackup o Commvault al presentar una VTL sobre iSCSI, con datos con ciclo de vida desde S3 a Glacier o Deep Archive. Es invaluable cuando la retención regulatoria se define en términos de medios de cinta y el software de respaldo existente no puede cambiar.

AWS Transfer Family

Transfer Family proporciona puntos finales SFTP, FTPS, FTP y AS2 totalmente administrados respaldados por S3 o EFS. La propuesta de valor es la preservación de los contratos de protocolo orientados a socios: los sistemas de proveedores que emiten archivos solo a través de SFTP continúan haciéndolo sin cambios, mientras que el extremo receptor es S3 nativo, con políticas de ciclo de vida, disparadores de Lambda e integración de análisis.

La trampa aquí es asumir que un proveedor heredado puede “simplemente cambiar a las API de S3”. Muchos sistemas de proveedores son dispositivos, fuentes HL7 de hospitales, sistemas de lotes bancarios o pipelines EDI B2B cuyo cliente SFTP está integrado en el firmware o en binarios firmados. El costo de la gestión de cambios, la revisión de seguridad y la recertificación de tocarlos a menudo excede toda la migración a AWS. Transfer Family lo evita por completo. El soporte de AS2 también permite cargas de trabajo EDI con recibos MDN y firma/cifrado de mensajes para el cumplimiento B2B.

La autenticación admite usuarios administrados por el servicio, AWS Directory Service (Managed Microsoft AD o AD Connector para AD local) o un proveedor de identidad personalizado a través de API Gateway/Lambda, lo que permite que las credenciales corporativas existentes sigan siendo la fuente de la verdad. Un autorizador de Lambda puede devolver roles de IAM por usuario, mapeos de directorios de inicio y políticas de sesión, lo que brinda aislamiento por proveedor sin infraestructura por proveedor.

Type: AWS::Transfer::Server
Properties:
  Protocols: [SFTP]
  IdentityProviderType: AWS_DIRECTORY_SERVICE
  IdentityProviderDetails:
    DirectoryId: d-9067f4a1c2
  Domain: S3
  EndpointType: VPC
  EndpointDetails:
    VpcId: vpc-0abc123
    SubnetIds: [subnet-0a, subnet-0b]
    SecurityGroupIds: [sg-0sftp]

Amazon AppFlow

AppFlow es la capa de integración administrada para el movimiento de datos de SaaS a AWS: Salesforce, ServiceNow, Google Analytics, Slack, Marketo, SAP OData, Zendesk y docenas de otros que fluyen a S3, Redshift o Snowflake. Maneja la paginación, la extracción incremental, el mapeo de campos, el filtrado, el enmascaramiento y la validación sin un trabajo ETL manual.

La característica crítica para la seguridad es la integración de PrivateLink para los conectores compatibles (especialmente Salesforce). En lugar de salir a la Internet pública para llegar al inquilino de SaaS y regresar a AWS, el flujo atraviesa un punto final de VPC privado, eliminando la exposición a la Internet pública de las cargas útiles de extracción y simplificando la postura de auditoría para cargas de trabajo de atención médica, finanzas y PII. Los flujos se pueden programar, activar por eventos de cambios de registros de SaaS o ejecutar bajo demanda, y admiten hasta 100 GB por ejecución de flujo.

AppFlow opera en una capa superior a DataSync o Storage Gateway: es la herramienta adecuada cuando la fuente es un SaaS impulsado por API, no un sistema de archivos o una base de datos.

Migración de bases de datos: DMS y SCT

AWS Database Migration Service replica datos entre bases de datos de origen y destino mientras el origen permanece completamente operativo. Admite migraciones homogéneas (MySQL → RDS MySQL, Oracle → RDS Oracle) y heterogéneas (Oracle → Aurora PostgreSQL, SQL Server → MySQL), y los destinos se extienden más allá de RDS a Aurora, Redshift, S3, DynamoDB y Kinesis. Los orígenes incluyen Oracle, SQL Server, MySQL, PostgreSQL, MongoDB y Db2.

Una tarea opera en uno de tres modos:

El motor de la migración con tiempo de inactividad mínimo es la Captura de Datos Modificados (CDC). Durante la carga completa más CDC, DMS copia masivamente las filas existentes mientras extrae el registro de transacciones de origen — Oracle redo, MySQL binlog, SQL Server MS-CDC o MS-Replication. Una vez que la carga completa se completa, CDC aplica los cambios en cola y mantiene el destino continuamente actualizado hasta que la aplicación cambia. No habilitar CDC cuando la aplicación debe permanecer escribible es un error arquitectónico común: la carga completa solo deja el destino obsoleto en el momento en que la carga se completa.

{
  "MigrationType": "full-load-and-cdc",
  "ReplicationTaskSettings": {
    "TargetMetadata": { "ParallelLoadThreads": 8 },
    "ChangeProcessingTuning": { "BatchApplyEnabled": true }
  }
}

Para trabajos heterogéneos, AWS Schema Conversion Tool (o su hermano en la nube DMS Schema Conversion) traduce DDL, procedimientos almacenados, vistas y funciones, marcando los elementos que requieren reescrituras manuales. DMS mueve datos; SCT convierte el esquema. Saltar el informe de evaluación de SCT es la forma en que las migraciones fallan tres días antes de la migración.

Los requisitos previos y las limitaciones específicas del motor son difíciles de ignorar. Los LOB de Oracle de más de 64 KB requieren el modo LOB limitado con un máximo fijo; LONG RAW tiene advertencias. PostgreSQL requiere wal_level=logical y un rol de replicación. MySQL requiere el registro binario en formato ROW con binlog_row_image suficiente y privilegios de CDC elevados (REPLICATION CLIENT, REPLICATION SLAVE). Oracle Spatial, los comportamientos específicos de RAC y los ensamblados CLR de SQL Server comúnmente no son compatibles. TLS se aplica entre la instancia de replicación y los puntos finales, con los modos SSL require, verify-ca o verify-full.

DMS Serverless es la opción correcta cuando el perfil de la carga de trabajo es impredecible o con picos — un sistema Oracle local con picos diurnos y noches tranquilas, por ejemplo. Usted define MinCapacityUnits y MaxCapacityUnits en DCU (DMS Capacity Units) y DMS escala la capacidad de replicación en función de la presión de la CPU y la memoria:

ReplicationConfigIdentifier: oracle-to-rds-cdc
ReplicationType: full-load-and-cdc
SourceEndpointArn: arn:aws:dms:...:endpoint:oracle-onprem
TargetEndpointArn:  arn:aws:dms:...:endpoint:rds-oracle
ComputeConfig:
  MinCapacityUnits: 4
  MaxCapacityUnits: 64
  MultiAZ: true

Una trampa frecuente es asumir que una instancia de DMS aprovisionada (por ejemplo, dms.c5.4xlarge) se autoescalará. No lo hará — las instancias aprovisionadas son hosts EC2 de tamaño fijo. Si el rendimiento excede la capacidad, el retraso de la replicación aumenta y debe modificar manualmente la clase de instancia, reiniciando las tareas. DMS aprovisionado se adapta a migraciones de estado estable con un rendimiento conocido; Serverless se adapta a las impredecibles.

Para una migración de MySQL de 20 TB con una ventana de dos semanas y un tiempo de inactividad ajustado, DMS con carga completa más CDC en Aurora MySQL o RDS MySQL es la opción rentable. Las restauraciones nativas de mysqldump/mysqlpump incurren en un tiempo de inactividad inaceptable; Snowball agrega latencia de envío y brechas fuera de línea.

DMS Fleet Advisor descubre inventarios de bases de datos locales, útil para la planificación de olas.

Migración de servidores: AWS Application Migration Service (MGN)

AWS Application Migration Service es el servicio principal de lift-and-shift (“rehost”) y ha reemplazado a CloudEndure Migration y Server Migration Service para la mayoría de los casos de uso. MGN instala un Agente de Replicación de AWS ligero en cada servidor de origen (físico, VMware, Hyper-V u otra nube). El agente realiza una instantánea inicial a nivel de bloque en un área de preparación de bajo costo en la VPC de destino — pequeñas instancias T3 con volúmenes EBS adjuntos — y luego replica continuamente los cambios a nivel de bloque de forma asíncrona. Debido a que la replicación es a nivel de bloque y continua, la migración se mide en minutos: MGN convierte los volúmenes de preparación en instancias EC2 de producción del tipo de instancia de destino en el momento de la migración.

1. Install replication agent on each source (or use agentless for vCenter)
2. Configure launch template (instance type, subnet, IAM role, tags)
3. Run "Test" launches → validate → "Cutover" launch → decommission source

Los lanzamientos de prueba son esenciales y a menudo se omiten. MGN inicia instancias de prueba aisladas desde el estado de replicación actual sin interrumpir la replicación en curso. Usted valida el comportamiento de la aplicación, descarta la prueba, itera y solo inicia la migración cuando las pruebas pasan — la migración detiene la replicación, lanza la instancia final y marca la ola como completa.

El enfoque incorrecto es exportar manualmente las VM a OVF, cargarlas a través de aws ec2 import-image y reinstalar las aplicaciones en instancias EC2 recién aprovisionadas. Esto es lento, propenso a errores, requiere un tiempo de inactividad por VM igual a la duración de la exportación, no proporciona replicación delta y no ofrece pruebas no disruptivas. MGN elimina todo eso — el origen sigue funcionando hasta el último segundo de la migración final, y la desviación entre el origen y el destino es esencialmente cero.

La guía general del portafolio es rehostear primero, luego replatformar o refactorizar en la Región donde el costo de iteración es menor. La refactorización y migración simultáneas multiplican el riesgo sin un beneficio compensatorio.

Conectividad híbrida: Direct Connect y VPN

AWS Direct Connect proporciona un circuito dedicado de Capa 2 desde un enrutador local a una ubicación de Direct Connect, ofreciendo un ancho de banda consistente (1, 10, 100 Gbps dedicados; sub-1 Gbps a través de conexiones alojadas por socios) y latencia predecible. Las interfaces virtuales particionan el circuito:

• VIF privada — acceso a una única VPC a través de una Virtual Private Gateway.
• VIF de tránsito — acceso a muchas VPC a través de una Direct Connect Gateway adjunta a una Transit Gateway. Este es el patrón canónico para entornos grandes de múltiples VPC y múltiples sitios.
• VIF pública — acceso a los puntos finales de servicios públicos de AWS (S3, DynamoDB) sin atravesar Internet.

DX no es, por sí mismo, de alta disponibilidad: un solo circuito en una única ubicación de DX depende de una única ruta de fibra. Dos patrones de resiliencia son importantes:

1. DX + respaldo de VPN de sitio a sitio a través de Internet es la HA mínima viable. BGP maneja la conmutación por error automática con AS-path prepending, MED o local-pref para preferir DX en estado estable.
2. Circuitos DX duales en ubicaciones DX separadas es el patrón de máxima resiliencia para cargas de trabajo de misión crítica y es requerido para el SLA de DX.

No aprovisionar ninguna ruta de respaldo es una trampa bien conocida: cuando DX falla y no hay VPN, las aplicaciones híbridas, los trabajos de DataSync y las cargas de Storage Gateway se detienen durante la duración de la reparación del operador. La VPN pura es aceptable para cargas de trabajo de menor rendimiento o como un puente mientras se aprovisiona DX, lo que puede llevar semanas.

On-prem Router ──── DX (primary, BGP MED=100) ────┐
                                                   ├── VGW/DXGW ── VPC
On-prem Router ──── VPN over Internet (backup) ────┘

# Multi-VPC access via DX Gateway
DirectConnectGateway:
  Associations:
    - TransitGateway: tgw-corp
    - VirtualPrivateGateway: vgw-prod-vpc
  AllowedPrefixes:
    - 10.0.0.0/8

Cuando se exige el cifrado de capa física, elija una conexión DX habilitada para MACsec. La combinación de DX para el ancho de banda, DataSync para la orquestación y Storage Gateway para el acceso local continuo es el patrón híbrido canónico para grandes conjuntos de datos en vivo que no pueden tolerar una ventana de inactividad.

AWS Outposts para infraestructura AWS local

Outposts extiende la infraestructura de AWS a las instalaciones de un cliente como un rack totalmente administrado (o servidores Outposts de 1U/2U). Ejecuta un conjunto seleccionado de servicios localmente — EC2, EBS, ECS, EKS, RDS, S3 en Outposts, EMR — con las mismas API que la Región principal. Las operaciones del plano de control regresan a la Región principal a través de un enlace de servicio de túneles cifrados redundantes; una interrupción de la WAN impide temporalmente el lanzamiento de nuevas instancias, pero no detiene las cargas de trabajo en ejecución.

La división de responsabilidad compartida es la trampa que atrapa a los operadores. AWS entrega y mantiene el hardware, el hipervisor y los servicios administrados. El cliente es responsable de:

• Espacio físico, energía, refrigeración y redes que cumplan con las especificaciones de Outposts (fuentes de alimentación redundantes, switches ascendentes, PDUs apropiadas).
• Seguridad física de las instalaciones.
• Configuración de la red local — el Local Gateway (LGW) para el tráfico local y el enlace ascendente del servicio.
• Preocupaciones del sistema operativo y de la aplicación de las cargas de trabajo, exactamente como en la Región.
• Conectividad WAN adecuada a la Región principal.

Outposts no elimina las operaciones, sino que cambia la abstracción. Asumir que AWS es responsable de la energía del centro de datos o de la red ascendente es una mala interpretación fundamental. Tampoco es “ejecutar cualquier servicio de AWS localmente”: la lista de servicios compatibles es finita, y servicios como Route 53 o IAM siguen siendo basados en la Región.

Para una modernización de Hadoop/Spark donde los datos deben permanecer en las instalaciones por razones regulatorias, EMR en Outposts es el patrón correcto: clústeres Spark administrados y elásticos con herramientas en la Región y residencia de datos local. Storage Gateway o DataSync no cumplen con el requisito de residencia; la migración lift-and-shift a EMR en la Región no cumple con la normativa.

Distribución de contenido a flotas de borde

Cuando los servidores Outposts, las tiendas minoristas o los dispositivos de borde extraen repetidamente la misma carga útil grande —una versión de software nocturna, por ejemplo—, la extracción directa de un bucket de S3 en una sola Región satura los enlaces ascendentes e infla el tiempo de implementación. El patrón correcto es CloudFront con un origen S3 y URL firmadas:

S3 bucket (ap-northeast-1)  ← Origin Access Control
        │
   CloudFront distribution (global edge PoPs)
        │
   Signed URLs (short expiry, per-server or per-release)
        │
   Edge devices download from nearest PoP

El primer dispositivo en una región calienta la caché de borde; cada dispositivo subsiguiente extrae con latencia de borde. Las URL firmadas evitan descargas no autorizadas sin credenciales de IAM por dispositivo, y no hay una flota de réplicas regionales que administrar.

Dos antipatrones a rechazar: alojar la versión en un único servidor web EC2 (un desastre de escalado y latencia), y replicar el bucket de S3 en cada Región a través de Cross-Region Replication solo para reducir la latencia de descarga (costo de almacenamiento innecesario y complejidad operativa que el almacenamiento en caché de CloudFront resuelve de forma gratuita).

Resumen de decisiones

← Almacenamiento y Ciclo de Vida de Datos · Todos los dominios · Redes y Conectividad →

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

Explorar Amazon →