AWS Core Services: IAM Fundamentals

Amazon Identity and Access Management (IAM) forms the foundation of security within AWS, controlling who can access your cloud resources and what actions they can perform. Think of IAM as the gatekeeper to your AWS environment, managing every request to your services. With IAM handling over 1.2 billion API calls per second globally^[1], understanding how to configure it properly isn’t just best practice; it’s essential for maintaining a secure cloud infrastructure.

Understanding IAM Core Components

At its heart, IAM operates as a role-based access control (RBAC) system^[2], where access is granted based on identities and their associated permissions. Let’s break down the fundamental building blocks.

Users

An IAM user represents a person or application that interacts with AWS services. Each user possesses long-term credentials, typically consisting of a username and password for console access, plus access keys (an access key ID and secret access key) for programmatic access via the API or CLI^[3]. However, modern AWS security practices strongly discourage relying on long-term credentials for routine operations.

Consider a development team member who needs to deploy applications to EC2 instances. Rather than sharing root account credentials, you’d create an IAM user with specific permissions tailored to their responsibilities.

Groups

Groups simplify permission management by allowing you to assign common permissions to multiple users simultaneously^[4]. Instead of configuring permissions individually for each team member, you can create groups like ‘Developers’, ‘Database Administrators’, or ‘Security Auditors’, attach policies to these groups, and then add users as members.

For example, your database team might need access to RDS and DynamoDB. Rather than attaching these permissions to five individual users, you’d create a ‘Database-Team’ group with the necessary policies and add all team members to it. When someone joins or leaves the team, you simply adjust group membership.

Roles

Roles differ fundamentally from users because they’re not associated with specific people or long-term credentials^[5]. Instead, roles are meant to be assumed temporarily by trusted entities, whether that’s an IAM user, an AWS service like EC2, or even users from another AWS account.

When you assume a role, AWS Security Token Service (STS) provides temporary security credentials that automatically expire^[6]. This approach is far more secure than embedding long-term access keys in applications. For instance, an EC2 instance running your web application can assume a role to access an S3 bucket, receiving temporary credentials that rotate automatically without requiring any code changes.

Policies

Policies are JSON documents that define permissions. They specify the effect (allow or deny), the actions that can be performed, and the resources those actions apply to^[7]. Every request to AWS is evaluated against applicable policies to determine whether it should be permitted.

Policies come in two main flavours: identity-based policies, which attach to users, groups, or roles, and resource-based policies, which attach directly to resources like S3 buckets. There are also AWS-managed policies (maintained by AWS for common scenarios) and customer-managed policies (custom policies you create for specific requirements).

Temporary Security Credentials with AWS STS

AWS Security Token Service (STS) generates temporary, limited-privilege credentials that control access to your resources^[8]. These credentials consist of three components: an access key ID, a secret access key, and a session token. Unlike permanent credentials, these expire automatically after a configurable duration, ranging from 15 minutes to 12 hours^[9].

Temporary credentials shine in several scenarios. For cross-account access, users in one AWS account can assume roles in another account without needing permanent credentials there. For federated access, users can authenticate through your organisation’s existing identity provider, then receive temporary AWS credentials. And for applications, services can request credentials on demand rather than having long-term keys embedded in configuration files.

The workflow is straightforward. An entity requests temporary credentials through an STS API operation like AssumeRole. AWS STS validates the request against the role’s trust policy, then generates and returns temporary credentials if authorised^[10]. The requesting entity uses these credentials to access AWS resources until they expire.

IAM Access Analyzer: Provable Security

IAM Access Analyzer uses automated reasoning, a mathematical technique, to analyse permissions and verify who can access your resources^[11]. This capability has expanded significantly in 2025.

The tool now offers three key capabilities. External access analysis shows which resources can be accessed outside your AWS organisation, helping you identify unintended public exposure. Unused access analysis identifies permissions, roles, and access keys that haven’t been used, allowing you to refine permissions toward least privilege^[12]. The newest feature, internal access analysis, uses automated reasoning to determine which principals within your organisation can access critical resources like S3 buckets and DynamoDB tables, evaluating multiple policy types including service control policies and resource control policies^[13].

This isn’t just pattern matching or heuristics. The engine constructs mathematical proofs about whether access paths exist, providing definitive answers rather than educated guesses.

Multi-Factor Authentication Requirements

