AWS Cloud Discovery using Patterns - Support and Troubleshooting

AWS Cloud Discovery using Patterns Summary This KB article describes the steps to set up the AWS environment for AWS cloud discovery. With this setup AWS cloud discovery will populate into the CMDB. A detailed documentation of the overall configuration setups in AWS portal side and Service now Instance.

Index:

Introduction Types of AWS Credentials Methods of granting access Types of discovery configuration setups based on Credentials Permissions Multi-Account Configuration Models Model 1: Single AWS Account Model 2: Management →Member accounts Model 3: Accessor → Management → Member accounts (Role chaining) Model 4: Accessor → Member/Management Direct Credential-Based discovery Credential-Less discovery

1. Introduction 1.1 Types of Credentials Permanent Credentials:

Permanent credentials are the actual AWS access keys associated with a service account. These are manually added in the AWS Credentials(aws_credentials) table of Now Platform. While managing permanent credentials requires more administrative effort, this approach avoids the complex configurations involved in using temporary credentials configurations.

Temporary Credentials:

Temporary credentials are generated using AWS Security Token Service (AWS STS) for IAM roles. After setting up IAM role-based access in AWS, the MID Server can assume those roles and use temporary credentials to access AWS resources. This method is generally preferred for security and scalability.

1.2 Methods of granting access Trusting Accounts

A trusting account is an AWS account that creates IAM roles and grants permission for an IAM user or role from another AWS account (the trusted account) to assume those roles using AWS Security Token Service (STS) .

In ServiceNow Cloud Discovery scenarios:

Trusting accounts do not store credentials in the ServiceNow instance. Instead, they create IAM roles with discovery permissions These roles trust the IAM identity (user or role) from the trusted/accessor account to assume those roles. At run time, the MID Server uses that IAM identity to assumes these roles and discover resources in the trusting accounts.

Trusted accounts

A trusted account is an AWS account that provids the IAM Identity (user or role) trusted by other AWS accounts (called trusting accounts) for cross-account access. In ServiceNow terminology, this is also referred to as the accessor account.

In ServiceNow Cloud Discovery scenarios:

The trusted account hold the credentials used by MID server These credentials can be either: Permanent credentials from an IAM user (manually entered in ServiceNow), or Temporary credentials , automatically generated when the MID Server is deployed on an EC2 instance with an attached IAM role (instance profile) . This IAM identity must be explicitly trusted in the trust policies of IAM roles in the trusting accounts . This model allows the MID Server to discover resources across multiple accounts without storing separate credentials for each one. Note: If the MID Server runs on an EC2 instance with an instance profile, AWS automatically issues temporary credentials through the instance metadata service.

Summary:

Account Type Description Trusting Account Creates IAM roles that trust the identity from the trusted account to assume them via STS. Trusted Account Holds the IAM user or role whose identity is used to assume roles in other accounts.

1.3 Types of discovery configuration setups based on Credentials ServiceNow Cloud Discovery for AWS supports two main configuration approaches based on how credentials are managed and accessed: Credential-Based Discovery and Credential-less discovery

Credential-Based Discovery

In this setup, permanent AWS credentials (access key ID and secret access key) from the accessor account (trusted account) are securely stored in the ServiceNow instance in the AWS Credentials (aws_credentials) table.

The MID Server uses these credentials to authenticate with AWS and assume roles in the trusting accounts. This setup is simpler to manage when running the MID Server outside AWS. However, it requires careful credential lifecycle management for security and compliance.

Credential-less Discovery

This approach eliminates the need to store AWS credentials in ServiceNow.

The MID Server is deployed on an EC2 instance within the accessor account (trusted account). The EC2 instance is assigned an IAM instance profile role that has the necessary permissions and trust relationships configured. The MID Server uses the EC2 instance's metadata service to retrieve temporary credentials automatically via AWS STS. This method is more secure and aligns with AWS best practices by avoiding hardcoded or long-term credentials. Summary

Setup Type Credential-based Credential-less Credentials in ServiceNow Yes (Permanent credentials for accessor account) No MID Server Location Anywhere (on-prem or cloud) Inside AWS EC2 in Accessor Account Use Case Easier setup outside AWS More secure, preferred for AWS-hosted MID

1.4 Permissions To create custom discovery policies instead of using ReadOnlyAccess refer to the " Permissions " sheet in the official Cloud Discovery patterns spreadsheet

This sheet provides detailed AWS actions required by ServiceNow for discovering various AWS resources.

Using this reference, you can define a tailored IAM policy that grants only the necessary permissions.

2. Multi-Account Configuration Models This section explains how to configure AWS Cloud Discovery in ServiceNow using different AWS account architectures. The configuration depends on how you manage access to AWS resources across multiple accounts.

ServiceNow supports the following credential and trust models for discovering AWS resources using a MID Server :

Support Account Models:

Model Id Name Authentication Type Use case M1 Single AWS Account IAM User (Access Key) IAM Role (EC2 Instance Profile) Use when discovering resources in a single AWS account using either static credentials (IAM User Access Key) or an EC2-attached IAM role . No cross-account access. M2 Management →Member accounts IAM User (Access key) in Management account IAM Role (EC2 Instance Profile) in Management account Use when the Management account holds either IAM User credentials or EC2-Attached IAM Role , and assumes roles in all Member accounts to perform discovery. M3 Accessor → Management → Member accounts ( Role chaining ) IAM User (Access key) in Accessor account IAM Role (EC2 Instance Profile) in Accessor account Use when the Accessor account holds either IAM User credentials or EC2-Attached IAM Role and performs role chaining through the Management account to access Member accounts . Suitable for setups requiring central credential storage and layered trust via a Management account. M4 Accessor → Member/Management Direct IAM User (Access key) in Accessor account IAM Role (EC2 Instance Profile) in Accessor account Use when the Accessor account holds either IAM User credentials or EC2-Attached IAM Role and can directly assume roles in both Management account and Member accounts. Ideal when all accounts trust the Accessor directly , removing the need for role chaining.

2.1 Model 1: Single AWS Account

This section explains how to configure AWS Cloud Discovery in ServiceNow for environments using only one AWS account . This is the simplest model, ideal for customers who do not use multiple AWS accounts or AWS Organizations.

ServiceNow supports two credential models for this configuration:

IAM User with static credentials (Access Key + Secret Key) IAM Role attached to EC2 (Instance Profile), for MID Server hosted on AWS 2.1.1 - Single AWS Account with IAM User (Access Keys)

This requires creating an IAM User with programmatic access and securely storing credentials in ServiceNow .

Section Item Details AWS Side Account Type - Single AWS Account IAM User - Create IAM User with Programmatic access

