Amazon Web Services

xAssets includes a built-in integration to import EC2 virtual machine instances, their attached EBS volumes, AMI details, and instance-type specifications from an Amazon Web Services (AWS) account. This page explains what the integration provides, its limitations, and how to configure it.

What the Integration Provides

The AWS integration imports cloud infrastructure data into xAssets as asset records, giving you visibility of your AWS resources alongside on-premises assets. It provides:

• EC2 instance master data — instance ID, instance type, hostname / DNS names, public and private IP addresses, MAC address, launch date, running state, availability zone, and key pair name
• Operating system — derived from the AMI (e.g. Windows_Server-2025-English-Full-Base-2026.03.11)
• Hardware specifications — vCPU count, memory, and sustained clock speed looked up from the AWS instance type catalogue
• EBS volume inventory — attached volume ID, device name, size (GiB → MB), and volume type (gp3, io1, etc.) as AssetDetailAllDisks rows
• Network addresses — public and private IP addresses, MAC address
• AWS tags — the Name tag maps to ComputerName, common ownership tags map to UserName, and the full tag set is stored on the Asset as HardwareAssetTag in key=value; key=value format
• Location — a child Location named Amazon <availability-zone> under a parent Amazon location

The integration pulls data from a single AWS region per credential pack, with automatic pagination so accounts with hundreds of instances sync in one transform call.

Limitations

The following data is not available from the EC2 APIs and is not imported:

• Windows internal hostname (e.g. EC2AMAZ-XXXXX) — this lives inside the OS and is not surfaced by any EC2 API. If you need it, either set a Name tag on the instance or use xAssets Network Discovery / the PCAnalyser agent against the instance.
• Installed software — use the xAssets Discovery Agent against the instance to capture this
• BIOS details, memory slot detail, Windows Services, firewall rules, device manager entries
• Windows Updates and patches
• User accounts logged on to the instance
• Non-EC2 resources (S3 buckets, RDS databases, Lambda functions, etc.) are not imported as assets

If you also have xAssets Network Discovery or the PCAnalyser agent deployed on the instance, these additional fields will be populated from that side.

Prerequisites

• An AWS account with programmatic access enabled
• An IAM user with read-only EC2 permissions (minimum: ec2:DescribeInstances, ec2:DescribeVolumes, ec2:DescribeImages, ec2:DescribeInstanceTypes). The AWS managed policy AmazonEC2ReadOnlyAccess covers all of these.
• Access to xAssets with permission to create credential packs
• The xAssets Batch Service must be running (the integration runs as a batch job)
• Outbound HTTPS access from the xAssets server to ec2.<region>.amazonaws.com

Setup

Step 1: Create an IAM User with an Access Key

1. Sign in to the AWS Management Console and open the IAM service
2. Navigate to Users > Create user
3. Give the user a recognisable name, e.g. xassets-integration
4. Choose Programmatic access only — do not tick "Provide user access to the AWS Management Console"
5. On the Set permissions step, select Attach policies directly and attach AmazonEC2ReadOnlyAccess
6. Complete the wizard, then open the newly created user
7. On the Security credentials tab, scroll to Access keys and click Create access key
8. Choose Application running outside AWS as the use case
9. Copy both the Access Key ID (starts with AKIA…) and the Secret access key

Important: The Secret access key is only shown once. Download the CSV or copy it immediately. If you lose it, you will need to create a new key pair.

Step 2: Identify the AWS Region

Determine which AWS region contains the instances you want to inventory. The AWS console's region switcher (top right) shows the current region. For a new account, check each region on the EC2 > Instances page to confirm which region your instances are actually in — the console defaults to us-east-1 (Virginia) which is often not where your instances were created.

The integration uses a regional suffix format in the credential pack, not just the region code:

The regional suffix scales naturally — the integration constructs service hostnames by prepending the service name (ec2.<domain>, etc.).

Step 3: Create a Credential Pack in xAssets

1. Navigate to Discover > Prepare > Credentials
2. Click New
3. Configure the credential pack as follows:

4. Click OK to save the credential pack

