EC2 Access Keys vs IAM Roles: Secure Instance Permissions – SAP-C02 Study Guide

Purpose of This Lesson

Amazon EC2 workloads often need to call other AWS services, such as Amazon S3, Amazon DynamoDB, or Amazon CloudWatch. This lesson explains two ways to provide those permissions:

• Long-term IAM user access keys configured on the instance
• An IAM role assigned to the EC2 instance

The preferred design is to use an IAM role with temporary credentials rather than embedding long-term credentials on the server.

Key Concepts

IAM user access keys on an EC2 instance

An IAM user can have an access key ID and secret access key. If these credentials are configured for the AWS CLI or an application on an EC2 instance, AWS API requests use the permissions attached to that IAM user.

This approach has several security and operational problems:

• Access keys are long-lived credentials.
• Credentials may be stored in plaintext in files such as ~/.aws/credentials, application configuration, environment variables, or deployment scripts.
• Anyone who obtains the keys can use them from outside the EC2 instance until the keys are disabled, deleted, or otherwise invalidated.
• Key rotation, distribution, and revocation become operational responsibilities.
• The permissions belong to the IAM user, which can make workload permissions broader than necessary.

Access keys should not be baked into AMIs, committed to source control, placed in user data, or copied into application packages.

IAM roles for EC2

An IAM role is an identity that applications can assume temporarily. The role contains permission policies describing which AWS actions and resources the workload can access.

To use a role with EC2, the role is associated with an instance profile. The instance profile is the EC2-facing container that allows the instance to assume the IAM role. In the EC2 console, this is commonly described as attaching an IAM role to the instance.

With this design:

1. The EC2 instance is launched with an instance profile.
2. The application or AWS CLI requests credentials through the EC2 instance metadata service.
3. AWS supplies temporary credentials for the role.
4. AWS API calls use those role permissions.
5. The credentials are automatically refreshed before expiration.

No permanent access key needs to be stored on the instance.

AWS Security Token Service and temporary credentials

AWS Security Token Service (AWS STS) issues temporary credentials associated with an assumed role. These credentials include an access key ID, secret access key, and session token, but they have a limited lifetime.

The SDKs and AWS CLI can obtain and refresh role credentials automatically. Temporary credentials reduce the impact of accidental exposure because they expire, although least privilege and protection of the instance still remain essential.

Instance metadata access

EC2 applications retrieve role credentials through the Instance Metadata Service (IMDS). Prefer IMDSv2, which uses session-oriented requests and helps reduce certain server-side request forgery (SSRF) risks.

Important operational controls include:

• Require IMDSv2 where practical.
• Limit or disable metadata access for workloads that do not need it.
• Prevent untrusted processes from accessing the metadata endpoint.
• Use least-privilege role policies.

The metadata service is not a replacement for authorization. It supplies credentials; the IAM role policy determines what those credentials can do.

Trust policy and permissions policy

An EC2 role has two related policy concerns:

• Trust policy: Specifies which principal can assume the role. For a standard EC2 role, the trusted service principal is typically ec2.amazonaws.com.
• Permissions policy: Specifies the AWS actions and resources available after the role is assumed.

A correctly written permissions policy is not sufficient if the trust policy does not allow EC2 to assume the role.

Example role policy

