Solución de problemas de Operaciones por lotes de S3 - Amazon Simple Storage Service
NoSuchJobExceptionInvalidManifestContent

Solución de problemas de Operaciones por lotes de S3

Puede utilizar Operaciones por lotes de Amazon S3 para realizar operaciones a gran escala en objetos de Amazon S3. Esta guía le ayuda a solucionar problemas comunes que puedan surgir.

Para solucionar problemas con Replicación por lotes de S3, consulte Solución de problemas de replicación.

Hay dos tipos principales de errores que provocan errores en las operaciones por lotes:

  1. Error de API: la API solicitada (como CreateJob) no se ha ejecutado correctamente.

  2. Error de trabajo: la solicitud de la API inicial se ha realizado correctamente, pero el trabajo ha fallado, por ejemplo, debido a problemas con el manifiesto o con los permisos de los objetos especificados en el manifiesto.

NoSuchJobException

Tipo: error de la API

La NoSuchJobException se produce cuando Operaciones por lotes de S3 no puede localizar el trabajo especificado. Este error se puede producir en varios escenarios además de la simple caducidad del trabajo. Entre las causas comunes se incluyen las siguientes.

  1. Caducidad del trabajo: los trabajos se eliminan automáticamente 90 días después de alcanzar un estado terminal (Complete, Cancelled o Failed).

  2. ID de trabajo incorrecto: el ID de trabajo utilizado en DescribeJob o UpdateJobStatus no coincide con el ID devuelto por CreateJob.

  3. Región incorrecta: se intenta acceder a un trabajo en una región diferente a la de donde se creó.

  4. Cuenta incorrecta: se utiliza un ID de trabajo de una cuenta de AWS diferente.

  5. Errores de formato de ID de trabajo: tipográficos, caracteres adicionales o formato incorrecto en el ID del trabajo.

  6. Problemas de temporización: se comprueba el estado del trabajo inmediatamente después de crearlo antes de registrarlo por completo.

Entre los mensajes de error relacionados se incluyen los siguientes.

  1. No such job

  2. The specified job does not exist

Prácticas recomendadas para evitar errores de la API NoSuchJobException

  1. Guarde los ID de trabajo inmediatamente: guarde el ID del trabajo de la respuesta CreateJob antes de realizar llamadas a la API posteriores.

  2. Implemente la lógica de reintentos: agregue un retroceso exponencial al comprobar el estado del trabajo inmediatamente después de su creación.

  3. Configure la supervisión: cree alarmas de CloudWatch para realizar un seguimiento de la finalización del trabajo antes de que caduquen los 90 días. Para obtener información, consulte Uso de alarmas de CloudWatch en la Guía del usuario de Amazon CloudWatch.

  4. Utilice regiones coherentes: asegúrese de que todas las operaciones laborales utilizan la misma región que las de creación de empleo.

  5. Valide la entrada: compruebe el formato de ID del trabajo antes de realizar llamadas a la API.

Cuándo caducan los trabajos

Los trabajos en estados terminales se eliminan automáticamente después de 90 días. Para evitar perder información sobre el trabajo, tenga en cuenta la siguiente información.

  1. Descargue los informes de finalización antes de que caduquen: para obtener instrucciones sobre cómo recuperar y almacenar los resultados de los trabajos, consulte .

  2. Archive los metadatos de los trabajos en sus propios sistemas: almacene la información fundamental sobre los trabajos en las bases de datos o sistemas de supervisión.

  3. Configure las notificaciones automáticas antes de la fecha límite de 90 días: utilice Amazon EventBridge para crear reglas que desencadenen notificaciones cuando se completen los trabajos. Para obtener más información, consulte Notificaciones de eventos de Amazon S3.

NoSuchJobExceptionSolución de problemas de

  1. Utilice el siguiente comando para comprobar que el trabajo existe en la cuenta y la región.

    
aws s3control list-jobs --account-id 111122223333 --region us-east-1

  2. Utilice el siguiente comando para buscar en todos los estados de los trabajos. Los posibles estados de los trabajos incluyen Active, Cancelled, Cancelling, Complete, Completing, Failed, Failing, New, Paused, Pausing, Preparing, Ready y Suspended.

    
