You've discovered what many other people have: The cloud is the new time-share mainframe.

Programming in the 1960s to 80s was like this too. You'd develop some program in isolation, unable to properly run it. You "submit" it to the system, and it would be scheduled to run along with other workloads. You'd get a printout of the results back hours later, or even tomorrow. Rinse and repeat.

This work loop is incredibly inefficient, and was replaced by development that happened entirely locally on a workstation. This dramatically tightened the edit-compile-debug loop, down to seconds or at most minutes. Productivity skyrocketed, and most enterprises shifted the majority of their workload away from mainframes.

Now, in the 2020s, mainframes are back! They're just called "the cloud" now, but not much of their essential nature has changed other than the vendor name.

The cloud, just like mainframes:

- Does not provide all-local workstations. The only full-fidelity platform is the shared server.

- Is closed source. Only Amazon provides AWS. Only Microsoft provides Azure. Only Google provides GCP. You can't peer into their source code, it is all proprietary and even secret.

- Has a poor debugging experience. Shared platforms can't generally allow "invasive" debugging for security reasons. Their sheer size and complexity will mean that your visibility will always be limited. You'll never been able to get a stack trace that crosses into the internal calls of the platform services like S3 or Lambda. Contrast this with typical debugging where you can even trace into the OS kernel if you so choose.

- Are generally based on the "print the logs out" feedback mechanism, with all the usual issues of mainframes such as hours-long delays.

While that’s generally true, the inputs and outputs and execution environment that you can count on is well-documented on AWS Lambda. That means that recreation of execution environment for the function in question is pretty reasonable locally (why is this not a thing then Amazon?!?). For the rest of AWS, you can either get credentials in place for access or mock those out somehow, but that’s not officially supported either.

I feel like the service is leaving a bunch of easy work on the table that would let people have a local development process that mirrors the remote development reality.

It is a thing; unfortunately it's not officially supported but I also find it crazy that so many developers are fine doing dev directly on "the cloud", as if that's a reasonable use of their time.

https://github.com/lambci/docker-lambda

https://github.com/localstack/localstack