如何通过CloudFront向AWS S3上传媒体文件？请求报错求助

Hey there, let's work through these frustrating errors together. The NotSignedUp message is especially misleading (since you clearly have S3 enabled), so we'll start with that, then tackle the XML issue and general 403s.

First: Fixing the "NotSignedUp" Error #

This almost never means your account isn't registered for S3—it's usually a problem with CloudFront origin configuration or signature targeting:

• Double-check your CloudFront origin settings: Make sure you're using the correct S3 endpoint for your bucket. For regional buckets, use your-bucket-name.s3.REGION.amazonaws.com instead of the old-style s3.amazonaws.com/your-bucket-name (this format causes signature mismatches).
• Verify your signed cookies' target service: If you're generating signed cookies for CloudFront, ensure the signature is scoped to CloudFront (not direct S3 access). If you accidentally sign requests for S3 but send them to CloudFront, S3 will reject the signature because the domain doesn't match.
• Confirm Origin Access Control (OAC) setup: If you're using OAC (the modern alternative to OAI), make sure your S3 bucket policy explicitly allows CloudFront to access the bucket. We'll cover this in detail below.

Next: Resolving the "MalformedXML" Error #

This error typically ties to incorrect PUT request formatting or invalid signature data:

• Check your PUT request body: If you're uploading a file, the request body should be the raw file content—not an XML wrapper. Avoid sending XML metadata unless you're configuring bucket settings (which you aren't here).
• Validate your signed cookies: Ensure all three required cookies (CloudFront-Policy, CloudFront-Signature, CloudFront-Key-Pair-Id) are correctly generated. The Policy must be a properly Base64-encoded JSON object with no truncation or encoding errors.
• Confirm your request path: If your target S3 path is s3://your-bucket/uploads/file.jpg, your CloudFront request path should be /uploads/file.jpg—not /your-bucket/uploads/file.jpg (unless you intentionally configured your origin to include the bucket name in the path, which is rare).
• Check Content-Type headers: For binary files (images, docs), set the correct Content-Type header (e.g., image/jpeg, application/octet-stream). If you leave it as text/xml, S3 will interpret the file as XML and throw this error if it doesn't match the expected schema.

Core Fixes for General 403 Errors #

All these issues boil down to permissions or signature validity. Here's what to verify:

• Update your S3 bucket policy for OAC: If you're using OAC, add this policy to your bucket to grant CloudFront access (replace placeholders with your details):

  {
    "Version": "2008-10-17",
    "Id": "PolicyForCloudFrontPrivateContent",
    "Statement": [
      {
        "Sid": "AllowCloudFrontAccess",
        "Effect": "Allow",
        "Principal": {
          "Service": "cloudfront.amazonaws.com"
        },
        "Action": ["s3:GetObject", "s3:PutObject"],
        "Resource": "arn:aws:s3:::YOUR-BUCKET-NAME/*",
        "Condition": {
          "StringEquals": {
            "AWS:SourceArn": "arn:aws:cloudfront::YOUR-AWS-ACCOUNT-ID:distribution/YOUR-CLOUDFRONT-DIST-ID"
          }
        }
      }
    ]
  }
  

  This allows both GET and PUT operations via your CloudFront distribution.
• Validate signed cookie scope: Ensure the policy in your signed cookies includes the correct resource paths (e.g., /* for all objects, or /uploads/* for a specific prefix) and allows both GET and PUT methods. Also, check that the expiration time hasn't passed.
• Check S3 Block Public Access settings: If your bucket has Block Public Access enabled (which is recommended), confirm you're using OAC/OAI to access it—direct public access will be blocked, even with valid signatures.
• Test direct S3 access first: Rule out S3-side issues by using the AWS CLI to upload/download a file directly:

  aws s3 cp test-file.txt s3://your-bucket/test-file.txt
  aws s3 cp s3://your-bucket/test-file.txt local-copy.txt
  

  If this works, the problem is definitely with CloudFront configuration or signatures.

Quick Test Workflow #

1. Confirm direct S3 operations work (using CLI as above).
2. Test a GET request to CloudFront without signed cookies—you should get a 403 (expected for private content).
3. Test GET with valid signed cookies—if this works, the signature logic is sound, and the issue is with your PUT request formatting.
4. Debug PUT requests by checking headers (especially Content-Type) and ensuring the request body is the raw file content, not XML.

That should cover all the common causes of these errors. Start with direct S3 testing to narrow down the problem, then work through the CloudFront configuration and signature checks.

内容的提问来源于stack exchange，提问作者Ultra S