- Generate Access Key ID & Secret Access Key

IAM User Permissions - Attach ReadonlyAccess or custom discovery policies (Refer Section 1.4) with required AWS permissions to discover AWS resources ServiceNow Side AWS Credentials Table ( aws_credentials )

- Create an entry using IAM User's Access Key ID and Secret Access Key Cloud Service Account ( cloud_service_account ) - Create an entry for this AWS account

- Associate it with the credentials entry from aws_credentials

2.1.2 - Single AWS Account with IAM Role (EC2 Instance Profile)

Use this model when your MID Server is running on an EC2 instance within the same AWS account . Instead of static credentials, you assign an IAM Role to the instance using an EC2 Instance Profile. ServiceNow Discovery uses the role automatically, improving security and manageability.

Section Item Details AWS Side Account Type - Single AWS Account IAM Role Create an IAM Role with EC2 trust relationship Attach ReadonlyAccess or custom discovery policies (Refer section 1.4) with required AWS permissions to discover AWS resources EC2 Instance Profile - Launch the MID Server on an EC2 instance

- Attach the IAM Role to the EC2 instance

ServiceNow Side AWS Credentials Table ( aws_credentials )

- Not required (credentials are dynamically provided by EC2 instance profile ) Mid server configuration property

- Set the MID Server parameter

mid.aws.instance_profile_name = Name of IAM role attached to EC2 instance

Cloud Service Account ( cloud_service_account ) - Create an entry for this AWS account

Note: When using EC2 Instance Profile–based authentication, ensure the MID Server is configured with the system property mid.aws.instance_profile_name , set to the IAM Role name attached to the EC2 instance. This tells the MID Server to retrieve temporary credentials from the instance metadata.

2.2 Model 2: Management →Member accounts

This model is used when a Management account centrally discovers AWS resources across multiple Member accounts. The Management account assumes a discovery role in each Member account using AWS STS AssumeRole.

Note: You may skip custom role creation in Member accounts if you're using AWS Organizations and the default role OrganizationAccountAccessRole . Ensure the Management account has permission to assume it.

ServiceNow supports two variants for authentication:

Option When to Use IAM User (Access Key) in Management Account Use if MID Server runs outside. AWS Static credentials required. IAM Role (EC2 Instance Profile) in Management Account Use if MID Server runs on an EC2 in the Management account. Credentials are dynamically provided by the instance profile. 2.2.1 IAM User in Management Account

MID Server uses Access Key + Secret Key to authenticate and assumes IAM roles in all Member accounts.

Section Account Item Details AWS Side Account Structure - Management Account - Member Accounts Management Account IAM User - Create IAM user with programmatic access

- Generate Access Key & Secret Key

- Attach policy allowing sts:AssumeRole on member roles

- Attach ReadonlyAccess or custom discovery policies (Refer section 1.4) with required AWS permissions to discover AWS resources

- Additionally , ensure the IAM User in the Management account has permissions to make AWS Organizations API calls (e.g., ListAccounts, DescribeOrganization) to dynamically discover member accounts. - This can be done by attaching the AWS-managed policy AWSOrganizationsReadOnlyAccess or including equivalent actions in a custom policy

Member Account IAM Role - Create custom IAM role in for each member account

- Trust policy allows management account to assume this role

- Attach ReadonlyAccess or custom discovery policies (Refer section 1.4) with required AWS permissions to discover AWS resources

Service Now Side Management Account AWS Credentials Table ( aws_credentials ) - Add a entry for Management account IAM user( Access Key + Secret Key) Cloud Service Account ( cloud_service_account ) Create an entry for Management account

Account Id -> Management account ID Discovery Credentials -> reference to accessor account credentials Datacenter Type -> AWS Datacenter (cmdb_ci_aws_datacenter) Is Management account -> Checked Member Account Cloud Service Account ( cloud_service_account ) Create an entry for member account

Account Id -> member account account ID Discovery Credentials -> leave it blank Datacenter Type -> AWS Datacenter (cmdb_ci_aws_datacenter) Is Management account -> Uncheck Accessor Account -> select management account Note : 1. This step repeated for each member account

2. Skip this step using default role (OrganizationAccountAccessRole) in member accounts

Cloud Service Account AWS Org Assume Role Params Table ( cloud_service_account_aws_org_assume_role_params ) - Create entry for each member account • Cloud Service Account ->Member account • Access Role Name -> Full custom IAM Role ARN

Note: Skip this step using default role (OrganizationAccountAccessRole) in member accounts

2.2.2 IAM Role (EC2 Instance Profile) in Management Account

MID Server is hosted on an EC2 instance in the Management account and uses the EC2 IAM role to assume roles in member accounts.

Section Account Item Details AWS Side Account Structure - Management Account - Member Accounts Management Account IAM Role - Create an IAM Role with EC2 trust relationship

- Attach policy allowing sts:AssumeRole on member roles

- Attach ReadonlyAccess or custom discovery policies (Refer section 1.4) with required AWS permissions to discover AWS resources

- Additionally , ensure the IAM Role in the Management account has permissions to make AWS Organizations API calls (e.g., ListAccounts, DescribeOrganization) to dynamically discover member accounts. - This can be done by attaching the AWS-managed policy AWSOrganizationsReadOnlyAccess or including equivalent actions in a custom policy

Member Account IAM Role - Create custom IAM role in for each member account

- Trust policy allows management account to assume this role

- Attach ReadonlyAccess or custom discovery policies (Refer section 1.4) with required AWS permissions to discover AWS resources

Service Now Side Management Account AWS Credentials Table ( aws_credentials ) - Not required (credentials are dynamically provided by EC2 instance profile ) Mid server configuration property - Set the MID Server parameter mid.aws.instance_profile_name = Name of IAM role attached to EC2 instance

Cloud Service Account ( cloud_service_account ) Create an entry for Management account

Account Id -> Management account ID Discovery Credentials -> leave it blank Datacenter Type -> AWS Datacenter (cmdb_ci_aws_datacenter) Is Management account -> Checked Member Account Same as Section "2.2.1 IAM User in Management Account" -> Member account configurations (one entry per Member account with correct IAM Role ARN)

2.3 Model 3: Accessor → Management → Member accounts (Role chaining)

This configuration is used when AWS resource discovery is initiated by a centralized Accessor account, which uses role chaining to access a Management account, and then further assumes roles into multiple Member accounts.

ServiceNow supports two variants for authentication:

Option When to Use IAM User (Access Key) in Accessor Account Use if MID Server runs outside AWS or cannot assume an EC2 instance role. Static credentials required. IAM Role (EC2 Instance Profile) in Accessor Account Use if MID Server runs on an EC2 in the Accessor account. Credentials are dynamically provided by the instance profile. 2.3.1 IAM User in Accessor Account

