It turns out Travis CI supports deploying directly to AWS Lambda: something I should have checked before doing any of the messy configuration with specifying IAM user policies for accessing an S3 bucket containing code. The disheartening part: Lambda almost certainly uses S3 under the covers anyway.
Unfortunately, it's looking like deploying to Lambda isn't as easy as I would have hoped, and deploying to S3 may have been the better option: I'm running into this error whenever Travis attempts to deploy:
Funnily enough, the "role" value it's marking as invalid is copy-pasted straight from the documentation. I'm convinced it's a false error message hiding the real problem, since I'm pretty sure that the value DOES match the regular expression shown.
I'm undecided at this point whether I should revert to using S3, or persist trying to fix the Lambda deploy. Annoyingly, I already deleted my IAM user and S3 bucket, so I'll have to go through the motions again in order to get anything working.
It's getting incredibly confusing, the sheer number of options available. I'm shying away from using the "Serverless" framework, as I want to learn how to architect basic serverless systems myself. But it just seems impossible to get anything done by using tools the way they're designed: I can't use Travis to deploy to Lambda because of that Ruby error above in DPL; I can't use Python 3.X on Lambda without literally using my own binaries; I can't use a non-zipped directory on S3 as the code for a Lambda handler; and about a million other things just don't seem to work quite right.
It's looking like the best option is to write my own deployment script. I might use the dpl script that Travis uses behind-the-scenes, or equally I might just use the AWS CLI to put a zipped deployment package into my code bucket.
I don't know what it is about infrastructure stuff like this, but I always dive into it thinking it's going to be easy, and I spend a whole day tearing my hair out before realising that nothing is as easy as it seems.