The lambda developer experience is pretty awful. I generally put "main" methods in all my lambdas so I can test them locally, but otherwise hitting actual AWS APIs. I'm not a big fan of mocking. Doing any sort of edit/deploy cycle is way too slow.

I had great success with unit testing the lambda code and mocking external/aws services.

For serious software you want a proper local/unit test setup anyway. Using this in your dev cycles is just the natural next step. Instead of waiting for the cdk/cfn deploy to finish, which really is way too slow, you just execute 'jest' or whatever test framework you have.

Sure, figuring out how to mock everything takes some upfront time, but it pays off in the long run.

I always write a remote function as just "an async function that takes type A and returns type B" - then I can write tests for it very easily and run it locally, IF it doesn't use any AWS services like databases.

For deployment I have a generic "wrapper" that makes it lambda-compatible by converting a webEvent -> Json and my outputJSON -> web response event.

Some people cram their entire application into a single lambda. Others are a little better and have their application spread out amongst multiple lambdas.