Note: The pack name must be exactly Amazon — the integration scripts read the pack by this name. Any trailing whitespace in the Domain Name, User Name or Password fields is trimmed automatically.

Step 4: Tag Your EC2 Instances (Optional but Recommended)

The integration uses AWS tags to populate fields that EC2 APIs don't otherwise expose:

In the AWS console, for each instance, go to Instance > Tags tab > Manage tags and add at minimum:

• Name=<your-computer-name> — for example, the Windows computer name your organisation would use
• Owner=<email-or-username> — should match an existing Custodian record in xAssets for the matching step to work

Additional tags (Environment, CostCenter, Project, etc.) are preserved verbatim in the HardwareAssetTag field.

Step 5: Run the Integration

1. Navigate to Discover > Integrations
2. Select AWS Integration
3. Click Queue at the top of the screen to add the integration to the batch job queue
4. The integration runs as a batch job. Monitor progress in the batch job status area. Status messages will show:
   • "Importing data from Amazon Web Services" — fetching instances with pagination
   • "Fetching EC2 enrichments (volumes, images, instance types)" — three enrichment API calls
   • "Moving AWS data to holding area" — mapping into the Discovery Load staging tables
   • "AWS Integration Completed. X asset records loaded." — finished

Step 6: Verify the Results

After the integration completes:

1. Open the Asset List and filter by Source = AWS to see imported assets
2. Open an individual asset to verify:
   • Hardware details — Manufacturer=Amazon, Model=t3.micro (or similar), Memory, CPU cores and speed
   • OperatingSystem — derived from the AMI name
   • Network tab — both public and private IP addresses, MAC address
   • Disk tab — one row per attached EBS volume with size in MB
   • Hardware Asset Tag field — contains the full AWS tag set in key=value; key=value format

Troubleshooting

HTTP 401 Unauthorised or "The request signature we calculated does not match"

This almost always means one of the cred-pack fields has a trailing space or the wrong value. Verify:

• The Domain Name is the regional suffix (e.g. eu-north-1.amazonaws.com), not a full URL or just a region code
• The User Name is the Access Key ID (starts with AKIA…), 20 characters
• The Password is the full 40-character Secret access key
• The system clock on the xAssets server is within ~5 minutes of UTC — AWS rejects signed requests with stale timestamps

HTTP 403 Forbidden / AccessDenied

The IAM user is missing a required permission. Attach AmazonEC2ReadOnlyAccess to the IAM user, or grant at least the four Describe* permissions listed in the Prerequisites.

Integration runs but creates no assets

Check x7temp.dbo.awsintegration after the 105 transform runs — it should contain one row per EC2 instance. If empty, the credential pack is likely pointing at the wrong region (the console's region switcher defaults to us-east-1, so your instances may be in a different region than expected).

Custodian is "Default Custodian" instead of the expected user

The integration populates NetworkDiscovery.UserName from tags named Owner, owner, OwnerEmail, Email, Custodian, CreatedBy, createdBy, or Manager (first match wins). Add one of these tags on the EC2 instance, with a value that matches an existing Custodian in xAssets, then re-run the integration.

Special Options

The following Special Options can be configured in Admin > Special Options to customise the integration behaviour:

Scheduling

To run the AWS integration on a schedule, configure a batch job schedule for the AWS Integration transform. A daily sync is typical; shorten the interval if you have fast-changing auto-scaling groups.

Multi-Region Accounts

The integration covers one AWS region per credential pack and integration run. To inventory a multi-region account:

1. Create one credential pack per region (Amazon us-east-1, Amazon eu-west-1, etc., each with the appropriate regional suffix in the Domain Name)
2. Clone the AWS Integration transform, one per region, each reading its own credential pack (change the pack name in the ReadCredentialPack line of the AWS Integration 105 transform)
3. Schedule all clones to run in sequence

Native enumeration of enabled regions via DescribeRegions is on the roadmap.

Related Articles

• Google Cloud — similar integration for Google Cloud Platform
• Azure Direct Integration — similar integration for Microsoft Azure
• Microsoft Intune — importing Intune-managed devices