Introduction
As organizations accelerate their cloud adoption on AWS, maintaining accurate and up-to-date visibility of cloud infrastructure within the ServiceNow Configuration Management Database (CMDB) becomes critical. ServiceNow offers two primary approaches for discovering and populating AWS resources into the CMDB:
This blog provides a detailed technical comparison to help architects, platform administrators, and IT leaders choose the right approach for their environment.
AWS Cloud & SSM Pattern-Based Discovery
Overview
AWS Cloud & Systems Manager (SSM) Pattern-Based Discovery leverages the native ServiceNow Discovery engine in conjunction with the AWS API’s & SSM agent. Instead of relying solely on IP-based probing, ServiceNow connects to AWS using IAM credential or role, retrieves cloud services data from API’s and EC2 instance inventory data from SSM, and uses horizontal discovery patterns to populate CMDB CIs.
This approach extends the classic ServiceNow Discovery model to the cloud, treating AWS resources like on-premises servers - with the SSM agent acting as the communication bridge between EC2 instances and the ServiceNow instance.
How It Works
- ServiceNow mid server connects to the AWS API using IAM credentials
- AWS SSM is used for deep OS-level discovery
- Discovery patterns execute to classify, identify, and map CIs
- Host-level details (OS, installed applications, running processes) are populated via the SSM agent
- Relationships between CIs are built based on discovery payload
Key Use Cases
- AWS Pattern-Based Discovery powers your entire SAM use cases
- Organizations already using ServiceNow Discovery for on-premises and wanting to extend to AWS with a consistent framework
- Environments requiring deep OS-level discovery (installed software, running processes, tcp ports,etc)
- Hybrid cloud environments where uniformity between on-prem and cloud discovery is desired
- Use cases needing application-level dependency mapping – ITOM Visibility
- Software inventory, configurations, and running processes from EC2 instances into ServiceNow CMDB, providing the audit-ready evidence - Regulatory Compliance
- Surfacing installed application data from every SSM-managed EC2 instance - Basic SAM
Pros
- Deep EC2 OS-level visibility
- Discovers OS details, installed applications, running processes, and network connections
- Consistent Discovery framework
- Same ServiceNow Discovery engine used for on-prem and cloud
- Rich dependency mapping
- Can build application service maps leveraging host-level data
- Customizable patterns
- Patterns can be customized for specific CIs or application stacks
- Supports compliance and ITSM workflows
- Data richness enables more accurate change management and CMDB health
Cons & Limitations
- Performance overhead
- Discovery scans can be resource-intensive in large-scale environments
- Configuration complexity
- Requires proper IAM roles and mid-server setup
AWS Service Graph Connector (SGC)
Overview
The AWS Service Graph Connector (SGC) is a certified, purpose-built integration available on the ServiceNow Store. It uses AWS APIs directly (without agents) to discover and import a broad range of AWS services including EC2 instances ((require SSM agents) into the ServiceNow CMDB.
How It Works
- AWS credentials (IAM role/access key) are configured in ServiceNow
- SGC makes REST API calls to AWS services (EC2, RDS, S3, Lambda, VPC, EKS, etc.)
- Certified CI mapping ensures proper CI class population and relationship creation
Key Use Cases
- Cloud-first or AWS-heavy environments where MID-less discovery is preferred
- Near real-time CMDB updates triggered by AWS resource changes
- Governance and compliance use cases
Pros
- Mid-less Architecture
- No MID required, connects via API.
- Consistent SGC framework
- User with SGC ecosystem could follow the similar approach for AWS discovery
- Certified by ServiceNow
- Fully supported, regularly updated, and certified integration on ServiceNow Store
- More controlled command set execution
- Run the predefined command list.
Cons & Limitations
- Limited host-level discovery for EC2 instances
- Does not discover deep level OS details
- Limited application dependency mapping
- Cannot build deep application service maps without pairing with other tools
Side-by-Side Comparison
The table below summarizes the key differences between both approaches across critical dimensions:
Choosing the Right Approach
Neither approach is universally superior — the right choice depends on your organization's discovery goals, AWS footprint, and CMDB strategy.
Recommended: Hybrid Approach
For most enterprise environments with significant AWS footprints, a hybrid strategy delivers the best of both worlds:
- Use Pattern-Based Discovery for EC2 instances that require deep host-level visibility - capturing running processes, installed software, open ports, and OS configurations. This approach is ideal when your CMDB strategy demands granular instance-level data, not just high-level cloud resource attributes pulled from AWS APIs.Beyond CMDB accuracy, it also provides strong support for Software Asset Management (SAM) use cases, with the host-level software inventory needed for license reconciliation, normalization, and compliance tracking.
- SGC is best recommended if you want to go for MID-less discovery or real-time discovery update.
This combination ensures complete infrastructure visibility while minimizing agent overhead for non-compute services.
Conclusion
Both AWS Cloud and SSM Pattern-Based Discovery and the AWS Service Graph Connector serve distinct purposes within the ServiceNow CMDB ecosystem. Understanding your organization's goals - whether deep host visibility or broad cloud service coverage - is the foundation for making the right choice.
1 Comment
