Authentication and Authorization (IAM)
Identity and Access Management (IAM) controls who can access AWS resources and what actions they can perform. Understanding IAM users, groups, roles, and JSON-based policies is essential for securing AWS environments and enforcing least privilege access.
Authentication vs Authorization
Authentication answers the question: “Who are you?” Authorization answers the question: “What are you allowed to do?”
In AWS, IAM is the service that enforces both. When a person or service attempts to access an AWS resource, IAM first verifies identity. Then it evaluates policies to determine whether the requested action is permitted.
This two-step model applies to every API call made in AWS. Whether launching an EC2 instance or reading from an S3 bucket, access is always evaluated against IAM policies.
IAM Users
An IAM user represents a specific person or application that requires long-term access to AWS. Each IAM user has unique credentials, such as a password for console access or access keys for programmatic access.
IAM users are typically created for employees who need direct interaction with AWS services. For example, a developer may require permissions to launch EC2 instances and manage S3 buckets.
Users can be assigned permissions directly through policies. However, managing permissions individually does not scale well in larger environments.
Note: User management must remain structured and consistent.
IAM Groups
IAM groups simplify permission management by organizing users with similar responsibilities. Instead of assigning permissions to each user individually, permissions are attached to a group. For example, a “Developers” group may have permissions to deploy EC2 instances and access development S3 buckets. A “Finance” group may have access only to billing dashboards.
When a new developer joins the organization, the administrator adds them to the Developers group. They automatically inherit the group’s permissions.
Groups do not contain credentials. They exist solely to manage permissions efficiently. If a user changes roles within the organization, removing them from one group and adding them to another adjusts permissions accordingly. This structured approach ensures IAM remains clear, maintainable, and capable of scaling with organizational growth.
This model reduces administrative overhead and supports the principle of least privilege.
Best Practice: Directly attaching permissions to users increases complexity and risk of inconsistent access control. Group-based permission management ensures standardized access patterns.
IAM Roles
IAM roles differ from users. A role does not represent a person. Instead, it defines a set of permissions that can be assumed temporarily.
Roles are used when AWS services need to interact with other AWS services securely. For example, an EC2 instance may need permission to read data from an S3 bucket.
Instead of embedding access keys inside the instance, you assign an IAM role to the EC2 instance. The instance then receives temporary credentials automatically. This eliminates the need to store long-term credentials in application code and enable secure service-to-service communication.
The “Hat” Analogy for IAM Roles
An IAM role can be understood as a “hat” containing permissions. When a user or service assumes a role, it temporarily “wears the hat” and gains the permissions defined within it.
When the session ends, the permissions are no longer active. For example, an EC2 instance running an application may assume a role that grants permission to access specific S3 objects. The instance does not permanently store credentials. Instead, AWS provides temporary credentials tied to the role, reducing risk by eliminating hardcoded secrets and minimizing exposure compared to static credentials.
Roles are commonly used for:
- EC2 instances accessing S3
- Lambda functions writing to DynamoDB
- Applications interacting with RDS
- Cross-account access scenarios
When a service assumes a role, AWS Security Token Service (STS) provides temporary credentials. These credentials expire automatically and are rotated by AWS.
This design enforces secure access patterns and reduces credential management overhead.
Defining Permissions as Code
In AWS IAM permissions are defined using JSON policy documents. These policies specify allowed or denied actions on AWS resources.
A basic policy includes statements that define:
- Effect (Allow or Deny)
- Action (such as s3:GetObject)
- Resource (such as a specific S3 bucket ARN)
Policies can be attached to users, groups, or roles.
For example, the following policy allows a user, group, or role to read objects from a specific S3 bucket.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::my-sample-bucket/*"
}
]
}
Because IAM policies are written in JSON, each permission is explicitly defined with structured keys like Effect, Action, and Resource. This makes it easy to see exactly what is allowed or denied, leaving no ambiguity. Being text-based, JSON policies can be stored in version control systems, allowing changes to be tracked, reviewed, and audited over time. It also makes access control programmable, so policies can be automated, reused, and managed like application code.
End-to-End Access Evaluation
When a request is made in AWS, IAM evaluates all applicable policies. This includes identity-based policies attached to users, groups, or roles, and resource-based policies attached directly to services like S3.
If any explicit deny exists, the request is denied. If an allow statement matches and no deny applies, the request succeeds. This evaluation logic ensures predictable access control outcomes. Understanding this evaluation process clarifies why certain requests fail.
Key takeaway: For foundational AWS understanding, recognize that every AWS action is controlled by IAM. Whether accessing billing dashboards or launching infrastructure, permissions determine capability.
My name is Naeem ul Haq. I’ve been working with AWS since its early days and have deep expertise across its evolving ecosystem.