aws s3control list-jobs --account-id 111122223333 --job-statuses your-job-status

  3. Utilice el siguiente comando para comprobar si el trabajo existe en otras regiones donde suele crear trabajos.

    
aws s3control list-jobs --account-id 111122223333 --region job-region-1 aws s3control list-jobs --account-id 111122223333 --region job-region-2

  4. Valide el formato de ID de trabajo. Los ID de trabajo suelen contener 36 caracteres, por ejemplo 12345678-1234-1234-1234-123456789012. Compruebe si hay espacios adicionales, caracteres faltantes o problemas con la distinción de mayúsculas y minúsculas y compruebe que está utilizando el ID de trabajo completo devuelto por el comando CreateJob.

  5. Utilice el siguiente comando para comprobar los registros de CloudTrail para ver si hay eventos de creación de trabajos.

    
    aws logs filter-log-events --log-group-name CloudTrail/S3BatchOperations \ --filter-pattern "{ $.eventName = CreateJob }" \ --start-time timestamp

AccessDeniedException

Tipo: error de la API

La AccessDeniedException se produce cuando se bloquea una solicitud de Operaciones por lotes de S3 debido a permisos insuficientes, operaciones no admitidas o restricciones de políticas. Este es uno de los errores más comunes en operaciones por lotes. Tiene las siguientes causas comunes:

  1. Permisos de IAM faltantes: la identidad de IAM carece de los permisos necesarios para las API de operaciones por lotes.

  2. Permisos de S3 insuficientes: faltan permisos para acceder a los buckets y objetos de origen o destino.

  3. Problemas de rol de ejecución de trabajos: el rol de ejecución de trabajos carece de permisos para realizar la operación especificada.

  4. Operaciones no compatibles: el intento de utilizar operaciones no se admite en la región o el tipo de bucket actuales.

  5. Problemas de acceso entre cuentas: faltan permisos para acceder a objetos o buckets entre cuentas.

  6. Restricciones de políticas basadas en los recursos: políticas de bucket o ACL de objetos que bloquean la operación.

  7. Restricciones de la política de control de servicio (SCP): políticas por organización que impiden la operación.

Mensajes de error relacionados:

  1. Access Denied

  2. User: arn:aws:iam::account:user/username is not authorized to perform: s3:operation

  3. Cross-account pass role is not allowed

  4. The bucket policy does not allow the specified operation

Prácticas recomendadas para evitar errores de la API AccessDeniedException

  1. Utilice el principio de privilegio mínimo: conceda solo los permisos mínimos necesarios para sus operaciones específicas.

  2. Pruebe los permisos antes de realizar trabajos grandes: ejecute pequeños trabajos de prueba para validar los permisos antes de procesar miles de objetos.

  3. Utilice el simulador de política de IAM: pruebe las políticas antes de implementarlas mediante el simulador de política de IAM. Para obtener más información, consulte Pruebas de la política de IAM con el simulador de política de IAM en la Guía del usuario de IAM.

  4. Implemente una configuración entre cuentas adecuada: compruebe la configuración de acceso entre cuentas para ver si hay configuraciones de trabajos entre cuentas. Para obtener más información, consulte Tutorial de IAM: Delegar el acceso entre cuentas de AWS mediante roles de IAM en la Guía del usuario de IAM.

  5. Supervise los cambios de permisos: configure alertas de CloudTrail para las modificaciones de la política de IAM que puedan afectar a las operaciones por lotes.

  6. Documente los requisitos de los roles: mantenga una documentación clara de los permisos necesarios para cada tipo de trabajo.

  7. Utilice plantillas de permisos comunes: utilice los ejemplos de permisos y las plantillas de políticas:

    1. Concesión de permisos para Operaciones por lotes

    2. Recursos entre cuentas de IAM en la Guía del usuario de IAM.

    3. Controle el acceso a puntos de conexión de VPC mediante el uso de políticas de punto de conexión en la Guía de AWS PrivateLink.

Solución de problemas de AccessDeniedException

