Introduction
Elisity Cloud Control Center (CCC) supports connectivity to Amazon Web Services (AWS) as a cloud workload connector, enabling discovery and visibility of EC2 instances within IdentityGraph. This extends Elisity's identity-based microsegmentation from on-premises network devices to cloud workloads, allowing administrators to manage both traditional endpoints and cloud instances under a unified policy framework.
The AWS connector discovers EC2 instances across selected AWS regions and imports their metadata into IdentityGraph. Administrators can then classify these workloads using Workload Policy Groups with matching criteria based on AWS tags, instance attributes, and interface properties. Policies defined in the Policy Matrix apply to cloud workloads alongside traditional device Policy Groups, enabling consistent segmentation across hybrid environments.
This article covers the following configuration workflow:
- Enabling the Workloads feature in Advanced Settings
- Configuring the AWS connector with IAM credentials and region selection
- Viewing discovered workloads in IdentityGraph
- Creating Workload Policy Groups for cloud workload classification
Prerequisites
- Administrator access to Elisity Cloud Control Center
- An AWS IAM user with programmatic access (Access Key ID and Secret Access Key) and read permissions for EC2 across the target regions
- At least one active EC2 instance in the target AWS account for discovery validation
Enable the Workloads Feature
The Workloads capability is an advanced feature that must be enabled before the AWS connector and Workloads navigation become available.
Step 1. Enable Workloads in Advanced Settings
Navigate to Settings > System > Advanced. Locate the Workloads tile and toggle Enable Workloads to the on position.
After enabling Workloads, the left navigation updates. The IdentityGraph menu expands to display two sub-items: Devices and Workloads. The Connectors page also displays the Amazon Web Services connector option.
The Workloads feature must be enabled before any cloud connector configuration or workload visibility is available in Cloud Control Center.
Configure the AWS Connector
After enabling Workloads, configure the AWS connector to establish connectivity to your AWS account and begin discovering EC2 instances.
Step 2. Open the Add Connector Dialog
Navigate to Settings > Connectors and click + Add Connector.
Step 3. Select Amazon Web Services
In the Add Connector dialog, locate and select Amazon Web Services. This will only be visible after enabling Workloads in Step 1. Click Configure.
The connector configuration wizard opens with a three-step process: Authentication, AWS Regions, and Summary.
Step 4. Configure Authentication
On the Authentication step, enter the following fields:
| Field | Description |
|---|---|
| Connector Name | A descriptive name for this AWS connector instance (for example, AWS-Production) |
| Access Key ID | The IAM Access Key ID for the AWS user account with EC2 read permissions |
| Secret Access Key | The IAM Secret Access Key corresponding to the Access Key ID |
Step 5. Test the Connection
Click Test Connection to validate the provided credentials against the AWS API. After your AWS credentials are successfully validated, click Next.
Important: If the test connection fails, verify that the IAM user has the required EC2 read permissions and that the Access Key ID and Secret Access Key are correct.
Step 6. Select AWS Regions
On the AWS Regions step, choose which AWS regions to scan for EC2 instances. Two options are available:
- All Regions - Scans all available AWS regions (17 regions). When selected, Cloud Control Center validates API access to every region during the permissions check. If the IAM credentials do not have access to all regions, Cloud Control Center automatically switches the selection to Custom and pre-selects only the regions where permissions were successfully validated.
-
Custom - Select specific regions to scan (for example,
us-east-1,us-east-2,us-west-1,us-west-2). Use this option to limit discovery to regions where your workloads reside or where the IAM user has permissions.
Select the appropriate option and, if using Custom, add the target regions to the Regions field.
Step 7. Validate Permissions
Click Validate Permissions to verify that the IAM credentials have API access to the selected regions. A success message confirms: "All regions verified successfully. You're ready to proceed with your workload setup." Click Next.
If All Regions is selected and validation fails for one or more regions, Cloud Control Center reports which regions could not be reached and automatically switches the selection from All Regions to Custom. The regions where permissions were successfully validated are pre-selected in the Custom regions list. This prevents the connector from making repeated API calls to regions where the IAM credentials lack access. Review the pre-selected regions, add or remove entries as needed, and click Validate Permissions again to confirm.
Step 8. Review and Submit
On the Summary step, review the connector configuration including the Authentication details (Connector Name, Authentication Method, and masked Access Key ID) and the number of selected AWS Regions. Click Submit to create the connector.
After submission, the connector appears on the Connectors page with an Active status. Cloud Control Center begins discovering EC2 instances across the configured regions. The initial discovery completes within approximately 60 seconds, and subsequent discovery cycles run at the same interval.
View Discovered Workloads
After the AWS connector completes its initial discovery cycle, discovered EC2 instances appear in the Workloads section of IdentityGraph.
Step 9. Navigate to the Workloads Page
Navigate to IdentityGraph > Workloads. The Workloads page displays a summary dashboard and a searchable table of all discovered cloud workloads.
Workload Summary
The summary section at the top of the page provides an overview of discovered workloads including:
- Total Workloads - The total count of discovered EC2 instances
- By State - Color-coded indicators showing the number of running, stopped, and terminated instances
- By Region - A donut chart showing the distribution of workloads across AWS regions
- By VPC - A donut chart showing the distribution of workloads across Virtual Private Clouds
- By Instance Type - A donut chart showing the distribution of workloads by EC2 instance type
Workload Table
The table below the summary lists each discovered workload with the following columns:
| Column | Description |
|---|---|
| Hostname/Instance ID | The hostname or AWS instance identifier for the workload |
| Provider | The cloud provider (AWS) |
| Status | The current state of the EC2 instance (Running, Stopped) |
| IP Addresses | The primary IP address of the instance, with a count of additional addresses if applicable |
| Instance Type | The AWS instance type (for example, t2.micro, t2.medium, t3.small) |
| Region | The AWS region where the instance runs (for example, us-west-1) |
| Platform | The operating system platform (for example, Linux/UNIX, Windows) |
| VPC | The AWS Virtual Private Cloud identifier where the instance resides |
| Subnet | The AWS subnet identifier for the instance |
Step 10. View Workload Details
Click on any workload in the table to open its detail page. The Workload Details page displays three sections of information:
Instance Details
This section displays the authoritative metadata sourced directly from AWS. These fields are read-only and update automatically during each discovery cycle:
| Field | Description |
|---|---|
| Instance ID | The unique AWS instance identifier |
| Endpoint Name | The connector name associated with this workload |
| Provider | The cloud provider (AWS) |
| MAC | The MAC address of the primary network interface |
| IP | The private IP address of the instance |
| Status | The current instance state (RUNNING, STOPPED) |
| Region | The AWS region |
| Virtual Network | The VPC identifier |
| Subnet | The subnet identifier |
| Availability Zone | The AWS availability zone |
| Instance Type | The EC2 instance type |
| Sync Status | The synchronization state between AWS and Cloud Control Center (UP_TO_DATE) |
Labels and Tags
This section displays two categories of metadata:
-
AWS Tags - Tags applied to the EC2 instance in AWS (for example,
Role: WebServer,Environment: Production,Application: CustomerPortal). These are read-only and synchronize automatically from AWS. - Labels - Elisity-specific labels that administrators can manually assign to the workload for additional classification.
Manually Configured
This section contains fields that administrators can edit directly in Cloud Control Center:
- Hostname - A custom hostname for the workload
- Risk Level - An administrator-assigned risk level
- Risk Score - An administrator-assigned risk score
Create Workload Policy Groups
Workload Policy Groups classify cloud workloads based on their AWS metadata, enabling policy enforcement through the Policy Matrix. Workload Policy Groups use matching criteria specific to cloud workload attributes, such as AWS tags, instance properties, and interface characteristics.
Step 11. Create a Workload Policy Group
Navigate to Policies > Policy Groups. Click + Create Policy Group and select Workload Policy Group from the dropdown menu.
The Policy Groups page also includes a Workload filter tab alongside All, Dynamic, and Static tabs, allowing administrators to view only Workload Policy Groups.
Step 12. Configure Policy Group Settings
On the Policy Group Configuration step, enter the following fields:
| Field | Description |
|---|---|
| Policy Group Name | A descriptive name for the Policy Group (for example, Production Environment AWS Workloads) |
| Security Level | The security classification level for workloads in this group |
| Policy Group Label | An optional label for organizing Policy Groups |
| Audit Comment | An optional comment for audit trail purposes (up to 255 characters) |
Expand Advanced Settings to configure additional options including Genre, Default Security Profile, Default Final Action, Description, and the Auto-Lock Devices into Policy Group checkbox.
Click Next to proceed to matching criteria configuration.
Step 13. Define Matching Criteria
On the Matching Criteria Configuration step, define the rules that determine which cloud workloads belong to this Policy Group. Select a criteria attribute from the Criteria dropdown, set a Condition (for example, Equals), and specify the Value to match.
The Criteria dropdown is organized into two categories:
Workload Criteria
| Criteria | Description |
|---|---|
| Account ID | Match workloads by AWS account identifier |
| Hostname | Match workloads by their hostname |
| Interface Tags | Match workloads by tags applied to specific network interfaces in AWS |
| Name | Match workloads by their AWS instance name |
| Platform | Match workloads by operating system platform (for example, Linux/UNIX, Windows) |
| Provider | Match workloads by cloud provider |
| Region | Match workloads by AWS region (for example, us-west-1) |
| Tags | Match workloads by instance-level AWS tags (for example, Environment:Production) |
| Workload state | Match workloads by their current state (Running, Stopped) |
| Workload type | Match workloads by their EC2 instance type |
| Zone | Match workloads by AWS availability zone |
Interface Criteria
In addition to workload-level attributes, the Criteria dropdown includes an Interface category with the following options for matching on network interface properties:
- Egress type
- MAC address
- Network ID
- Network name
- Security policies
- Subnet CIDR
Click + And Rule to add multiple matching criteria. All criteria within a rule use AND logic, meaning a workload must match all specified criteria to be included in the Policy Group.
Tags are the primary classification method for cloud workloads. Changes to AWS tags propagate to Cloud Control Center within approximately 60 seconds, enabling dynamic Policy Group membership based on your AWS tagging strategy.
After defining the matching criteria, click Next to review the summary and complete the Policy Group creation.
Policy Enforcement for Cloud Workloads
Cloud workloads and traditional device Policy Groups coexist in the same Policy Matrix, enabling administrators to define policies governing traffic between on-premises devices and cloud workloads. Workload Policy Groups appear alongside Dynamic and Static Policy Groups in the matrix.
Policy enforcement for traffic between on-premises devices and cloud workloads (north-south traffic) occurs at the on-premises Virtual Edge Node. When an on-premises device communicates with an AWS workload through a VPN or direct network connection, the Virtual Edge Node applies the policies defined in the Policy Matrix for the corresponding Policy Groups.
Cloud workload policy enforcement requires network reachability between the on-premises Virtual Edge Node and the AWS workloads. Ensure that a VPN or direct network connection exists between the on-premises infrastructure and the target AWS environment.
Operationalization
Connector Status
After configuring the AWS connector, verify its status by navigating to Settings > Connectors. The Amazon Web Services connector should display an Active status, indicating that Cloud Control Center is successfully communicating with the AWS API and discovering EC2 instances at the configured interval.
Verification
To confirm that the Cloud Workloads integration is functioning correctly:
- Navigate to IdentityGraph > Workloads and verify that EC2 instances from the configured regions appear in the workload list.
- Click on an individual workload to confirm that Instance Details, AWS Tags, and other metadata are populated.
- Navigate to Policies > Policy Groups and verify that any created Workload Policy Groups display the expected matched asset count.
- If applicable, verify that tag changes made in the AWS console are reflected in Cloud Control Center within approximately 60 seconds.
Troubleshooting
| Issue | Resolution |
|---|---|
| Workloads navigation item does not appear | Verify that the Workloads feature is enabled under Settings > System > Advanced. The toggle must be in the on position. |
| AWS connector test connection fails | Verify that the IAM Access Key ID and Secret Access Key are correct and that the IAM user has the required EC2 read permissions. |
| Region validation fails for some regions | The IAM user may not have permissions for certain regions. Cloud Control Center automatically selects only the accessible regions. Adjust the IAM policy to include the desired regions if needed. |
| No workloads appear after connector setup | Allow approximately 60 seconds for the initial discovery cycle to complete. Verify that EC2 instances exist in the selected regions and that the connector status is Active. |
| Workload Policy Group shows zero matched assets | Verify that the matching criteria values exactly match the AWS metadata. For tag-based matching, confirm that the tag key and value format in Cloud Control Center matches the format used in AWS. |
| AWS tag changes are not reflected | Tag changes propagate from AWS to Cloud Control Center within approximately 60 seconds. If changes do not appear after this interval, verify the connector status is Active. |