EC2 Instance Roles, Access Keys, and Temporary Credentials | AWS Systems Architect Professional

Study guide

Technical reference and lesson notes

This lesson explains how Amazon EC2 instances securely access other AWS services, such as Amazon S3, without embedding long-term credentials on the server.

For the AWS Certified Solutions Architect – Professional SAP-C02 exam, this is a foundational IAM design topic. Many scenario questions test whether you know the secure, scalable, and operationally correct way to allow AWS workloads to call other AWS services.

The key takeaway is simple:

Do not store IAM user access keys on EC2 instances. Use IAM roles attached through instance profiles instead.

Key Concepts

Why EC2 Instances Need AWS Permissions

An EC2 instance often needs to interact with other AWS services.

Common examples include:

An application on EC2 reading objects from Amazon S3
A web server writing logs to Amazon CloudWatch Logs
A backup process copying files to an S3 bucket
An application retrieving secrets from AWS Secrets Manager
An instance accessing Amazon DynamoDB, Amazon SQS, or Amazon SNS

Because AWS services are API-driven, the EC2 instance needs AWS credentials with permission to call the required API actions.

For example, if an application on EC2 needs to read from an S3 bucket, it may need permissions such as:

s3:GetObject
s3:ListBucket

If it needs to write to the bucket, it may need:

s3:PutObject

The design question is not just whether the instance can access S3. The real exam-relevant question is:

What is the most secure and operationally sound way to grant that access?

Option 1: Using Access Keys on an EC2 Instance

One way to give an EC2 instance AWS permissions is to create access keys for an IAM user and configure those keys on the instance.

Access keys consist of:

Access Key ID
Secret Access Key

These function similarly to a username and password for AWS API access.

The access keys inherit the permissions of the IAM user they belong to. If the IAM user has a policy allowing access to an S3 bucket, then any application using that user’s access keys can perform those allowed actions.

Why This Is a Bad Design for EC2

Storing access keys on an EC2 instance creates several security and operational risks.

Credentials Can Be Exposed

Access keys are commonly stored in local configuration files, environment variables, application configuration files, or deployment scripts.

If an attacker gains access to the instance, they may be able to retrieve the credentials and use them outside the instance.

This is especially dangerous because those credentials are not tied to the instance itself. They can often be used from anywhere unless additional controls are in place.

Access Keys Are Long-Term Credentials

IAM user access keys are long-lived. They remain valid until they are manually rotated, disabled, or deleted.

That means if the keys are leaked and no one notices, they can continue to be used indefinitely.

This creates a major risk in production environments.

Key Rotation Becomes an Operational Burden

If access keys are embedded on servers, teams must manage:

Secure storage
Key rotation
Application restarts or redeployments
Incident response if keys are exposed
Auditing where keys are being used

At scale, this becomes difficult to manage and easy to get wrong.

Poor Fit for Automated Cloud Environments

Cloud workloads are dynamic. Instances may be replaced frequently through Auto Scaling groups, AMIs, launch templates, or automation pipelines.

Embedding static credentials into servers does not align well with modern cloud-native infrastructure patterns.

Option 2: Using IAM Roles for EC2

The preferred method is to attach an IAM role to the EC2 instance.

An IAM role allows the instance to obtain temporary security credentials automatically.

Instead of storing static access keys on the server, the instance receives temporary credentials from AWS.

These credentials are:

Automatically generated
Short-lived
Automatically rotated
Scoped to the permissions assigned to the role
Not manually stored on the instance as long-term secrets

This is the standard AWS best practice for allowing EC2 instances to access other AWS services.

How IAM Roles Work with EC2

When using an IAM role with EC2, several components are involved.

IAM Role

The IAM role defines what permissions are available.

For example, the role may include a policy allowing the EC2 instance to read from a specific S3 bucket.

Example permissions may include:

{
  "Effect": "Allow",
  "Action": [
    "s3:GetObject"
  ],
  "Resource": "arn:aws:s3:::example-bucket/*"
}