Siga estos pasos de forma sistemática para identificar y resolver los problemas de permisos.

  1. Compruebe Operaciones compatibles con las operaciones por lotes de S3 si hay operaciones compatibles por región. Confirme que las operaciones de los buckets de directorio solo estén disponibles en los puntos de conexión regionales y zonales. Compruebe que la operación sea compatible con la clase de almacenamiento del bucket.

  2. Utilice el siguiente comando para determinar si puede mostrar trabajos.

    
 aws s3control list-jobs --account-id 111122223333

  3. Utilice el siguiente comando para comprobar los permisos de IAM para la identidad solicitante. La cuenta que ejecuta el trabajo necesita los siguientes permisos: s3:CreateJob, s3:DescribeJob, s3:ListJobs-s3:UpdateJobPriority y s3:UpdateJobStatus-iam:PassRole.

    
aws sts get-caller-identity 111122223333

  4. Utilice el siguiente comando para comprobar si el rol existe y es asumible.

    
aws iam get-role --role-name role-name

  5. Use el siguiente comando para revisar la política de confianza del rol. El rol que ejecute el trabajo debe tener lo siguiente:

    1. Una relación de confianza que permita que batchoperations.s3.amazonaws.com adopte el rol.

    2. Las operaciones que realiza la operación por lotes (por ejemplo s3:PutObjectTagging para operaciones de etiquetado).

    3. Acceso a los buckets de origen y destino.

    4. Permiso para leer el archivo de manifiesto.

    5. Permiso para redactar informes de finalización.

    
aws iam get-role --role-name role-name --query 'Role.AssumeRolePolicyDocument'

  6. Uso del siguiente comando para restablecer el acceso a los buckets de manifiesto y origen.

    
aws s3 ls s3://bucket-name

  7. Prueba de la operación que realiza la operación por lotes. Por ejemplo, si la operación por lotes realiza el etiquetado, etiquete un objeto de ejemplo en el bucket de origen.

  8. Revise las políticas de bucket para ver si hay políticas que puedan denegar la operación.

    1. Compruebe las ACL de los objetos si trabaja con controles de acceso antiguos.

    2. Compruebe que ninguna política de control de servicio (SCP) bloquee la operación.

    3. Confirme que las políticas de punto de conexión de VPC permitan las operaciones por lotes si se utilizan puntos de conexión de VPC.

  9. Utilice el siguiente comando para usar CloudTrail para identificar errores de permisos.

    
aws logs filter-log-events --log-group-name CloudTrail/S3BatchOperations \
    --filter-pattern "{ $.errorCode = AccessDenied }" \
    --start-time timestamp

SlowDownError

Tipo: error de la API

La excepción SlowDownError se produce cuando la cuenta ha superado el límite de tasa de solicitudes para las API de Operaciones por lotes de S3. Se trata de un mecanismo de limitación para evitar que el servicio se vea desbordado por un número excesivo de solicitudes. Tiene las siguientes causas comunes:

  1. Alta frecuencia de solicitudes a la API: se realizan muchas llamadas a la API en poco tiempo.

  2. Operaciones de trabajo simultáneas: varias aplicaciones o usuarios crean o administran trabajos simultáneamente.

  3. Scripts automatizados sin límite de velocidad: scripts que no implementan las estrategias de espera adecuadas.

  4. Sondeo del estado del trabajo con demasiada frecuencia: se comprueba el estado del trabajo con más frecuencia de la necesaria.

  5. Patrones de tráfico en ráfagas: picos repentinos en el uso de la API durante las horas punta de procesamiento.

  6. Límites de capacidad regional: se supera la capacidad de solicitud asignada para la región.

Mensajes de error relacionados:

  1. SlowDown

  2. Please reduce your request rate

  3. Request rate exceeded

Prácticas recomendadas para evitar errores de la API SlowDownError

  1. Implemente una limitación de velocidad del cliente: agregue retrasos entre las llamadas a la API en las aplicaciones.

  2. Utilice el retroceso exponencial con la fluctuación: asigne al azar los retrasos en los reintentos para evitar problemas de rebaño abrumadores.

  3. Configure una lógica de reintentos adecuada: implemente reintentos automáticos con retrasos cada vez mayores para los errores transitorios.

  4. Utilice arquitecturas basadas en eventos: sustituya los sondeos por notificaciones de EventBridge para los cambios en el estado de los trabajos.

  5. Distribuya la carga a lo largo del tiempo: escalone la creación de puestos de trabajo y las comprobaciones de estado en distintos periodos de tiempo.

  6. Supervise y envíe alertas sobre los límites de velocidad: configure alarmas de CloudWatch para detectar cuándo se acerca a los límites.

