For S3 you do need to generate a presigned URL, so you would have to add this logic there somewhere instead of "just having a generic HTTP upload endpoint".
Unless the solution is "don't have the problem in the first place" the cloud limitations are just getting in the way here.
The solution is to use the appropriate tool for the job. If you're locked in to highly crusty legacy software, it's inevitably going to require workarounds. There are good technical reasons why arbitrary-size single-part file uploads are now considered an anti-pattern. If you must support them, then don't be shocked if you wind up needing EC2 or other lower-level service as a point of ingress into your otherwise-serverless ecosystem.
If we want to treat the architectural peculiarities of GP's stack as an indictment of serverless in general, then we could just as well point to the limitations of running LAMP on a single machine as an indictment of servers in general (which obviously would be silly, since LAMP is still useful for some applications, as are bare metal servers).
We down play how trivial it is to generate a signed url, it’s only like a few lines and a function call to get but, you then have to send this to the client. The client has to then use this url, then check back with you to see if it arrived resulting in a kind of pea soup architecture unless your application is also entirely event driven. Oh how we get suckered in…
GP said this is an app from the 2000s.
For S3 you do need to generate a presigned URL, so you would have to add this logic there somewhere instead of "just having a generic HTTP upload endpoint".
Unless the solution is "don't have the problem in the first place" the cloud limitations are just getting in the way here.