Best practice for AWS resources such as EC2 / Lambda / etc is to use IAM roles, detailed here. In short you don't create a user for a server, you create a role that the service can assume that has a set of permissions which is associated with the EC2 server.
That server with a role is given "temporary" credentials when it's running so it can access any service that the IAM role permits. When I say "temporary", the credentials give to the service are short lived, maybe 24 hours, but when they expire new credentials are issued. This is usually transparent, unless you're writing software that uses them, in which case you have to check them occasionally. I might not have the fine details quite right there, but it's more or less correct.
AWS has predefined policies which can make defining roles easier.
For example, you can define role that says "EC2 servers with this role can push to SQS, pull from SQS, execute this one lambda function" and anything not explicitly granted is denied. Sometimes it takes a bit of experimenting to get the permissions you need worked out. Least privilege is best so that if a resource like EC2 server is compromised it doesn't have admin rights to AWS and can't delete everything or say start crypto mining.
If you're working in a large company doing AWS work I suggest you get some AWS training. Online training for AWS Architect Associate with a place like Cloud Guru is a minimum you'd need. AWS is complex. I've been working in AWS full time for years, but I learn something new every day.
