Introducción
Si gestionás una infraestructura de transferencia de archivos sobre AWS Transfer Family con más de un workflow activo, probablemente te topaste con una limitación que genera fricción diaria: todos los logs de ejecución de cada workflow terminaban en el mismo log group del servidor. Eso significa que para aislar la traza de un flujo de ETL financiero del de un partner externo, tenías que desplegar servidores Transfer completos, o bien filtrar a mano con queries de Logs Insights sobre un stream único donde se mezclan ejecuciones, errores de autenticación y timeouts de S3. El resultado: dashboards saturados, políticas de retención genéricas que no responden a los SLAs de cada cliente, y una auditoría de cumplimiento que se vuelve inmanejable cuando el volumen de transferencias crece.
La ausencia de un destino de log a nivel workflow obligaba a los equipos de infraestructura a elegir entre sobreprovisionar servidores o aceptar un modelo de logging «todo junto». Ninguna de las dos opciones escala bien cuando un mismo equipo administra 15, 30 o 50 workflows con distintos niveles de criticidad. AWS resolvió este punto con la habilitación de log groups personalizados por workflow, disponible desde octubre de 2026 en todas las regiones donde Transfer Family ofrece managed workflows.
Qué ocurrió
AWS Transfer Family ahora permite seleccionar un log group de CloudWatch Logs a nivel de workflow, completamente separado del log group configurado en el servidor. Al crear o modificar un workflow desde la consola de Transfer Family o vía API, aparece una opción para definir el destino de logs del flujo de ejecución. Si elegís un log group propio, Transfer Family entrega los logs únicamente allí y deja de requerir el logging role del servidor para ese workflow específico.
El formato de los logs no cambia: siguen siendo JSON estructurado y se consultan con CloudWatch Logs Insights con la misma sintaxis de campos. Lo que sí cambia es la topología: podés enviar los logs de varios workflows relacionados a un log group compartido para construir métricas consolidadas, o aislar un workflow sensible en un log group con retención de 365 días mientras los demás conservan 30 días. Los workflows existentes que no se modifiquen continúan usando su configuración actual sin interrupción, lo que elimina el riesgo de ruptura en pipelines en producción.
Impacto para DevOps / Infraestructura / Cloud / Seguridad
Para los equipos de SRE y DevOps que operan Transfer Family como capa de integración con sistemas ERP, data lakes o partners B2B, la separación de logs por workflow destraba tres problemas operativos concretos. Primero, la observabilidad: un dashboard de CloudWatch que antes mezclaba 40 workflows ahora puede segmentarse por dominio funcional, reduciendo el tiempo de triage ante una transferencia fallida. Segundo, la gestión de costos: CloudWatch Logs cobra por ingesta y almacenamiento; aislar workflows de bajo volumen en log groups con retención corta reduce el gasto sin tocar los flujos críticos. Tercero, la segregación de acceso: con IAM policies a nivel de log group ARN, podés otorgar a un equipo de auditoría acceso de solo lectura al log group del workflow financiero sin exponer los logs de los demás flujos.
Desde la perspectiva de seguridad, la eliminación del logging role del servidor para workflows con log group propio reduce la superficie de permisos IAM. Un workflow que escribe en su propio log group no necesita que el rol del servidor incluya logs:PutLogEvents sobre el log group del servidor, lo que acota el blast radius ante una eventual escalada de privilegios. Para organizaciones con marcos de cumplimiento tipo SOC 2, ISO 27001 o PCI-DSS, la capacidad de aplicar políticas de retención y cifrado (KMS) distintas por log group simplifica la evidencia ante auditoría.
Detalles técnicos
La funcionalidad se activa al momento de crear el workflow o al modificarlo mediante UpdateWorkflow en la API de Transfer Family. El parámetro relevante es CustomLogGroup (o la opción equivalente en la consola bajo «Log destination»), donde especificás el nombre del log group de CloudWatch Logs. El log group debe existir previamente o crearse con el prefijo /aws/transfer/ por convención, aunque AWS no lo exige estrictamente.
El rol de ejecución del workflow (ExecutionRole) necesita permiso logs:PutLogEvents y logs:CreateLogStream sobre el ARN del log group designado. Si no configurás un log group a nivel workflow, Transfer Family cae en el comportamiento heredado: usa el logging role del servidor y escribe en el log group asociado a ese servidor. No hay cambio en el esquema JSON de cada entrada: campos como WorkflowId, ExecutionId, Status, Timestamp, ErrorCode y ErrorMessage permanecen intactos.
La consulta en Logs Insights no requiere adaptación. Un ejemplo de query para filtrar errores de un workflow específico dentro de un log group compartido:
fields @timestamp, @message, WorkflowId, Status, ErrorCode
| filter WorkflowId = ‘wf-0123456789abcdef0’
| filter Status = ‘FAILED’
| sort @timestamp desc
| limit 50
La disponibilidad es global: todas las regiones donde Transfer Family ofrece managed workflows ya soportan esta opción. No hay costo adicional por habilitarla; el cargo sigue siendo el estándar de CloudWatch Logs por evento ingestado y por día de almacenamiento.
Qué deberían hacer los administradores y equipos técnicos
Revisá el inventario de servidores y workflows de Transfer Family en tu cuenta. Listá los workflows activos con el siguiente comando CLI:
aws transfer list-workflows –region us-east-1 \
–query ‘Workflows[].[WorkflowId,Arn,Name]’ –output table
Identificá los workflows que hoy comparten un log group de servidor y evaluá cuáles necesitan aislamiento por requisitos de retención, acceso o volumen. Para los flujos que requieren separación, creá el log group destino:
aws logs create-log-group \
–log-group-name /aws/transfer/finanzas/etl-sap \
–retention-in-days 365
Modificá el workflow para apuntar al log group nuevo:
aws transfer update-workflow \
–workflow-id wf-0123456789abcdef0 \
–logging-role arn:aws:iam::123456789012:role/TransferWorkflowLoggingRole \
–custom-log-group /aws/transfer/finanzas/etl-sap
Asegurate de que el ExecutionRole del workflow tenga logs:PutLogEvents y logs:CreateLogStream sobre el nuevo ARN. Si usás Terraform, el recurso aws_transfer_workflow expone el atributo custom_log_group; actualizá el estado con terraform apply y verificá que no se destruya ni reemplace el workflow existente.
Para equipos con múltiples workflows que comparten un mismo dominio de negocio, consideren un log group consolidado (por ejemplo, /aws/transfer/partners/) y usen el campo WorkflowId en Logs Insights para segmentar. Esto reduce la cantidad de log groups a gestionar y facilita dashboards unificados en CloudWatch.
Conclusión
La asignación de log groups por workflow en Transfer Family no es un feature cosmético: resuelve un punto de dolor operativo que obligaba a sobreprovisionar servidores o a aceptar un modelo de logging monolítico. La implementación es retrocompatible —los workflows existentes no se tocan— y el esfuerzo de migración se limita a crear log groups, ajustar IAM y modificar la configuración de cada workflow. Para equipos que manejan decenas de flujos de transferencia con distintos niveles de criticidad, esta separación se traduce en observabilidad más fina, costos de logging controlados y una postura de seguridad IAM más acotada. El cambio no requiere downtime y se puede aplicar workflow por workflow, lo que lo hace seguro para entornos productivos.
Fuentes
- https://aws.amazon.com/about-aws/whats-new/2026/10/transfer-family-custom-cloudwatch-log-groups/