Hey there! Let's break down the most likely reasons your thumbnail generation function isn't working when you upload JPEGs to S3. Based on the setup steps you shared, here are the key areas to check:

1. Lambda Execution Role Permissions #

Lambda needs specific permissions to interact with S3 (both reading the original image and writing the thumbnail) and CloudWatch Logs (to help you debug). Make sure your function's execution role has these policies attached:

• AmazonS3FullAccess (or a more restrictive policy that allows s3:GetObject on your source bucket and s3:PutObject on your destination bucket)
• CloudWatchLogsFullAccess (to let you view error logs that reveal what's breaking)

Pro tip: Avoid full access in production—lock down permissions to only the buckets and actions your function actually needs.

2. S3 Event Trigger Configuration #

Double-check that your S3 bucket is actually triggering the Lambda function:

• Go to your S3 bucket > Properties > Event notifications
• Verify the trigger is enabled, set to fire on All object create events (or specifically Put events)
• Confirm prefix/suffix filters are correct (e.g., if you only want JPEGs, set the suffix to .jpg or .jpeg)
• Ensure the trigger is linked to the correct Lambda function

3. ZIP Packaging Mistakes #

Lambda expects your handler file (CreateThumbnail.js) to be at the root of the ZIP, not nested inside a parent folder. Here's the correct structure:

your-zip-file.zip
├── CreateThumbnail.js
└── node_modules/
    └── [all your installed dependencies]

If you zipped the main folder itself instead of its contents, Lambda won't find the handler. To fix this:

• Open your main folder, select CreateThumbnail.js and node_modules directly
• Zip those two items (not the parent folder)

4. Dependencies Compatibility #

If you're using image processing libraries like sharp or gm, they need to be compiled for Lambda's runtime environment (Amazon Linux 2). If you installed them on your local machine (especially Windows or macOS), the binaries won't work on Lambda.

Fix this by:

• Using a pre-built Lambda layer for the image library (AWS provides official layers for sharp)
• Or compiling dependencies in an Amazon Linux 2 environment (use Docker to mimic Lambda's runtime)

5. Handler Code Bugs #

Check your CreateThumbnail.js for common issues:

• Ensure the handler function is correctly exported (e.g., exports.handler = async (event) => { ... })
• Verify you're parsing the S3 event correctly to get the source bucket and object key
• Add explicit checks for JPEG files (validate file extensions or MIME type image/jpeg)
• Include console.error() statements to log errors—this will show up in CloudWatch and tell you exactly where things fail

6. Runtime Version Mismatch #

Confirm your Lambda function uses the same Node.js runtime version you used to install dependencies. For example, if you installed sharp for Node.js 18.x, your Lambda should run on Node.js 18.x.

Final Debugging Step #

If you're still stuck, check the CloudWatch Logs for your Lambda function:

• Go to your Lambda function > Monitor > Logs > Log groups
• Look for recent log streams and scan for error messages (like permission denied, missing dependencies, or invalid image processing logic)

These logs are your best tool for pinpointing the exact issue—don't skip checking them!

内容的提问来源于stack exchange，提问作者Wai Yan Hein