'InvalidS3ObjectException' When Amazon Rekognition Cannot Read Image from S3
Troubleshooting region mismatch, bucket policies, object ownership, and KMS encryption conflicts
Category: IAM & Permission Boundaries
Problem
Your application calls DetectLabels in Amazon Rekognition.
IAM permissions look correct.
The role has rekognition:DetectLabels.
S3 access appears configured.
Yet the call fails with:
InvalidS3ObjectException: Unable to get object metadata from S3.
The object exists.
The key is correct.
Still failing.
Clarifying the Issue
InvalidS3ObjectException does not mean the object is missing.
đź“Ś It means Rekognition could not successfully retrieve or validate the object from S3.
This error usually masks one of four underlying causes:
- S3 bucket policy denial
- Region mismatch between S3 and Rekognition
- Object-level ACL conflict
- KMS-encrypted object without proper key permissions
Rekognition must:
- Call the API successfully
- Access the S3 object
- Retrieve object metadata
- Decrypt the object if encrypted
Failure at any of those layers produces this exception.
Why It Matters
This error often appears after fixing IAM permissions.
Engineers think:
“Rekognition is broken.”
It isn’t.
đź“Ś This is a storage boundary issue — not a Rekognition failure.
If left unresolved, it can:
- Break media ingestion pipelines
- Cause silent batch job failures
- Trigger retry storms
- Delay production rollouts
The key is isolating which S3 boundary is failing.
Key Terms
- InvalidS3ObjectException – Rekognition cannot retrieve or validate the S3 object.
- Bucket Policy – Resource-based policy attached directly to an S3 bucket.
- Object ACL – Access control list applied at the object level.
- KMS Key Policy – Policy controlling access to encrypted S3 objects.
- Region Alignment – Rekognition and S3 must operate in the same AWS region.
- Object Ownership (Bucket Owner Enforced) – Modern S3 setting that disables ACLs entirely.
Steps at a Glance
- Confirm S3 and Rekognition are in the same region.
- Verify the object key and path are correct.
- Inspect S3 bucket policy for explicit denies.
- Check object ownership and ACL settings.
- Validate KMS encryption permissions.
- Confirm execution role has
s3:GetObject.
Detailed Steps
Step 1: Confirm Region Alignment
Rekognition is region-scoped.
If your S3 bucket is in us-west-2 and Rekognition is invoked in us-east-1, the request will fail.
Check:
- S3 bucket region
- Rekognition client region configuration
They must match.
Region mismatch is one of the most common hidden causes of this error.
Step 2: Inspect the S3 Bucket Policy
Open the S3 bucket → Permissions → Bucket Policy.
Look for:
{
"Effect": "Deny",
"Principal": "*",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::your-bucket/*"
}
Even if your IAM role allows s3:GetObject, a bucket-level explicit deny overrides it.
Bucket policies operate independently of IAM identity policies.
If a deny exists, Rekognition cannot access the object.
Step 3: Check Object Ownership and ACL Settings
If object ownership differs from bucket ownership, the object may not grant read permissions.
Inspect the object → Permissions → Access Control List.
Ensure the execution role (or bucket owner) has read access.
However, in modern S3 configurations, many buckets use Bucket Owner Enforced object ownership. When this setting is enabled, ACLs are disabled entirely and ignored by S3.
If Object Ownership is set to Bucket Owner Enforced, ACLs are not the issue. In that case, focus on bucket policy and IAM permissions instead.
ACL-related failures most commonly occur when:
- Objects are uploaded from another account
- Cross-account pipelines are involved
- Legacy buckets still rely on ACL-based access control
Modern best practice is disabling ACLs and relying exclusively on bucket policies — but mixed environments still surface this issue.
Step 4: Validate KMS Encryption Permissions
If the object is encrypted with SSE-KMS, Rekognition must be able to decrypt it.
Check:
- S3 object encryption settings
- Associated KMS key
Then inspect the KMS key policy.
The execution role must have:
kms:Decrypt
for the specific key.
Even with full S3 access, lack of KMS permissions will cause retrieval failure and surface as InvalidS3ObjectException.
This is frequently overlooked.
Step 5: Confirm Role Permissions
Ensure the execution role includes:
s3:GetObject
on the exact object ARN.
Wildcard access may be insufficient if conditions are applied.
Use IAM Policy Simulator if necessary.
If the role cannot download the object directly using the same credentials, Rekognition cannot either.
Pro Tips
- Region mismatch should be checked first — it’s fast to validate.
- Bucket policy explicit denies override IAM allows.
- If Object Ownership is set to Bucket Owner Enforced, ACLs are irrelevant.
- KMS key policy restrictions are invisible unless explicitly reviewed.
- Test S3 access independently using the same role credentials.
If the API call succeeds but the image cannot be retrieved, the failure still surfaces as InvalidS3ObjectException.
Conclusion
InvalidS3ObjectException is not a Rekognition defect.
It is S3 refusing or failing to serve the object.
When IAM permissions appear correct, look at:
- Region alignment
- Bucket policy
- Object ownership and ACL configuration
- KMS key policy
Rekognition depends on S3 behaving correctly.
This is a storage boundary issue — not an Rekognition issue.
Aaron Rose is a software engineer and technology writer at tech-reader.blog and the author of Think Like a Genius.
Comments
Post a Comment