I’d totally not expected anyone at Strapi to “recommend” this approach 
So I’ve given it a try since posting and so far it’s working pretty well. I’ve got about 8 endpoints that are hitting the MongoDB database on Atlas underneath, many of these are returning static content for a website.
So at the moment, because a single user will make multiple requests that request that static content, I’ve deployed a single lambda for primitive get requests, that has a basic router in there. The advantage of this is I can cache my MongoDB connection between invocations and reduce cold start times. If/when site traffic picks up I’ll split these functions back out. Also planning on using Gatsby or similar to pull out the static content from Strapi whenever it changes (using a Webhook to a GitHub pipeline) and that’ll reduce my dependency on this routing Lambda.
Regarding running Strapi locally - that works for me. But actually there’s someone else who needs access who isn’t as technical as me. So I’m planning on deploying Strapi to EC2 - but it’s going to sit in a turned off state by default. I’m planning on an API Gateway request triggering a Lambda to spin up the EC2 instance, and a redirect to the actual Strapi IP. This might take a couple of minutes, but that’s not a problem in this case. Hope to hack a similar spin down the EC2 lambda into the Logout of Strapi somehow - not worked that one out yet.
But basically I’ve got a site kinda working, costing me the price of an S3 bucket so far. So not too bad!