Introduction

An EC2 instance cannot have multiple instance-profile roles attached at the same time. The current AWS model is still one instance profile per instance, and an instance profile contains exactly one IAM role.

If software on the instance needs additional permission sets, the normal pattern is to attach one base role to the instance and let that role call AWS STS to assume other roles as needed. That preserves least privilege without pretending the instance can natively wear several roles at once.

What EC2 Actually Supports

When you launch an EC2 instance, you associate an IAM instance profile. That profile supplies temporary credentials through the instance metadata service. The important limit is architectural, not cosmetic: the instance profile can hold only one IAM role.

So if the question is “Can I attach two IAM roles directly to one EC2 instance?”, the answer is no.

What you can do is:

• attach one role as the instance profile role
• grant that role permission to call sts:AssumeRole
• create one or more target roles with trust policies that allow assumption from the base role

That gives the application multiple permission sets, just not multiple directly attached instance roles.

A Typical Design

Suppose a server normally reads from S3 but occasionally needs to write to a specific DynamoDB table in another account. A clean setup looks like this:

• the EC2 instance profile role has only baseline permissions plus sts:AssumeRole
• a second role grants the DynamoDB access
• the application assumes the second role only for the operation that needs it

This keeps default credentials narrow while allowing controlled escalation for specific tasks.

Example With the AWS CLI

First, the application uses the instance profile credentials automatically. Then it assumes a target role:

aws sts assume-role \
  --role-arn arn:aws:iam::123456789012:role/report-writer \
  --role-session-name ec2-report-job

That returns temporary credentials. You can export them into the shell and use them for the next command:

1export AWS_ACCESS_KEY_ID="..."
2export AWS_SECRET_ACCESS_KEY="..."
3export AWS_SESSION_TOKEN="..."
4aws dynamodb list-tables

In application code, the SDK usually handles this more cleanly than manual exports.

Example in Python With boto3

1import boto3
2
3
4def assume_role(role_arn: str, session_name: str = "ec2-app"):
5    sts = boto3.client("sts")
6    response = sts.assume_role(RoleArn=role_arn, RoleSessionName=session_name)
7    creds = response["Credentials"]
8    return boto3.Session(
9        aws_access_key_id=creds["AccessKeyId"],
10        aws_secret_access_key=creds["SecretAccessKey"],
11        aws_session_token=creds["SessionToken"],
12    )
13
14
15session = assume_role("arn:aws:iam::123456789012:role/report-writer")
16s3 = session.client("s3")
17print(s3.list_buckets())

This code assumes the process is already running on EC2 with a valid instance profile role.

Why AWS Works This Way

The one-role-per-instance-profile model keeps the default trust path simple. Every application on the instance shares the same metadata-service credentials unless it deliberately assumes something else.

That is an important security point. If multiple unrelated applications share one EC2 instance, they also share the base role unless you add another isolation boundary. If you need per-workload identities by default, container task roles or separate compute units are usually a better fit than stuffing more permissions into one VM.

Better Alternatives for Some Workloads

If the real problem is that multiple applications on one host need different permissions, consider a design change instead of a more complex role chain.

Good alternatives include:

• separate EC2 instances for separate trust boundaries
• ECS task roles for containers on ECS
• EKS service-account-based role mapping for Kubernetes workloads
• Lambda execution roles for event-driven jobs

Those models map identity closer to the unit of work.

Common Pitfalls

The biggest mistake is assuming one EC2 instance can directly attach multiple IAM roles the way a user can switch roles in the console. That is not how instance profiles work.

Another common mistake is making the instance role extremely broad because several applications share the box. That solves the immediate access problem but weakens least privilege.

Teams also forget the trust policy on the target role. The base instance-profile role needs permission to call sts:AssumeRole, and the target role must trust that base role.

Finally, do not confuse “multiple permission sets available through STS” with “multiple roles attached to the instance.” They are operationally related but technically different.

Summary

• An EC2 instance can have only one attached instance profile at a time.
• An instance profile can contain only one IAM role.
• To access multiple permission sets, use the attached role to assume other roles with AWS STS.
• Keep the base role narrow and grant elevated permissions only through explicit role assumption.
• If workloads need separate identities by default, use stronger isolation such as ECS task roles, EKS service accounts, or separate instances.