Introducción
Cualquier equipo que haya coordinado una migración de petabytes entre storage local y S3, o que gestione transfers de DataSync recurrentes entre múltiples tareas, conoce el problema: a las dos de la mañana tenés catorce ejecuciones corriendo en paralelo y no podés responder en cinco segundos si la tarea de NFS a EFS está avanzando o se trabó en el 40%. Hasta ahora, la única opción era abrir cada ejecución individualmente en la consola, o bien armar un dashboard custom en Amazon CloudWatch con métricas de BytesTransferred, FilesTransferred y ExecutionDuration, algo que consume tiempo de ingeniería y se desactualiza cada vez que agregás una tarea nueva.
AWS lanzó en septiembre de 2026 un dashboard de monitoreo integrado directamente en la consola de AWS DataSync. No es una feature de CloudWatch ni un servicio aparte: es una capa de visibilidad nativa que agrega, filtra y resume todas las ejecuciones de tareas del account en una vista unificada. El cambio es concreto para quien opera DataSync a escala, y lo analizamos en detalle.
Qué ocurrió
El equipo de producto de AWS DataSync habilitó un panel de monitoreo que aparece como vista principal dentro de la consola de DataSync (console.aws.amazon.com/datasync). El dashboard muestra, por cada ejecución de tarea, el estado actual (running, completed, error, cancelled), las tasas de transferencia de bytes y archivos por segundo, la duración acumulada, y el volumen total transferido. La información no es nueva en sí — DataSync siempre expuso estas métricas — pero antes estaban dispersas: una ejecución por página, sin agregación cross-task.
Lo que cambió es la capa de correlación. El dashboard permite filtrar ejecuciones por cinco dimensiones: estado, tarea, modo de tarea (one-time, scheduled, incremental), execution ID, y rango de tiempo de inicio. Sobre el conjunto filtrado, el panel calcula y muestra el conteo de ejecuciones exitosas versus fallidas, el acumulado de datos y archivos transferidos agrupado por tarea, y un resumen de la salud general del pipeline de transfers. Para troubleshooting, seleccionar una ejecución con estado error despliega el detalle del error sin necesidad de bucear en logs de CloudWatch o en el registro de eventos de la tarea.
Además del detalle por ejecución, el dashboard muestra métricas de inventario: cantidad total de tareas configuradas, locations registrados, agentes desplegados, y una tasa de transferencia total en tiempo real que agrega el throughput de todas las ejecuciones activas en el account.
Impacto para DevOps / Infraestructura / Cloud / Seguridad
Para equipos de infraestructura que gestionan migraciones de storage on-premises (NFS, SMB, HDFS) hacia S3, EFS o FSx, el impacto operativo es directo. Una migración típica de 500 TB puede involucrar entre 10 y 30 tareas de DataSync ejecutándose en ventanas de 24 a 72 horas. Antes, el monitoreo de esas tareas requería un dashboard custom en CloudWatch construido con queries de AWS/DataSync namespace, o un script que consultaba la API DescribeTaskExecution en loop. El nuevo panel reduce ese overhead a una vista preconfigurada que no requiere desarrollo ni mantenimiento.
Desde la perspectiva de seguridad y cumplimiento, la visibilidad centralizada sobre qué datos se transfirieron, a qué locations y con qué volumen acumulado facilita auditorías de data governance. Si un equipo de seguridad necesita verificar que una migración de datos sensibles (PII, PHI) completó correctamente y sin errores parciales, el dashboard permite filtrar por tarea y revisar el conteo de archivos transferidos versus esperados sin cruzar manualmente registros de CloudTrail con métricas de CloudWatch.
Para equipos SRE que definen SLOs sobre pipelines de datos, la métrica de «tasa total de transferencia en tiempo real» es un indicador de salud del pipeline que antes requería armar una consulta PromQL o una alarm CloudWatch sobre la suma de BytesTransferred de todas las tareas activas. Ahora ese número está visible por defecto.
Detalles técnicos
El dashboard opera dentro del namespace de la consola de DataSync y consume las mismas métricas que DataSync publica en CloudWatch (AWS/DataSync), pero las presenta con agregación server-side. Las dimensiones disponibles para filtrar son:
- Status: RUNNING, COMPLETED, ERROR, CANCELLED, INTERRUPTED
- Task: identificador de la tarea (task-0123456789abcdef0)
- Task Mode: ONE_TIME, SCHEDULED, INCREMENTAL
- Execution ID: identificador único de la ejecución (exec-0123456789abcdef0)
- Start Time: rango temporal de inicio de ejecución
Las métricas de throughput que muestra incluyen BytesTransferred y FilesTransferred como deltas por segundo, y ExecutionDuration como tiempo transcurrido. El agrupamiento por tarea permite identificar cuellos de botella: si una tarea de SMB a S3 muestra una tasa de 12 MB/s mientras el resto transfiere a 450 MB/s, el dashboard lo hace visible sin necesidad de correlacionar manualmente.
Para el caso de troubleshooting, al seleccionar una ejecución en estado ERROR, el panel muestra el código de error y el mensaje de la API DescribeTaskExecution. Los errores más comunes en DataSync incluyen AccessDeniedException (permisos IAM sobre el location de destino), NetworkConnectionException (agente sin conectividad al endpoint de S3 o del storage on-prem), y InvalidRequestException (configuración del task que cambió a mitad de ejecución).
El dashboard está disponible sin costo adicional en todas las regiones comerciales de AWS donde opera DataSync, incluyendo AWS GovCloud (US). No requiere habilitar CloudWatch, configurar alarms, ni desplegar agentes adicionales. El acceso se realiza desde console.aws.amazon.com/datasync con las mismas credenciales IAM que ya usan para operar DataSync.
Qué deberían hacer los administradores y equipos técnicos
1. Reemplacen dashboards custom de CloudWatch donde aplique. Si el equipo construyó un dashboard en CloudWatch con queries tipo:
SEARCH(‘{AWS/DataSync,TaskId} MetricName=»BytesTransferred»‘, ‘Average’, 300)
para monitorear múltiples tareas, evalúen si el nuevo panel nativo cubre el caso de uso. El dashboard de DataSync no reemplaza alarmas automatizadas, pero sí elimina la necesidad de una vista operativa dedicada. Mantengan las alarms en CloudWatch para notificación push (SNS, PagerDuty), pero retiren la consulta manual del dashboard custom.
2. Ajusten permisos IAM si el equipo operativo no tenía acceso a la consola. El dashboard se renderiza en la consola de DataSync, así que los operadores necesitan al menos datasync:DescribeTask, datasync:DescribeTaskExecution y datasync:ListTasks en su policy. Si antes monitoreaban exclusivamente por CLI o API, verifiquen que la role del equipo de infraestructura incluye:
{
«Effect»: «Allow»,
«Action»: [
«datasync:ListTasks»,
«datasync:DescribeTask»,
«datasync:DescribeTaskExecution»,
«datasync:ListLocations»,
«datasync:ListAgents»
],
«Resource»: «*»
}
3. Incorporen el dashboard al runbook de migraciones. Para migraciones activas, definan un checkpoint operativo cada 4 horas donde el responsable revise el dashboard, verifique que la tasa de transferencia se mantiene dentro del rango esperado (por ejemplo, >80% de la capacidad del enlace WAN), y confirme que no hay ejecuciones en estado INTERRUPTED que requieran reintentar.
4. No eliminen CloudWatch como capa de alertado. El dashboard es una herramienta de visibilidad, no de notificación. Las alarms sobre BytesTransferred == 0 durante más de 15 minutos, o sobre ErrorCount > 0 en una ventana de 5 minutos, siguen siendo necesarias para detección proactiva fuera del horario laboral.
Conclusión
El dashboard de monitoreo de AWS DataSync no introduce capacidades que no existían — las métricas siempre estuvieron disponibles vía API y CloudWatch. Lo que cambia es el costo de operación: pasar de «construir y mantener una vista de monitoreo» a «abrir la consola y ver el estado». Para equipos que gestionan de 5 a 50 tareas concurrentes de DataSync, esto elimina una fricción operativa real. Para quienes ya tienen un stack de observabilidad maduro con Grafana o dashboards CloudWatch a medida, el panel nativo complementa sin reemplazar. La recomendación práctica: actívenlo como vista operativa del día a día, mantengan las alarms automatizadas como red de seguridad, y evalúen en la próxima migración si el dashboard custom que armaron sigue justificando su mantenimiento.
Fuentes
- https://aws.amazon.com/about-aws/whats-new/2026/09/datasync-monitoring-dashboard