AWS Lambda与S3触发异常求助（Terraform部署）

Oh yeah, I’ve dealt with this exact head-scratcher multiple times when setting up S3-to-Lambda triggers via Terraform. That first upload where nothing happens is so frustrating, but there’s almost always a clear root cause—and ways to dig into the history to confirm it.

Common Reasons for Initial Trigger Failures #

• IAM Permission Propagation Delay: Terraform often provisions S3 buckets, Lambda functions, and their associated IAM policies in parallel. But AWS IAM permissions can take a few seconds (or even minutes) to fully propagate across regions. If S3 tries to invoke Lambda before the permissions are active, the notification gets dropped silently.
• Mismatched Event Filters: Double-check your Terraform event filter configuration. If you specified a prefix or suffix (like .xml), even a tiny mismatch (e.g., .XML instead of .xml—S3 filters are case-sensitive!) will prevent triggers from firing.
• Lambda Cold Start/Throttling: Rare, but possible—if your Lambda has zero reserved concurrency, the first invocation might hit a throttle during cold start. You’ll usually see this in CloudWatch logs, though.

How to Audit S3 Uploads & Event Delivery History #

You’ve got a few tools to trace exactly what’s happening:

• S3 Server Access Logs: Enable these for your bucket (point logs to a separate S3 bucket to avoid recursive logging). These logs will show every PUT request (your file uploads) and S3’s attempts to send event notifications. Look for entries with x-amz-event-id—if you see a 403 status code next to those, that’s a permission issue.
• AWS CloudTrail: CloudTrail logs all AWS API calls. Search for your bucket’s ARN to find:
  • The PutObject event that corresponds to your file upload
  • Any Invoke API calls from S3 to your Lambda function
    If you see an AccessDenied error on the Invoke call, that’s your smoking gun for IAM issues.
• Lambda CloudWatch Logs: Even if the function doesn’t execute, check its CloudWatch Log group. Sometimes you’ll find error logs about missing permissions or invalid payloads that explain the failure.
• S3 Event Delivery Status: In the S3 console, go to your event notification configuration and check the "Delivery status" tab (if you enabled it). This will show success/failure counts and detailed error messages for failed deliveries.

Fixes to Get Triggers Working Immediately #

• Enforce Terraform Dependencies: Add an explicit dependency to ensure your S3 notification is created only after the Lambda permission is ready. In your aws_s3_bucket_notification resource, add:

  depends_on = [aws_lambda_permission.s3_invoke_lambda]
  

  This prevents Terraform from configuring the notification before the IAM policy is fully set up.
• Validate Event Filters: Double-check your filter rules. For example:

  filter {
    suffix = ".xml" # Confirm this matches your file's actual extension (case-sensitive!)
  }
  

• Force a Notification Refresh: As you noticed, just opening the event notification in the S3 console and saving it (without changes) often fixes the issue. This forces S3 to refresh its cache of the notification configuration.
• Verify Lambda Resource Policy: Ensure your aws_lambda_permission is correctly scoped to your bucket. It should look something like this:

  resource "aws_lambda_permission" "s3_invoke_lambda" {
    statement_id  = "AllowS3BucketInvoke"
    action        = "lambda:InvokeFunction"
    function_name = aws_lambda_function.your_xml_processor.function_name
    principal     = "s3.amazonaws.com"
    source_arn    = aws_s3_bucket.your_xml_bucket.arn
  }
  

  Confirm the source_arn is exactly your bucket’s ARN—no typos!

Most of the time, this boils down to AWS’s eventual consistency or Terraform’s parallel provisioning. Checking the logs will quickly narrow down the issue, and adding the dependency usually prevents the problem from happening in future deployments.

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