Instance Profiles for EC2 Workloads

Applications on EC2 often need to call AWS APIs, but embedding access keys is dangerous. The solution is to give the instance its own identity through an instance profile, which delivers temporary role credentials automatically. This is one of the most-tested patterns for eliminating long-term secrets from workloads.

An instance profile is a container for an IAM role that you attach to an EC2 instance. Although you assign a role conceptually, EC2 actually attaches the instance profile that wraps that role. When you create a role for EC2 in the console, an instance profile of the same name is created automatically; with the CLI or API you may need to create it explicitly.

Once an instance profile is attached, the instance can retrieve temporary credentials from the Instance Metadata Service (IMDS), a special link-local endpoint at 169.254.169.254. The AWS SDK and CLI fetch and refresh these credentials transparently, so application code never handles keys at all.

The credentials live under a metadata path tied to the role name. SDKs query it automatically, but understanding the path helps when troubleshooting why an instance has unexpected permissions. The command below shows where credentials are exposed on the instance.

A major benefit is that IMDS credentials are automatically rotated well before they expire. There is nothing to store, no key to leak permanently, and no rotation process to build. This is why AWS recommends instance profiles over any scheme that places static keys on a server.

The original metadata service (IMDSv1) could be abused through SSRF (Server-Side Request Forgery) attacks to steal role credentials. IMDSv2 requires a session token obtained via a PUT request first, which blocks most SSRF exploits. The exam expects you to enforce IMDSv2 and ideally set the hop limit to 1 to prevent containers from reaching it.

The instance-profile role should follow least privilege: grant only the specific actions and resources the workload needs. An over-broad EC2 role is dangerous because any compromise of the instance, including through SSRF, exposes those permissions. Scope policies tightly and use conditions to limit blast radius.

If you find static access keys hard-coded in an application or a credentials file on an instance, the remediation is to attach an instance profile and delete the keys. The exam often frames this as fixing a finding: the right answer removes the long-term secret and relies on the role-based credentials from IMDS.

An EC2 instance can have only one instance profile attached at a time, and thus one role. If a workload needs different permission sets, design separate roles and either separate instances or have the application assume additional roles via STS as needed, rather than over-broadening the single attached role.

Because the role credentials appear in CloudTrail as actions by an assumed-role session, you can audit exactly what an instance did. If an instance is compromised, snapshotting and checking CloudTrail for that role's session reveals what the attacker accessed. Tight role scope plus CloudTrail visibility is the secure, exam-favored combination.

To secure EC2 access: attach an instance profile wrapping a least-privilege role, enforce IMDSv2, set the metadata hop limit to 1, and remove any static keys. The instance fetches and auto-rotates temporary credentials from IMDS, giving compute a secure identity without any secret you have to manage.

Check your instance-profile knowledge.

An instance profile wraps an IAM role and attaches it to EC2, delivering auto-rotated temporary credentials through the Instance Metadata Service. This removes static keys entirely. Enforce IMDSv2 and a hop limit of 1 to block SSRF credential theft, scope the role with least privilege, and audit its sessions in CloudTrail.