Hi @AvinashU,
I'm assuming you're on pattern-based AWS Cloud Discovery (MID Server plus Discovery patterns), since the Accessor/OrgAssumeRole/Cross-Account distinction is specific to that architecture and doesn't apply the same way to the Service Graph Connector for AWS. If that assumption's wrong, say so and I'll adjust.
The three pieces map to three different jobs in the trust chain:
- Accessor role: lives in a dedicated discovery-only AWS account. It's the entry point your credential-less setup (MID Server on an EC2 instance, using STS) assumes into first, so you're not putting long-lived keys or a broad-reach role directly on the Management account.
- OrgAssumeRole: a role in your AWS Organizations Management (payer) account that the Accessor assumes next, and which is itself trusted to assume into every Member account under the org, typically deployed org-wide via CloudFormation StackSets or Control Tower. One chain, Accessor to Management to OrgAssumeRole, reaches every member without a role per account.
- Cross-Account AssumeRole: a role created individually in each target account, in or out of an Organization, that the Accessor or Management account assumes directly. No org-wide trust involved, one role and one trust relationship per account.
So your Option 1 is really Accessor to Management to Member role-chaining, riding on the trust AWS Organizations already gives the Management account over its members. Option 2 is the same Accessor hitting each account's own role directly, no chaining through Management.
On the ServiceNow side, you don't need a separate Cloud Account record per member when using OrgAssumeRole. You configure one Cloud Service Account pointing at the Accessor (or Management, if you skip the Accessor hop), then add each member account's ID and Access Role Name as rows in the AWS Org Assume Role Params related list on that record, the underlying table is cloud_service_account_aws_org_assume_role_params. Discovery walks those rows and pulls resources from every listed member without you standing up a Cloud Account per account. To restrict discovery to specific members, just don't add rows for the accounts you want excluded, or scope the discovery schedule to the account IDs you want in scope. One gotcha: if an IAM role gets renamed in AWS, Discovery does not auto-repopulate the Access Role Name field on those rows, that's a manual or scripted bulk update on your end. Cross-Account AssumeRole uses a separate related list, AWS Cross Assume Role Params, same one-row-per-account pattern, but each row carries its own role ARN since there's no org-wide trust to lean on.
For an enterprise AWS Organization, OrgAssumeRole is the better default: fewer roles to provision and rotate, and a new member account joining the org gets onboarded by adding one row instead of standing up a fresh role and trust policy. Cross-account roles make more sense for a handful of accounts outside an Organization, or where one member needs tighter, non-inherited trust that you don't want flowing from Management.
On your best-practice question about the AWS Service Management Connector: it's a different product from what you're describing here, it's built for provisioning and operating AWS resources (Service Catalog, Systems Manager, AWS Config, Security Hub) from inside ServiceNow, not for account/resource discovery or the role topology above. Worth flagging too, AWS is ending support for it on March 31, 2027, so I wouldn't anchor new architecture on it. For discovery specifically you're really choosing between pattern-based Discovery (the model above) and the separate Service Graph Connector for AWS, which is agentless but does less host-level discovery than patterns with SSM.
Thank you,
Vikram Karety
Octigo Solutions INC