La mayoría de los AWS SDK incluyen una lógica de reintento integrada para los errores que limitan la velocidad. Configúrelos de la siguiente manera:

  1. AWS CLI: use los parámetros cli-read-timeout y cli-connect-timeout.

  2. AWS SDK para Python (Boto3): configure los modos de reintento y el número máximo de intentos en la configuración del cliente.

  3. AWS SDK para Java: use la configuración RetryPolicy y ClientConfiguration.

  4. AWS SDK para JavaScript: configure maxRetries y retryDelayOptions.

Para obtener más información sobre los patrones de reintento y las prácticas recomendadas, consulte Reintentar con un patrón de retroceso en la guía de orientación prescriptiva de AWS.

Solución de problemas de SlowDownError

  1. En el código, implemente inmediatamente el retroceso exponencial.

    ejemplo de retroceso exponencial en bash
    
for attempt in {1..5}; do
    if aws s3control describe-job --account-id 111122223333 --job-id job-id; then 
        break
    else 
        wait_time=$((2**attempt)) echo "Rate limited, waiting ${wait_time} seconds..." sleep $wait_time
        fi
done

  2. Use CloudTrail para identificar el origen del alto volumen de solicitudes.

    
aws logs filter-log-events \
    --log-group-name CloudTrail/S3BatchOperations \
    --filter-pattern "{ $.eventName = CreateJob || $.eventName = DescribeJob }" \
    --start-time timestamp \
    --query 'events[*].[eventTime,sourceIPAddress,userIdentity.type,eventName]'

  3. Revise la frecuencia de sondeo.

    1. Evite comprobar el estado de los trabajos más de una vez cada 30 segundos en el caso de los trabajos activos.

    2. Utilice notificaciones de finalización de trabajos en lugar de sondeos cuando sea posible.

    3. Implemente la fluctuación en los intervalos de sondeo para evitar la sincronización de las solicitudes.

  4. Optimice sus patrones de uso de la API.

    1. Varias operaciones por lotes cuando sea posible.

    2. Se utiliza ListJobs para obtener el estado de varios trabajos en una sola llamada.

    3. Guarde en caché la información de los trabajos para reducir las llamadas a la API redundantes.

    4. Distribuya la creación de empleo a lo largo del tiempo en lugar de crear muchos puestos de trabajo simultáneamente.

  5. Utilice las métricas de CloudWatch para las llamadas a la API a fin de supervisar sus patrones de solicitudes.

    
   aws logs put-metric-filter \
       --log-group-name CloudTrail/S3BatchOperations \
       --filter-name S3BatchOpsAPICallCount \      
       --filter-pattern "{ $.eventSource = s3.amazonaws.com && $.eventName = CreateJob }" \
       --metric-transformations \        
       metricName=S3BatchOpsAPICalls,metricNamespace=Custom/S3BatchOps,metricValue=1

InvalidManifestContent

Tipo: error de trabajo

La excepción InvalidManifestContent se produce cuando hay problemas con el formato del archivo de manifiesto, el contenido o la estructura que evitan que Operaciones por lotes de S3 procese el trabajo. Tiene las siguientes causas comunes:

  1. Infracciones de formato: faltan columnas obligatorias, delimitadores incorrectos o estructura CSV con formato incorrecto.

  2. Problemas de codificación del contenido: codificación de caracteres incorrecta, marcadores de BOM o caracteres distintos de UTF-8.

  3. Problemas con las claves de objeto: caracteres no válidos, codificación de URL incorrecta o claves que superan los límites de longitud.

  4. Limitaciones de tamaño: el manifiesto contiene más objetos de los que admite la operación.

  5. Errores de formato de ID de versión: los ID de versión de los objetos versionados con formato incorrecto o no válidos.

  6. Problemas con el formato de ETag: formato de ETag incorrecto o faltan comillas para las operaciones que requieren ETag.

  7. Datos incoherentes: formatos mixtos dentro del mismo manifiesto o recuentos de columnas incoherentes.

Mensajes de error relacionados:

  1. Required fields are missing in the schema: + missingFields

  2. Invalid Manifest Content

  3. The S3 Batch Operations job failed because it contains more keys than the maximum allowed in a single job

  4. Invalid object key format

  5. Manifest file is not properly formatted

  6. Invalid version ID format

  7. ETag format is invalid

