Amazon S3 バッチオペレーションの問題をトラブルシューティングするにはどうすればよいですか?

所要時間3分
0

バケット内のオブジェクトの Amazon Simple Storage Service (Amazon S3) バッチオペレーションジョブを作成すると、Amazon S3 はエラーを返します。または、バッチジョブが失敗します。

簡単な説明

Amazon S3 バッチオペレーションジョブで問題が発生して正常に実行できない場合、ジョブは失敗します。ジョブが失敗すると、1 つ以上の失敗コードと理由が生成されます。Amazon S3 バッチオペレーションの失敗コードと理由を確認するには、ジョブの詳細をリクエストしてください。ジョブの完了レポートで失敗コードと理由を確認することもできます。

ジョブが多数の失敗オペレーションを実行するのを防ぐため、Amazon S3 はすべてのバッチオペレーションジョブにタスク失敗のしきい値を課しています。Amazon S3 は、1,000 件以上のタスクが実行された後のタスク失敗率をモニタリングします。ジョブで失敗率が 50% を超えると、そのジョブは失敗します。この問題を解決するには、障害の原因を確認して修正してください。その後、ジョブを再送信します。

解決策

マニフェストファイルの形式が正しくない (.csv または JSON)

Amazon S3 バッチオペレーションは、.csv および JSON (Amazon S3 インベントリレポート) のマニフェストファイルをサポートしています。マニフェストファイルが正しくない場合は、Amazon S3 で新しいバッチジョブを作成し、正しい形式を指定する必要があります。

  • Amazon S3 インベントリレポートには、CSV 形式のレポートを使用し、インベントリレポートに関連付けられた manifest.json ファイルを指定します。

  • .csv ファイルの場合は、マニフェストファイルの各行にバケット名とオブジェクトキーを含めます。オプションで、オブジェクトバージョンを含めてください。マニフェストにバージョン ID を含める場合は、すべてのオブジェクトの ID を指定する必要があります。そうでない場合は、どのオブジェクトについてもバージョン ID を含めないでください。オブジェクトキーは URL でエンコードする必要があります。

    注: マニフェスト内のオブジェクトがバージョン管理されたバケットにある場合は、オブジェクトのバージョン ID を指定する必要があります。そうしないと、バッチジョブは失敗します。または、Amazon S3 がバッチジョブを誤ったバージョンのオブジェクトに適用する可能性があります。

詳細については、「マニフェストの指定」を参照してください。

マニフェストファイルに複数のバケット名が指定されているか、複数のヘッダー行が含まれている

S3 バッチオペレーションでは、マニフェストファイルに表示されているすべてのオブジェクトが同じバケットに存在する必要があります。そうしないと、次のエラーが表示されます:

「Reasons for failure: Cannot have more than 1 bucket per Job.JOB_ID」

S3 バッチオペレーションジョブの場合は、マニフェストファイルにバケット名が 1 つだけ指定され、ヘッダー行が含まれていないことを確認してください。この例では、マニフェストファイルに複数のヘッダー行が含まれているため、Amazon S3 はエラーを返します。

bucket,key
my-batch-bucket,object001.txt
my-batch-bucket,object002.txt
my-batch-bucket,object003.txt
my-batch-bucket,object004.txt

IAM ロールにはマニフェストファイルを読み取る権限がありません

S3 バッチオペレーションジョブを作成する AWS Identity and Access Management (IAM) ロールには、マニフェストファイルの GetObject 読み取り権限が必要です。S3 オブジェクトの所有権とアクセスの不一致がないか、オブジェクトのメタデータを確認します。また、マニフェストファイルを暗号化するサポートされていない AWS Key Management Service (AWS KMS) キーがないか確認します。

IAM ロールに適切な権限がない場合、S3 バッチオペレーションジョブを作成すると次のエラーが表示されます:

AWS CLI エラーの例

「Reason for failure Reading the manifest is forbidden: AccessDenied」