MID Server uses Accessor account (Access Key + Secret Key) to authenticate and assumes IAM role in management account. Management IAM role assumes role in all Member accounts.

Refer 3 . Credential-Based discovery section for clear step by step.

Section Account item Details AWS Side Account Structure Accessor Account - IAM User Management Account (Trusts Accessor account && Trusted by Member account) Member accounts (Trusts Management account) Accessor Account IAM User Create IAM user with programmatic access IAM policy allows sts:AssumeRole on role in Managment Account Attach ReadonlyAccess or custom discovery policies (Refer section 1.4) with required AWS permissions to discover AWS resources Management Account IAM Role Create IAM role Trust policy: allows Accessor IAM User to assume this role Permissions: sts:AssumeRole on roles in Member Accounts Attach ReadonlyAccess or custom discovery policies (Refer section 1.4) with required AWS permissions to discover AWS resources Additionally , ensure the IAM Role in the Management account has permissions to make AWS Organizations API calls (e.g., ListAccounts, DescribeOrganization) to dynamically discover member accounts. - This can be done by attaching the AWS-managed policy AWSOrganizationsReadOnlyAccess or including equivalent actions in a custom policy Member Account IAM Role Create IAM role Trust policy: allows IAM Role from Management Account to assume it Attach ReadonlyAccess or custom discovery policies (Refer section 1.4) with required AWS permissions to discover AWS resources Trust Chain Summary Accessor Account IAM User → assumes → IAM Role in Management Account → assumes → IAM Role in Member Accounts Permission Summary Accessor IAM User: sts:AssumeRole on Management Role: SN_MGMT_ASSUME_ROLE Management IAM Role: sts:AssumeRole on Member Role: SN_MEMBER_ACCOUNT_ROLE For all Accounts(Accessor / Management / member account) Read-only or discovery-specific permissions Service Now Side Accessor Account AWS Credentials Table ( aws_credentials ) Create a credential entry for Accessor account IAM user( Access Key + Secret Key) Cloud Service Account ( cloud_service_account ) Create an entry for accessor account

Account Id -> Accessor account ID Discovery Credentials -> reference to accessor account credentials Datacenter Type -> AWS Datacenter (cmdb_ci_aws_datacenter) Is Management account -> false Management Account Cloud Service Account ( cloud_service_account )

Create an entry for Management account

Account Id -> Management account ID Discovery Credentials -> leave it blank Datacenter Type -> AWS Datacenter (cmdb_ci_aws_datacenter) Is Management account -> Checked Accessor Account -> Reference to Accessor account Cloud Service Account AWS Cross Assume Role Params ( cloud_service_account_aws_cross_assume_role_params ) Create entry for Management account • Cloud Service Account ->Management account • Access Role Name -> Full Management IAM Role ARN Member Account Cloud Service Account ( cloud_service_account )

Create an entry for member account

Account Id -> member account account ID Discovery Credentials -> leave it blank Datacenter Type -> AWS Datacenter (cmdb_ci_aws_datacenter) Is Management account -> Uncheck Accessor Account -> select management account Note : This step repeated for each member account

Cloud Service Account AWS Org Assume Role Params Table ( cloud_service_account_aws_org_assume_role_params )

Create entry for each member account • Cloud Service Account ->Member account • Access Role Name -> Full ARN of the member account IAM Role

Note: Skip if using AWS default role OrganizationAccountAccessRole

2.3.2 IAM Role (EC2 Instance Profile) in Accessor Account

MID Server is hosted on an EC2 instance in the Accessor account and uses the EC2 IAM role to assume roles in Management account. Management Account IAM Role assumes in all member accounts.

When to Use Use this variant when:

Your MID Server runs on an EC2 instance inside the Accessor account You want to avoid managing static credentials (Access Key & Secret) You want to use IAM Role-based dynamic credentials via instance metadata

Refer 4 . Credential-Less discovery section for clear step by step.

Section Account item Details AWS Side Account Structure Accessor Account (Ec2 Instance Profile) Management Account (Trusts Accessor account && Trusted by Member account) Member accounts (Trusts Management account) Accessor Account IAM Role Create an IAM Role with EC2 trust relationship AM policy allows sts:AssumeRole on role in Management Account Attach ReadonlyAccess or custom discovery policies (Refer section 1.4) with required AWS permissions to discover AWS resources Management Account IAM Role Create IAM role Trust policy: allows Accessor IAM Role to assume this role Permissions: sts:AssumeRole on roles in Member Accounts Attach ReadonlyAccess or custom discovery policies with required AWS permissions to discover AWS resources Additionally , ensure the IAM Role in the Management account has permissions to make AWS Organizations API calls (e.g., ListAccounts, DescribeOrganization) to dynamically discover member accounts. - This can be done by attaching the AWS-managed policy AWSOrganizationsReadOnlyAccess or including equivalent actions in a custom policy Member Account IAM Role Create IAM role Trust policy: allows IAM Role from Management Account to assume it Attach ReadonlyAccess or custom discovery policies with required AWS permissions to discover AWS resources Trust Chain Summary Accessor Account IAM User → assumes → IAM Role in Management Account → assumes → IAM Role in Member Accounts Permission Summary Accessor IAM User: sts:AssumeRole on Management Role: SN_MGMT_ASSUME_ROLE Management IAM Role: sts:AssumeRole on Member Role: SN_MEMBER_ACCOUNT_ROLE For all Accounts(Accessor / Management / member account) Read-only or discovery-specific permissions Service Now Side Accessor Account AWS Credentials Table ( aws_credentials ) Not required (credentials are dynamically provided by EC2 instance profile ) Mid server configuration property Set the MID Server parameter mid.aws.instance_profile_name = Name of IAM role attached to EC2 instance

Management Account Same as Section "2.3.1 IAM User in Accessor Account" -> Management account configurations (one entry for Service account and one entry for cloud_service_account_aws_cross_assume_role_params) Member Account Same as Section "2.3.1 IAM User in Accessor Account" -> Member account configurations (one entry per Member account with correct IAM Role ARN)

2.4. Model 4: Accessor → Member/Management Direct

This configuration assumes that the Accessor Account IAM User/Role directly assumes IAM roles in management account and all Member Accounts. Both Management and Member Accounts trust the Accessor IAM User directly – No Role Chaining.

2.4.1 IAM User in Accessor Account Direct

MID Server uses Accessor account (Access Key + Secret Key) to authenticate and assumes IAM role in both Management account and all member accounts.

