When you start learning about AWS Identity and Access Management (IAM), you'll encounter terms like IAM users, IAM roles, and IAM policies. The difference between IAM users and IAM roles is particularly easy to confuse.
An IAM user is a user ID on Amazon Web Services (AWS) that is associated with a person. You use a password to log in to the AWS Management Console, and an access key to operate from the AWS Command Line Interface (AWS CLI) or external tools.
On the other hand, IAM roles are a mechanism for associating permissions with AWS services such as Amazon EC2 and AWS Lambda, applications, and other entities that temporarily require permissions.
When accessing other AWS resources from one AWS service, the basic design principle is to use IAM roles rather than storing IAM user access keys on the server or in the code. This article explains the differences between IAM users and IAM roles, their relationship to IAM policies, and how to choose between them in different use cases.
IAM is a service that manages access to AWS resources. Both IAM users and IAM roles are involved in permission management, but they differ in the entity that uses those permissions.
An IAM user is a user ID on AWS that is associated with a person. It is used to log in to the AWS Management Console and to perform operations from the AWS CLI. On the other hand, an IAM role is a mechanism for associating temporary permissions with AWS services and applications that require permissions, such as Amazon EC2 and AWS Lambda.
Item | IAM users | IAM role |
Main target | People | AWS services, applications, and targets for which permissions are temporarily used. |
Authentication information | Password, access key | Temporary security credentials |
Main usage scenarios | Logging into the AWS Management Console, and performing operations from the AWS CLI. | Accessing Amazon S3 from Amazon EC2, and accessing Amazon DynamoDB from AWS Lambda. |
Notes | Access key management is required. | Designing the scope of permissions is necessary. |
The deciding factor for choosing between them is whether a human is performing the operation or whether an AWS service or application is using it in its processing. If a human is logging into AWS and performing operations, an IAM user is the preferred choice. If Amazon EC2, AWS Lambda, or other services are accessing other AWS resources, an IAM role is used.
IAM users are unique IDs created for each person using AWS, such as administrators, developers, and operations personnel. Passwords are used to log in to the AWS Management Console, while access keys are used when operating from the AWS CLI or external tools.
It's important to note that access keys remain as fixed authentication credentials. If they are leaked externally, there is a risk that a third party could manipulate your AWS resources. Avoid situations such as writing them directly into the source code, sharing them among multiple people, leaving unused keys, or operating with broad permissions.
While IAM users are easy to create, the more users you create, the more you need to manage. We manage them in a way that allows you to track their issuance destinations, permissions, and access key usage.
IAM roles are not identities fixed to a specific person. They are a mechanism for associating temporary security credentials with entities that require permissions, such as Amazon EC2, AWS Lambda, applications, or other AWS accounts.
For example, when reading files from Amazon S3 from Amazon EC2, you associate an IAM role with Amazon EC2. You don't need to store access keys within your application. Similarly, when accessing Amazon DynamoDB from AWS Lambda, you configure the necessary permissions for the execution role of your Lambda function.
IAM roles clearly define "which actions are permitted for which targets." If only reading Amazon S3 is sufficient, write and delete permissions are unnecessary. By limiting permissions to only the necessary operations, you can limit the scope of impact in the event of an error or misuse.
The choice between an IAM user and an IAM role depends on "who will be interacting with AWS" and "where the credentials will be managed." An IAM user is a suitable candidate when a person logs into the AWS Management Console. On the other hand, an IAM role is used when services such as Amazon EC2 or AWS Lambda access other AWS resources.
Storing access keys on servers or in code leaves open the risk of leaks and unattended security. When granting permissions to a service, first check if IAM roles can be used as an alternative.
IAM users are the preferred choice when people, such as administrators, developers, and operations personnel, interact with AWS. Passwords are used to log in to the AWS Management Console, while access keys are used to interact with AWS CLI and external tools.
However, creating an IAM user is not the end of the process. You must assign permissions to each user, set up multi-factor authentication (MFA), and delete users and access keys that are no longer needed. If users remain after a change in responsibilities or after an employee leaves the company, an unmanaged entry point will remain in the AWS environment.
When multiple people in a company use AWS, in addition to individually creating IAM users, consider using AWS IAM Identity Center. This allows for centralized management of login methods and permissions, even as the number of users increases.
When services such as Amazon EC2 and AWS Lambda access services like Amazon S3 and Amazon DynamoDB, IAM roles are used. You associate an IAM role with the service and grant it only the necessary permissions.
If your application on Amazon EC2 reads files from Amazon S3, you associate an IAM role with Amazon EC2. By selecting the role during instance creation or configuration changes, you eliminate the need to store access keys on the application side.
When writing data to Amazon DynamoDB from AWS Lambda, you also set an execution role for the Lambda function. This allows you to grant write permissions to the target table without writing access keys in the code.
The biggest reason to use IAM roles is that you don't need to leave fixed authentication information on the server or in the code.
Access keys are authentication credentials used when operating AWS from the AWS CLI or external tools. While convenient, mishandling them can lead to unauthorized access to your AWS environment.
Things to avoid include hardcoding keys into source code, sharing keys among multiple people, leaving unused keys unattended, and operating with excessively strong permissions. In particular, access keys that are used for a long period of time are more likely to remain after changes in personnel or operational procedures.
When using access keys, clearly define their purpose, users, and scope of permissions. Allow only the necessary operations and delete them when they are no longer needed. If the purpose is to access AWS resources from AWS services, check if an IAM role can be used as an alternative before issuing them.
IAM users and IAM roles are entities that are granted permissions. The actual operations they are allowed to perform are defined in IAM policies.
Operations such as reading files from Amazon S3, launching Amazon EC2 instances, and writing data to Amazon DynamoDB are determined by IAM policies. Simply creating IAM users or IAM roles does not allow you to manipulate AWS resources.
IAM policies are settings that describe the operations that are allowed on AWS resources. They are used to control things like allowing only specific buckets in Amazon S3 to be read, or allowing the start and stop of Amazon EC2 instances.
When considering permissions, we separate "who should have them" from "what they should be allowed to do." IAM users and IAM roles are the entities that are granted permissions, while IAM policies are the settings that determine the operations that those entities are allowed to perform.
Even when accessing Amazon S3, if a developer is operating from the AWS CLI, the policy is set for the IAM user. If accessing from an application on Amazon EC2, the policy is set for the IAM role associated with Amazon EC2. Even if the target of the operation is the same, the setting location changes depending on the entity using it.
IAM policies can be set for both IAM users and IAM roles. Setting a policy for an IAM user allows that user to perform permitted operations. Setting a policy for an IAM role allows AWS services and applications that utilize that role to perform those operations.
What you want to avoid is granting broad permissions when you're unsure. For operations that only require reading from Amazon S3, write and delete permissions are unnecessary. For operations that write data to Amazon DynamoDB, you should limit permissions to the target table and the necessary operations.
Development, operations, and monitoring require different operations. Whether using IAM users or IAM roles, first determine the purpose and then allow only that scope using IAM policies.
When granting permissions to AWS services, you use IAM roles rather than IAM user access keys. This is because you can associate the necessary permissions with the service itself, without leaving fixed authentication information on the server or in the code.
When accessing Amazon S3 from an application on Amazon EC2, it will work even if the access key is stored in the OS or application. However, if the key remains in source code, configuration files, shared folders, etc., there is a risk of leakage and misuse. In some cases, unused keys may be left behind after a change in personnel.
IAM roles allow you to associate the necessary permissions with execution environments such as Amazon EC2 and AWS Lambda. Since credentials are treated as temporary security credentials, there's no need to store fixed access keys long-term.
Access keys are authentication credentials used when interacting with AWS from the AWS CLI or external tools. While they may be necessary for human-operated applications, granting permissions to AWS services carries significant management risks.
To access Amazon S3 from Amazon EC2, associate an IAM role with Amazon EC2. By selecting the role during instance creation or configuration changes, you eliminate the need for your application to retain access keys.
In AWS Lambda, you also set an execution role for your function. Instead of writing access keys in the code, you access Amazon DynamoDB and other services using the permissions granted to the execution role.
IAM roles allow you to configure separate permissions for each service. If you only need to read files from Amazon S3 from Amazon EC2, you would limit permissions to read access to the target S3 bucket. Write and delete permissions are not required.
When writing data to Amazon DynamoDB from AWS Lambda, only allow the target table and the necessary operations. Granting permissions to operate on unrelated AWS services or resources will broaden the scope of impact in the event of an error or misuse.
The purpose of IAM roles is not just to bypass access keys. In permission management, the goal is not simply to "make things work," but to be able to explain "which services are allowed to perform which operations on which resources."
IAM users and IAM roles should be used differently depending on the situation. IAM roles are used when an AWS service accesses another AWS resource, while IAM users and access keys are used when a person or external tool interacts with AWS.
To access Amazon S3 from Amazon EC2, you use an IAM role.
If your application on Amazon EC2 reads files from Amazon S3, you need to associate an IAM role with your Amazon EC2 instance. When creating or modifying an instance, you select an IAM role and configure an IAM policy for that role to read the target S3 bucket.
In this configuration, access keys are not stored on the Amazon EC2 OS or in the application's configuration files. The application accesses Amazon S3 using the permissions of the IAM role associated with Amazon EC2.
What you want to avoid is a configuration where IAM user access keys are stored within Amazon EC2. If the keys are leaked or remain on the server after they are no longer needed, it can become an entry point for misuse.
When accessing Amazon DynamoDB from AWS Lambda, you also use IAM roles.
You configure an execution role for AWS Lambda. You then grant this execution role an IAM policy to access the target table in Amazon DynamoDB. For processes that only require reading, you restrict permissions to read only; for processes that require writing, you add write permissions.
You don't need to write access keys in your code. AWS Lambda accesses Amazon DynamoDB with the permissions of the configured execution role.
In a serverless configuration, the required permissions differ for each function. Functions for user registration, aggregation processing, and notification sending access AWS resources and perform different operations. Instead of granting all functions the same broad permissions, permissions are divided according to the processing content.
When developers or operations personnel log in to the AWS Management Console, IAM users are the preferred option. IAM users can have a password set for login and multi-factor authentication (MFA) can also be enabled.
However, even when a person is operating AWS, they don't always grant permissions directly to an IAM user. When dealing with multiple AWS accounts, or when you want to separate normal permissions from administrator permissions, you might use a switch role to temporarily switch to a different IAM role.
Switching roles allows the logged-in user to switch to an authorized IAM role and operate AWS resources with the permissions set for that role. The permissions of the original user and the switched role are not combined. Once the work is done, the user can revert to their original permissions, making it suitable for operations where strong permissions are used only when necessary.
When multiple people in a company use AWS, in addition to individually creating IAM users, consider using AWS IAM Identity Center. This allows for centralized management of user logins and permissions, making it easier to handle situations where the number of users increases or when managing multiple AWS accounts.
Regardless of the method used, not all developers should be given strong privileges. The necessary operations differ for testing, development, operations, and monitoring. Granting broad privileges like AdministratorAccess from the start increases the scope of impact from errors and configuration mistakes.
User permissions manage not only "who can log in," but also "which roles they can switch to," "what operations they can perform," and "whether there are any users or permissions that are no longer needed."
When interacting with AWS from external tools or scripts, you may need to use IAM user access keys. This is the case when manipulating AWS resources from the AWS CLI or certain management tools.
When using access keys, clearly define their purpose. Decide which tools they will be used with, which AWS resources they will access, and which operations they will be allowed to perform, and then set only the necessary permissions.
What you want to avoid is reusing access keys with strong privileges for extended periods. Writing them directly into the source code, sharing them among multiple people, or retaining them after a change in responsibility all pose risks.
Even when operating from external tools, it may be possible to use IAM roles or temporary credentials depending on the usage. In particular, if the purpose is to access AWS resources from a process running on AWS, check whether an IAM role can be used as an alternative before issuing access keys.
IAM users and IAM roles should be designed with post-creation management in mind. Creating too many can lead to management omissions, while granting too broad permissions can increase the scope of errors and misuse.
While IAM users can be created for each individual user, managing them becomes more complex as the number increases. This is because it becomes difficult to track who has what permissions and which access keys they are using.
A particular problem arises when unused IAM users and access keys are left in place. If IAM users remain after a change in responsibilities or after an employee leaves the company, they leave an entry point to the AWS environment. If access keys were issued, it is necessary to confirm whether those keys are still in use and whether they can be deleted.
When creating IAM users, clearly define the user, purpose, and scope of permissions. Delete unnecessary IAM users and access keys and perform a regular inventory.
When multiple people in a company use AWS, in addition to individually creating IAM users, you should also consider using methods such as AWS IAM Identity Center to centrally manage logins and permissions.
IAM users and IAM roles should only be granted the necessary permissions. While granting broad permissions from the start simplifies setup, it also widens the scope of impact in the event of errors or misuse.
For example, if you only need to read files from Amazon S3, you don't need write or delete permissions. If you need to write data to Amazon DynamoDB, you only need to set permissions for the target table and the operations you need.
Strong privileges like AdministratorAccess should be handled with particular caution. If you continue to use the same privileges you temporarily used during testing in a production environment, you may end up granting permissions for operations that are not actually necessary.
When setting permissions, consider "who will be using it," "which AWS resources it will access," and "what operations it will be allowed to perform." Whether it's an IAM user or an IAM role, do not grant it excessive permissions for its intended use.
IAM users are identities associated with people, while IAM roles are a mechanism for associating temporary permissions with AWS services and applications. IAM roles are used when accessing other AWS resources from services such as Amazon EC2 or AWS Lambda.
Permissions are defined in IAM policies. These can be set for both IAM users and IAM roles, but the permitted operations should be limited to what is necessary.
When a person is operating AWS, an IAM user is a good option. However, in environments where multiple people use AWS, consider management methods such as using AWS IAM Identity Center. Avoid leaving access keys unattended or granting excessive permissions, and use different methods depending on the purpose.
