Résolution des problèmes liés à S3 Batch Operations - Amazon Simple Storage Service
NoSuchJobExceptionInvalidManifestContent

Résolution des problèmes liés à S3 Batch Operations

Vous pouvez utiliser Amazon S3 Batch Operations pour effectuer des opérations par lot à grande échelle sur des objets Amazon S3. Ce guide vous aide à résoudre les problèmes courants que vous pourriez rencontrer.

Pour résoudre les problèmes liés à la réplication par lot S3, consultez Résolution des problèmes de réplication.

Il existe deux principaux types d’échecs qui entraînent des erreurs :

  1. Échec de l’API : l’exécution de l’API demandée (par exemple, CreateJob) a échoué.

  2. Échec de la tâche : la demande d’API initiale a abouti, mais la tâche a échoué, par exemple en raison de problèmes liés au manifeste ou aux autorisations d’accès aux objets spécifiés dans le manifeste.

NoSuchJobException

Type : échec de l’API

L’exception NoSuchJobException se produit lorsque S3 Batch Operations ne parvient pas à localiser la tâche spécifiée. Cette erreur peut se produire dans plusieurs scénarios autres que la simple expiration d’une tâche. Les causes sont généralement les suivantes.

  1. Expiration de la tâche : les tâches sont automatiquement supprimées 90 jours après avoir atteint l’état terminal (Complete, Cancelled ou Failed).

  2. ID de tâche incorrect : l’ID de la tâche utilisé dans DescribeJob ou UpdateJobStatus ne correspond pas à l’ID renvoyé par CreateJob.

  3. Mauvaise région : tentative d’accès à une tâche dans une autre région que celle où elle a été créée.

  4. Mauvais compte : utilisation d’un ID de tâche provenant d’un autre compte AWS.

  5. Erreurs de format de l’ID de tâche : fautes de frappe, caractères supplémentaires ou mise en forme incorrecte de l’ID de tâche.

  6. Problèmes de synchronisation : vérification du statut de la tâche immédiatement après sa création, avant qu’elle ne soit complètement enregistrée.

Les messages d’erreur associés sont les suivants.

  1. No such job

  2. The specified job does not exist

Bonnes pratiques pour éviter les échecs de l’API NoSuchJobException

  1. Stocker les ID de tâche immédiatement : enregistrez l’ID de tâche indiqué dans la réponse CreateJob avant d’effectuer les appels d’API suivants.

  2. Implémenter une logique de nouvelle tentative : ajoutez un backoff exponentiel lors de la vérification du statut de la tâche immédiatement après sa création.

  3. Configurer une surveillance : créez des alarmes CloudWatch pour suivre l’achèvement des tâches avant l’expiration des 90 jours. Pour plus de détails, consultez Utilisation des alarmes Amazon CloudWatch dans le Guide de l’utilisateur Amazon CloudWatch.

  4. Faire preuve de cohérence dans l’utilisation des régions : assurez-vous que toutes les opérations utilisent la même région pour la création de tâches.

  5. Valider la saisie : vérifiez le format de l’ID de tâche avant d’effectuer des appels d’API.

Quand les tâches expirent

Les tâches à l’état terminal sont automatiquement supprimées après 90 jours. Pour éviter des perdre des informations sur les tâches, tenez compte des points suivants.

  1. Télécharger les rapports d’achèvement avant l’expiration : pour obtenir des instructions sur la récupération et le stockage des résultats des tâches, consultez .

  2. Archiver les métadonnées des tâches dans vos propres systèmes : stockez les informations critiques des tâches dans vos bases de données ou vos systèmes de surveillance.

  3. Configurer des notifications automatiques avant le délai de 90 jours : utilisez Amazon EventBridge pour créer des règles qui déclenchent des notifications lorsque les tâches sont terminées. Pour plus d’informations, consultez Notifications d’événements Amazon S3.