Section Account item Details AWS Side Account Structure Accessor Account (IAM User) Management Account (Trusting Accessor account) Member accounts (Trusting Accessor account directly) Accessor Account IAM User Create IAM user with programmatic access IAM policy allows sts:AssumeRole on role in Management Account ( SN_MGMT_ASSUME_ROLE ) and All member accounts( SN_MEMBER_ACOCUNT_ASSUME_ROLE ) Attach ReadonlyAccess or custom discovery policies (Refer section 1.4) with required AWS permissions to discover AWS resources Management Account IAM Role Create IAM role (e.g., SN_MGMT_ASSUME_ROLE) Trust policy allows Accessor IAM User ARN to assume this role Attach ReadonlyAccess or custom discovery policies (Refer section 1.4) with required AWS permissions to discover AWS resources Additionally , ensure the IAM Role in the Management account has permissions to make AWS Organizations API calls (e.g., ListAccounts, DescribeOrganization) to dynamically discover member accounts. - This can be done by attaching the AWS-managed policy AWSOrganizationsReadOnlyAccess or including equivalent actions in a custom policy Member Account IAM Role Create IAM role (e.g., SN_MEMBER_ACCOUNT_ROLE) Trust policy allows Accessor IAM User ARN to assume this role Attach ReadonlyAccess or custom discovery policies (Refer section 1.4) with required AWS permissions to discover AWS resources Trust Chain Summary Accessor Account IAM User → assumes → SN_MGMT_ASSUME_ROLE (in Management Account) Accessor Account IAM User → assumes → SN_MEMBER_ACCOUNT_ROLE (in Member Accounts) Permission Summary Accessor IAM User: sts:AssumeRole on Management Role: SN_MGMT_ASSUME_ROLE sts:AssumeRole on Member Role: SN_MEMBER_ACCOUNT_ROLE For all Accounts(Accessor / Management / member account) Read-only or discovery-specific permissions Service Now Side Accessor Account AWS Credentials Table ( aws_credentials ) Create a credential entry for Accessor account IAM user( Access Key + Secret Key) Cloud Service Account ( cloud_service_account ) Create an entry for accessor account

Account Id -> Accessor account ID Discovery Credentials -> reference to accessor account credentials Datacenter Type -> AWS Datacenter (cmdb_ci_aws_datacenter) Is Management account -> false Management Account Cloud Service Account ( cloud_service_account )

Create an entry for Management account

Account Id -> Management account ID Discovery Credentials -> leave it blank Datacenter Type -> AWS Datacenter (cmdb_ci_aws_datacenter) Is Management account -> Checked Accessor Account -> Reference to Accessor account Cloud Service Account AWS Cross Assume Role Params ( cloud_service_account_aws_cross_assume_role_params ) Create entry for Management account • Cloud Service Account ->Management account • Access Role Name -> Full Management IAM Role ARN Member Account Cloud Service Account ( cloud_service_account )

Create an entry for member account

Account Id -> member account account ID Discovery Credentials -> leave it blank Datacenter Type -> AWS Datacenter (cmdb_ci_aws_datacenter) Is Management account -> Uncheck Accessor Account -> select management account Note : This step repeated for each member account

Cloud Service Account AWS Cross Assume Role Params ( cloud_service_account_aws_cross_assume_role_params )

Create entry for each member account • Cloud Service Account ->Member account • Access Role Name -> Full ARN of the member account IAM Role

2.4.2 IAM Role (EC2 Instance Profile) in Accessor Account Direct

MID Server is hosted on an EC2 instance in the Accessor account and uses the EC2 IAM role to assume roles in management account and all member accounts directly.

When to Use Use this variant when:

Your MID Server runs on an EC2 instance inside the Accessor account You want to avoid managing static credentials (Access Key & Secret) You want to use IAM Role-based dynamic credentials via instance metadata Accessor account assume roles in management account and all member accounts directly.

Section Account item Details AWS Side Account Structure Accessor Account (EC2 Instance Profile) Management Account (Trusting Accessor account) Member accounts (Trusting Accessor account directly) Accessor Account IAM User Create an IAM Role with EC2 trust relationship AM policy allows sts:AssumeRole on role in Management Account Attach ReadonlyAccess or custom discovery policies with required AWS permissions to discover AWS resources Management Account IAM Role Create IAM role Trust policy allows Accessor IAM Role ARN to assume this role Permissions: sts:AssumeRole on roles in Member Accounts Attach ReadonlyAccess or custom discovery policies with required AWS permissions to discover AWS resources Additionally, ensure the IAM Role in the Management account has permissions to make AWS Organizations API calls (e.g., ListAccounts, DescribeOrganization) to dynamically discover member accounts. - This can be done by attaching the AWS-managed policy AWSOrganizationsReadOnlyAccess or including equivalent actions in a custom policy Member Account IAM Role Create IAM role (e.g., SN_MEMBER_ACCOUNT_ROLE) Trust policy allows Accessor IAM User ARN to assume this role Attach ReadonlyAccess or custom discovery policies with required AWS permissions to discover AWS resources Trust Chain Summary Accessor Account IAM User → assumes → in Management Account) Accessor Account IAM User → assumes → in all Member Accounts Permission Summary Accessor IAM User: sts:AssumeRole on Management Role sts:AssumeRole on Member Role For all Accounts(Accessor / Management / member account) Read-only or discovery-specific permissions Service Now Side Accessor Account AWS Credentials Table ( aws_credentials ) Not required (credentials are dynamically provided by EC2 instance profile ) Mid Server configuration property Set the MID Server parameter mid.aws.instance_profile_name = Name of IAM role attached to EC2 instance

Cloud Service Account ( cloud_service_account ) Create an entry for accessor account

Account Id -> Accessor account ID Discovery Credentials -> Leave it blank Datacenter Type -> AWS Datacenter (cmdb_ci_aws_datacenter) Is Management account -> false Management Account Same as Section "2.4.1 IAM User in Accessor Account Direct" -> Management account configurations (one entry for Service account and one entry for cloud_service_account_aws_cross_assume_role_params)

Member Account Same as Section "2.4.1 IAM User in Accessor Account Direct" -> Member account configurations (one entry per Member account with correct IAM Role ARN)

3. Credential-Based discovery This section provides a step-by-step guide to configure AWS Cloud Discovery using permanent IAM user credentials in Model 3: Accessor → Management → Member accounts (Role chaining) .

In this setup, ServiceNow uses static IAM credentials (Access Key & Secret) from the Accessor account to assume IAM roles across Management and Member accounts to discover AWS resources.

You will configure three types of AWS accounts:

Accessor Account: Hosts the IAM user used by the MID Server Management Account: Assumes roles into Member accounts Member Accounts

