We close the IAM chapter with a practical list of best practices: the things you should always do to keep your AWS account secure. Consider it your security checklist. Many of these we have already seen throughout the chapter; here we bring them together and organize them so you can apply them from day one.

The root user (the email you used to create the account) has absolute power. It is your most sensitive asset.

• Enable MFA on the root immediately (subchapter 7.4).
• Do not generate access keys for the root. If it has them, delete them.
• Do not use it for day-to-day tasks. Create an IAM administrator user for your work.
• Store its credentials in a very secure place and use it only for the few tasks that strictly require it (such as closing the account or changing the support plan).

This is the number one practice. A compromised root account is a completely lost account.

• MFA on the root (mandatory).
• MFA on all users with relevant permissions, especially administrators.
• For companies, consider enforcing MFA by policy (so nothing sensitive can be done without it).

The principle from subchapter 7.2, in concrete actions:

• Grant only the necessary permissions, not AdministratorAccess for convenience.
• Be specific with actions and resources.
• Review periodically and remove permissions that are no longer used.
• Use IAM Access Analyzer (a free AWS tool) to detect excessive permissions or unintended external access.

• Do not attach policies user by user. Create groups by function (Developers, Administrators, Support…) and assign permissions to the group.
• Adding or removing someone is as simple as putting them in or taking them out of the group.
• Easier to maintain and less prone to errors.

• Never embed access keys inside an EC2 instance, a Lambda, or your application code.
• Assign a role with just the right permissions (subchapters 7.1 and 7.4). The service obtains temporary credentials automatically, with no keys to steal.
• This also applies to your CI/CD pipeline and tools like Terraform.

• Prefer temporary credentials (STS / roles) whenever possible.
• If you need permanent keys for a person, rotate them regularly (change them every so often).
• Never upload keys to a Git repository. Use a secrets manager (Chapter 23) and tools that detect keys in code before uploading.
• Deactivate keys that are not used.

Reminder of the real danger: bots scan GitHub looking for leaked keys and exploit them in seconds. A leaked permanent key with many permissions can cost you thousands of euros. Treat keys like passwords: secret, rotated, and minimal.

• Define a password policy in your account: minimum length, mix of characters, reasonable expiration, no reuse.
• Encourage the use of password managers.

You can’t protect what you can’t see. Enable logging of who does what:

• AWS CloudTrail: logs all actions performed in your account (who, what, when). It’s your “security camera.” Essential and you should enable it from the start.
• CloudWatch (Chapter 24) for alarms on suspicious activity.
• GuardDuty (Chapter 23) for automatic threat detection.

We’ll see these tools in Part VI; for now, remember that auditing is part of security.

• For multiple people or multiple accounts, use AWS IAM Identity Center (formerly AWS SSO): centralized access, with temporary credentials and MFA, without creating IAM users one by one.
• In large environments, combine with AWS Organizations and Service Control Policies (Chapters 23 and 30) to set limits at the organization level.

Your minimum IAM security list from day one:

Tip: Set this up when creating the account, before you start building anything. It’s much easier to start from a secure base than to “fix security later.”

• Protect the root (MFA, no keys, don’t use it daily): it’s the number one priority.
• MFA everywhere and least privilege always.
• Groups for people, roles for services; avoid permanent keys and never upload them to Git.
• Audit with CloudTrail from the start: visibility is part of security.
• For teams and multi-account, centralize with IAM Identity Center and Organizations.
• Apply the checklist when creating the account, not after.

With this, you finish Chapter 7 and master identity and access. In Chapter 8, the last of the essential services, we’ll look at AWS’s managed databases.