The role is not a user. It is an identity that can be assumed by a trusted entity.

In this case, the trusted entity is the EC2 service.

Trust Policy

The role must trust EC2 so that EC2 instances can assume the role.

A simplified trust relationship for EC2 commonly uses the service principal:

{
  "Effect": "Allow",
  "Principal": {
    "Service": "ec2.amazonaws.com"
  },
  "Action": "sts:AssumeRole"
}

This allows EC2 to assume the role and retrieve temporary credentials.

AWS Security Token Service

AWS Security Token Service, or AWS STS, provides temporary credentials when a role is assumed.

For EC2, the instance uses the role attached to it and obtains temporary credentials automatically.

These credentials include:

Access key ID
Secret access key
Session token

Unlike IAM user access keys, these credentials expire and are rotated automatically.

Instance Profile

An instance profile is the container that allows an IAM role to be attached to an EC2 instance.

For exam purposes, remember:

IAM roles are attached to EC2 instances through instance profiles.

When you choose an IAM role while launching or modifying an EC2 instance, AWS uses an instance profile behind the scenes.

The application running on the instance does not need hardcoded credentials. AWS SDKs and CLI tools can automatically retrieve the temporary credentials from the instance metadata service.

Instance Metadata Service

Applications and AWS SDKs on the EC2 instance can retrieve role credentials from the EC2 Instance Metadata Service.

In modern secure environments, IMDSv2 should be preferred or required.

IMDSv2 improves security by using session-based requests, reducing the risk of certain metadata credential theft scenarios.

For the SAP-C02 exam, the main point is:

The application can automatically use the role credentials without the administrator placing access keys on the instance.

Security Benefits of IAM Roles

Using IAM roles with EC2 provides several security advantages.

No Long-Term Credentials on the Instance

There are no permanent IAM user access keys stored in files or application configuration.

This reduces the blast radius if the instance is compromised.

Temporary Credentials Expire Automatically

The credentials issued through STS are short-lived.

Even if temporary credentials are exposed, they expire automatically.

This is much safer than long-lived access keys.

Easier Rotation

AWS handles credential rotation automatically.

Administrators do not need to manually rotate access keys across fleets of EC2 instances.

Better Least Privilege Design

Roles can be scoped to the exact permissions the workload requires.

For example, instead of giving broad S3 access, the role can allow read-only access to one bucket or even one prefix within a bucket.

Better Operational Scalability

Roles work well with:

Auto Scaling groups
Launch templates
Immutable infrastructure
Golden AMIs
CI/CD pipelines
Infrastructure as Code
Large EC2 fleets

You can attach the correct role at launch rather than injecting secrets into the instance.

Example Scenario: EC2 Accessing Amazon S3

Assume an application running on EC2 needs to read files from an S3 bucket.

Poor Design

Create an IAM user, generate access keys, and configure those keys on the instance.

Problems:

Credentials are long-term
Keys may be exposed if the instance is compromised
Manual rotation is required
Keys may be copied outside AWS
Difficult to audit and manage at scale

Better Design

Create an IAM role for EC2, attach a least-privilege policy allowing access to the required S3 bucket, and attach the role to the EC2 instance using an instance profile.

Benefits:

No static credentials stored on the instance
Temporary credentials are automatically rotated
Access is limited by the role policy
Easier to manage across multiple instances
Aligns with AWS best practices

Important Design Considerations

Least Privilege Permissions

Do not attach broad permissions such as AmazonS3FullAccess unless there is a strong reason.

For exam and real-world design, prefer policies scoped to:

Specific bucket
Specific object prefix
Required actions only
Required KMS key permissions if the S3 bucket uses SSE-KMS

Example:

{
  "Effect": "Allow",
  "Action": [
    "s3:GetObject"
  ],
  "Resource": "arn:aws:s3:::example-bucket/app-data/*"
}

If the application needs to list the bucket, that is a separate permission on the bucket ARN:

{
  "Effect": "Allow",
  "Action": [
    "s3:ListBucket"
  ],
  "Resource": "arn:aws:s3:::example-bucket"
}

S3 Bucket Policies Can Also Matter

The IAM role may allow access, but an S3 bucket policy can still restrict or deny access.

For S3 access, effective permissions may involve:

IAM role policy
S3 bucket policy
AWS Organizations SCPs
Permissions boundaries
KMS key policy if using SSE-KMS
Explicit denies

For SAP-C02, remember that identity-based permissions alone may not be enough if a resource-based policy or explicit deny blocks access.

KMS Permissions for Encrypted Data

If the S3 bucket uses server-side encryption with AWS KMS, the EC2 role may also need KMS permissions.

Common required actions include:

kms:Decrypt
kms:Encrypt
kms:GenerateDataKey

This is a common real-world troubleshooting issue. The S3 permissions may be correct, but access still fails because the role does not have the necessary KMS key permissions.

Role Attachment and Replacement

An EC2 instance can have an IAM role attached through an instance profile. In operational environments, you can attach or replace an IAM role on an existing instance.

This is useful when fixing permission issues without rebuilding the instance.

However, from a governance perspective, role changes should be controlled because they can significantly change what the instance can access.

Exam-Relevant Takeaways

For the SAP-C02 exam, remember these core points:

Use IAM roles for EC2 workloads that need AWS API access.
Do not store IAM user access keys on EC2 instances.
Access keys are long-term credentials and create security risk if exposed.
IAM roles use AWS STS to provide temporary credentials.
Temporary credentials expire and are automatically rotated.
An instance profile is used to attach an IAM role to an EC2 instance.
The role’s permissions determine what the EC2 instance can do.
The role’s trust policy determines who or what can assume the role.
For EC2, the trust policy must allow the EC2 service to assume the role.
Use least privilege when granting access to services such as S3.
For S3 with SSE-KMS, remember to include KMS permissions as well.
Use IMDSv2 to improve protection of instance metadata and credentials.

Architecture Decision Guide

Scenario	Best AWS Choice	Why
EC2 instance needs to read objects from S3	IAM role attached to EC2 using an instance profile	Provides temporary credentials without storing access keys on the instance
Application on EC2 needs AWS API access	IAM role for EC2	AWS SDKs can automatically retrieve temporary credentials
Developer needs CLI access from a laptop	IAM Identity Center, federated access, or tightly controlled IAM user access keys if required	Human access should be separated from workload access
Legacy application requires static credentials	Prefer refactoring to use IAM role; if unavoidable, store secrets in AWS Secrets Manager and rotate	Static credentials are higher risk and require stronger controls
EC2 instance needs access to encrypted S3 objects using SSE-KMS	IAM role with S3 permissions and KMS permissions	S3 access alone may not be enough when KMS encryption is involved
Multiple EC2 instances in an Auto Scaling group need the same AWS permissions	Attach an IAM role through the launch template or launch configuration	Scales cleanly without embedding credentials in the AMI
Need to restrict EC2 access to a specific S3 bucket prefix	IAM role policy scoped to bucket and prefix	Enforces least privilege
Concerned about metadata credential theft	Require IMDSv2	IMDSv2 provides stronger protection for metadata access

Common Exam Traps

Choosing Access Keys Instead of IAM Roles

A common wrong answer is to create IAM user access keys and place them on the EC2 instance.

This is usually not the best answer.

For AWS-hosted workloads, IAM roles are the preferred approach.

Using the Root Account or Root Access Keys

Never use root account access keys for application access.

Root credentials should not be used for workloads, automation, or applications.

Granting Overly Broad Permissions

Another trap is selecting an answer that grants full access to an AWS service when the workload only needs limited permissions.

For example, giving AmazonS3FullAccess when the application only needs to read one bucket is not least privilege.

Forgetting About the Instance Profile

The exam may mention attaching a role to EC2. Technically, the role is associated with the instance using an instance profile.