Account Setup Model

3.1 Account types

3.1.1. Accessor Account (Trusted Account) -> IAM User

Key Role: Holds an IAM User with permanent credentials and is trusted by the management account

This account contains as IAM user with permanent AWS credentials (Access Key ID and Secret Key) configured in the ServiceNow Connections & Credentials module MID Server uses these credentials to assume roles in Management account during discovery It may be: A member account within the AWS Organization, or An external account outside the organization Acted as trusted account for the management account Can also contain AWS resources to be discovered 3.1.2. Management Account -> IAM Role

Key Role: Trusting account for the accessor account and trusted account for member accounts

The management account (previously called the master account) is the root account of the AWS Organization. It trusts the IAM user from the accessor account by defining a role that allows cross-account discovery via the MID Server In this context act as trusting account It also defines IAM roles that are assumed by the MID Server during discovery in member accounts , making it a trusted account for those accounts. Can also contain AWS resources to be discovered 3.1.3. Member accounts (Trusting Accounts) -> IAM Role

Key Role: IAM role trust the management account for access.

These are accounts under the organization They trust IAM roles from the management account , allowing the MID Server to perform cross-account discovery. Contain AWS resources that are subject to discovery. Summary

Account Type Act as Trust Relationship Accessor Account Trusted Account (Accessor) Provides IAM user trusted by the Management Account Management account Trusting (of Accessor) & Trusted (for Members) Trusts the Accessor IAM user; its role is assumed by member accounts Member account Trusting Account Trusts the discovery role owned by the Management Account

3.2 Accessor Account Configuration This section outlines the step-by-step process to configure the Accessor Account in both the AWS Portal and the ServiceNow instance .

3.2.1 Accessor Account Setup in AWS portal 3.2.1.1. Create an IAM User (Ex. SN_ACCESSOR_ACCOUNT_USER)

Navigate to the IAM > Users > create user

Step 1 : Specify user defaults

User name: Enter user name (ex., SN_ACCESSOR_ACCOUNT_USER ) Step 2: Set Permissions

Add AWS managed ReadonlyAccess policy or custom policy (Refer section 1.4) that grants required permissions for discovery Step 3: Review and create

Create 3.2.1.2. Add Inline Policy to Assume Roles in Management Account

Attach an inline policy to the IAM user allowing it to assume a role in the Management account. (ex. SN_MGMT_ACCOUNT_ROLE )

Example inline policy: { "Version": "2012-10-17", "Statement": [ { "Sid": "AllowAssumeRole", "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": "arn:aws:iam:: :role/SN_MGMT_ACCOUNT_ROLE" } ] } Note: The IAM role (e.g., SN_MGMT_ACCOUNT_ROLE ) referenced here must be created in the Management Account. This will be covered in a later section.

3.2.1.3. Generate Access key

Go to the IAM user created above. under the Secutiry credentilas tab, generate a new Access Key : Create access key Securely store the Access Key and Secret Key — these will be required during configuration in ServiceNow. outcome: The accessor account is now configured with the following:

An IAM user that has: Permissions to discover resources in own account Permissions to assume a role in the Management Account via sts:AssumeRole A generated Access Key and Secret Key for authentication with ServiceNow Important:

Retain the following details for use in later configuration steps:

Accessor Account ID IAM User Name IAM User Access Key and Secret Key 3.2.2 Accessor Account Setup in ServiceNow Instance

Step 3.2.2.1: Add Accessor Credentials

Go to the Connections & Credentials -> Credentials Create a new entry of type AWS Credentials , and add the IAM User’s Access Key and Secret Key Step 3.2.2.2: Create a Cloud Service Account

Navigate to: Workspaces -> Cloud discovery Workspace -> Cloud discovery -> New discovery schedule Fill in Schedule Details: Choose the provider: AWS Discovery schedule name : Your preferred name of schedule discovery schedule name -> Cloud provider ->AWS MID selection type: Based on your AWS discovery design Next 3. Create Service Account: Service Account -> New Service account

Name : Friendly name Account ID : Accessor Account Id Credential: Link to the credential created above Datacenter Type: AWS Test account -> It takes couple of minutes. Step 3.2.2.3: Test Service Account

Use the Test account button on the service account record. This triggers a background check and creates a Discovery Status record. You can review the logs under the Discovery Status to verify results. Test Account Troubleshooting:

This creates a record in Discovery status table. Go to Discovery status -> Search for description: " Perform validation account - " ->Refer to the most recent log for troubleshooting if validation fails. outcome:

Service Account validation should be successful. The MID Server can now use this accessor account to assume roles in the Management Account for cloud discovery.

Optional: Create Discovery Schedule for Accessor Account :

After validating the Accessor account’s service account, you may proceed to create a discovery schedule for it — only if you intend to discover resources within the Accessor account itself.

Use Case: If the Accessor account contains AWS resources (e.g., EC2, S3) to be discovered independently of any Management or Member account.

Skip this step if:

The Accessor account is already part of the AWS Organization under the Management account, and You plan to create a centralized discovery schedule from the Management account (which will automatically include the Accessor if it’s a Member account)

3.3 Management account Configuration

This section outlines the step-by-step process to configure the Management Account in both the AWS Portal and the ServiceNow instance .

3.3.1 Management Account Setup in AWS portal 3.3.1.1. Create an IAM Role (Ex. SN_MGMT_ACCOUNT_ROLE)

Navigate to the IAM > Roles > create role

Step 1 : Select trusted entity