NoSuchJobExceptionRésolution des problèmes liés à

  1. Utilisez la commande suivante pour vérifier que la tâche existe dans votre compte et dans votre région.

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

  2. Utilisez la commande suivante pour effectuer une recherche parmi tous les statuts de tâche. Les statuts de tâche possibles sont Active, Cancelled, Cancelling, Complete, Completing, Failed, Failing, New, Paused, Pausing, Preparing, Ready et Suspended.

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

  3. Utilisez la commande suivante pour vérifier si la tâche existe dans d’autres régions dans lesquelles vous créez fréquemment des tâches.

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

  4. Validez le format de l’ID de tâche. Les ID de tâche contiennent généralement 36 caractères, par exemple 12345678-1234-1234-1234-123456789012. Vérifiez s’ils ne comportent pas d’espaces supplémentaires, de caractères manquants ou de problèmes de casse, et vérifiez que vous utilisez l’ID de tâche complet renvoyé par la commande CreateJob.

  5. Utilisez la commande suivante pour vérifier les événements de création de tâches dans les journaux CloudTrail.

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

AccessDeniedException

Type : échec de l’API

L’exception AccessDeniedException se produit lorsqu’une demande S3 Batch Operations est bloquée en raison d’autorisations insuffisantes, d’opérations non prises en charge ou de restrictions de politiques. Il s’agit de l’une des erreurs les plus courantes de Batch Operations. Les causes sont généralement les suivantes :

  1. Autorisations IAM manquantes : l’identité IAM ne dispose pas des autorisations requises pour les API Batch Operations.

  2. Autorisations S3 insuffisantes : autorisations manquantes pour accéder aux compartiments et aux objets source ou de destination.

  3. Problèmes liés au rôle d’exécution des tâches : le rôle d’exécution des tâches ne dispose pas des autorisations nécessaires pour effectuer l’opération spécifiée.

  4. Opérations non prises en charge : tentative d’utilisation d’opérations non prises en charge dans la région ou le type de compartiment en cours.

  5. Problèmes d’accès intercompte : autorisations manquantes pour les accès intercomptes aux compartiments ou aux objets.

  6. Restrictions des stratégies basées sur les ressources : stratégies de compartiment ou listes ACL d’objets bloquant l’opération.

  7. Restrictions de la politique de contrôle des services (SCP) : politiques au niveau de l’organisation empêchant l’opération.

Messages d’erreur associés :

  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

Bonnes pratiques pour éviter les échecs de l’API AccessDeniedException

  1. Utiliser le principe du moindre privilège : accordez uniquement les autorisations minimales requises pour vos opérations spécifiques.

  2. Tester les autorisations avant des tâches de grande ampleur : exécutez de petites tâches en guise de test pour valider les autorisations avant de traiter des milliers d’objets.

  3. Utiliser le simulateur de politiques IAM : testez les politiques avant leur déploiement à l’aide du simulateur de politiques IAM. Pour plus d’informations, consultez Test des politiques IAM avec le simulateur de politiques IAM dans le Guide de l’utilisateur IAM.

  4. Mettre en œuvre une configuration d’accès intercompte appropriée : vérifiez votre configuration d’accès intercompte pour les configurations de tâches intercomptes. Pour plus d’informations, consultez Didacticiel IAM : Délégation de l’accès entre des comptes AWS à l’aide de rôles IAM dans le Guide de l’utilisateur IAM.

  5. Surveiller les modifications des autorisations : configurez des alertes CloudTrail pour surveiller les modifications de politiques IAM susceptibles d’affecter Batch Operations.

  6. Documenter les exigences des rôles : conservez une documentation claire des autorisations requises pour chaque type de tâche.

  7. Utiliser des modèles d’autorisation courants : utilisez les exemples d’autorisations et les modèles de politiques :

    1. Octroi d’autorisations pour Batch Operations

    2. Ressources intercomptes dans IAM dans le Guide de l’utilisateur IAM.

    3. Utilisation des stratégies de point de terminaison pour contrôler l’accès aux points de terminaison d’un VPC dans le Guide AWS PrivateLink.