注: AWS コマンドラインインターフェイス (AWS CLI) コマンドの実行中にエラーが発生した場合は、「AWS CLI エラーのトラブルシューティング」を参照してください。また、AWS CLI の最新バージョンを使用していることを確認してください。

Amazon S3 コンソールエラーの例

「Warning: Unable to get the manifest object's ETag.Specify a different object to continue」

注: S3 バッチオペレーションは、AWS KMS で暗号化された CSV インベントリレポートをサポートします。S3 バッチオペレーションは、AWS KMS で暗号化された .csv マニフェストファイルをサポートしていません。詳細については、「S3 コンソールを使用したインベントリの設定」を参照してください。

バッチジョブが別のリージョンにある

S3 バッチオペレーションのコピージョブは、オブジェクトをコピーする宛先バケットと同じ AWS リージョンにある必要があります。バッチジョブを作成するときに、宛先バケットと同じリージョンを選択します。たとえば、宛先バケットが us-west-2 リージョンにある場合は、バッチジョブのリージョンとして us-west-2 を選択します。

S3 インベントリレポートのターゲットバケットが見つからない

S3 バッチオペレーションが生成するマニフェストのターゲットバケットが必要です。Amazon S3 バケットポリシーでは、s3:PutObject アクションも許可する必要があります。レポートが別の AWS アカウントに送信される場合は、ターゲットバケットが IAM ロールに s3:PutObject アクションの実行を許可していることを確認します。

IAM ロールの信頼ポリシーが見つからない

注: IAM ユーザーではなく IAM ロールを指定してください。

IAM ロールの信頼ポリシーは、他のプリンシパルがそのロールを引き継ぐために満たす必要がある条件を定義します。S3 バッチオペレーションのサービスプリンシパルが IAM ロールを引き継ぐことができるようにするには、ロールに信頼ポリシーをアタッチします。

この信頼ポリシーの例では、Amazon S3 へのアクセスを許可しています。これにより、権限のエスカレーションに関連するリスクが軽減されます:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "batchoperations.s3.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

バッチジョブを作成するための IAM 権限がない

S3 バッチオペレーションジョブを作成して実行する前に、IAM ロールに必要な権限を付与します。IAM ロールに S3 バッチオペレーションジョブの実行に必要な権限がない場合、バッチジョブは失敗します。

S3 バッチオペレーションジョブを作成するには、IAM ロールに s3:CreateJob 権限を付与します。ジョブを作成する同じエンティティにも iam:PassRole 権限が必要です。これにより、エンティティはバッチジョブに指定した IAM ロールを渡すことができます。詳細については、「IAM JSON ポリシー要素: リソース」を参照してください。

ソースバケット、S3 インベントリレポート、または宛先バケットへのアクセス権が見つからない

S3 バッチオペレーションに使用する IAM ロールに、バッチジョブの実行に必要な権限があることを確認してください。

コピー操作の IAM ポリシーの例を次に示します:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Action": [
        "s3:PutObject",
        "s3:PutObjectAcl",
        "s3:PutObjectTagging"
      ],
      "Effect": "Allow",
      "Resource": "arn:aws:s3:::{{DestinationBucket}}/*"
    },
    {
      "Action": [
        "s3:GetObject",
        "s3:GetObjectAcl",
        "s3:GetObjectTagging",
        "s3:ListBucket"
      ],
      "Effect": "Allow",
      "Resource": [
        "arn:aws:s3:::{{SourceBucket}}",
        "arn:aws:s3:::{{SourceBucket}}/*"
      ]
    },
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:GetObjectVersion"
      ],
      "Resource": [
        "arn:aws:s3:::{{ManifestBucket}}/*"
      ]
    },
    {
      "Effect": "Allow",
      "Action": [
        "s3:PutObject"
      ],
      "Resource": [
        "arn:aws:s3:::{{ReportBucket}}/*"
      ]
    }
  ]
}

詳細については、「Amazon S3 バッチ操作に対するアクセス許可の付与」を参照してください。

