My company uses AWS for compute, storage, databases and more. However, they use the root key for access to everything and I'm trying to move away from that for security purposes. Any leak could result in catastrphic data leaks, or crippling bills from AWS. I'd like to prevent that as much as possible by permissioning keys (I know how to do that) and having keys auto expire after x weeks.

I've done a bit of exploration and haven't found something perfect. the closest I've found is the following. (We use Azure to authorize users to AWS) it's a tool that allows the aws cli access to aws by authorizing through azure: https://github.com/dtjohnson/aws-azure-login

The above gives us a daily authorization through the cli to access certain parts of AWS. However, that isn't exactly what we want. Management prefers longer expiry periods for convenience and we need actual keys to be able to use a tool like Cyberduck and to spin up instances in AWS, etc.

Is it possible to create keys by user that expire every X weeks and require a new request for a key?

DO NOT use an access key for your AWS account root user. Use IAM users for everyday interaction with AWS. Now that is out of the way...

Use Temporary Security Credentials

You can create IAM roles rather than users and generate temporary security credentials. These have an access key ID, a secret access key, and a security token that indicates when the credentials expire.

Normally access keys remain valid until you manually revoke them. However, temporary security credentials obtained through IAM roles and other features of the AWS Security Token Service expire after a short period of time.

In your example talking about Instances or CLI scripts rather than passing or embedding an access key to the application, define an IAM role that has appropriate permissions for your application and launch the Amazon EC2 instance with roles for EC2. This associates an IAM role with the Amazon EC2 instance and lets the application get temporary security credentials that it can in turn use to make calls. The CLI can get temporary credentials from the role automatically.

Root User

The root user should have MFA enabled, then have it locked away and never used. Never create access keys for the root user.

IAM Administrator

Create an IAM administrator user with MFA required that has full rights, including billing.

IAM Policy and Groups

Next create an IAM policy that gives users access to the services and functions they're allowed to use. The policy should mandate MFA has been used for all functions, other than being allowed into IAM to set up MFA. Attach this policy to a group. You can create as many policies and groups as you need. You can further lock things down with Service Control Policies if you see any benefit. You can do things like region enforcement and preventing use of expensive resources (e.g. GPU instances or RedShift / RDS) in either IAM or SCP.

Federation or IAM Users

Now either federate your account(s) to on-premise active directory, or create IAM users and add them to a group. Don't add policies to the users directly. These users can have access keys, but these are subject to MFA as well.

Outcome

All of this gives you good control of your account, lets you trace who did what (make sure Cloud Trail is enabled and the bucket is protected), reduces exposure to hackers increasing the bill, and probably other benefits too.