Résolution des problèmes liés à l’API AccessDeniedException

Suivez systématiquement ces étapes pour identifier et résoudre les problèmes d’autorisation.

  1. Consultez Opérations prises en charge par S3 Batch Operations pour connaître les opérations prises en charge par région. Vérifiez que les opérations sur les compartiments de répertoires ne sont disponibles qu’aux points de terminaison régionaux et zonaux. Vérifiez que l’opération est prise en charge par la classe de stockage de votre compartiment.

  2. Utilisez la commande suivante afin de déterminer si vous pouvez répertorier les tâches.

    
 aws s3control list-jobs --account-id 111122223333

  3. Utilisez la commande suivante pour vérifier les autorisations IAM de l’identité demandeuse. Le compte exécutant la tâche doit disposer des autorisations suivantes : s3:CreateJob, s3:DescribeJob, s3:ListJobs-s3:UpdateJobPriority, s3:UpdateJobStatus-iam:PassRole.

    
aws sts get-caller-identity 111122223333

  4. Utilisez la commande suivante pour vérifier si le rôle existe et peut être endossé. 

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

  5. Utilisez la commande suivante pour passer en revue la stratégie d’approbation du rôle. Le rôle exécutant la tâche doit inclure les éléments suivants :

    1. Relation d’approbation permettant à batchoperations.s3.amazonaws.com d’endosser ce rôle.

    2. Opérations effectuées par la fonctionnalité Opération par lot (par exemple, s3:PutObjectTagging pour les opérations de balisage).

    3. Accès aux compartiments source et de destination.

    4. Autorisation de lire le fichier manifeste.

    5. Autorisation de rédiger des rapports d’achèvement.

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

  6. Utilisez la commande suivante pour rétablir l’accès au manifeste et aux compartiments source.

    
aws s3 ls s3://bucket-name

  7. Testez l’opération effectuée par Batch Operations. Par exemple, si celle-ci effectue un balisage, balisez un exemple d’objet dans le compartiment source.

  8. Passez en revue les stratégies de compartiment pour identifier celles susceptibles de refuser l’opération.

    1. Vérifiez les listes ACL des objets si vous utilisez des contrôles d’accès existants.

    2. Vérifiez qu’aucune politique de contrôle des services (SCP) ne bloque l’opération.

    3. Vérifiez que les politiques de point de terminaison d’un VPC autorisent Batch Operations si vous utilisez des points de terminaison d’un VPC.

  9. Utilisez la commande suivante pour utiliser CloudTrail afin d’identifier les échecs d’autorisation.

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

SlowDownError

Type : échec de l’API

L’exception SlowDownError se produit lorsque votre compte a dépassé le taux de demandes limite de S3 Batch Operations. Il s’agit d’un mécanisme de limitation qui empêche le service d’être submergé par un trop grand nombre de demandes. Les causes sont généralement les suivantes :

  1. Fréquence élevée des demandes d’API : trop grand nombre d’appels d’API en peu de temps.

  2. Tâches simultanées : plusieurs applications ou utilisateurs créent/gèrent des tâches simultanément.

  3. Scripts automatisés sans limitation de débit : scripts qui ne mettent pas en œuvre de stratégies de backoff appropriées.

  4. Interrogation trop fréquente du statut des tâches : vérification du statut des tâches plus fréquente que nécessaire.

  5. Modèles de trafic en rafale : pics soudains d’utilisation des API pendant les périodes de traitement de pointe.

  6. Limites de la capacité régionale : dépassement de la capacité de demande allouée pour votre région.

Messages d’erreur associés :

  1. SlowDown

  2. Please reduce your request rate

  3. Request rate exceeded