If a question asks what enables the EC2 instance to use the role, remember the instance profile.

Confusing IAM Users and IAM Roles

IAM users are long-term identities.

IAM roles are assumable identities that provide temporary credentials.

For EC2 workloads, use roles.

Forgetting KMS Permissions

If an EC2 instance can access an S3 bucket but still cannot read encrypted objects, the issue may be missing KMS permissions.

This is especially relevant when S3 objects are encrypted with a customer-managed KMS key.

Assuming the Role Policy Is the Only Policy That Matters

Effective access can also be affected by:

S3 bucket policies
KMS key policies
SCPs
Explicit denies
Permissions boundaries
VPC endpoint policies

For professional-level exam scenarios, AWS may include multiple policy layers.

Real-World Engineer Notes

In a real AWS environment, IAM roles for EC2 are one of the first controls to standardize.

From an operations and security perspective, static access keys on servers create unnecessary risk. They are difficult to rotate, easy to accidentally expose, and often end up copied into scripts, configuration files, AMIs, or deployment pipelines.

A better engineering pattern is to define workload-specific IAM roles.

For example:

AppServerReadOnlyS3Role
WebServerCloudWatchLogsRole
BatchProcessorDynamoDBWriteRole
BackupInstanceS3WriteRole

Each role should be scoped to the minimum permissions required.

In production, you should also monitor for access key usage. If EC2-based applications are using IAM user keys, that may indicate technical debt or a security gap.

Operationally, when troubleshooting EC2 access to S3, check:

Is the IAM role attached to the instance?
Does the role policy allow the required S3 action?
Is the resource ARN correct?
Does the bucket policy allow or deny the request?
Is there an explicit deny?
Is the object encrypted with KMS?
Does the role have KMS permissions?
Are SCPs or permissions boundaries limiting access?
Is the application using the instance role credentials, or is it accidentally using old local credentials?

That last point matters. If static credentials exist on an instance, the AWS CLI or SDK may use them instead of the instance role, depending on the credential provider chain. This can make troubleshooting confusing.

From a governance standpoint, IAM role changes should be tracked through Infrastructure as Code whenever possible. Tools such as AWS CloudFormation, Terraform, or AWS CDK make it easier to review and control permission changes.

For hardened environments, require IMDSv2 on EC2 instances to reduce the risk of metadata credential exposure.

Quick Reference Summary

EC2 instances often need permissions to access other AWS services.
Access keys are long-term credentials tied to IAM users.
Storing access keys on EC2 is insecure and difficult to manage.
IAM roles are the preferred way to grant AWS service access to EC2.
EC2 roles use AWS STS temporary credentials.
Temporary credentials are automatically rotated and expire.
An instance profile is used to attach an IAM role to EC2.
The role permissions define what the instance can do.
The trust policy defines who can assume the role.
For EC2, the trusted service is ec2.amazonaws.com.
Use least privilege permissions.
Remember KMS permissions when accessing encrypted S3 objects.
Prefer IMDSv2 for metadata security.

Flashcards

Q: What is the preferred way to allow an EC2 instance to access other AWS services?
A: Attach an IAM role to the EC2 instance using an instance profile.

Q: Why should access keys not be stored on EC2 instances?
A: They are long-term credentials that can be exposed if the instance is compromised and require manual rotation.

Q: What are the two parts of an IAM access key?
A: Access Key ID and Secret Access Key.

Q: What AWS service provides temporary credentials when a role is assumed?
A: AWS Security Token Service, or AWS STS.

Q: What is an instance profile?
A: An instance profile is the container used to attach an IAM role to an EC2 instance.

Q: What determines what an EC2 instance can do after assuming a role?
A: The permissions policies attached to the IAM role.

Q: What determines whether EC2 can assume an IAM role?
A: The role’s trust policy.

Q: What service principal is commonly used in an EC2 role trust policy?
A: ec2.amazonaws.com.

