Connect an AWS account

Argus scans AWS through a read-only IAM role in the connected account that it assumes with short-lived credentials. Nothing is installed, no keys are copied around, and deleting the role revokes Argus's access at any time.

Prerequisites

• Permission to create an IAM role in the AWS account being connected.
• A free account slot on the plan: 1 cloud account on Free, unlimited on Pro. See Billing & plans.

1. Start the connect wizard

Go to Accounts and click Connect account. Pick Amazon Web Services, then the recommended Assume role method. The wizard asks for:

Field	Value
Account ID	the 12-digit AWS account id
Role ARN	the ARN of the role created in step 2. The role name must start with argus-scan-, e.g. arn:aws:iam::123456789012:role/argus-scan-readonly
External ID	generated by Argus and shown read-only. Copy it into the role's trust policy
Session duration	optional, in seconds, default 3600

Below the fields, the wizard shows the two values only Argus can provide, each with a copy button:

• the Argus scanner principal, the identity that will call the role and that the trust policy must name, and
• the complete role trust policy, prefilled with that principal and the workspace's External ID, ready to paste as is.

The External ID is unique to the workspace and is authored by Argus on the server. It is the isolation boundary AWS recommends for cross-account access, ensuring only that workspace can use the role.

2. Create the role in the AWS account

Create an IAM role whose name starts with argus-scan-. Argus can only assume roles named with that prefix, so a role with any other name never connects. Paste the trust policy shown by the wizard on it; it lets Argus assume the role, scoped to the workspace's External ID:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": { "AWS": "<the Argus scanner principal, from the wizard>" },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringEquals": { "sts:ExternalId": "<your External ID>" }
      }
    }
  ]
}

Attach the two AWS-managed read-only policies the checks rely on:

• arn:aws:iam::aws:policy/SecurityAudit
• arn:aws:iam::aws:policy/job-function/ViewOnlyAccess

The role grants no write access of any kind, and the short-lived credentials Argus obtains never leave AWS.

The two managed policies do not cover every check. A check whose read call the role is not allowed to make cannot return a result for that account, so a scan that reports no failures is not by itself proof that every check ran.

3. Test the connection

Finish the wizard. Argus stores the role configuration server-side and runs an asynchronous connection test, an sts:AssumeRole plus an identity call. It normally lands in a couple of seconds. The account card reports:

• Connected. The account is ready to scan.
• Checking… The test is still in flight. Give it a moment.
• Failed. Re-check the role ARN, the role name prefix, the trust policy, and the External ID, then use Test connection on the account card to retry.

Connect an AWS Organization

On the Pro plan the wizard's AWS step offers a third method, AWS Organizations, that registers many accounts at once. Argus reads the organization through a role in the management account, lets you pick accounts from the organizational unit (OU) tree, then registers each one exactly as in the single-account flow above: one Argus scan role per account, one connection test per account. On the Free plan the method is shown but disabled, with the plan notice.

Prerequisites

• Access to the organization's management account (or a delegated administrator) to create a CloudFormation stack and a StackSet.
• Trusted access for CloudFormation StackSets enabled in the organization's settings, so a service-managed StackSet can reach the member accounts.

1. Set up access

The set-up step shows the workspace's External ID and the Argus scanner principal, each with a copy button, followed by two guided actions:

1. Create the management-account role. Signed in to the management account, open the quick-create link. It launches a stack that creates the role argus-scan-management, with read access to the organization and the same scan permissions as a single-account role, so the management account is scanned too. The External ID is prefilled.
2. Deploy the Argus scan role to the member accounts. Still in the management account, open the StackSets console and create a StackSet with service-managed permissions: paste the template URL shown in the wizard, set the ExternalId parameter to the value above, and target the organization root or the OUs you want scanned. Every targeted account gets the role argus-scan-member. Accounts that join a targeted OU later receive the role automatically.

Paste the stack's ManagementRoleArn output into Management-account role ARN. The wizard checks that it is an IAM role ARN whose name starts with argus-scan-. Tick the confirmation and click Discover accounts.

2. Discovery

Discovery runs in the background: Argus assumes the management-account role and lists the organization's roots, OUs and accounts. It usually takes a few seconds. If it runs longer than about half a minute, the wizard shows how much of the 3-minute limit is left; nothing is registered until you choose accounts. If discovery fails, the wizard names the cause and what to check:

Cause	What to check
The management-account role was not found	The stack has reached CREATE_COMPLETE and the ARN is its ManagementRoleArn output
The role refused the Argus scanner principal	The stack was created with the External ID shown in the wizard and the trust policy was not edited afterwards
The role cannot read the organization	The stack was created with Organizations enabled, from the management account or a delegated administrator
Discovery did not finish in time	The walk ran past the 3-minute limit. Retry; if it keeps happening, tell support how many accounts the organization has

Retry discovery runs it again; Edit setup returns to the previous step.

3. Choose accounts

The OU tree lists every account with its id and email. Selecting an OU selects its active accounts, recursively. Accounts that are already connected to the workspace are marked as such and are never registered twice. Suspended, closing and closed accounts cannot be selected. A pinned toggle includes the management account, scanned through the management-account role. The pencil on a selected row sets the account's alias; the default is its AWS account name. The counter reads X of Y selected; Connect N accounts starts the registration.

4. Connect

Each selected account is registered with its Argus scan role and tested, five at a time, with a live status per row:

• Connected, Testing…, Queued.
• Failed, with the reason. The usual cause is a member account the StackSet has not reached yet. Retry re-runs that account's test; Retry failed re-runs every failed one. Failed accounts stay on the list as Failed, so you can fix the role and use Test connection on the account card later.
• Checking, for a test that is taking longer than expected. You can leave the wizard; the card shows the result once the test finishes.

Continue with connected only closes the wizard while tests are still running, once at least one account has connected. Done closes it after every test has a verdict.

Afterwards

The accounts list groups the organization's accounts under a header with the organization's name and id. Every card shows its Organization unit. A provider group named after the organization is created and kept in step. Sync organization on the header reads the organization again and offers the accounts that joined since the last sync, marked New.

Static keys

For accounts where creating a role is not possible, the Static keys method accepts an access key id, a secret access key, and an optional session token. Prefer the assumed role whenever possible: keys are long-lived credentials that need manual rotation. Keys are stored server-side and never shown again.

Other providers

The same wizard lists connectors for other environments, each with its own read-only auth method: Azure subscriptions with a service principal, Google Cloud projects with a service-account key, Kubernetes clusters, and further SaaS and IaC connectors. AWS is the primary, most complete provider today.