Bonnes pratiques pour éviter les échecs de l’API SlowDownError

  1. Implémenter une limitation du débit côté client : ajoutez des délais entre les appels d’API dans vos applications.

  2. Utiliser un backoff exponentiel avec de la gigue : répartissez de manière aléatoire les délais de nouvelle tentative pour éviter les problèmes de bousculade.

  3. Configurer une logique de nouvelle tentative appropriée : implémentez des tentatives automatiques avec des délais croissants pour les erreurs transitoires.

  4. Utiliser des architectures basées sur les événements : remplacez les interrogations par des notifications EventBridge pour les changements de statut des tâches.

  5. Répartir la charge dans le temps : échelonnez la création de tâches et les vérifications de statut sur différentes périodes.

  6. Surveiller les limites de débit et recevoir des alertes : configurez des alarmes CloudWatch pour détecter quand vous approchez des limites.

La plupart des kits AWS SDK intègrent une logique de nouvelle tentative pour limiter les erreurs de débit. Configurez-la comme suit :

  1. AWS CLI : utilisez les paramètres cli-read-timeout et cli-connect-timeout.

  2. Kit AWS SDK pour Python (Boto3) : configurez les modes de nouvelle tentative et le nombre maximal de tentatives dans la configuration de votre client.

  3. Kit AWS SDK pour Java : utilisez les paramètres RetryPolicy et ClientConfiguration.

  4. Kit AWS SDK pour JavaScript : configurez maxRetries et retryDelayOptions.

Pour plus d’informations sur les modèles de nouvelle tentative et les bonnes pratiques, consultez Nouvelle tentative avec un schéma de backoff dans le Guide Recommandations AWS.

Résolution des problèmes liés à l’API SlowDownError

  1. Dans votre code, implémentez immédiatement un backoff exponentiel.

    Exemple de backoff exponentiel dans 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. Utilisez CloudTrail pour identifier la source du volume élevé de demandes.

    
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. Vérifiez la fréquence d’interrogation.

    1. Évitez de vérifier le statut des tâches actives plus d’une fois toutes les 30 secondes.

    2. Utilisez les notifications d’achèvement des tâches au lieu d’interroger ces dernières lorsque cela est possible.

    3. Intégrez de la gigue dans vos intervalles d’interrogation pour éviter les demandes synchronisées.

  4. Optimisez les modèles d’utilisation de vos API.

    1. Regroupez plusieurs opérations lorsque cela est possible.

    2. Utilisez ListJobs pour obtenir le statut de plusieurs tâches en un seul appel.

    3. Mettez en cache les informations relatives aux tâches afin de réduire les appels d’API redondants.

    4. Répartissez la création des tâches dans le temps au lieu d’en créer plusieurs simultanément.

  5. Utilisez les métriques CloudWatch pour les appels d’API afin de surveiller vos modèles de demandes.

    
   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

Type : échec de la tâche

L’exception InvalidManifestContent se produit lorsque des problèmes de format, de contenu ou de structure du fichier manifeste empêchent S3 Batch Operations de traiter la tâche. Les causes sont généralement les suivantes :

  1. Violations de format : colonnes obligatoires manquantes, délimiteurs incorrects ou mauvaise structure CSV.

  2. Problèmes de codage du contenu : codage des caractères, marqueurs de nomenclature incorrects, ou caractères non UTF-8.

  3. Problèmes liés à la clé d’objet : caractères non valides, codage en URL incorrect ou clés dépassant les limites de longueur maximale.

  4. Limites de taille : le manifeste contient plus d’objets que ce que l’opération prend en charge.

  5. Erreurs de format des ID de version : ID de version mal formés ou non valides pour les objets dont la gestion des versions est active.

  6. Problèmes de format des balises d’entité : format incorrect des balises d’entité ou guillemets manquants pour les opérations nécessitant des balises d’entité.

  7. Données incohérentes : formats mixtes dans le même manifeste ou nombre de colonnes incohérent.

Messages d’erreur associés :

  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

