Nice work 
And yes, it’s usually just some mistake in the code, misuse of an API, etc.
An uncaught error in the lambda function will be thrown out to the API gateway, which will wrap the error in a 500 response and send it back. But this implicit 500 response doesn’t have a CORS header, so when it gets to the browser, it fails the CORS check. The actual error message from lambda never gets to the browser.
It’s misleading, but from the browser’s perspective, it’s correct behaviour. If you make the request from, say, curl, you will find it doesn’t hit the CORS error, because CORS is not required in these cases (there is no other origin).
Some good ways to avoid this (not implying that you don’t do any or all of this): have well-structured, modular code; write unit and/or integration tests; automate as much as you can; and run functions locally. It’s much less expensive (on your time) to run something locally and have it spit an error straight back at you, than it is to deploy, then call the API, then check the remote logs, etc.
I’m actually wondering now, whether there is a fix for this in the API Gateway configuration, just by enabling CORS on the 500 response. And then how you would do that in serverless and/or cloud formation (i.e. via a serverless plugin). 