How to create the OpsCurb Core Scan Role

If your team wants a useful first AWS cost scan, start small. A reliable pattern is one core role first, then add optional capabilities only when you actually need them.

What these roles should and should not do

These roles should:

let OpsCurb assume role with the external ID you expect
include only the actions needed for the enabled workflow
avoid any create, modify, or delete permissions

These roles should not:

include broad write permissions “just in case”
bundle unrelated optional workflows into one broad core role
bypass normal tagging, naming, or access-review standards

Step 1: Create the core trust policy

Use the trust relationship generated during onboarding (or from the OpsCurb Terraform module) and confirm the external ID is present. The role should trust only the intended OpsCurb assume-role flow in your AWS account.

Step 2: Create the required Core Scan Role

In the AWS console:

Open IAM and create a new role.
Choose a custom trust policy.
Paste the trust relationship with the external ID condition.
Name the role clearly, for example OpsCurbCoreScanRole.

Step 3: Attach the core permissions policy

Attach only the permissions needed for the baseline scan. Read the policy carefully before saving. The canonical core policy file is aws-console-setup/permissions-policy.core-scan.json. The public Permissions Matrix lists the exact action mapping.

A quick reminder: keep write actions out unless there is a separate, explicit approval path.

Step 4: Validate the core configuration

Before sharing the role ARN with OpsCurb:

confirm the trust policy has the expected principal and external ID
confirm permissions match the baseline feature set you want
confirm the role is in the intended AWS account

If your team prefers CLI validation, an assume-role test is a good final check.

Step 5: Run the first scan

Once the role ARN is configured in OpsCurb:

Connect the account.
Run the first scan.
Review the first-scan brief and top savings findings.

The Core Scan Role stays limited to baseline scan permissions. Your team still decides what actions to take next.

Step 6: Add optional roles only if needed

Optional roles are available for:

Deep Inspect
Advanced log diagnostics
S3 inventory
IAM hygiene
Tag inventory

Connect optional roles later from Settings only when that workflow is needed. Each one should include just the permissions for that specific workflow.

Where OpsCurb helps

This is the trust model OpsCurb is built on: Core Scan Role first, optional scoped capabilities after, no agent model, and no write access by default. That gives startup teams a safer starting point for evaluating AWS waste without giving away mutation rights.

Next steps:

Review Security & Trust
Review the public Permissions Matrix
Preview the Sample First-Scan Report
Book the Free Review to review your first scan live

How to Create the OpsCurb Core Scan Role