AI Service Graph Connector for Amazon
On this page
AI Service Graph Connector for Amazon
The AI Service Graph Connector for Amazon enables you to discover and import AI assets from your AWS environment into ServiceNow AI Control Tower.
The connector integrates with your AWS account (Amazon Bedrock, Amazon SageMaker, Amazon CloudWatch, and Amazon Bedrock AgentCore) to catalog AI systems, agents, models, prompts, and tools. Usage data is automatically collected and populated into the AI Control Tower value dashboard, providing comprehensive visibility and governance of your AI operations.
Download apps from the Store
Visit the ServiceNow store website to download the AI Service Graph Connector for Amazon application.
Supported ServiceNow versions
This connector is supported on the following ServiceNow releases:
Release Status Australia Supported Zurich Supported Yokohama SupportedUser Roles
You must have one of the following roles assigned.
Required Roles sn_ai_disc.discovery_admin sn_cmdb_int_util.sgc_adminServiceNow Prerequisites
Complete the following setup steps once when configuring the connector for the first time.
Note: Updating data source access and clear cache is a prerequisite that needs to be completed only once, when setting up a new instance for the first time.
Update Data Source Access
The connector requires write permissions to the Data Source table to create data sources.
To enable data source creation:
-
Select Global from the application picker.
-
Navigate to Application Access.
-
Select the Can create, Can update, and Can delete check boxes.
-
Select Update.
-
Switch to the connector application scope.
Clear the cached data for the Data Source and Tables.
To clear the cache:
-
Navigate to System Definition > Background Scripts.
-
Enter the following script in the Run Script text box:
GlideTableManager.invalidateTable('sys_data_source'); GlideCacheManager.flushTable('sys_data_source'); GlideTableManager.invalidateTable('sys_db_object'); GlideCacheManager.flushTable('sys_db_object');
-
Select Run Script.
Note: The script might take several minutes to complete. After completion, switch to the connector application scope.
AWS Prerequisites
AWS prerequisites for version 1.1.0
Complete the following steps in your Azure environment before creating an Azure Foundry connection. Configure OAuth Credentials:
The connector uses OAuth to authenticate with Azure APIs. To obtain credentials, register an application in Microsoft Entra ID. For full instructions, see, https://learn.microsoft.com/en-us/rest/api/azure/#register-your-client-application-with-azure-ad
The Azure client application requires the following roles:
-
Reader role at the subscription or resource group level to discover resources.
-
Foundry User role in the Azure AI Foundry resources.
Note: Starting from March 2026, ServiceNow supports the new Azure AI Foundry alongside the original Foundry. The New Foundry treats each agent version as a distinct entity.
AWS prerequisites for version 2.0.2
The AWS connector requires a read-only IAM user and a read-only role deployed across the accounts you want to discover. Download the CloudFormation templates from the playbook and deploy them using the AWS CloudFormation console as a Stack (single account) or a StackSet (multiple accounts across the Organization).
Before proceeding, confirm you have:
AWS Account- Active AWS account with access to the services you want to connect to.
Required IAM permissions
The IAM roles created by the templates earlier grant read-only access to the following services:
-
Amazon Bedrock
-
Amazon SageMaker
-
Amazon CloudWatch Logs
-
Amazon Bedrock AgentCore
-
AWS Organizations
-
Amazon EC2
Pre-Deployment Checklist
Before deploying any templates, confirm the following:
You have AWS CloudFormation Stack and StackSet deployment permissions in the relevant accounts.
Target member accounts have Amazon Bedrock, SageMaker, and/or AgentCore enabled - accounts without these services will return 403 errors during discovery.
If using Standalone Mode, confirm the target account ID where SgAictReadOnlyAccessRole.yml will be deployed.
If using StackSet deployment, confirm that Automatic Deployment is enabled so newly created accounts are covered automatically.
The default role name across all templates is SgAictReadOnlyAccessRole. If your organization requires a different naming convention, update it consistently across all templates and in the ServiceNow connector configuration before deployment.
Perform the AWS prerequisites:
1. Choose your deployment scenario
Determine how your ServiceNow IAM user will be setup in AWS:
-
Scenario 1- Management Account: The ServiceNow IAM user is created directly in the AWS Org/Management account.
-
Scenario 2- Delegated Member Account: The ServiceNow IAM user is created in a dedicated member account, with a cross-account role in the Management account for Organizational-level access.
-
Standalone Mode: Available in both scenarios. Use this to test discovery against a single AWS account before rolling out to the full organization.
Templates required per scenario
<table id=“table_xcn_hfy_yjc”><tbody><tr><td>
Template
</td><td>
Deployed as
</td><td>
Scenario 1
</td><td>
Scenario 2
</td></tr><tr><td>
ServiceNowAictUser.yml
</td><td>
Stack
</td><td>
✔ (Management account)
</td><td>
✔ (Designated Member account)
</td></tr><tr><td>
SgcAictReadOnlyAccessRole.yml
</td><td>
StackSet
</td><td>
✔ (all member accounts)
</td><td>
✔ (all member accounts)
</td></tr><tr><td>
SgcAictReadOnlyOrgAccessRole.yml
</td><td>
Stack
</td><td>
—
</td><td>
✔ (Management account)
</td></tr></tbody> </table>2. Download the CloudFormation templates
Deploy the following AWS CloudFormation templates based on your selected scenario:
-
Navigate to the connector playbook, open the Prerequisites section.
-
Select Download basic scripts. This downloads a ZIP file containing the following CloudFormation templates:
-
ServiceNowAictUser.yml- Required in all scenarios. Deploy in the account where the ServiceNow IAM user will reside:
-
Management account for Scenario 1
-
Designated account for Scenario 2
-
-
SgcAictReadOnlyAccessRole.yml- Required in all scenarios. Deploy across all member accounts via StackSet for Organization-wide discovery, or in a single target account for Standalone Mode.
-
SgcAictReadOnlyOrgAccessRole.yml- Required only for Scenario 2. Deploy in the Org/Management account to grant the Designated account cross-account Organization read access.
-
-
Sign in to https://console.aws.amazon.com using your Management account.
-
Extract the ZIP so the template files are available on your local machine.
3. Enable trusted access for StackSets
Service-managed StackSets require trusted access between AWS Organizations and CloudFormation. This is a one-time setup in the Management account.
-
Sign in to the Management account.
-
Search for CloudFormation in the left navigation pane and select StackSets.
-
If trusted access is not enabled, a banner prompts you to enable it. Select Enable trusted access.
CLI Alternative:
aws organizations enable-aws-service-access\ --service-principal member.org.stacksets.cloudformation.amazonaws.com
Note: For more information, see the AWS documentation on enabling trusted access with AWS Organizations.
4. Deploy the ServiceNow IAM user (Stack)
The ServiceNowAictUser.yml template creates the ServiceNow IAM user with the required read-only permissions. Deploy it as a Stack in the account where the user should reside — the Management account for Scenario 1, or the Designated Member account for Scenario 2.
-
Sign in to the account where the user will be created.
-
Search for CloudFormation and select Create stack With new resources (standard).
-
Under Specify template:
-
Prepare template: Choose an existing template.
-
Template source: Upload a template file.
-
Select Choose file and upload ServiceNowAictUser.yml and select Next.
-
-
Under Specify stack details:
-
Stack name: aict-servicenow-user.
-
Parameters:
-
UserAccountType: ManagementAccount (Scenario 1) or DesignatedMemberAccount (Scenario 2)
-
SNUserName: servicenow-aict-user
-
MbrActRoleName: Leave the default value (SgcAictReadOnlyAccessRole).
-
-
Select Next.
-
-
Under Configure stack options, leave the default values and select Next.
-
On the Review and create page, scroll to the bottom and select I acknowledge that AWS CloudFormation might create IAM resources check box.
-
Select Submit. The stack status shows CREATE_IN_PROGRESS, then CREATE_COMPLETE.
-
Open the stack, select the Outputs tab, and note the ServiceNowUserARN value.
Note: The IAM resources created are strictly read-only and scoped to AI Discovery APIs (Bedrock, SageMaker, AgentCore, and CloudWatch Logs).
5. Deploy the Org-access role (Scenario 2 only, Stack)
Note: This step applies only to Scenario 2 (user in a Designated Member account). Skip it for Scenario 1.
The SgcAictReadOnlyOrgAccessRole.yml template creates a read-only role in the Management account, scoped to Organization, Account, and Region APIs. The ServiceNow user assumes this role to enumerate the Organization.
-
Sign in to the Management account.
-
Search for CloudFormation, then select Create stack with new resources (standard).
-
Under Specify template:
-
Prepare template: Choose an existing template.
-
Template source: Upload a template file.
-
Select Choose file and upload SgcAictReadOnlyOrgAccessRole.yml.
-
Select Next.
-
-
Under Specify stack details:
-
Stack name: aict-org-readonly-role
-
Parameters:
-
DesignatedAccountId: the 12-digit account ID where the ServiceNow user was created (Prerequisite 4).
-
ServiceNowUserName: servicenow-aict-user
-
-
Select Next.
-
-
Under Configure stack options, leave the default values and select Next.
-
On the Review and create page, scroll to the bottom and select the check box I acknowledge that AWS CloudFormation might create IAM resources.
-
Select Submit and wait for CREATE_COMPLETE.
Note: This template is not needed for Scenario 1, because the user created in the Management account already has Organization permissions inline.
6. Deploy the member-account role (StackSet)
The SgcAictReadOnlyAccessRole.yml template creates the SgcAictReadOnlyAccessRole read-only role that the ServiceNow user assumes to make API calls in each member account. Deploy it as a StackSet from the Management account across all member accounts.
-
Sign in to the Management account.
-
Search for CloudFormation in the left navigation pane, select StackSets > Create StackSet.
-
Under Permissions, select Service-managed permissions.
-
Under Specify template:
-
Prepare template: Choose an existing template.
-
Template source: Upload a template file.
-
Select Choose file and upload SgcAictReadOnlyAccessRole.yml.
-
Select Next.
-
-
Under Specify StackSet details:
-
StackSet name: aict-member-readonly-role
-
Parameters:
-
ServiceNowUserAccountId: the 12-digit account ID where the ServiceNow user was created (Management account for Scenario 1, Designated Member account for Scenario 2).
-
ServiceNowUserName: servicenow-aict-user
-
RoleName: leave default (SgcAictReadOnlyAccessRole)
-
-
Select Next.
-
-
Under Configure StackSet options, leave the default values and select Next.
-
Under Set deployment options:
-
Add stacks to stack set: Deploy new stacks
-
Deployment targets — select one of the following:
-
Deploy to organization — Deploys to all accounts in the Organization
-
Deploy to organizational units (OUs) — Select Add an OU and paste the target OU ID(s).
-
For a subset of accounts within an OU, set Account filter type to Intersection and provide the specific account numbers.
-
-
Automatic deployment: Enabled — accounts added to the Organization or OU in the future automatically receive the role.
-
Account removal behavior: Delete stacks.
-
Specify regions: Add the region(s) matching your connector configuration (for example, us-east-1).
-
Select Next.
-
-
On the Review page, select the I acknowledge that AWS CloudFormation might create IAM resources check box, then select Submit.
-
On the Operations tab, monitor the StackSet operation until the status shows SUCCEEDED.
Note:
IAM is a global service. Although a region must be specified for the StackSet, the role created by this template is global and identical regardless of region. For more information, see the AWS documentation on creating StackSets with service-managed permissions.
Standalone Mode: To validate against a single account before deploying org-wide, deploy SgcAictReadOnlyAccessRole.yml as a regular Stack (following the Prerequisite 4) in that one account. After validation, deploy the StackSet across all accounts.
7. Generate the access key
The connector requires an Access Key ID and Secret Access Key from the IAM user created in the Prerequisite 4 (Deploy the ServiceNow IAM user (Stack) steps).
-
Sign in to the account where the ServiceNow user was created.
-
Search for IAM, then select Users > servicenow-aict-user.
-
Select the Security credentials tab, then select Create access key.
-
Select Application running outside AWS, then select Next.
-
(Optional) Add a description tag, then select Create access key.
-
Save the credentials:
-
Access Key ID: AKIA...
-
Secret Access Key: wJal... The Secret Access Key is only shown only once. Download the .csv file or save the value immediately.
CLI Alternative:
aws iam create-access-key --user-name servicenow-aict-user
-
Note: An IAM user can have a maximum of two access keys. If two access keys already exist, delete one before creating a new one.
8. Setup CloudWatch Log Group and CloudTrail
The connector queries CloudWatch Logs to retrieve Bedrock invocation counts per agent. CloudTrail captures the Bedrock data events and delivers them to the log group. Complete this step in each member account from which you want usage data.
This step is optional - complete it only if you want agent invocation counts. Asset discovery works without it.
-
Create the CloudWatch Log Group.
-
Search CloudWatch → Logs → Log groups → Create log group
-
Log group name: /aws/bedrock/aict-invocations
-
Retention: 90 days (recommended).
-
Select Create. CLI Alternative
# Create aws logs create-log-group --log-group-name /aws/bedrock/aict-invocations # Verify aws logs describe-log-groups --log-group-name-prefix /aws/bedrock/aict-invocations
Note: If a log group already exists for this purpose, use its name in the connector configuration.
-
-
Create an IAM Role for CloudTrail to CloudWatch Logs delivery
CloudTrail requires permission to write events into the log group. Create a role that grants this permission.
-
IAM → Roles → Create role
-
Trusted entity type: AWS service
-
Service: CloudTrail
-
Select Next.
-
-
Attach the following inline policy:
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "logs:CreateLogStream", "logs:PutLogEvents" ], "Resource": "arn:aws:logs:*:*:log-group:/aws/bedrock/aict-invocations:*" } ] } -
Role name: CloudTrailToCloudWatchLogsRole → Create role
-
Copy the Role ARN — required in Step 10, when configuring CloudWatch Logs delivery in the trail.
-
Create the CloudTrail. Search CloudTrail > Trails > Create trail
-
Trail settings:
-
Trail name: servicenow-aict-bedrock-trail
-
Storage location: Create a new S3 bucket or use existing.
-
S3 bucket name: servicenow-aict-cloudtrail-logs-<account-id>
-
-
CloudWatch Logs — Enable:
-
Log group: /aws/bedrock/aict-invocations
-
IAM role: CloudTrailToCloudWatchLogsRole (from Step 7)
-
-
Select Next → Events
-
Event type: Data events
-
Uncheck Management events
-
-
Configure data event selectors — add each of the following:
Data event source Event type Bedrock Agent Alias AWS::Bedrock::AgentAlias Bedrock Async Invoke AWS::Bedrock::AsyncInvoke Bedrock Inline Agent AWS::Bedrock::InvokeInlineAgent Bedrock Knowledge Base AWS::Bedrock::KnowledgeBase Bedrock Model AWS::Bedrock::Model Bedrock Session AWS::Bedrock::Session Bedrock Flow Alias AWS::Bedrock::FlowAlias -
Select Next > Review > Create trail
CLI Alternative:
# Create trail aws cloudtrail create-trail \\ --name servicenow-aict-bedrock-trail \\ --s3-bucket-name servicenow-aict-cloudtrail-logs-<account-id> \\ --cloud-watch-logs-log-group-arn arn:aws:logs:<region>:<account-id>:log-group:/aws/bedrock/aict-invocations \\ --cloud-watch-logs-role-arn arn:aws:iam::<account-id>:role/CloudTrailToCloudWatchLogsRole # Enable logging aws cloudtrail start-logging --name servicenow-aict-bedrock-trail # Verify trail is active aws cloudtrail get-trail-status --name servicenow-aict-bedrock-trail
Note:
Repeat this step in each member account from which you want usage data. Note the log group name — enter it in the Log Group Names field of the connector configuration.
Bedrock data events are only logged when agents are invoked. If no invocations have occurred, the log group exists but is empty. Invocation counts populate after the first discovery run.
9. Verify Services
-
Bedrock:
-
Search “Bedrock” → Bedrock console loads
-
CLI (example): aws bedrock list-foundation-models –region us-east-1
-
-
SageMaker:
-
Search “SageMaker” → SageMaker console loads
-
CLI (example): aws sagemaker list-models –region us-east-1
-
-
CloudWatch Logs:
-
Search “CloudWatch” → CloudWatch → Logs → Log groups
-
CLI (example): aws logs describe-log-groups –region us-east-1
-
AWS prerequisites for version 2.1.2
To setup AWS instructions, see the Automating AICT AWS Connector Setup Using the CloudShell Deployment Script [KB3138431] article in the Now Support Knowledge Base.
AWS Prerequisite Troubleshooting
Error Solution Access Denied (creating stack/StackSet) Ensure your session has CloudFormation, IAM, and Organizations permissions in the relevant account. Stack fails with “requires capabilities: [CAPABILITY_NAMED_IAM]” On the Review page, select the check box acknowledging that CloudFormation may create IAM resources. StackSet operation FAILED Open the StackSet → Operations tab → view the failed stack instance. Common causes: SCP restrictions, name conflicts from a prior failed run. Trusted access not enabled Enable trusted access between AWS Organizations and CloudFormation StackSets in the Management account (Prerequisite 3). StackSet has no deployment targets Verify you selected Deploy to organization or provided a valid OU ID. Service unavailable in region Use us-east-1; not all regions have all services. Can’t see Secret Access Key Delete the key and create a new one. Log group already exists Use the existing group; skip Prerequisite 8 or reuse the name. Explicit deny in service control policy An SCP is blocking the action on that account. Contact the Organization administrator.Data Mapping
The following table lists the data sources, the staging tables, and the target tables CMDB CI classes and non-CMDB classes where data is stored for a AWS project.
Data Source Staging Table Target Table SGawsBedrockAIAssetDSUtilSNC sn\_ai\_disc\_aws\_sgc\_bedrock\_ai\_asset sn\_ai\_disc\_aws\_sgc\_bedrock\_ai\_system \(routes to other staging tables\) SGawsBedrockAISystemDSUtilSNC sn\_ai\_disc\_aws\_sgc\_bedrock\_ai\_system alm\_ai\_system\_digital\_asset SGawsBedrockAIModelDSUtilSNC sn\_ai\_disc\_aws\_sgc\_bedrock\_ai\_model alm\_ai\_model\_digital\_asset SGawsBedrockAIToolDSUtilSNC sn\_ai\_disc\_aws\_sgc\_bedrock\_ai\_tool sn\_ent\_ai\_tool SGawsBedrockAIPromptDSUtilSNC sn\_ai\_disc\_aws\_sgc\_bedrock\_ai\_prompt alm\_ai\_prompt\_digital\_asset SGawsBedrockAISbcompM2mDSUtilSNC sn\_ai\_disc\_aws\_sgc\_bedrock\_sbcomp\_m2m sn\_ent\_ai\_system\_subcomponent\_m2m SGawsBedrockAIUsageDSUtilSNC sn\_ai\_disc\_aws\_sgc\_bedrock\_ai\_usage sn\_ai\_disc\_ai\_usage SGAgentCoreDataSourceUtil \(importAgentRuntimesByID\) sn\_ai\_disc\_aws\_sgc\_agentcore\_ai\_system alm\_ai\_system\_digital\_asset SGAgentCoreDataSourceUtil \(importCodeInterpretersByID, importBrowsersByID, importTargetsByID\) sn\_ai\_disc\_aws\_sgc\_agentcore\_ai\_tool sn\_ent\_ai\_tool SGAgentCoreDataSourceUtil \(getAWSAgentCoreUsage\) sn\_ai\_disc\_aws\_sgc\_agentcore\_ai\_usage sn\_ai\_disc\_ai\_usage SGSageMakerAIModelDSUtilSNC sn\_ai\_disc\_aws\_sgc\_sg\_awssagemaker\_model alm\_ai\_model\_digital\_asset SGSageMakerModelCardDSUtilSNC sn\_ai\_disc\_aws\_sgc\_sg\_awssagemaker\_model alm\_ai\_model\_digital\_assetKeep exploring.
Find another answer, or bring this documentation into your own tools.