One idea is to remove the CreateLogGroup permission from the lambda. That way it won't be able to create unlimited retention log groups in arbitrary regions. Note you'll also want to remove the AWSLambdaBasicExecutionRole - it has permissions to create log groups (and conflicts with the lambda-edge-cloudwatch-logs policy).

One idea is to remove the CreateLogGroup permission from the lambda.

I'm aware of this trick but I think it's a poor substitute (on AWS' part) for not having better configurability of the automatic log groups used by Lambdas. As the name of the group and the region the groups will be created in is known, this can be anticipated and configured ahead of time - it's just the hell of figuring out a method of doing this that doesn't require the user to pass 17 different providers to the module (I'm not even inflating that number!) to do the thing in each region.

Yeah, exactly. Terraform doesn't exactly make this easy, either. On the balance, it's probably better to have no logs for the redirect service (are they even useful outside of test and dev?) than infinite retention logs, at least by my reckoning.

It's a fair point. I've seen ever-growing Cloudwatch log groups getting into the 100s of GBs because they were left unconfigured. :( It's a growing cost over time which is the antithesis of this set-up. I'll think about it, worst case it's another configurable flag 🤔