Organizations SCP が制限されている

AWS Organizations を使用している場合は、Amazon S3 へのアクセスを拒否する Deny ステートメントがないことを確認してください。たとえば、サービスコントロールポリシー (SCP) がすべての S3 アクションを明示的に拒否しているとします。この場合、バッチジョブの作成時に「Access Denied」エラーが表示されることがあります。

このポリシー例では、すべての S3 アクションを明示的に拒否します:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Principal": "*",
      "Effect": "Deny",
      "Action": "s3:*",
      "Resource": "*"
    }
  ]
}

制限のあるポリシーを適用するには、S3 バッチオペレーションが操作を実行するために使用する IAM ロールを許可リストに追加します。この例では、ポリシーに例外を追加しています:

{
  "Version": "2012-10-17",
  "Statement": \[
    {
      "Principal": "\*",
      "Effect": "Deny",
      "Action": "s3:\*",
      "Resource": "\*",
      "Condition": {
        "StringNotLike": {
          "aws:userId": \[
            "AROAEXAMPLEID:\*",
            "AIDAEXAMPLEID",
            "111111111111"
          \]
        }
      }
    }
  \]
}

オブジェクトのバージョン ID がマニフェストに見つからない

バッチオペレーションジョブで、バージョン ID フィールドが空であるマニフェスト内のオブジェクトが見つかると、次のエラーが表示されます:

「Error: BUCKET_NAME,prefix/file_name,failed,400,InvalidRequest,Task failed due to missing VersionId」

マニフェスト形式が操作中にバージョン ID を使用する場合、バージョン ID フィールドを空の文字列にすることはできません。代わりに、バージョン ID フィールドは「null」文字列にする必要があります。バージョン管理外のジョブではこのエラーは発生しません。マニフェストにあるバージョン ID ではなく、各オブジェクトの最新バージョンで動作します。このエラーを修正するには、空のバージョン ID を NULL 文字列に変換します

注: バッチオペレーションは、その特定のオブジェクトでは失敗しますが、ジョブ全体で失敗するわけではありません。

Amazon S3 オブジェクトロック保持モードがオンになっていると、ジョブレポートが配信されない

ガバナンスモードまたはコンプライアンスモードの宛先バケットにオブジェクトロック保持モードを設定すると、次のエラーが表示されることがあります:

「Error: Reasons for failure.The job report could not be written to your bucket.Please check your permissions.」

Amazon S3 は、保持モード設定の宛先バケットのオブジェクトロックをサポートしていません。保持モードを設定すると、バケットは write-once-read-many (WORM) で保護されます。このエラーを修正するには、オブジェクトロック保持モードが設定されていないジョブ完了レポートの宛先バケットを選択してください。

注: 失敗するのは完了レポートであり、ジョブではありません。ジョブは正常に完了し、すべてのオブジェクトが処理されます。

ETag のバージョンが一致しない

バッチオペレーションジョブでマニフェストを指定する場合、マニフェストオブジェクトキー、ETag、およびオプションでバージョン ID を指定できます。マニフェストファイルを指定する際は、ETag の値が S3 バケット内のマニフェストオブジェクトの最新バージョンの ETag と一致することを確認します。Amazon S3 コンソールの [バッチオペレーション] タブで、マニフェストファイルプロパティの [マニフェストオブジェクト ETag] を確認します。AWS CLI で、マニフェストの仕様が渡す Etag の値を確認します。

コンソールまたは AWS CLI に入力された ETag が S3 バケットの ETag と一致しない場合、次のエラーが発生します:

「Error reading the manifest.Caused by: ETag mismatch.Expected ETag: 69f52a4e9f797e987155d9c8f5880897」

このエラーの Expected ETag を書き留め、両方のバージョンの ETag が一致していることを確認してください。詳細については、「マニフェストの指定」を参照してください。

AWS公式
AWS公式更新しました 6ヶ月前
コメントはありません