Skip to content

Amazon S3 Troubleshooting

Connection failures from S3 fall into four categories: credential errors (AWS rejected the keys themselves), IAM Role errors (STS refused to issue temporary credentials), permission errors (credentials are valid but the IAM policy is missing actions), and bucket configuration errors (the bucket, region, or KMS key is misconfigured). The structure of the AWS error message indicates which layer failed and where to look first.

Common Errors

Error Likely Cause Fix
InvalidAccessKeyId The Access Key ID does not exist or has been deactivated. Verify the Access Key ID in IAM > Users > Security credentials, or generate a new key pair.
SignatureDoesNotMatch The Secret Access Key is incorrect, or it was copied with extra whitespace, a trailing newline, or truncated characters. Re-copy the Secret Access Key carefully. Confirm that the Access Key ID and Secret belong to the same IAM identity.
AccessDenied The IAM identity authenticated but lacks one or more required S3 permissions, the bucket policy or S3 Block Public Access settings explicitly deny access, or the bucket is in a different AWS account without cross-account permissions configured. Compare the attached IAM policy against the Source or Enrichment tables. Check the bucket policy for explicit Deny statements. Confirm the bucket is in the correct AWS account.
NoSuchBucket The bucket name in the URI does not exist or was deleted. Verify the bucket name and ensure the URI follows the format s3://<bucket-name>.
AllAccessDisabled AWS has administratively disabled the bucket. Uncommon, typically tied to account suspension, billing, or compliance issues. Contact AWS Support. The bucket cannot be accessed until AWS re-enables it.
AccessDenied referencing a KMS action (sometimes surfaced as KMS.AccessDeniedException depending on the SDK version) The bucket uses SSE-KMS and the IAM identity cannot decrypt (or, on enrichment, cannot generate a data key for) the customer-managed key. Grant kms:Decrypt (and kms:GenerateDataKey for writes) on the bucket's KMS key.

Note

Less common AWS errors that do not match one of the patterns above are shown as the original message from the S3 SDK. The patterns above cover the credential, permission, and bucket cases reported most frequently.

Detailed Notes

Credential errors

If the message describes an invalid Access Key ID, a key/signature mismatch, or unrecognized credentials, AWS rejected the request at the authentication layer. This happens before any IAM policy is evaluated, so adjusting permissions will not help. Focus on the credentials themselves:

  • Re-copy the Access Key ID and Secret Access Key, watching for stray whitespace, trailing newlines, or truncated characters.
  • Confirm the Access Key ID and Secret Access Key belong to the same IAM identity.
  • If your access keys come from a temporary STS session (assumed role or SSO), Access Key authentication cannot accept a session token directly. Switch the connection to IAM Role authentication, or generate long-lived access keys for a dedicated IAM user.
  • If credentials were recently rotated, update the connection with the new values.

Note

Authentication errors occur before any IAM permission policy is evaluated. Modifying policies will not resolve them. Only correcting the credentials does.

IAM Role errors

If you selected IAM Role authentication and the error message mentions assuming a role, an IRSA service account (used by EKS deployments), or a malformed trust policy, the credentials reached AWS but STS refused to issue session credentials for the role:

  • Calling identity not trusted: The dataplane identity is not listed as a Principal in the role's trust policy. Add it (Managed deployments use the per-tenant dataplane role ARN; Self-Hosted deployments use the base role or IAM user ARN).
  • External ID mismatch: The trust policy enforces an sts:ExternalId condition and the value entered in the connection form does not byte-match. Watch for whitespace and copy-paste artifacts.
  • Malformed trust policy: The role's trust policy has invalid JSON or an unknown principal. Open the role in IAM and fix the trust policy document.

For the full setup, see IAM Role Authentication.

Permission errors

If the credentials are valid but AWS denies a specific S3 action, the IAM policy is missing actions or the bucket policy overrides them.

  • Missing bucket-level permissions: The most common case. The IAM policy grants s3:GetObject (object-level) but not s3:ListBucket and s3:GetBucketLocation (bucket-level). Both are required.
  • Bucket policy conflict: The bucket has a resource-based policy with an explicit Deny that overrides the IAM policy.
  • S3 Block Public Access: The bucket's public access settings may block access even for authenticated IAM users if the policy references public access.
  • Wrong resource ARN: The IAM policy specifies a different bucket or path than the one in the connection form. Compare the Resource ARN to the URI value.

Use AWS CloudTrail to identify the exact action and resource that was denied. The event names the missing permission.

Bucket configuration errors

These errors point to the bucket itself or its configuration, not your IAM policy:

  • Bucket does not exist: The bucket name was misspelled or the bucket was deleted. The AWS error is NoSuchBucket.
  • Bucket in different account: The bucket belongs to a different AWS account and cross-account access has not been configured. This surfaces as AccessDenied, not a bucket-specific error code.
  • Encrypted bucket without KMS grants: The bucket uses SSE-KMS and the IAM identity cannot decrypt or generate data keys. Grant kms:Decrypt (and kms:GenerateDataKey for writes) scoped to the KMS key ARN. AWS surfaces this as AccessDenied referencing the missing KMS action (or, in some SDK versions, as KMS.AccessDeniedException).
  • Bucket administratively disabled: Rare. If AWS returns AllAccessDisabled, the bucket has been disabled at the account level (account suspension, billing, or compliance). Contact AWS Support.

Diagnostic order

Investigate in the order AWS evaluates requests: authentication first, role assumption second, authorization third, then bucket configuration. Resolving credential errors before policy errors avoids investigating IAM changes that won't fix the actual issue.

Message describes… Layer that failed Where to look
InvalidAccessKeyId, SignatureDoesNotMatch, expired session Authentication Verify the credentials themselves; IAM policies are not evaluated at this stage
Assuming an IAM Role, a service account (IRSA, used by EKS), or trust policy STS / role assumption Verify the Role ARN, the role's trust policy, and that the dataplane identity is trusted
AccessDenied on a specific S3 action Authorization Compare the IAM policy to the minimum-permissions tables and use CloudTrail to identify the missing action
NoSuchBucket, AllAccessDisabled, or AccessDenied referencing KMS Bucket configuration Confirm the bucket name, account, and KMS key