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

La decisión: ancho de banda frente a envío físico

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 no perdonan. 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 su 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 al mes, lo que no se acerca ni de lejos a un plazo de 30 días. Incluso saturados al máximo 24/7, 100 Mbps mueven solo ~1 TB/día, por lo que 150 TB necesitan un mínimo de 150 días. A escala de petabytes, el panorama empeora: un enlace de 500 Mbps con una eficiencia del mundo real ofrece un rendimiento teórico de aproximadamente 5,4 TB/día, lo que significa que 10 PB requerirían más de cinco años de transferencia continua, más tiempo del que se tarda en aprovisionar la mayoría de los circuitos de Direct Connect.

Una regla general razonable:

La respuesta incorrecta más común en los escenarios de migración es elegir una transferencia por WAN que matemáticamente no puede finalizar dentro del plazo establecido. La trampa corolaria —“simplemente lo ejecutaremos cada noche por la WAN”— no es solo más lenta. Consume ancho de banda de producción, se arriesga a transferencias parciales o corruptas que requieren nuevas subidas y, por lo general, cuesta más una vez que se contabilizan los cargos por ancho de banda y el tiempo de ingeniería. El cargo por una unidad Snowball más el envío es una partida presupuestaria fija y predecible.

La familia Snow para la transferencia masiva sin conexión

Los dispositivos Snowball Edge vienen en dos variantes:

Snowcone es el formato pequeño (~8 TB de SSD), reforzado y transportable por mensajería, útil para sitios con espacio limitado y precargado con agentes de DataSync para la 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 descontinuado en favor de flotas de Snowball Edge en paralelo en la mayoría de las regiones. Seleccionar Snowmobile para cualquier cosa por debajo de un petabyte es un distractor.

