Lambda@Edge isn't quite a fit for image resizing, at this point. It is intended for more lightweight tasks, like header manipulation and small text-based response generation.
In Lambda@Edge, the deployment zip file is limited to 1 MiB, the container memory is limited to 128 MiB, the runtime is limited to 1 sec on the viewer side and 3 sec on the origin side, and although the available CPU capacity is not explicitly published it is some fraction of the capacity of 1 modern 2.3-2.4 GHz Xeon core. It's sufficient for sub-millisecond header rewrites, but not image resizing.
Now that Lambda@Edge has the ability to inspect the query string, it's conceivable that you could use it, instead of API Gateway, to invoke the second Lambda function that actually does the resize (invoke Lambda from Lambda) then convert the response from the API Gateway format into the CloudFront format, so the cost per invocation would potentially be lower (since a Lambda@Edge request costs less than an API Gateway request)... but it's not a direct substitute for what API Gateway + Lambda are doing in the established example. You would do this with an Origin Request trigger.
Lambda@Edge also can't return generated binary content (only UTF-8 character content), though that is not directly relevant to the resize example as implemented, since redirects are used to send the browser to the new target object.
It's very useful but not fully equivalent to API Gateway + Lambda.
