Storing AWS access/secret keys, or role policies; which should be stored in vault?

Question

So I'm running into a strange architectural issue involving vault, and I'm throwing it out to the web because I don't think how we're proposing to do it is correct

Currently we have quite a few users for gitlab pipelines, where we save their access/secret keys in env variables for use by our pipelines. WE in turn cycle the access/secrets of every user every 90 days, with the values stored in keeper for use if needed. as you can guess, it's tedious.

So I was conversing with the person that's been put in charge of being our vault admin, on how we can have it where vault can store the access/secret keys for each of our pipeline users when they're updated every ninety days, presumably through a lambda function or pipeline. Instead there's already a plan in place where each role will have their policies stored in vault (even though there's a character limit that we do hit with some of our policies), and then the pipelines will call the roles that way instead. I'm not really understanding why we're doing it that way instead of just doing a k/v access/secret storage setup, as it feels like we're duplicating data in both vault and aws. trying to have it explained was like trying to watch a tv program in another language. I'm wondering if anyone else here could possibly shed some light as to why they'd want to do it that way, and why it would be better?