La variante de cómputo no es solo una unidad más grande. Ejecuta AMIs de EC2, funciones de 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 eliminar 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 de forma intermitente (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 un cifrado de 256 bits en reposo utilizando claves de KMS que nunca salen de AWS. Las carcasas son a prueba de manipulaciones, con una etiqueta de envío de tinta electrónica (E Ink) y un Módulo de plataforma segura (Trusted Platform Module) de hardware. Los datos en el dispositivo se escriben utilizando el cliente de Snowball, el punto de conexión 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. A su regreso, el contenido se ingiere en S3 y el dispositivo se borra criptográficamente según la norma NIST 800-88.

Para trabajos de petabytes por sitio, el paralelismo es el patrón a seguir. Una oficina con una capacidad de enlace de 1–2 Gbps 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, a la vez que preserva el enlace de internet de la oficina. Para un trabajo de 600 TB en dos semanas con un enlace saturado de 100 Mbps, una pequeña flota en paralelo 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 en línea, 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 a las herramientas más simples. Un directorio con 20 millones de archivos de 4 KB copiado con aws s3 cp sufre un cuello de botella por la latencia de ida y vuelta, no por el rendimiento (throughput); cada PutObject incurre en un viaje de ida y vuelta TLS/HTTP y un cargo por solicitud de API. Agrupar los archivos en paquetes comprimidos funciona, pero se pierde la capacidad de acceder a cada archivo individualmente. El agente de DataSync paraleliza la transferencia a través de múltiples flujos TCP, maneja los metadatos de forma nativa, verifica la suma de comprobación (checksum) de cada archivo de extremo a extremo con SHA-256, reintenta las operaciones de forma transparente e informa a CloudWatch, alcanzando hasta ~10 Gbps por agente con precios predecibles por GB.

Los orígenes y destinos abarcan NFS, SMB, HDFS, almacenamientos de objetos autogestionados, S3, EFS, FSx for Windows File Server, FSx for Lustre, FSx for OpenZFS y FSx for NetApp ONTAP. Las transferencias utilizan TLS 1.2 en tránsito y pueden atravesar los endpoints de interfaz de VPC para no salir a la red pública de internet.

Un detalle crítico: DataSync requiere un agente para los orígenes NFS/SMB on-premises. El agente se ejecuta como una VM en VMware, Hyper-V o KVM, en EC2 o en un Snowcone. Creer que DataSync funciona sin agente para entornos on-prem es una trampa común; solo funciona sin agente cuando ambos extremos 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 son importantes. La limitación del 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 del horario laboral y la exclusión de archivos transitorios. Sobre una conexión Direct Connect de 10 Gbps con usuarios que continúan leyendo y escribiendo, programar tareas repetidas es el patrón canónico: el barrido inicial transfiere el grueso de los datos, las ejecuciones incrementales sucesivas capturan los deltas, y es posible transferir 700 TB en bastante menos de una semana, incluso con una utilización parcial.

Un escollo más sutil se refiere a la fidelidad de los metadatos. DataSync preserva 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 un NAS. Las ACL específicas del proveedor, los atributos extendidos más allá de lo que expone el protocolo, las instantáneas (snapshots) y los metadatos de deduplicación quedan fuera de su alcance. Cuando el cumplimiento normativo requiere una réplica exacta del NAS que incluya las características del proveedor, DataSync por sí solo es insuficiente; se requiere una ruta compatible con NetApp, como FSx for 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 se encarga del 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 on-premises continúan comunicándose a través de NFS, SMB, iSCSI o iSCSI-VTL mientras los datos aterrizan en S3, S3 Glacier o como 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 on-prem.

File Gateway es el caballo de batalla. Escribir en \\gateway\share\reports\2024\report.pdf produce s3://bucket/reports/2024/report.pdf, que es 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 copia de seguridad de caja negra. El almacenamiento en caché local significa que los archivos de acceso frecuente (hot) se devuelven a la velocidad de la LAN; los archivos de acceso esporádico (cold) se transmiten desde S3 bajo demanda.

La caché es el punto clave del dispositivo. Las lecturas de datos de acceso frecuente se sirven localmente; las escrituras aterrizan primero en el disco local y se suben de forma asíncrona. Un error de diseño común es asumir que, por estar respaldado en S3, cada lectura incurre en la latencia de un viaje de ida y vuelta por internet; no es así, siempre que el conjunto de trabajo quepa en la caché. Por el contrario, un dimensionamiento insuficiente de la caché produce fallos de caché constantes 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 Cached frente a Stored merece una atención especial. El modo Cached mantiene la copia principal en S3 con los bloques de acceso frecuente en local: es barato, elástico, pero un fallo de caché supone un viaje de ida y vuelta por la WAN. El modo Stored mantiene la copia principal en el disco local con instantáneas asíncronas a S3 como EBS snapshots: cada lectura es local y de baja latencia, pero todo el conjunto de datos debe caber on-prem. Para un requisito de reemplazo de copias de seguridad como “acceso local a todos los datos mientras se respaldan en AWS”, el modo Stored es el correcto; el modo Cached violaría el requisito. Elegir Cached para una carga de trabajo que necesita todo el conjunto de datos con baja latencia va en contra del diseño; elegir Stored cuando la ubicación no puede alojar el conjunto de datos completo es imposible por definición.

Tape Gateway responde a un requisito muy específico: retirar una librería de cintas física manteniendo intactos los flujos de trabajo de Veeam, NetBackup o Commvault, al presentar una VTL sobre iSCSI, con un ciclo de vida de los datos que los mueve de S3 a Glacier o Deep Archive. Es de un valor incalculable cuando la retención por normativa se define en términos de medios de cinta y el software de backup existente no se puede cambiar.

AWS Transfer Family

Transfer Family proporciona endpoints SFTP, FTPS, FTP y AS2 totalmente gestionados, respaldados por S3 o EFS. La propuesta de valor es la preservación de los contratos de protocolo de cara a los socios: los sistemas de proveedores que solo emiten archivos vía 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 con analíticas.

La trampa aquí es asumir que un proveedor tradicional puede simplemente “cambiar a las API de S3”. Muchos sistemas de proveedores son appliances, flujos HL7 de hospitales, sistemas de procesamiento por lotes bancarios o canales 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 para modificarlos a menudo supera el de toda la migración a AWS. Transfer Family evita todo eso por completo. El soporte para AS2 habilita adicionalmente cargas de trabajo EDI con recibos MDN y firma/cifrado de mensajes para el cumplimiento normativo B2B.

La autenticación admite usuarios gestionados por el servicio, AWS Directory Service (Managed Microsoft AD o AD Connector para AD on-prem), o un proveedor de identidad personalizado a través de API Gateway/Lambda, permitiendo que las credenciales corporativas existentes sigan siendo la fuente de verdad. Un autorizador de Lambda puede devolver roles de IAM por usuario, mapeos de directorios de inicio y políticas de sesión, proporcionando aislamiento por proveedor sin necesidad de una 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 gestionada para el movimiento de datos de SaaS a AWS: Salesforce, ServiceNow, Google Analytics, Slack, Marketo, SAP OData, Zendesk y docenas de otros que fluyen hacia 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 de ETL desarrollado manualmente.

La característica crítica para la seguridad es la integración con PrivateLink para los conectores compatibles (notablemente Salesforce). En lugar de salir a la internet pública para alcanzar al tenant de SaaS y regresar a AWS, el flujo atraviesa un endpoint de VPC privado, eliminando la exposición de las cargas de datos extraídas a la internet pública y simplificando la postura de auditoría para cargas de trabajo de salud, finanzas y PII. Los flujos pueden ser programados, disparados por eventos de cambio en registros de SaaS o ejecutados bajo demanda, y soportan hasta 100 GB por ejecución de flujo.

AppFlow opera en una capa superior a DataSync o Storage Gateway: es la herramienta correcta cuando el origen 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 totalmente operativo. Soporta 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 transición con tiempo de inactividad mínimo es la Captura de Datos de Cambio (Change Data Capture). Durante una carga completa con CDC, DMS copia masivamente las filas existentes mientras extrae datos del registro de transacciones de origen: redo logs de Oracle, binlog de MySQL, MS-CDC o MS-Replication de SQL Server. Una vez que la carga completa finaliza, el CDC aplica los cambios en cola y mantiene el destino continuamente actualizado hasta que la aplicación hace el cambio. No habilitar el CDC cuando la aplicación debe permanecer escribible es un error de arquitectura común: una carga completa únicamente deja el destino desactualizado en el momento en que la carga termina.

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

Para trabajos heterogéneos, AWS Schema Conversion Tool (o su equivalente en la nube, DMS Schema Conversion) traduce DDL, procedimientos almacenados, vistas y funciones, marcando los elementos que requieren reescritura manual. DMS mueve los datos; SCT convierte el esquema. Omitir el informe de evaluación de SCT es la razón por la que las migraciones fracasan tres días antes de la transición.

Los prerrequisitos y limitaciones específicos del motor tienen graves consecuencias si se ignoran. Los LOB de Oracle por encima de 64 KB requieren el modo LOB limitado (limited LOB mode) 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 (binary logging) en formato ROW con un 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 están soportados. Se exige TLS entre la instancia de replicación y los endpoints, 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, por ejemplo, un sistema Oracle on-prem con picos durante el día y noches tranquilas. Se definen MinCapacityUnits y MaxCapacityUnits en DCU (DMS Capacity Units) y DMS escala la capacidad de replicación basándose en la presión de CPU y 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 (p. ej., dms.c5.4xlarge) escalará automáticamente. No lo hará: las instancias aprovisionadas son hosts EC2 de tamaño fijo. Si el rendimiento excede la capacidad, el retraso en la replicación (replication lag) aumenta y se debe modificar manualmente la clase de instancia, reiniciando las tareas. DMS aprovisionado es adecuado para migraciones de estado estable con un rendimiento conocido; Serverless es adecuado para 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 hacia Aurora MySQL o RDS MySQL es la jugada más rentable. Las restauraciones nativas con mysqldump/mysqlpump incurren en un tiempo de inactividad inaceptable; Snowball añade latencia de envío y brechas de desconexión.

DMS Fleet Advisor descubre inventarios de bases de datos on-prem, lo cual es útil para la planificación por oleadas (wave planning).

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

AWS Application Migration Service es el principal servicio de lift-and-shift (modalidad “rehost”) y ha reemplazado a CloudEndure Migration y Server Migration Service para la mayoría de los casos de uso. MGN instala un AWS Replication Agent 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 transició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 transició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 levanta instancias de prueba aisladas a partir del 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 transición cuando las pruebas son exitosas. La transición detiene la replicación, lanza la instancia final y marca la oleada como completada.

El enfoque incorrecto es exportar manualmente las VM a OVF, subirlas mediante 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 cada 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 transición final, y la deriva entre el origen y el destino es prácticamente cero.

La guía general del portafolio es primero hacer rehost, y luego replatform o refactorizar dentro de la región, donde el costo de iteración es menor. La refactorización y la migración simultáneas multiplican el riesgo sin un beneficio que lo compense.

Conectividad híbrida: Direct Connect y VPN

AWS Direct Connect proporciona un circuito dedicado de capa 2 desde un router 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 una latencia predecible. Las interfaces virtuales (Virtual Interfaces) particionan el circuito:

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

DX no es, por sí solo, de alta disponibilidad: un único 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 Site-to-Site a través de internet es la alta disponibilidad mínima viable. BGP gestiona 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 de DX separadas es el patrón de máxima resiliencia para cargas de trabajo de misión crítica y es un requisito para el SLA de DX.

No aprovisionar ninguna ruta de respaldo es una trampa 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 reparación del proveedor. Una 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 a nivel físico, elija una conexión DX con MACsec habilitado. Combinar 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 conjuntos de datos grandes y activos que no pueden tolerar una ventana de inactividad.

AWS Outposts para infraestructura de AWS on-premise

Outposts extiende la infraestructura de AWS a las instalaciones de un cliente como un rack completamente gestionado (o servidores Outposts 1U/2U). Ejecuta un conjunto seleccionado de servicios localmente — EC2, EBS, ECS, EKS, RDS, S3 on Outposts, EMR — con las mismas API que la región principal. Las operaciones del plano de control fluyen de vuelta 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 lanzar nuevas instancias, pero no detiene las cargas de trabajo en ejecución.

La división de la responsabilidad compartida es la trampa en la que caen los operadores. AWS entrega y mantiene el hardware, el hipervisor y los servicios gestionados. 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, conmutadores de subida, PDU apropiadas).
• Seguridad física de las instalaciones.
• Configuración de la red local: el Local Gateway (LGW) para el tráfico on-premise y el enlace de subida del servicio.
• Aspectos del sistema operativo y la aplicación de las cargas de trabajo, exactamente como en la región.
• Conectividad WAN adecuada de vuelta a la región principal.

