S3 Inventory Reports: Track Objects and Metadata at Scale (2026)

S3 Inventory reports, when they fail, usually do so because the underlying S3 bucket is misconfigured for access or the IAM permissions are too restrictive.

Common Causes and Fixes for S3 Inventory Report Failures

S3 Bucket Policy Denying Access: The S3 bucket designated to store your inventory reports is not configured to allow S3 Inventory to write to it.
- Diagnosis: Check the bucket policy of your destination bucket. Look for statements that explicitly deny s3:PutObject actions for the inventory report prefix or deny access from the AWS account running the inventory.
- Fix: Add a statement to the bucket policy that explicitly allows s3:PutObject from the AWS account that generates the inventory.
```
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::<YOUR_AWS_ACCOUNT_ID>:root"
            },
            "Action": "s3:PutObject",
            "Resource": "arn:aws:s3:::<YOUR_DESTINATION_BUCKET_NAME>/<YOUR_INVENTORY_REPORT_PREFIX>/*"
        }
    ]
}
```
  Replace <YOUR_AWS_ACCOUNT_ID>, <YOUR_DESTINATION_BUCKET_NAME>, and <YOUR_INVENTORY_REPORT_PREFIX> with your specific values. This policy grants your AWS account the necessary permission to write objects (the inventory reports) into the specified bucket and prefix.
- Why it works: S3 Inventory runs as a service within your AWS account. This policy explicitly authorizes your account’s principal to perform the PutObject action, which is required to write the generated report files.
IAM Role Lacking Permissions: The IAM role associated with the S3 Inventory configuration (if you’re using a role for cross-account access or specific service permissions) doesn’t have the necessary permissions to read from the source bucket or write to the destination bucket.
- Diagnosis: Examine the IAM policy attached to the role used by S3 Inventory. Ensure it includes permissions like s3:GetObject, s3:ListBucket for the source bucket, and s3:PutObject for the destination bucket and prefix.
- Fix: Attach a managed policy like AmazonS3ReadOnlyAccess (for source bucket read) and a custom policy allowing write access to the destination bucket.
```
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:ListBucket"
            ],
            "Resource": "arn:aws:s3:::<YOUR_SOURCE_BUCKET_NAME>"
        },
        {
            "Effect": "Allow",
            "Action": [
                "s3:GetObject"
            ],
            "Resource": "arn:aws:s3:::<YOUR_SOURCE_BUCKET_NAME>/*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "s3:PutObject"
            ],
            "Resource": "arn:aws:s3:::<YOUR_DESTINATION_BUCKET_NAME>/<YOUR_INVENTORY_REPORT_PREFIX>/*"
        }
    ]
}
```
  Replace <YOUR_SOURCE_BUCKET_NAME>, <YOUR_DESTINATION_BUCKET_NAME>, and <YOUR_INVENTORY_REPORT_PREFIX> with your specific values. This policy grants the role the read permissions for the source bucket and the write permissions for the destination bucket.
- Why it works: IAM roles are the standard way to grant granular permissions to AWS services. This policy ensures the role S3 Inventory assumes has all the required permissions to interact with both the source and destination S3 buckets.
Source Bucket Encryption Mismatch: If your source S3 bucket is encrypted with SSE-KMS, and the IAM role or user creating the inventory doesn’t have permissions to use the KMS key, the inventory process will fail.
- Diagnosis: Verify if the source bucket is encrypted with SSE-KMS. Check the KMS key policy for the key used and ensure the IAM role/user has kms:Decrypt and kms:GenerateDataKey permissions on that key.
- Fix: Update the KMS key policy to grant kms:Decrypt and kms:GenerateDataKey permissions to the IAM role or user.
```
{
    "Sid": "AllowS3InventoryToUseKMS",
    "Effect": "Allow",
    "Principal": {
        "AWS": "arn:aws:iam::<YOUR_AWS_ACCOUNT_ID>:<IAM_ROLE_OR_USER_NAME>"
    },
    "Action": [
        "kms:Decrypt",
        "kms:GenerateDataKey"
    ],
    "Resource": "*"
}
```
  Replace <YOUR_AWS_ACCOUNT_ID> and <IAM_ROLE_OR_USER_NAME> with the appropriate values. This allows the specified principal (the role or user running S3 Inventory) to decrypt objects in the source bucket and generate data keys for reading.
- Why it works: SSE-KMS encryption requires explicit permission to access the KMS key for decryption operations. This policy grants that necessary access.
Destination Bucket Versioning Not Enabled: S3 Inventory requires versioning to be enabled on the destination bucket to support overwriting previous reports and managing report versions.
- Diagnosis: Check the versioning status of your destination S3 bucket in the S3 console.
- Fix: Enable versioning on the destination bucket.
```
aws s3api put-bucket-versioning --bucket <YOUR_DESTINATION_BUCKET_NAME> --versioning-configuration Status=Enabled
```
  Replace <YOUR_DESTINATION_BUCKET_NAME> with your bucket name. This ensures that S3 can properly manage the lifecycle of your inventory reports within the bucket.
- Why it works: Versioning allows S3 to maintain multiple versions of an object. For inventory reports, this is crucial for tracking changes over time and preventing accidental data loss if a report is overwritten or deleted.
Incorrect Inventory Configuration (Prefix/Format): The specified prefix for the inventory report in the destination bucket might be invalid, or the report format is incompatible with downstream processing.
- Diagnosis: Review the S3 Inventory configuration. Ensure the Prefix field points to a valid location within the destination bucket and that the Format (e.g., CSV, ORC, Parquet) is correctly specified and supported.
- Fix: Correct the Prefix value in the S3 Inventory configuration to a valid path (e.g., inventory-reports/daily/). Ensure the Format is set to CSV, ORC, or PARQUET.
- Why it works: The prefix defines where the report files will be written. An invalid prefix can lead to write failures. The format dictates how the data is structured, and incorrect specification can lead to processing errors later.
Cross-Account Access Issues: If the source and destination buckets are in different AWS accounts, proper cross-account IAM roles and bucket policies are essential.
- Diagnosis: Verify that the IAM role used by S3 Inventory in the source account has permissions to list and get objects from the source bucket. Additionally, verify that the destination bucket’s policy in the destination account explicitly grants s3:PutObject permission to the IAM role in the source account.
- Fix:
  - Source Account: Create an IAM role with permissions to read the source bucket.
  - Destination Account: Update the destination bucket policy to allow s3:PutObject from the IAM role in the source account.
```
// Destination Bucket Policy (in destination account)
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::<SOURCE_ACCOUNT_ID>:role/<ROLE_NAME_IN_SOURCE_ACCOUNT>"
            },
            "Action": "s3:PutObject",
            "Resource": "arn:aws:s3:::<YOUR_DESTINATION_BUCKET_NAME>/<YOUR_INVENTORY_REPORT_PREFIX>/*"
        }
    ]
}
```
  Replace <SOURCE_ACCOUNT_ID>, <ROLE_NAME_IN_SOURCE_ACCOUNT>, <YOUR_DESTINATION_BUCKET_NAME>, and <YOUR_INVENTORY_REPORT_PREFIX>.
- Why it works: This establishes a trusted communication channel between the two accounts, allowing the S3 Inventory service in the source account to write its output to the designated bucket in the destination account.

The next error you’ll likely encounter after fixing these issues is a "Request Limit Exceeded" error on the source bucket if you’re listing a very large number of objects, which will require a different strategy like increasing the frequency of your inventory reports or considering alternative listing methods.