Prácticas recomendadas para evitar errores en los trabajos de InvalidManifestContent

  1. Valide antes de cargar: pruebe el formato del manifiesto con trabajos pequeños antes de procesar conjuntos de datos grandes.

  2. Utilice una codificación coherente: utilice siempre la codificación UTF-8 sin BOM para los archivos de manifiesto.

  3. Implemente estándares de generación de manifiestos: cree plantillas y procedimientos de validación para la creación de manifiestos.

  4. Maneje los caracteres especiales correctamente: codifique en URL las claves de objetos que contienen caracteres especiales.

  5. Supervise el recuento de objetos: realice un seguimiento del tamaño del manifiesto y divida los trabajos grandes de forma proactiva.

  6. Valide la existencia de los objetos: compruebe la existencia de los objetos antes de incluirlos en los manifiestos.

  7. Utilice herramientas de AWS para la generación de manifiestos: aproveche s3api list-objects-v2 de la AWS CLI para generar listas de objetos con el formato adecuado.

Problemas y soluciones de manifiestos comunes:

  1. Faltan columnas obligatorias: asegúrese de que el manifiesto incluya todas las columnas obligatorias para el tipo de operación. Las columnas que faltan más comunes son Bucket y Key.

  2. Formato CSV incorrecto: utilice delimitadores de coma, asegúrese de que el recuento de columnas sea coherente en todas las filas y evite los saltos de línea incrustados en los campos.

  3. Caracteres especiales en las claves de objeto: codifique en URL las claves de objeto que contienen espacios, caracteres Unicode o caracteres especiales XML (<, >, &, “, ‘).

  4. Archivos de manifiesto grandes: divida los manifiestos que superen el límite de operaciones en varios manifiestos más pequeños y cree trabajos independientes.

  5. ID de versión no válidos: asegúrese de que los ID de versión sean cadenas alfanuméricas con el formato correcto. Elimine la columna de ID de versión si no es necesaria.

  6. Problemas de codificación: guarde los archivos de manifiesto como UTF-8 sin BOM. Evite copiar los manifiestos a través de sistemas que es posible que modifiquen la codificación.

Para obtener especificaciones y ejemplos detallados del formato de manifiesto, consulte lo siguiente:

  1. Especificar un manifiesto

  2. Operaciones compatibles con las operaciones por lotes de S3

  3. Denominación de objetos de Amazon S3

Solución de problemas de InvalidManifestContent

  1. Descargue e inspeccione el archivo de manifiesto. Compruebe manualmente que el manifiesto cumpla con los requisitos de formato:

    1. Formato CSV con delimitadores de coma.

    2. Codificación UTF-8 sin BOM.

    3. Número coherente de columnas en todas las filas.

    4. No hay líneas vacías ni espacios finales.

    5. Las claves de objeto tienen codificación URL adecuada si contienen caracteres especiales.

    Utilice el siguiente comando para descargar el archivo de manifiesto.

    
aws s3 cp s3://amzn-s3-demo-bucket1/manifest-key ./manifest.csv

  2. Compruebe las columnas obligatorias para su operación:

    1. Todas las operaciones: Bucket, Key

    2. Operaciones de copia: VersionId (opcional)

    3. Operaciones de restauración: VersionId (opcional)

    4. Operaciones de sustitución de etiquetas: no se requieren columnas adicionales.

    5. Operaciones de sustitución de ACL: no se requieren columnas adicionales.

    6. Iniciar la restauración: VersionId (opcional)

  3. Compruebe los límites de recuento de objetos:

    1. Copia: mil millones de objetos como máximo.

    2. Eliminación: mil millones de objetos como máximo.

    3. Restauración: mil millones de objetos como máximo.

    4. Etiquetado: mil millones de objetos como máximo.

    5. ACL: mil millones de objetos como máximo.

  4. Cree un manifiesto de prueba con algunos objetos del manifiesto original.

  5. Use el siguiente comando para comprobar si existe un ejemplo de objetos del manifiesto.

    
aws s3 ls s3://amzn-s3-demo-bucket1/object-key

  6. Compruebe los detalles del error del trabajo y revise el motivo del error y cualquier detalle específico del error en la descripción del trabajo.

    
aws s3control describe-job --account-id 111122223333 --job-id job-id