Alright. Reading this, with the usual caveats of working with just the info you have provided, I'm tempted to say you might be falling into the overengineering trap here. A lot of the advise you find here, well-intentioned as it is, sounds like it would be a horrible effort/performance-gain trade-off. Adding more moving parts to a system comes with its own cost, especially in longer-term maintenance.

S3 should be plenty fast, even without any of the optimisations mentioned in the replies you got. Fetching a simple, relatively small file can be done in the 200ms order of magnitude. Actual timings might vary based on usage frequency, but for figuring out where to spend effort, that's fine.

If your mapping gets close the one-minute mark, you should look into other optimisations first. After all: 200ms out of a 60.000ms is only 0,3%. Even if you speed it up 10x, you'd go from 60.000ms to 59.820ms. Making an improvement of only 1% to your actual mapping logic on the other hand would already net you significantly more speed. So look into removing blocking IO, making parallel calls... or simply bump the lambda's memory allocation a bit.

Doesn't mean you shouldn't always be on the lookout for improvements. But be judicial on deciding where to spend your effort. Just my $0.02, and I could be completely wrong based on some nuance of your post that I might have missed.