As of June 2025, AWS now enforces MFA for root users across all account types, making it the first cloud provider to mandate this protection^[14]. This prevents over 99% of password-related attacks^[15]. AWS supports various MFA methods, including FIDO-certified security keys and FIDO2 passkeys, with up to eight MFA devices registrable per root or IAM user.

MFA adds an essential security layer. Even if an attacker compromises a password, they cannot access the account without the second authentication factor. For programmatic access, you can use the GetSessionToken API operation, which requires an MFA code and returns temporary credentials that respect MFA requirements.

Best Practices for IAM Security

Implementing IAM correctly requires following established security principles. The principle of least privilege means granting only the permissions absolutely necessary to perform specific tasks^[16]. Start with minimal permissions and incrementally add what’s needed, rather than beginning with broad access and attempting to restrict it later.

Never use your root user for everyday tasks^[17]. The root user has unrestricted access to everything in your account. Configure MFA on it, then create IAM users or roles for daily operations. For account management tasks that previously required root access, AWS now allows authorised IAM principals to manage account names and other account-level configurations^[18].

Prefer roles over users wherever possible. Roles provide temporary credentials that automatically expire and don’t require manual rotation^[19]. For EC2 instances, attach IAM roles (instance profiles) rather than embedding access keys in applications. For cross-account access, assume roles rather than creating users in multiple accounts.

Leverage groups for permission management at scale. Assigning policies to individual users quickly becomes unmanageable as your organisation grows. Group users by job function, attach policies to groups, and manage access through group membership.

Use Service Control Policies (SCPs) when managing multiple accounts with AWS Organisations^[20]. SCPs establish permission guardrails across all accounts, preventing actions even if an IAM policy would otherwise allow them. Recently, AWS brought SCPs to full parity with IAM policy capabilities, including support for conditions and NotResource elements^[21], making it easier to implement clean, intuitive access controls across your organisation.

Regularly audit your permissions using IAM Access Analyzer and last accessed information. Remove unused permissions, delete inactive users, and rotate access keys at least every 90 days if you must use them^[22]. AWS CloudTrail logs every IAM API call, providing visibility into who’s doing what in your environment.

For applications requiring complex permission scenarios, consider attribute-based access control (ABAC) using tags. This allows permissions to scale with your resources without constantly updating policies. For example, you could grant developers access to any EC2 instance tagged with their team name, and new instances would automatically be accessible when tagged appropriately.

IAM Policy Language Enhancements

IAM policies have grown more expressive. You can now use wildcards at the beginning or middle of action strings, making policies more concise when covering service actions that follow patterns. Conditions in Allow statements let you grant permissions contextually, such as limiting actions to specific regions or requiring certain resource tags^[23].

When crafting policies, validate them before deployment. IAM Access Analyzer offers custom policy checks that can be embedded in CI/CD pipelines^[24], allowing developers to verify policies meet your organisation’s security standards before they’re deployed. This shifts security left, catching issues during development rather than after deployment.

Real-World Implementation Patterns

Let’s consider practical scenarios. For a web application on EC2 that needs to read from S3 and write to DynamoDB, you’d create a role with policies granting s3:GetObject on specific buckets and dynamodb:PutItem on specific tables. The EC2 launch configuration would specify this role, and the application would automatically receive temporary credentials through the instance metadata service.

For developers who need access to multiple AWS accounts (development, staging, production), you’d create roles in each account with trust relationships allowing users from your central identity account to assume them. Developers would assume different roles depending on which environment they’re working in, with more restrictive permissions in production.

For third-party integrations requiring AWS access, you’d create a role with an external ID in the trust policy. The external party would use their AWS account to assume your role, providing the external ID as proof of identity. This prevents the confused deputy problem where a third party might accidentally or maliciously access the wrong customer’s resources.

The Foundation of AWS Security

IAM serves as the foundational security layer for everything in AWS. Every API call, every resource access, every service interaction passes through IAM’s evaluation engine. Understanding how to architect your IAM configuration properly means understanding how to secure your entire AWS environment.

The service continues to evolve, with recent enhancements to Access Analyzer, SCPs, and account management showing AWS’s commitment to making security both more powerful and more manageable. As your AWS usage grows, investing time in properly structuring your IAM strategy pays dividends in security, compliance, and operational efficiency.

References