Type: Custom trust policy Add principal -> principal type : IAM Users -> ARN -> arn:aws:iam::{Account}:user/{UserName} Replace {Account} with Actual Accessor Account ID and {UserName} with IAM user name created in Accessor account Add principal Sample custom trust policy { "Version": "2012-10-17", "Statement": [ { "Sid": "Statement1", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam:: :user/ " }, "Action": "sts:AssumeRole" } ] } Step 2 : Add permissions -> Add AWS managed ReadonlyAccess policy or custom policy (Refer section 1.4) that grants required permissions for discovery

Add AWSOrganizationsReadOnlyAccess policy.

Note: AWSOrganizationsReadOnlyAccess is optional if the AWS managed ReadonlyAccess policy used

Step 3: Name, review, and create

Role name: SN_MGMT_ACCOUNT_ROLE ( management IAM role (e.g., SN_MGMT_ACCOUNT_ROLE ) used for IAM inline policy creation for Accessor account IAM user)

Step 4: Create role

3.3.1.2. Add Inline Policy to Assume Roles in member accounts

Attach an inline policy to the SN_MGMT_ACCOUNT_ROLE that allows it to assume roles in all member accounts.

{ "Version": "2012-10-17", "Statement": [ { "Sid": "VisualEditor0", "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": "arn:aws:iam::*:role/SN_MEMBER_ACCOUNT_ROLE" } ] } Note: The SN_MEMBER_ACCOUNT_ROLE must be created in each member account later.

outcome: The Management account is now configured with the following:

An IAM Role that has: Trust relationship with Accessor account IAM user Permissions to discover resources within the management account Permissions to assume a role in each member account via sts:AssumeRole Permission to discover sub accounts - AWSOrganizationsReadOnlyAccess policy Important:

Retain the following details for use in later configuration steps:

Management Account ID ARN of IAM Role - SN_MGMT_ACCOUNT_ROLE 3.3.2 Management Account Setup in ServiceNow Instance

Create a Cloud Service account for the Management Account:

Navigate to: Workspaces -> Cloud discovery Workspace -> Cloud discovery -> New discovery schedule Fill in Schedule Details: Choose the provider: AWS Discovery schedule name : Your preferred name of schedule discovery schedule name -> Cloud provider ->AWS MID selection type: Based on your AWS discovery design Next 3. Create Service Account: Service Account -> New Service account

Name : Friendly name fro account Account ID : Management Account Id Access Role Name: Full ARN of Management account IAM role( SN_MGMT_ACCOUNT_ROLE ) Select Accessor Account: Select accessor account from List. Accessor Cloud Service Account already created and validated in step 2.2.2 Accessor Account Setup in ServiceNow Instance Test account -> It takes couple of minutes. Test account validation success then it discover all member accounts under management account Test Account Troubleshooting:

This creates a record in Discovery status table. Go to Discovery status -> Search for description: " Perform validation account - " ->Refer to the most recent log for troubleshooting if validation fails. Go to Discovery status -> Search for description: " Perform Refresh Member Accounts for schedule - " ->Refer to the most recent log for relevant details. outcome:

Successful validation of the Management Account Service Account Discovery ready to fetch data from all member accounts trusted by the Management Account

Optional: Create Discovery Schedule for Management Account

Note: After validating the Management account’s service account, you may proceed to create a discovery schedule for it — only if you intend to discover resources within the Management account itself at this stage.

However, if you are planning to create a centralized discovery schedule from the Management account (which will also automatically include all configured Member accounts), you should skip creating the schedule now.

Instead, continue with the configuration of all required Member accounts, and create the schedule after completing those steps to enable full multi-account discovery in one execution.

3.4 Member account Configuration This section outlines the step-by-step process to configure the Member Account in both the AWS Portal and the ServiceNow instance .

Note: This process must be repeated for every member account you want to discover.

3.4.1 Member Account Setup in AWS portal 3.4.1.1. Create an IAM Role (Ex. SN_MEMBER_ACCOUNT_ROLE)

Navigate to the IAM > Roles > create role

Step 1 : Select trusted entity

Type: Custom trust policy Add principal -> principal type : IAM Roles -> ARN -> arn:aws:iam:: {Account} :role/ {RoleNameWithPath} Replace {Account} with Actual Member Account ID and { RoleNameWithPath } with IAM Role name (e.g., SN_MGMT_ACCOUNT_ROLE ) created in the management account Add principal Example custom trust policy { "Version": "2012-10-17", "Statement": [ { "Sid": "Statement1", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam:: :role/SN_MGMT_ACCOUNT_ROLE" }, "Action": "sts:AssumeRole" } ] } Step 2 : Add permissions -> Attach AWS managed ReadonlyAccess policy or custom discovery policy that grants required permissions for discovery

Step 3: Name, review, and create

Role name: SN_MEMBER_ACCOUNT_ROLE ( Member Account IAM role (e.g., SN_MEMBER_ACCOUNT_ROLE ) used for IAM inline policy creation for Management account IAM Role)

Step 4: Create role

outcome: The Member Account is now configured with the following:

An IAM Role ( SN_MEMBER_ACCOUNT_ROLE ) that has: Trust relationship with Management account IAM Role Permissions to discover resources within the member account Important:

Retain the following details for use in later configuration steps:

Member Account ID Full ARN of created IAM Role - SN_MEMBER_ACCOUNT_ROLE

3.4.2 Member Account Setup in ServiceNow Instance

Step1: Add Org Assume Role Parameters:

Navigate to: Cloud Provisioning and Governance -> Organization Access Parameters -> AWS Org Assume Role Parameters-> New

Form Fileds:

Access role name: Complete ARN of Member Account IAM Role (Ex., arn:aws:iam:: :role/SN_MEMEER_ACCOUNT_ROLE

Cloud service account: Select Management account (created in earlier steps)

Note: This step need to be completed for all member accounts. If all member accounts use the same IAM role name, you can use a wildcard for the account ID in the ARN: arn:aws:iam::*:role/SN_MEMEER_ACCOUNT_ROLE -> the account id in IAM Role is replaced by a '*'. The MID Server will substitute in the appropriate account number during discovery.

Step 2: (Optional) Create a Cloud Service account for the Member Account:

You do not need to create a separate Service Account in ServiceNow for each member account. Instead, the Management Account’s Service Account will be used to discover all member accounts.

However, if the member account is not already present in the cmdb_ci_cloud_service_account table, you can manually create it for testing.

Step 3: (Optional) Below step is optional for existing member accounts. Test account trouble shooting is same as Management account

Test Account Troubleshooting:

This creates a record in Discovery status table. Go to Discovery status -> Search for description: " Perform validation account - " Refer to the most recent log for troubleshooting if validation fails. outcome:

Successful validation of the Member Account Service Account

Final Step: Create Cloud Discovery Schedule for Management and Member Accounts Now that the Management account and all required Member accounts have been fully configured, you can proceed to create a Cloud Discovery Schedule from the Management account. This schedule will:

Discover resources in the Management account Automatically discover resources in all trusted Member accounts Use the role chaining setup established earlier Outcome: The discovery process will use the Management account’s IAM role to assume into all configured Member accounts. Resources from both the Management and Member accounts will be discovered and populated in the CMDB 4. Credential-less discovery This section provides a step-by-step guide to configure AWS Cloud Discovery using IAM Role (EC2 Instance Profile) in Accessor Account in Model 3: Accessor → Management → Member accounts (Role chaining) .

What is Credential-less Discovery? Credential-less discovery allows ServiceNow to perform AWS discovery without using permanent IAM credentials (i.e., Access Key and Secret Key). Instead, the MID Server runs on an EC2 instance in the Accessor account that is assigned an IAM Role . This role provides temporary credentials through the Instance Metadata Service (IMDS).

This model improves security by eliminating the need to store long-term credentials and aligns with AWS best practices for short-lived credential usage.

In this setup, Discovery allows ServiceNow Cloud Discovery to access AWS accounts without using long-term, manually managed credentials (like IAM user access keys) . Instead, it leverages temporary credentials provided by AWS through instance metadata when the MID Server runs on an EC2 instance with an appropriate IAM Role attached.

You will configure three types of AWS accounts:

Accessor Account: Hosts the IAM Role attached to EC2 instance profile Management Account: Assumes roles into Member accounts Member Accounts How it works

In a credential-less setup, ServiceNow uses Mid server to generate temporary credentials for accessor using instance profile. In credential-less setup, there are no permanent IAM credentials. Instead: The MID Server runs on an EC2 instance in the Accessor account. The EC2 instance is assigned an IAM Role with the required permissions to assume a role in the Management account. This role uses the Instance Metadata Service to provide temporary credentials. The MID Server retrieves these credentials at runtime , and uses them to: Assume a role in the Management account The Management account then assumes roles into each Member account Discovery proceeds across the account hierarchy using this trust chain.

Account Structure Comparison

Account Type Credential-based Discovery Credential-less Discovery Accessor Account - IAM User permanent credentials

- Mid Server can be run anywhere where (on-prem/ EC2 instance)

- IAM user with sts:AssumeRole permission to Management account

- IAM Role trust relationship to the EC2 Service

- IAM role attached to EC2 instance

- MID server must run on the same EC2 instance

- IAM Role with sts:AssumeRole permission to Management account

Management Account - Trust relationship with Accessor Account IAM User - Trust relationship with Accessor Account IAM Role attched to the EC2 instance Member Account - IAM Role trusted by Management Account - No change from credential-based setup

Account Setup Model

4.1 Account types

Credential-less discovery still involves configuring the same three types of accounts:

4.1.1. Accessor Account (Trusted Account) -> EC2 instance with IAM Role attached

Key Role: Holds EC2 instance with IAM Role attached and IAM Role is trusted by the management account

It trusts the EC2 service Hosts the MID server on an EC2 instance MID Server uses these credentials to assume roles in Management account during discovery It may be: A member account within the AWS Organization, or An external account outside the organization Acted as trusted account for the management account Can also contain AWS resources to be discovered 4.1.2. Management Account -> IAM Role

Key Role: Trusting account for the accessor account and trusted account for member accounts

The management account (previously called the master account) is the root account of the AWS Organization. It trusts the IAM Role from the accessor account by defining a role that allows cross-account discovery via the MID Server In this context act as trusting account It also defines IAM roles that are assumed by the MID Server during discovery in member accounts , making it a trusted account for those accounts. Can also contain AWS resources to be discovered 4.1.3. Member accounts (Trusting Accounts) -> IAM Role

Key Role: IAM role trust the management account for access.

These are accounts under the organization They trust IAM roles from the management account , allowing the MID Server to perform cross-account discovery. Contain AWS resources that are subject to discovery. Summary

Account Type Act as Trust Relationship Accessor Account Trusted Account (Accessor) Provides IAM Role trusted by the Management Account Management account Trusting (of Accessor) & Trusted (for Members) Trusts the Accessor IAM Role; its role is assumed by member accounts Member account Trusting Account Trusts the discovery role owned by the Management Account

4.2 Accessor Account Configuration This section outlines the step-by-step process to configure the Accessor Account in both the AWS Portal for credential-less discovery and the ServiceNow instance .

4.2.1 Accessor Account Setup in AWS portal This section outlines the step-by-step instructions to configure the Accessor Account in the AWS Portal for credential-less discovery, where the MID Server runs on an EC2 instance using an IAM Role instead of permanent credentials.

Note: These steps apply to the account where the MID Server is hosted (Accessor Account).

4.2.1.1. Create an IAM Role (Ex. SN_MID_SERVER_EC2_ROLE)

Navigate to the IAM > Roles > create role

Step 1 : Select trusted entity

Trusted entity type: AWS service Use case -> Service or use case: EC2 Click Next: Permissions Step 2 : Add permissions -> Add AWS managed ReadonlyAccess policy or custom policy that grants required permissions for discovery

Step 3: Name, review, and create

Role name: SN_MID_SERVER_EC2_ROLE

Step 4: Create role

4.2.1.2. Add Inline Policy to Assume Role in Management Account

Attach an inline policy to the Accessor Account IAM role created in above step allowing it to assume a role in the Management account. (ex. SN_MGMT_ACCOUNT_ROLE )

Go to newly created role (Ex., SN_MGMT_ACCOUNT_ROLE )

Navigate to Permissions -> Create inline policy

Step 1: Specify permission

Select a service : STS

Action allowed: Write -> AssumeRole

Add ARN : Specify ARN -> other account: Management Account ID>

Resource role name with path: Management account IAM Role (Ex., SN_MGMT_ACCOUNT_ROLE) (to be created later)

Click Add ARNs

Step 2: Review and create

Policy name : friendly name (ex., InlinePolicyToAllowAssumeRoleToMgmtAccount)

Create Policy

Example inline policy: { "Version": "2012-10-17", "Statement": [ { "Sid": "AllowAssumeRole", "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": "arn:aws:iam:: :role/SN_MGMT_ACCOUNT_ROLE" } ] } This inline policy enables the EC2 IAM Role to assume the Management Account’s discovery role during runtime

Note: The IAM role (e.g., SN_MGMT_ACCOUNT_ROLE ) referenced here must be created in the Management Account. This will be covered in a later section.

4.3.1.3. Attach IAM role to EC2 instance Hosting the MID Server

Navigate to Ec2 > instances > Choose the instance where the MID server (or will be) is installed If the instance is not yet created, create it before proceeding. Go to Actions > Security > Modify IAM role under IAM role -> select IAM Role (ex, SN_MID_SERVER_EC2_ROLE ) Click Update IAM Role Verify: On the EC2 instance details page, under IAM role, the attached role should now be listed.

outcome: An IAM Role (SN_MID_SERVER_EC2_ROLE): Trusted by the EC2 service Granted permissions to: Discover local resources Assume the IAM Role in the Management Account using sts:AssumeRole This IAM Role is now attached to the EC2 instance running the MID Server Important:

Retain the following details for use in later configuration steps:

Accessor Account ID ARN of IAM Role 4.2.2 Accessor Account Setup in ServiceNow Instance

Prerequisite: Ensure that the Mid server is installed and running on the EC2 instance in the accessor Acocunt, which has the IAM role (SN_MID_SERVER_EC2_ROLE) attached.

4.2.2.1 Add MID Server Instance profile Parameter

To allow the MID Server to use temporary credentials via EC2 metadata:

Navigate to Mid Server record in ServiceNow instance (hosted on EC2 instance) Under configuration parameters, click new Enter the following details: Parameter name: mid.aws.instance_profile_name value: Name of IAM role attached to EC2 instance (ex., SN_MID_SERVER_EC2_ROLE) Save the parameter Step 4.2.2.2: Create a Service Account

Navigate to: Workspaces -> Cloud discovery Workspace -> Cloud discovery -> New discovery schedule Fill in Schedule Details: Choose the provider Discovery schedule name : Your preferred name of schedule discovery schedule name Cloud provider: AWS MID selection type: Specific MID Server -> Discovery must use the appropriate mid Server (User Specific MID cluster also) Toggle Credential-less discovery MID Servers -> Select the correct Mid server (Instance profile attached) 3. Create Service Account: Service Account -> New Service account

Name : Friendly name for account Account ID : Accessor Account Id Leave credentials blank (as this is credential-less setup) Test account -> It takes couple of minutes. Test Account Troubleshooting:

This creates a record in Discovery status table. Go to Discovery status -> Search for description: " Perform validation account - " ->Refer to the most recent log for troubleshooting if validation fails. outcome:

Accessor Account validation should be successful.

Optional: Create Discovery Schedule for Accessor Account :

After validating the Accessor account’s service account, you may proceed to create a discovery schedule for it — only if you intend to discover resources within the Accessor account itself.

Use Case: If the Accessor account contains AWS resources (e.g., EC2, S3) to be discovered independently of any Management or Member account.

Skip this step if:

The Accessor account is already part of the AWS Organization under the Management account, and You plan to create a centralized discovery schedule from the Management account (which will automatically include the Accessor if it’s a Member account)

4.3 Management account Configuration This section outlines the step-by-step process to configure the Management Account in both the AWS Portal and the ServiceNow instance for use in Credential-less discovery.

4.3.1 Management Account Setup in AWS portal 4.3.1.1. Create an IAM Role (Ex. SN_MGMT_ACCOUNT_ROLE)

This role allows the Accessor Account to assume the Management Account role and discover resources and member accounts.

Navigate to the IAM > Roles > create role

Step 1 : Select trusted entity

Type: Custom trust policy Add principal -> principal type : IAM Role -> ARN -> arn:aws:iam::{Account}:role/{RoleNameWithPath} Replace {Account} with Actual Accessor Account ID and {RoleNameWithPath} with IAM Role (ex., SN_MID_SERVER_EC2_ROLE )created in Accessor account Add principal Sample custom trust policy { "Version": "2012-10-17", "Statement": [ { "Sid": "TrustAccessorRole", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam:: :role/ " }, "Action": "sts:AssumeRole" } ] } Step 2 : Add permissions -> Add AWS managed ReadonlyAccess policy or custom policy that grants required permissions for discovery

Add AWSOrganizationsReadOnlyAccess policy.

Note: AWSOrganizationsReadOnlyAccess is optional if the AWS managed ReadonlyAccess policy used

Step 3: Name, review, and create

Role name: SN_MGMT_ACCOUNT_ROLE ( management IAM role (e.g., SN_MGMT_ACCOUNT_ROLE ) used for IAM inline policy creation for Accessor account IAM user)

Step 4: Create role

4.3.1.2. Add Inline Policy to Assume Roles in member accounts

Attach an inline policy to the SN_MGMT_ACCOUNT_ROLE that allows it to assume roles in all member accounts.

{ "Version": "2012-10-17", "Statement": [ { "Sid": "VisualEditor0", "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": "arn:aws:iam::*:role/SN_MEMBER_ACCOUNT_ROLE" } ] } Note: The SN_MEMBER_ACCOUNT_ROLE must be created in each member account later.

outcome: The Management account is now configured with the following:

An IAM Role that has: Trust relationship with Accessor account IAM Role Permissions to discover resources within the management account Permissions to assume a role in each member account via sts:AssumeRole Permission to discover sub accounts - AWSOrganizationsReadOnlyAccess policy Important:

Retain the following details for use in later configuration steps:

Management Account ID ARN of IAM Role - SN_MGMT_ACCOUNT_ROLE 4.3.2 Management Account Setup in ServiceNow Instance

Create a Cloud Service account for the Management Account:

Navigate to: Workspaces -> Cloud discovery Workspace -> Cloud discovery -> New discovery schedule Fill in Schedule Details: Choose the provider: AWS Discovery schedule name : Your preferred name of schedule discovery schedule name -> Cloud provider ->AWS MID selection type: Based on your AWS discovery design ( Use Instance profile attached mid server ) Next 3. Create Service Account: Service Account -> New Service account

Name : Friendly name fro account Account ID : Management Account Id Access Role Name: Full ARN of Management account IAM role( SN_MGMT_ACCOUNT_ROLE ) Select Accessor Account: Select accessor account from List. Accessor Cloud Service Account already created and validated in step 2.2.2 Accessor Account Setup in ServiceNow Instance Test account -> It takes couple of minutes. Test account validation success then it discover all member accounts under management account Test Account Troubleshooting:

This creates a record in Discovery status table. Go to Discovery status -> Search for description: " Perform validation account - " ->Refer to the most recent log for troubleshooting if validation fails. Go to Discovery status -> Search for description: " Perform Refresh Member Accounts for schedule - " ->Refer to the most recent log for relevant details. outcome:

Successful validation of the Management Account Service Account Discovery ready to fetch data from all member accounts trusted by the Management Account Optional: Create Discovery Schedule for Management Account

Note: After validating the Management account’s service account, you may proceed to create a discovery schedule for it — only if you intend to discover resources within the Management account itself at this stage.

However, if you are planning to create a centralized discovery schedule from the Management account (which will also automatically include all configured Member accounts), you should skip creating the schedule now.

Instead, continue with the configuration of all required Member accounts, and create the schedule after completing those steps to enable full multi-account discovery in one execution.

4.4 Member account Configuration:

it is exactly same as member account configuration in credential-based discovery ( 3.4 Member account Configuration) on both AWS portal side and ServiceNow side

Final Step: Create Cloud Discovery Schedule for Management and Member Accounts Now that the Management account and all required Member accounts have been fully configured, you can proceed to create a Cloud Discovery Schedule from the Management account. This schedule will:

Discover resources in the Management account Automatically discover resources in all trusted Member accounts Use the role chaining setup established earlier Outcome: The discovery process will use the Management account’s IAM role to assume into all configured Member accounts. Resources from both the Management and Member accounts will be discovered and populated in the CMDB