Outposts no elimina las operaciones, sino que desplaza la abstracción. Asumir que AWS es responsable de la energía del centro de datos o de la red de subida es un error fundamental de interpretación. Tampoco es “ejecutar cualquier servicio de AWS on-premise”: la lista de servicios soportados es finita, y servicios como Route 53 o IAM permanecen basados en la región.

Para una modernización de Hadoop/Spark donde los datos deben permanecer on-premise por razones regulatorias, EMR on Outposts es el patrón correcto: clústeres de Spark elásticos y gestionados con las herramientas de la región y residencia de datos local. Storage Gateway o DataSync incumplen el requisito de residencia; un lift-and-shift a EMR en la región incumple la normativa.

Distribución de contenido a flotas en el borde

Cuando servidores Outposts, tiendas minoristas o dispositivos de borde extraen repetidamente la misma carga útil de gran tamaño (por ejemplo, una versión de software nocturna), hacerlo directamente desde un bucket de S3 en una única región satura los enlaces ascendentes e infla el tiempo de despliegue. El patrón correcto es CloudFront con un origen de 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 posterior extrae con latencia de borde. Las URL firmadas evitan descargas no autorizadas sin necesidad de credenciales IAM por dispositivo, y no hay que gestionar una flota de réplicas regionales.

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

Resumen de decisiones

← Almacenamiento y ciclo de vida de los datos · Todos los dominios · Redes y conectividad →

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

Explorar Amazon →