Resizing on the fly. Think of an API that gets an image and desired resolution and sends it. It's a common enough use case. Compare Lambda as the entry point of this API compared to another framework.
Any other webserver is simply get image off S3->Resize it->Send raw binary data to the user (and optionally cache the resized image if you think it'll be requested in that size again).
The Lambda flow is as follows. Get image off S3->Resize it->upload to S3 and then redirect the user to that image via a cloudfront URL.
Unnecessary steps caused by the inability of Lambda get binary data out through the API Gateway. Particularly from the users point of view. You double the number of requests they have to make to fetch images.
Oh. Yeah, that's not a good use case for lambda. Resizing images, sure, but not handling requests like that
Lambda is great for running code in response to events (like SNS messages or S3 file uploads), but I really don't think it should be used for something like handling web requests. Just because you _can_ do something with a million steps and configuring 50 AWS services together, doesn't mean you _should_.
Except that on S3 upload there will be only three attempts to execute Lambda, and then it will give up. I can easily imagine a simple outage that will lead to three errors in a row, and the S3 files goes unaccounted.
You're far better of sending out an SNS or an SQS triggered by an S3 object creation event.
Any other webserver is simply get image off S3->Resize it->Send raw binary data to the user (and optionally cache the resized image if you think it'll be requested in that size again).
The Lambda flow is as follows. Get image off S3->Resize it->upload to S3 and then redirect the user to that image via a cloudfront URL.
Unnecessary steps caused by the inability of Lambda get binary data out through the API Gateway. Particularly from the users point of view. You double the number of requests they have to make to fetch images.