Bonnes pratiques pour empêcher les échecs des tâches InvalidManifestContent

  1. Valider avant le chargement : testez le format du manifeste avec de petites tâches avant de traiter de grands jeux de données.

  2. Utiliser un codage cohérent : utilisez toujours le codage UTF-8 sans nomenclature pour les fichiers manifestes.

  3. Mettre en œuvre des normes de génération de manifestes : créez des modèles et des procédures de validation pour la création de manifestes.

  4. Gérer correctement les caractères spéciaux : codez en URL les clés d’objet contenant des caractères spéciaux.

  5. Surveiller le nombre d’objets : suivez la taille du manifeste et répartissez les tâches volumineuses de manière proactive.

  6. Valider l’existence des objets : vérifiez que les objets existent avant de les inclure dans des manifestes.

  7. Utiliser des outils AWS pour la génération des manifestes : utilisez AWS CLI s3api list-objects-v2 pour générer des listes d’objets correctement formatées.

Problèmes courants liés aux manifestes et solutions correspondantes :

  1. Colonnes requises manquantes : assurez-vous que votre manifeste inclut toutes les colonnes requises pour votre type d’opération. Les colonnes les plus couramment manquantes sont Compartiment et Clé.

  2. Format CSV incorrect : utilisez des virgules comme délimiteurs, veillez à ce que le nombre de colonnes soit cohérent sur toutes les lignes et évitez les sauts de ligne dans les champs.

  3. Caractères spéciaux dans les clés d’objet : les clés d’objet codées en URL contiennent des espaces, des caractères Unicode ou des caractères spéciaux XML (<, >, &, «, ’).

  4. Fichiers manifestes volumineux : divisez les manifestes dépassant la limite d’opérations en plusieurs manifestes plus petits et créez des tâches distinctes.

  5. ID de version non valides : assurez-vous que les ID de version sont correctement formatés sous forme de chaînes alphanumériques. Supprimez la colonne des ID de version si elle n’est pas nécessaire.

  6. Problèmes de codage : enregistrez les fichiers manifestes au format UTF-8 sans nomenclature. Évitez de copier des manifestes avec des systèmes susceptibles de modifier le codage.

Pour obtenir des spécifications détaillées et des exemples de format de manifeste, consultez ce qui suit :

  1. Spécification d’un manifeste

  2. Opérations prises en charge par S3 Batch Operations

  3. Attribution d’un nom aux objets Amazon S3

Résolution des problèmes liés à l’API InvalidManifestContent

  1. Téléchargez et inspectez le fichier manifeste. Vérifiez manuellement que le manifeste répond aux exigences de format :

    1. Format CSV séparé par des virgules.

    2. Codage des caractères UTF-8 sans nomenclature.

    3. Nombre homogènes de colonnes sur toutes les lignes.

    4. Absence de lignes vides et d’espaces de fin.

    5. Clés d’objet correctement codées en URL si elles contiennent des caractères spéciaux.

    Utilisez la commande suivante pour télécharger le fichier manifeste.

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

  2. Vérifiez les colonnes requises pour votre opération :

    1. Toutes les opérations : Bucket, Key

    2. Opérations de copie : VersionId (facultatif)

    3. Opérations de restauration : VersionId (facultatif)

    4. Opérations de remplacement de balises : aucune colonne supplémentaire n’est requise.

    5. Opérations de remplacement de listes ACL : aucune colonne supplémentaire n’est requise.

    6. Initiation de restauration : VersionId (facultatif)

  3. Vérifiez les nombres limites d’objets :

    1. Copie : 1 milliard d’objets maximum.

    2. Suppression : 1 milliard d’objets maximum.

    3. Restauration : 1 milliard d’objets maximum.

    4. Balisage : 1 milliard d’objets maximum.

    5. Liste ACL : 1 milliard d’objets maximum.

  4. Créez un manifeste de test avec quelques objets de votre manifeste d’origine.

  5. Utilisez la commande suivante pour vérifier s’il existe un échantillon d’objets du manifeste.

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

  6. Vérifiez les détails de l’échec de la tâche et passez en revue le motif de l’échec ainsi que les détails concernant les erreurs spécifiques dans la description de la tâche.

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