docs: lead IAM pages with the AWS concept terms users search

docs/identity/iam-groups/README.md

@@ -1,6 +1,6 @@
 ---
-title: "IAM Groups"
-description: "Organise IAM users into groups and manage permissions once for the whole team."
+title: "AWS IAM Groups for Shared User Permissions"
+description: "Organise AWS IAM users into groups, manage membership, and attach managed or inline policies once for the whole team instead of granting them user by user."
 category: "Identity"
 tags:
   - iam
@@ -15,9 +15,9 @@ resources:
     url: "https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html"
 ---
 
-# IAM Groups
+# AWS IAM Groups for Shared User Permissions
 
-> Organise IAM users into groups and manage permissions once for the whole team.
+> Organise AWS IAM users into groups, manage membership, and attach managed or inline policies once for the whole team instead of granting them user by user.
 
 ## Table of Contents
 
@@ -33,11 +33,11 @@ resources:
 
 ## Overview
 
-A group is a collection of IAM users. Policies attached to a group apply to every member, so instead of attaching the same policy to each developer individually, you attach it once to a `developers` group and manage membership.
+A group is a collection of [IAM users](/docs/iam-users-and-policies). Policies attached to a group apply to every member, so instead of attaching the same policy to each developer individually, you attach it once to a `developers` group and manage membership.
 
 Members inherit both the group's **attached managed policies** and its **inline policies**, combined with any policies on the user itself. Policy evaluation is the same as everywhere else: an explicit `Deny` in any applicable policy wins, and anything not allowed is denied.
 
-Groups cannot be nested, and a group is not a principal — it cannot sign requests or own access keys. Like all IAM resources, groups are scoped to the account that creates them.
+Groups cannot be nested, and a group is not a principal — it cannot sign requests or own access keys. The identity you assume to get credentials is an [IAM role](/docs/iam-roles-and-instance-profiles), not a group. Like all IAM resources, groups are scoped to the account that creates them.
 
 ## Prerequisites
 

docs/identity/iam-roles-and-instance-profiles/README.md

@@ -1,6 +1,6 @@
 ---
-title: "IAM Roles and Instance Profiles"
-description: "Create IAM roles with trust policies, wrap them in instance profiles, and grant EC2 instances credentials without static keys."
+title: "AWS IAM Roles and Instance Profiles for EC2"
+description: "Create AWS IAM roles with trust policies, wrap them in instance profiles, and launch EC2 instances that receive credentials with no static access keys at all."
 category: "Identity"
 tags:
   - iam
@@ -18,9 +18,9 @@ resources:
     url: "https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2_instance-profiles.html"
 ---
 
-# IAM Roles and Instance Profiles
+# AWS IAM Roles and Instance Profiles for EC2
 
-> Create IAM roles with trust policies, wrap them in instance profiles, and grant EC2 instances credentials without static keys.
+> Create AWS IAM roles with trust policies, wrap them in instance profiles, and launch EC2 instances that receive credentials with no static access keys at all.
 
 ## Table of Contents
 
@@ -39,7 +39,7 @@ resources:
 
 ## Overview
 
-A role is an IAM identity with permissions but no long-lived credentials. Instead of an access key pair, a role has a **trust policy** declaring who may assume it; whoever assumes the role receives short-lived, auto-rotating STS credentials.
+A role is an IAM identity with permissions but no long-lived credentials. Unlike an [IAM group](/docs/iam-groups), which only bundles users together, a role is a principal in its own right: instead of an access key pair it has a **trust policy** declaring who may assume it, and whoever assumes the role receives short-lived, auto-rotating STS credentials.
 
 An **instance profile** is the container that binds a role to an EC2 instance. An instance launched with a profile gets the role's credentials delivered through [IMDS](/docs/imds) — no static keys baked into the image, no `~/.aws/credentials` inside the guest.
 

docs/identity/iam-users-and-policies/README.md

@@ -1,6 +1,6 @@
 ---
-title: "IAM Users and Policies"
-description: "Create IAM users, manage access keys, and control permissions with policies."
+title: "AWS IAM Users, Policies, and Access Keys"
+description: "Create AWS IAM users, issue and rotate access keys, and write and attach JSON policies that control exactly what each user can do in a Spinifex account."
 category: "Identity"
 tags:
   - iam
@@ -17,9 +17,9 @@ resources:
     url: "https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html"
 ---
 
-# IAM Users and Policies
+# AWS IAM Users, Policies, and Access Keys
 
