Skip to main content
Identity Authority
Category: Cloud Identity

Instance Profile

Also known as: IAM Instance Profile, EC2 Instance Profile
Simply put

An instance profile is a container that holds a single IAM role and lets you attach that role to an Amazon EC2 instance. When the instance starts, code running on it can obtain temporary AWS credentials tied to the role, so you don't have to store long-lived access keys on the machine. In effect, it is the mechanism that passes role information to an EC2 instance.

Formal definition

In AWS IAM, an instance profile is a container that holds exactly one IAM role and serves as the mechanism for passing that role to an EC2 instance at launch. Once associated, workloads on the instance can retrieve temporary, automatically rotated AWS credentials derived from the role, eliminating the need for statically stored access keys. The instance profile governs what the instance is authorized to do (the role and its attached policies determine permissions), and is limited to containing a single IAM role.

Why it matters

Instance profiles address one of the most persistent risks in cloud operations: long-lived, statically stored access keys sitting on a compute instance. When code needs to call AWS APIs, the naive approach is to embed an access key and secret on the machine, where they can be leaked through misconfiguration, source-control commits, or a compromised host. An instance profile removes that need by allowing workloads on an EC2 instance to retrieve temporary, automatically rotated credentials derived from an attached IAM role, so there are no permanent keys to steal or rotate manually.

Because the instance profile is the delivery mechanism that binds an IAM role to an instance, it sits directly on the boundary between authorization design and runtime credential distribution. The role and its attached policies determine what the instance is authorized to do; the instance profile determines which instance receives those permissions. Getting this pairing right is central to least-privilege enforcement in AWS, since an overly broad role attached via an instance profile grants that scope to any process running on the instance. In most deployments this makes the instance profile a natural focus for access reviews and blast-radius analysis.

Who it's relevant to

Cloud and platform engineers
Engineers provisioning EC2 instances use instance profiles to grant workloads AWS API access without embedding static keys. Understanding that an instance profile carries exactly one role, and that the role's policies define permissions, is essential for wiring up compute in a least-privilege manner.
Security architects
Architects rely on instance profiles as the control point that determines which permissions reach a given instance. Because the temporary credentials replace long-lived keys, instance profiles are a key part of reducing exposure to credential theft in AWS environments.
IAM and cloud governance teams
Teams conducting access reviews and least-privilege audits need to trace which role each instance profile carries and what that role authorizes, since an over-permissioned role attached to an instance extends its scope to every process on that host.

Inside Instance Profile

Associated IAM Role
An instance profile acts as a container for a single IAM role. The role holds the permission policies that define what the instance may do, while the instance profile is the mechanism that delivers that role to the compute instance.
Instance Profile Name and ARN
Each instance profile has its own name and Amazon Resource Name, distinct from the role it contains, allowing it to be referenced when launching or associating with an instance.
Trust Relationship (via the Role)
The contained role's trust policy typically permits the compute service (for example, the EC2 service principal) to assume the role, which is what enables temporary credentials to be issued to the instance.
Temporary Credential Delivery
Rather than storing static keys on the instance, the instance profile enables the delivery of short-lived, automatically rotated credentials for the associated role, retrievable by workloads running on the instance.

Common questions

Answers to the questions practitioners most commonly ask about Instance Profile.

Is an instance profile the same thing as an IAM role?
No. An instance profile is a container that holds a single IAM role and acts as the mechanism for passing that role to a compute instance, whereas the IAM role itself is the identity that defines the permissions. The distinction matters because you attach a role to an instance profile, and the instance profile is what you associate with the instance. In most deployments the instance profile and its contained role share the same name, which contributes to the confusion, but they are separate objects.
Does an instance profile authenticate the instance or authorize what it can do?
Neither directly, and it is important to keep these steps separate. An instance profile is a delivery mechanism that enables an instance to assume an IAM role and obtain temporary credentials. Authentication of the calling principal and authorization of individual API actions are handled at request time by the cloud provider's access control evaluation against the assumed role's policies. The instance profile itself does not perform authentication or authorization; it establishes which role's credentials become available to workloads on the instance.
How does a workload on the instance actually retrieve credentials through an instance profile?
Typically the workload queries the instance metadata service, which surfaces temporary credentials associated with the role held by the instance profile. The exact endpoint, metadata service version, and retrieval semantics depend on the cloud provider and configuration. These credentials are usually short-lived and rotated automatically, so applications generally read them at runtime rather than storing long-lived secrets. Consult your provider's documentation for the specific metadata behavior and any hardening options.
Can an instance profile contain more than one role?
In common cloud implementations an instance profile holds a single IAM role. If a workload needs a different set of permissions, the usual approaches are to change the role attached to the instance profile, replace the instance profile associated with the instance, or have the application assume a separate role at runtime using the base credentials. Behavior and limits vary by provider, so verify the specific constraints in your environment.
How should permissions delivered through an instance profile be scoped?
Permissions are defined on the IAM role contained in the instance profile, so scoping is done through that role's policies. In most deployments the guidance is to grant only the permissions the workload on that instance requires, following least-privilege principles. Because any process able to reach the metadata service can typically obtain these credentials, the role's granted permissions effectively bound what a compromised workload on that instance can do.
What happens to running workloads when the role in an instance profile is changed?
Depending on the provider and configuration, updating the policies on the attached role generally takes effect for subsequent credential evaluations without recreating the instance, while swapping the role held by the instance profile may require the metadata service to surface new credentials before workloads see the change. Existing cached credentials on the instance may continue to reflect prior permissions until they are refreshed. Test the propagation behavior in your specific environment rather than assuming immediate effect.

Common misconceptions

An instance profile and an IAM role are the same thing.
They are distinct objects. The IAM role holds the permission and trust policies (authorization), while the instance profile is a container that binds that role to a compute instance so credentials can be delivered. In many consoles the two are created together, which obscures the distinction, but at the API level they are separate resources.
An instance profile can contain multiple roles to combine permissions.
An instance profile is typically limited to a single role. To change the effective permissions, you generally modify the contained role's policies or swap the associated role rather than adding additional roles to the profile.
Using an instance profile authenticates the workloads or users on the instance.
An instance profile is an authorization delivery mechanism, not an authentication method for end users. It provides the instance with credentials to act under a role's permissions; it does not verify the identity of any human principal interacting with applications on that instance.

Best practices

Attach a role scoped to the least privilege the instance's workload actually requires, rather than reusing a broad or shared role across many instances.
Prefer instance profile-delivered temporary credentials over embedding static access keys on the instance, and rely on the automatic rotation this provides.
Verify that the contained role's trust policy permits only the intended compute service principal to assume it, limiting who can obtain the credentials.
Use distinct roles and instance profiles per workload or environment so that permissions can be audited and revoked independently.
Regularly review the permission policies on the associated role as part of access certification, since changes there directly change what the instance can do.
Where configuration allows, restrict or monitor access to the credential retrieval endpoint on the instance to reduce the risk of credential exposure to unintended local processes.
Promotional banner for the Penetration Report Template Kit