It's no secret that the rise of cloud computing transformed the market. Not long ago, companies had to provision and maintain their own on-premise infrastructure before they could bring products to market. The cloud changed that paradigm and enabled organisitations to significantly reduce their time-to-market and upfront capital expenses.
One of the most predominant cloud service providers is AWS, known for its wide range of powerful services that allow organizatiosn to deploy solutions globally in minutes.
Among AWS’s many services, Identity and Access Management (IAM) is one of the most critical ones as it controls who can access it and what actions they are allowed to perform.
Key IAM concepts
There are four fundamental concepts that within the IAM service that you should understand:
IAM User
IAM Users are individual user user accounts, similar to those you’d find on any website that requires a username and password for authentication. They represent specific people or applications that need direct access to AWS.
IAM Role
IAM Roles represent a set of permissions associated with a specific function, for example, an Administrator or Security Engineer role. These roles define what actions an entity can perform.
IAM Policy
IAM Policies are documents written in JSON that explicitly define which actions are allowed or denied for a given user or role. A single policy can be attached to multiple users or roles.
IAM Group
IAM Groups are simply a collection of IAM Users. It allows you to manage permissions for multiple users at once instead of assigning policies individually.
For instance, you could create a group called Developers and add all IAM users to it. Every member of the group will inherit the permissions defined in the policy attached to the group.
The Problem with IAM Users
As mentioned earlier, IAM Users function much like any standard user account, with a username and password used to log in to the AWS console. Additionally, each IAM User can have up to two Access Keys active at any given time. These keys, consisting of a public and private pair, allow users to interact with AWS programmatically through the AWS CLI or AWS SDKs.
For developers, this is often the easiest way to interact with AWS resources via code. However, there’s a major issue: both IAM user passwords and access keys are long-term credentials. They don’t expire by default unless the user or administrator rotates them manually.
This creates several security risks:
Long-Lived Credentials
The longer they remain active, the greater the chance they could be compromised or leaked.
In fact, leaked IAM access keys is one of the most common root causes of breaches.
Non-Compliance with Security Standards
Most security standards and benchmarks recommend rotating credentials every 90 days. Failing to do so can result in compliance violations during audits.
Lack of Proper Offboarding
If a user account is created directly in AWS (instead of through an Identity Provider), that account remains active even after an employee leaves the company, which means they could still log in later.
Lack of visibility in large organizations
IAM Users are local to each AWS account. In organizations with hundreds or thousands of accounts, tracking down a leaked access key or auditing active credentials becomes painful and time-consuming.
Each account manages its own users and permissions, so offboarding or permission updates must be repeated manually across accounts — an error-prone and inefficient process.
Inconsistent Access Control
When you use IAM Users, permissions are often added directly to individual accounts, which leads to inconsistent access patterns and policy sprawl.
Different users end up with slightly different permissions, making it difficult to enforce the principle of least privilege. Auditing who has what access becomes complex and slow.
Best practices
Always avoid IAM Users as much as you can and instead use IAM Roles, which rely on short-term credentials provided via AWS STS that are automatically rotated.
Whenever possible, consider configuring a federation between your Identity Provider (IdP) and IAM or AWS Identity Center, especially if your organization manages multiple AWS accounts.
This approach not only improves security but also simplifies access management across teams and environments and increases visibility into the location of your IAM users across the AWS organization.
In summary
While IAM Users may seem convenient, they can expose your AWS environment to unnecessary risk if used improperly. By adopting IAM Roles and federated access, you ensure your credentials are short-lived, your organization remains compliant, and your cloud environment stays secure.
Top comments (0)