本地执行AWS SAM package遇AccessDenied：无法上传构件

Even though you’ve confirmed the S3 bucket exists and you believe you have access, that AccessDenied error on PutObject often comes down to subtle permission or configuration gaps. Let’s walk through the most common fixes step by step:

1. Verify Your IAM Permissions Cover Object-Level Actions #

It’s easy to assume you have full bucket access, but double-check that your IAM user/role has explicit permissions for s3:PutObject (and optionally s3:GetObject if you need to overwrite artifacts). The critical detail here is that your policy must target objects inside the bucket, not just the bucket itself.

Example IAM policy snippet to fix this:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:PutObject", "s3:GetObject"],
      "Resource": "arn:aws:s3:::sam-project-deployment--29/*"
    },
    {
      "Effect": "Allow",
      "Action": "s3:ListBucket",
      "Resource": "arn:aws:s3:::sam-project-deployment--29"
    }
  ]
}

Notice the /* at the end of the resource for object-level actions—without this, you can list the bucket but can’t write to it.

2. Check the Bucket Policy for Blocking Deny Statements #

Bucket policies take precedence over IAM policies, so even if your IAM identity has permissions, a bucket policy might be blocking access. Look for any Deny statements that could target your user/role, or add an explicit Allow entry for your identity’s ARN to perform s3:PutObject.

3. Account for Server-Side Encryption (SSE) Requirements #

If your bucket has default server-side encryption enabled (especially with SSE-KMS), you’ll need additional KMS permissions. The identity used by SAM CLI needs:

• kms:GenerateDataKey (to encrypt the artifact during upload)
• kms:Decrypt (if you need to retrieve the artifact later)

Add these permissions to your IAM policy, targeting the KMS key ARN linked to the bucket.

4. Confirm You’re Using the Correct AWS Credentials #

Sometimes SAM CLI picks up credentials from a different profile or environment variable than you expect. Run this command to verify the identity you’re currently using:

aws sts get-caller-identity

Cross-check this identity’s permissions in the IAM console. If you’re using a specific profile, add --profile your-profile-name to both the SAM command and this verification command.

5. Double-Check Bucket Region & Name Spelling #

Even though you confirmed the bucket exists, make sure:

• The bucket was created in us-east-2 (the region specified in your SAM command)
• The bucket name in the command (sam-project-deployment--29) matches exactly—extra or missing hyphens are a surprisingly common gotcha.

6. Isolate the Issue with a Direct AWS CLI Test #

Rule out SAM-specific problems by testing a simple PutObject with the AWS CLI:

aws s3 cp some-local-file.txt s3://sam-project-deployment--29/test-file.txt --region us-east-2

If this fails, the problem is definitely with permissions or bucket configuration. If it works, check your SAM template’s CodeUri path to ensure it points to a valid local directory/file that SAM can package.

Start with these steps—most of the time, the issue is a missing permission scope or a credential mix-up.

内容的提问来源于stack exchange，提问作者Michael Durrant