Передовой практикой для ресурсов AWS, таких как EC2/Lambda/и т. д., является использование ролей IAM, подробно здесь. Короче говоря, вы не создаете пользователя для сервера, вы создаете роль, которую может принять служба, которая имеет набор разрешений, связанных с сервером EC2.
Этот сервер с ролью получает «временные» учетные данные, когда он работает, поэтому он может получить доступ к любой службе, разрешенной ролью IAM. Когда я говорю «временный», учетные данные, предоставляемые службе, недолговечны, может быть, 24 часа, но по истечении срока их действия выдаются новые учетные данные. Обычно это прозрачно, если только вы не пишете программное обеспечение, которое их использует, и в этом случае вам придется время от времени их проверять. Возможно, я не совсем точно уловил детали, но это более или менее правильно.
В AWS есть предопределенные политики, которые упрощают определение ролей.
Например, вы можете определить роль, в которой говорится: «Серверы EC2 с этой ролью могут передавать в SQS, извлекать из SQS, выполнять эту одну лямбда-функцию», и все, что не предоставлено явно, будет отклонено. Иногда требуется немного поэкспериментировать, чтобы получить необходимые разрешения. Наименьшие привилегии лучше всего, так что если ресурс, такой как сервер EC2, скомпрометирован, у него не будет прав администратора для AWS и он не сможет удалить все или сказать, чтобы начать крипто-майнинг.
Если вы работаете в крупной компании, выполняющей работу с AWS, я предлагаю вам пройти обучение по работе с AWS. Онлайн-обучение для AWS Architect Associate в таком месте, как Cloud Guru, — это необходимый минимум. AWS сложный. Я много лет работаю в AWS на постоянной основе, но каждый день узнаю что-то новое.