A workload that only needs to read objects from one S3 bucket should receive narrowly scoped permissions rather than broad account-wide access:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::example-bucket/app-config/*"
    }
  ]
}

The role may also require s3:ListBucket on the bucket resource if the application must list objects. Object-level and bucket-level S3 permissions use different resource ARNs.

Exam-Relevant Takeaways

• Prefer IAM roles for applications running on EC2.
• Do not configure long-term IAM user access keys on instances when an instance role can provide the required access.
• An EC2 instance receives a role through an instance profile.
• EC2 role credentials are temporary and issued through AWS STS.
• AWS SDKs and the AWS CLI automatically use and refresh role credentials when configured correctly.
• A role’s trust policy controls who can assume the role; its permissions policy controls what the role can do.
• Apply least privilege to the role and scope access to specific actions and resources.
• Use IMDSv2 and restrict metadata access to reduce credential theft risk.
• If an application uses multiple AWS accounts, use cross-account role assumption rather than distributing long-term keys.
• Rotating or replacing an EC2 instance role is generally safer and simpler than distributing new credentials to many servers.

Architecture Decision Guide

Requirement or situation	Recommended approach	Reason
EC2 application needs access to S3, DynamoDB, or CloudWatch	Attach an IAM role through an instance profile	Provides automatically refreshed temporary credentials
Existing long-term keys are stored on an instance	Replace them with an instance role	Removes plaintext, long-lived credentials from the workload
Workload needs access in another AWS account	Assume a cross-account IAM role using STS	Avoids sharing user access keys between accounts
A third-party tool cannot use an instance role	Use a carefully controlled alternative, such as temporary credentials or a dedicated identity mechanism	Some legacy tools do not support role credentials
Workload does not need AWS API access	Do not attach unnecessary permissions or a role	Reduces attack surface
Instance must be prevented from obtaining metadata credentials	Disable or restrict IMDS access	Prevents unnecessary credential exposure
Application needs credentials outside AWS	Use an appropriate federated or workload identity solution where supported	Avoids creating unmanaged long-term IAM user keys

Common Exam Traps

• Confusing an IAM role with an instance profile: EC2 attaches an instance profile, which references the IAM role.
• Assuming roles have passwords or permanent keys: Roles are assumed and normally provide temporary credentials.
• Choosing access keys because they are simpler: Long-term keys on an instance are usually the less secure answer when a role is available.
• Using the wrong S3 ARN: s3:GetObject applies to object ARNs, while bucket-level actions such as s3:ListBucket use the bucket ARN.
• Ignoring the trust policy: The role needs a trust relationship that permits EC2 to assume it.
• Believing temporary credentials eliminate all risk: A compromised instance can still use credentials available through metadata until they expire or are revoked.
• Assuming an instance role grants unrestricted permissions: The role is limited by its identity policies, resource policies, permission boundaries, SCPs, and other applicable controls.
• Putting secrets in user data: User data can be exposed through instance access and should not be used for permanent credentials.

Real-World Engineer Notes

• Use separate roles for different workload types rather than one powerful role shared by every instance.
• Keep role policies resource-scoped and action-scoped. Avoid Action: "*" and Resource: "*" unless there is a documented requirement.
• Monitor role usage with AWS CloudTrail and review unused permissions with IAM Access Analyzer and related tooling.
• When an instance is compromised, isolate or terminate it, investigate CloudTrail activity, and consider replacing or restricting the role. Temporary credentials are not a substitute for incident response.
• Enforce IMDSv2 through launch templates, organization policies, or configuration controls where appropriate.
• Applications should use the AWS SDK default credential provider chain instead of manually reading or copying credentials.
• If credentials must be used temporarily for an exceptional migration or legacy process, store them in a managed secret solution and define a rotation and removal plan.

Quick Reference Summary

• Best default for EC2: IAM role attached through an instance profile.
• Credential type: Temporary credentials issued through AWS STS.
• Credential delivery: EC2 Instance Metadata Service, preferably IMDSv2.
• Avoid: Long-term IAM user access keys stored on servers.
• Trust policy: Defines who may assume the role.
• Permissions policy: Defines allowed AWS actions and resources.
• Security baseline: Least privilege, IMDSv2, CloudTrail monitoring, and no secrets in AMIs or user data.

Flashcards

1. Q: What is the preferred way to grant an EC2 application access to AWS services?

A: Attach an IAM role to the instance through an instance profile.

1. Q: Why are IAM user access keys on an EC2 instance risky?

A: They are long-lived credentials that may be stored in plaintext and remain usable if copied.

1. Q: Which AWS service issues temporary credentials when an IAM role is assumed?

A: AWS Security Token Service (AWS STS).

1. Q: How does an EC2 workload normally obtain role credentials?

A: Through the EC2 Instance Metadata Service using the SDK or AWS CLI credential provider chain.

1. Q: What is the purpose of an EC2 instance profile?

A: It is the EC2 association mechanism that provides an IAM role to the instance.

1. Q: What does an IAM role trust policy control?

A: Which principals or AWS services are allowed to assume the role.

1. Q: What does an IAM permissions policy control?

A: Which actions the role can perform on which resources.

1. Q: What is the recommended version of the EC2 Instance Metadata Service?

A: IMDSv2.

1. Q: Do role credentials need to be manually rotated on the EC2 host?

A: Normally no; the SDK or CLI obtains and refreshes temporary credentials automatically.

1. Q: What should be used for cross-account access instead of sharing IAM user keys?

A: A cross-account IAM role assumed through AWS STS.

Practice Questions

Question 1

A fleet of EC2 instances runs an application that reads configuration files from a specific S3 prefix. The current design stores an IAM user’s access key and secret key in the application configuration on every instance. What is the most secure redesign?

A. Encrypt the access keys with a customer managed KMS key and keep them in the AMI
B. Store the access keys in EC2 user data
C. Attach an IAM role through an instance profile with least-privilege S3 permissions
D. Create a new IAM user for every EC2 instance

Correct answer: C

An instance role provides temporary credentials without distributing long-term IAM user keys. The role should allow only the required S3 actions and prefix.

Question 2

An EC2 application has an attached role, but calls to an S3 bucket fail with AccessDenied. The role’s permissions policy allows s3:GetObject on the expected object ARN. Which additional item should be checked first?

A. Whether the EC2 instance has a public IPv4 address
B. Whether the role trust policy allows EC2 to assume the role
C. Whether the IAM user password has expired
D. Whether the instance was launched in a public subnet

Correct answer: B

The role must have a trust relationship allowing the EC2 service to assume it. Network placement and public addressing are not required for role authorization itself.

Question 3

A security team is concerned that a server-side request forgery vulnerability could expose credentials available to an EC2 application. Which control best reduces the risk of unauthorized metadata credential retrieval?

A. Require IMDSv2 and restrict metadata access
B. Assign a broader IAM role so requests do not fail
C. Store a second copy of the access keys in Secrets Manager
D. Place the instance in a public subnet

Correct answer: A

IMDSv2 adds session-oriented protections, and restricting metadata access reduces the ability of untrusted processes to retrieve role credentials. Least-privilege permissions should also be applied.

Question 4

An application in Account A must read objects from an S3 bucket in Account B. The company does not want to distribute credentials belonging to either account. Which design is most appropriate?

A. Create a long-term IAM user in Account B and copy its keys to Account A
B. Configure the EC2 instance in Account A with a role that can assume a trusted role in Account B
C. Make the S3 bucket public
D. Attach the Account B role directly to an EC2 instance in Account A without a trust relationship

Correct answer: B

A cross-account role in Account B can trust the appropriate principal from Account A. The workload assumes the role through STS and receives temporary credentials.

Question 5

An EC2 application needs to list objects in an S3 bucket and download objects under app-config/. Which permissions are most likely required?

A. s3:* on all resources
B. s3:ListBucket on the bucket ARN and s3:GetObject on the relevant object ARN
C. s3:GetObject on the bucket ARN only
D. s3:ListAllMyBuckets on every bucket in the account

Correct answer: B

S3 bucket-level and object-level actions use different resource scopes. Listing requires a bucket-level permission, while downloading requires object-level permission for the relevant key prefix.