Если у вас активно используется #AWS_Organizations, то стоит задуматься над тем, чтобы прописать пароли у root-юзеров в созданных суб-аккаунтах (что не часто делается, особенно если они создаются автоматически).

Указание фейковой почты для #root_user уязвимо с точки зрения безопасности. Лучшей практикой является установка пароля для рута и включение #MFA на какое-то условно защищённое устройство (и, к примеру, помещённое в сейф).

Кроме того не стоит забывать, что Амазон шлёт некоторые важные (в т.ч. критические - взлом и т.п.) #notifications на почту root-юзера. Это можно в некоторой мере решить, указав Alternate Contacts в настройках аккаунта, однако некоторые сервисы (если не ошибаюсь, #SES), могут слать notifications лишь на рут-почту.

#security #best_practices

В продолжение темы защиты #root_user — для особо опасливых можно посоветовать накрыть всё это дело сверху #SCP политикой для #AWS_Organizations, запрещающей работу из-под рута.

{
  "Effect": "Deny",
  "Action": "*",
  "Resource": "*",
  "Condition": {
    "StringLike": {
      "aws:PrincipalARN": "arn:aws:iam::*:root"
    }
  }
}

Правда некоторые сервисы под капотом используют (требуют) рута, потому стоит протестировать на чём-то неважном (возможно разбанить нужные сервисы, требующие root).

#paranoid #security

Некоторые операции в AWS консоли требуют именно рута (т.е. нужно логиниться как #root_user). Чтобы не гуглить в поисках объяснения, почему у вас в консоли нет какой-то вещи, в то время, как в документации или какой-то статье она есть, то стоит периодически заходить сюда:

https://docs.aws.amazon.com/general/latest/gr/aws_tasks-that-require-root.html

Например, это будет полезно, если вы вдруг захотите включить мегазащиту MFA Delete на свой бакет с нажитыми за долгие годы бесценными логами или срочно потребуется посмотреть в консоли Account Canonical User ID (он же #s3_canonical) — всё это также должно делаться из-под рута.