Q: Why are IAM role credentials safer than IAM user access keys?
A: IAM role credentials are temporary, automatically rotated, and do not require static credentials to be stored on the instance.

Q: If an EC2 instance needs to read encrypted objects from S3 using SSE-KMS, what permissions may be required besides S3 permissions?
A: KMS permissions such as kms:Decrypt.

Q: What is a common exam trap involving EC2 and S3 access?
A: Choosing to create IAM user access keys and store them on the instance instead of using an IAM role.

Q: What metadata service version should be preferred for stronger EC2 credential protection?
A: IMDSv2.

Q: What should you do if an EC2 application needs access only to one S3 bucket prefix?
A: Create a least-privilege IAM role policy scoped to the specific bucket prefix and required actions.

Q: Can an S3 bucket policy override or restrict access even if the EC2 role allows access?
A: Yes. Resource-based policies and explicit denies can affect the final authorization decision.

Q: Why are IAM roles useful for Auto Scaling groups?
A: Instances can automatically receive the correct temporary credentials without embedding secrets in AMIs or scripts.

Practice Questions

Question 1:
An application running on an EC2 instance needs to read objects from an S3 bucket. A developer suggests creating an IAM user, generating access keys, and storing the keys in a configuration file on the instance. What is the best solution?

A. Store the IAM user access keys in the application configuration file
B. Store the access keys in an encrypted file on the EC2 instance
C. Attach an IAM role to the EC2 instance using an instance profile
D. Use the AWS root account access keys for the application

Correct Answer:
C. Attach an IAM role to the EC2 instance using an instance profile

Explanation:
IAM roles are the preferred way to grant AWS permissions to EC2 instances. They provide temporary credentials through AWS STS and avoid storing long-term access keys on the instance.

Question 2:
An EC2 instance has an IAM role that allows s3:GetObject on a specific bucket. The application can list the bucket but cannot read objects encrypted with a customer-managed KMS key. What is the most likely missing permission?

A. iam:PassRole
B. kms:Decrypt
C. ec2:DescribeInstances
D. sts:GetCallerIdentity

Correct Answer:
B. kms:Decrypt

Explanation:
When S3 objects are encrypted with a customer-managed KMS key, the role needs the appropriate KMS permissions, such as kms:Decrypt, in addition to the required S3 permissions.

Question 3:
What is the purpose of an instance profile in relation to EC2 and IAM roles?

A. It stores access keys for the EC2 instance
B. It allows an IAM role to be associated with an EC2 instance
C. It encrypts the EC2 instance root volume
D. It creates an S3 bucket policy for the instance

Correct Answer:
B. It allows an IAM role to be associated with an EC2 instance

Explanation:
An instance profile is the mechanism used to attach an IAM role to an EC2 instance. The role provides temporary credentials to applications running on the instance.

Question 4:
A security team finds long-term IAM user access keys stored on several EC2 instances. What is the best remediation strategy?

A. Replace the access keys with root account credentials
B. Move the same access keys to a different directory on the instance
C. Create IAM roles with least-privilege permissions and attach them to the EC2 instances
D. Increase the permissions of the IAM users so fewer keys are required

Correct Answer:
C. Create IAM roles with least-privilege permissions and attach them to the EC2 instances

Explanation:
The secure AWS design pattern is to use IAM roles for EC2 workloads. This removes the need to store long-term credentials and allows AWS to provide temporary, automatically rotated credentials.

Question 5:
An application running on EC2 is using AWS SDKs to access Amazon S3. No credentials are configured in the application. The EC2 instance has an IAM role attached. How does the application obtain credentials?

A. From the root account
B. From the EC2 Instance Metadata Service
C. From the S3 bucket policy
D. From AWS Organizations

Correct Answer:
B. From the EC2 Instance Metadata Service

Explanation:
AWS SDKs can automatically retrieve temporary credentials associated with the EC2 instance role from the Instance Metadata Service. IMDSv2 is preferred for stronger metadata security.