-> Create IAM users, manage access keys, and control permissions with policies.
+> Create AWS IAM users, issue and rotate access keys, and write and attach JSON policies that control exactly what each user can do in a Spinifex account.
 
 ## Table of Contents
 
@@ -119,7 +119,7 @@ aws iam delete-user --user-name alice
 
 ## Access Keys
 
-Access keys are how users authenticate with the AWS CLI. Each user can have up to **2 access keys** at a time, allowing key rotation without downtime.
+Access keys are how users authenticate with the AWS CLI. Each user can have up to **2 access keys** at a time, allowing key rotation without downtime. For credentials that expire on their own instead of a long-lived key pair, see [STS and Temporary Credentials](/docs/sts). Workloads running inside an EC2 instance should not carry a user's access key at all — they pick up role credentials automatically through [IMDS](/docs/imds).
 
 ### Create an Access Key
 

docs/identity/imds/README.md

@@ -1,6 +1,6 @@
 ---
-title: "IMDS (Instance Metadata Service)"
-description: "Access instance metadata, user data, and IAM role credentials from inside a guest VM with IMDSv2."
+title: "AWS IMDS: Instance Metadata Service (IMDSv2)"
+description: "Query AWS instance metadata, read user data, and fetch short-lived IAM role credentials from inside a guest VM using IMDSv2 session tokens on Spinifex."
 category: "Identity"
 tags:
   - imds
@@ -18,9 +18,9 @@ resources:
     url: "https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html"
 ---
 
-# Instance Metadata Service (IMDS)
+# AWS IMDS: Instance Metadata Service (IMDSv2)
 
-> Access instance metadata, user data, and IAM role credentials from inside a guest VM with IMDSv2.
+> Query AWS instance metadata, read user data, and fetch short-lived IAM role credentials from inside a guest VM using IMDSv2 session tokens on Spinifex.
 
 ## Table of Contents
 
@@ -153,7 +153,7 @@ Returns the decoded user data, or 404 if the instance was launched without any.
 
 ## IAM Role Credentials
 
-Instances launched with an IAM instance profile get short-lived, auto-rotating credentials through IMDS — no static keys baked into the image. Creating roles and instance profiles is covered in [IAM Roles and Instance Profiles](/docs/iam-roles-and-instance-profiles).
+Instances launched with an IAM instance profile get short-lived, auto-rotating credentials through IMDS — no static keys baked into the image. Creating roles and instance profiles is covered in [IAM Roles and Instance Profiles](/docs/iam-roles-and-instance-profiles). These are the same temporary credentials [STS](/docs/sts) issues, delivered to the guest automatically instead of through an explicit `assume-role` call.
 
 ```bash
 # Discover the role name

docs/identity/sts/README.md

@@ -1,6 +1,6 @@
 ---
-title: "STS and Temporary Credentials"
-description: "Mint short-lived credentials with STS — assume roles, issue session tokens, and federate Kubernetes workloads with OIDC."
+title: "AWS STS Temporary Credentials and AssumeRole"
+description: "Use AWS STS to issue temporary credentials: assume an IAM role, request a session token, or federate Kubernetes workloads with OIDC web identity on Spinifex."
 category: "Identity"
 tags:
   - sts
@@ -18,9 +18,9 @@ resources:
     url: "https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html"
 ---
 
-# STS and Temporary Credentials
+# AWS STS Temporary Credentials and AssumeRole
 
-> Mint short-lived credentials with STS — assume roles, issue session tokens, and federate Kubernetes workloads with OIDC.
+> Use AWS STS to issue temporary credentials: assume an IAM role, request a session token, or federate Kubernetes workloads with OIDC web identity on Spinifex.
 
 ## Table of Contents
 
@@ -43,7 +43,7 @@ STS (Security Token Service) issues **temporary credentials**: an `ASIA`-prefixe
 Spinifex supports the three main ways to obtain them:
 
 - **`assume-role`** — exchange your IAM user credentials for a [role's](/docs/iam-roles-and-instance-profiles) permissions, gated by the role's trust policy.
-- **`get-session-token`** — get a time-boxed copy of your own user's permissions.
+- **`get-session-token`** — get a time-boxed copy of your own [IAM user's](/docs/iam-users-and-policies) permissions.
 - **`assume-role-with-web-identity`** — exchange an OIDC ID token (a Kubernetes ServiceAccount token) for role credentials, with no IAM credentials at all.
 
 EC2 instances get role credentials a fourth way, automatically through [IMDS](/docs/imds) — no STS call needed in the guest.