Troubleshooting SG-AWS Missing RAM/CPU/Disk data - Diagnostic Tool shows IAM Failures & Empty S3 Con

[String]

Hi Team ,

We are currently configuring the Service Graph Connector for AWS (SG-AWS) to populate our CMDB with detailed EC2 instance information (RAM, CPU count, Disk sizes, etc.). We are running into an issue where these "deep discovery" fields are consistently empty in ServiceNow.

We have run the built-in Diagnostic Tool and found two critical issues preventing this data from being collected. We need clarification or confirmation on the next steps to ensure the AWS team can address their side of the configuration.

Issue 1: Deep Discovery Features "Opted Out" (S3 Configuration Missing)

The diagnostic tool noted that it skipped testing the SSM SendCommand/S3 APIs entirely because the necessary S3 parameters were empty in our Guided Setup configuration. This confirms that ServiceNow is not even attempting the API calls needed to gather OS-level details.

Diagnostic Snippet:

SSM Send Command API Count	-
S3 Get API Count	-
S3 Delete API Count	-

Diagnostic Summary - Notes:
2	SendCommand S3 properties are set to empty, diagnostic tool assumes that this feature is opted out and will not test the API access test to this feature.

Question: Is our interpretation correct that we simply need the AWS team to provide the S3 Bucket Name, Account ID, and Region, and we input those into the Guided Setup to enable this feature? 

Issue 2: IAM Access / Assume Role Failure (AWS Configuration Error)

The second issue is a clear IAM access failure in one of our main accounts. This appears to be an AWS-side configuration that needs remediation.

Diagnostic Snippet:

Diagnostic Summary - Notes:
14	IAM access accessible - FAILED. Check if ServiceNow user has IAM role (sts:AssumeRole) setup properly for the accounts: [12345]

Question: This points specifically to the sts:AssumeRole configuration. We are using the SnowOrganizationAccountAccessRole model. This note provides concrete evidence that the trust relationship or the policy in the target AWS account is misconfigured.

So the fix requires the AWS team to verify the trust policy on their end to allow our ServiceNow user to assume that specific role? if so what is that role ?

Any advice on how to best present this evidence to the AWS Infrastructure team, or if am misunderstanding any part of these diagnostic notes, would be greatly appreciated!

Please guide me with best practices 

Thanks in advance.