Overview
Elisity Cloud Control Center (CCC) onboards an Amazon Web Services (AWS) account as a Virtual Edge Node. One Virtual Edge Node covers one AWS account, one region within that account, and one or more Virtual Private Clouds (VPCs) in that region. Elisity discovers the EC2 instances in those VPCs as workloads in IdentityGraph, classifies them by the instance tags they already carry in AWS, and enforces east-west policy between them using native AWS Security Groups.
Nothing is installed in the account. There is no agent on the instances, no appliance in the VPC, and no inbound access to your environment. The Virtual Edge calls the AWS API outbound over HTTPS with an IAM access key that you supply, and reads traffic records from the VPC Flow Logs that you deliver to Amazon S3.
This article covers the following workflow:
- Preparing the IAM access key, VPC Flow Logs, Workload Distribution Zone and Site Label
- Onboarding the AWS account through the Add Virtual Edge Node wizard
- Reviewing the discovered EC2 workloads in IdentityGraph
- Classifying workloads with their AWS instance tags and enforcing policy from the Policy Matrix
- Verifying allowed and rejected traffic
Choosing Between the AWS Connector and an AWS Virtual Edge Node
Cloud Control Center offers two AWS integrations. They are configured in different places and do different jobs, and the choice determines which article you follow.
| AWS Connector | AWS Cloud (Dataplane, Account Scope) | |
|---|---|---|
| Configured under | IdentityGraph > Connectors | Edge Management > Virtual Edge Nodes |
| Scope of one object | The accounts the credential is authorized to read | One account, one region and the VPCs selected within it |
| Policy enforcement | Not provided | AWS Security Groups, within each selected VPC |
Choose the AWS Virtual Edge Node, described in this article, when you intend to enforce policy between EC2 instances. Choose the AWS connector when you want the instances represented in IdentityGraph for visibility and inventory only. Only the Virtual Edge Node writes enforcement into the account.
Prerequisites
- A Virtual Edge that is online and available to manage the new Virtual Edge Node.
- The 12-digit AWS account ID of the account you are onboarding.
- An IAM access key, consisting of an access key ID and a secret access key, for a user or role holding the permissions listed below.
- Outbound HTTPS reachability from the Virtual Edge to the AWS API endpoints.
- A Workload Distribution Zone and a Site Label available for assignment.
- Optionally, VPC Flow Logs delivering to an Amazon S3 bucket for each VPC you want traffic reporting on.
IAM Permissions
Elisity authenticates to AWS as the identity behind the access key you supply. Grant it the following three groups of permissions.
| Purpose | Permissions |
|---|---|
| Discover regions, VPCs, EC2 instances and network interfaces | ec2:Describe* |
| Create and modify Security Groups, and assign instance network interfaces to them | Security Group create and modify permissions, plus ec2:ModifyNetworkInterfaceAttribute
|
| Read VPC Flow Log records from the S3 bucket they are delivered to |
s3:GetObject and s3:ListBucket on the flow-log bucket |
The wizard verifies the enforcement permissions live against the account before you can complete onboarding, so a missing permission surfaces while you are still in the wizard rather than at the first policy push.
VPC Flow Logs
Traffic visibility depends on VPC Flow Logs that you enable in AWS. Elisity does not enable them, because which VPCs are logged and at whose cost is your decision. For each VPC where you want traffic reporting, create a flow log with an S3 destination and confirm that the access key can read the bucket.
Flow logs are optional. Discovery and enforcement work without them, and a VPC with no flow log reports no traffic in Traffic Analytics or in the Policy Matrix traffic view.
Workload Distribution Zone and Site Label
An AWS Virtual Edge Node uses a Workload Distribution Zone. Create the Distribution Zone and the Site Label before you start the wizard, because both are selected on a wizard step rather than created from it.
Scope
- One account, one region. A Virtual Edge Node covers exactly one AWS account and exactly one region within it. To cover a second region, or a second account, add another Virtual Edge Node.
- One or more VPCs. Within the selected region you choose which VPCs the Virtual Edge Node covers. VPCs you do not select are neither discovered nor enforced.
- Enforcement is intra-VPC only. Policy is enforced between instances inside the same VPC. Traffic between peered VPCs, traffic crossing a transit gateway, and traffic to or from anything outside the VPC are not enforced by this Virtual Edge Node.
Add the Virtual Edge Node
Navigate to Edge Management > Virtual Edge Nodes and click Add Virtual Edge Node. The wizard presents the steps Choose a Virtual Edge, Virtual Edge Node Type, Virtual Edge Node Configuration, AWS Region, AWS VPCs, Site Label and Distribution Zone and Summary. The Security Platform Type step does not apply to this node type and remains inactive in the step rail.
Step 1. Choose a Virtual Edge. Select the Virtual Edge that will manage this Virtual Edge Node, then continue.
Step 2. Select the Virtual Edge Node type. On the Virtual Edge Node Type step, select the Cloud Managed card, then select the radio button AWS Cloud (Dataplane, Account Scope). Selecting it switches the step rail to AWS Region and AWS VPCs; no steps for other cloud providers appear.
Step 3. Enter the account and credentials. The Virtual Edge Node Configuration step identifies the AWS account and the access key Elisity authenticates with.
| Field | Description |
|---|---|
| Name | Required. The name this Virtual Edge Node is listed under. Use a name that identifies the account and region it covers. |
| Account ID | Required. The 12-digit AWS account ID, entered as <ACCOUNT_ID>. |
| Access Key ID | Required. The access key ID of the IAM access key, entered as <ACCESS_KEY_ID>. |
| Secret Access Key | Required. The secret that pairs with the access key ID. The value is masked as you enter it. |
| Description | Optional. Free text describing the purpose of this Virtual Edge Node. |
Step 4. Select the region. On the AWS Region step, open the Region list and select exactly one region. Cloud Control Center reads the region list live from the account, so only regions the account has enabled are offered.
Step 5. Select the VPCs. The AWS VPCs step invites you to "Select the VPCs in that region this Virtual Edge Node will cover". Open the VPCs list and select one or more. Each VPC is listed by its name tag and CIDR, falling back to the VPC identifier when the VPC carries no name tag.
As you select VPCs, Cloud Control Center runs two checks against the account and reports the result on the step itself.
| Check | What it confirms | Healthy result |
|---|---|---|
| Enforcement Permissions | That the credential may create Security Groups and attach instance network interfaces to them. The step states the model directly: "Elisity creates one security group per policy group and VPC (Elisity_<group>_<vpc>) and assigns your instances' network interfaces to them, so every interface is enforced independently." | "Can create security groups and assign them to instances" |
| VPC Flow Logs | That each selected VPC has an active flow log with an S3 destination, and that the credential can read the bucket. The step states: "Flow records are read from your VPC Flow Logs in S3. Elisity never enables them — which VPCs are logged and at whose cost is your decision." | A Network and Flow Logs table listing each selected VPC as "Logging to S3" |
A VPC with no flow log is reported as Flow logs off, and the step raises the panel "No traffic will be reported for some networks", which names the affected VPCs and states the remediation: "To see flows, create a VPC flow log delivering to an S3 bucket for each VPC (VPC, Flow logs, Create flow log, destination S3). Discovery and enforcement work without them."
Distinguish the two conditions. A VPC without a flow log is your configuration decision, so the warning is informational and does not block onboarding. A credential that cannot read the flow-log bucket is a permission gap on the Elisity side of the contract, and it does block onboarding until the bucket permissions are granted.
Step 6. Assign the Site Label and Distribution Zone. Select the Site Label that places these workloads in your policy topology and the Workload Distribution Zone that determines which policy is distributed to them. Both values may be inherited from the Virtual Edge.
Step 7. Review the Summary and finish. The Summary step lists the managing Virtual Edge, the region, the selected VPCs, the account ID, and the Site Label and Distribution Zone assignment. Confirm the values and complete the wizard.
Editing an Existing AWS Virtual Edge Node
Editing an AWS Virtual Edge Node re-opens the same wizard with every step available in the rail. Use it to move the node to a different region, to add or remove VPCs, or to replace the access key.
The AWS Region and AWS VPCs steps behave as they do during onboarding, and the two checks run again against the saved credentials, so a permission or flow-log change made in AWS since onboarding is reported the next time you open the wizard. A Finish button sits alongside Next, so a change can be saved without walking the remaining steps. The Summary step shows the values the node is saved with, including whether the Site Label and Distribution Zone are inherited from the Virtual Edge.
The secret access key remains masked when you edit a Virtual Edge Node. It is re-sent to AWS only if you retype it, so you can change the region or the VPC selection without re-entering the credential.
View Discovered Workloads
Discovery begins as soon as the wizard completes, and within approximately 60 seconds the EC2 instances in the selected VPCs appear under IdentityGraph > Workloads.
The Workload Summary panel at the top of the page reports the total workload count and a breakdown By State, and groups the workloads By Region, By Virtual Network, By Instance Type, By Provider, By VEN Name and by Top Tags. Filtered to a single AWS Virtual Edge Node, the region and virtual network panels each resolve to one value, confirming that the node picked up the region and VPCs you selected.
Unfiltered, the same summary places the AWS workloads alongside every other dataplane in the tenant. AWS, Azure, Google Cloud Platform and Kubernetes workloads are counted together under By Provider and appear in the same region and virtual network groupings, which is what allows a single Policy Group and a single Policy Matrix to span all of them. The table beneath the summary lists each workload with its hostname or instance identifier, provider, endpoint name, status, Policy Group, VEN ID and VEN name.
Select a workload to open Workload Details.
| Panel | Contents |
|---|---|
| Workload Information | Cloud Provider, IP Address and Distribution Zone. |
| Instance Details | Instance ID, Endpoint Name, Provider, MAC, Status, VEN ID, VEN Name, Region, Virtual Network and Subnet. |
| Labels and Tags | AWS Tags holds the instance tags imported from AWS, one chip per tag. Manually Configured Labels holds any labels applied in Cloud Control Center. |
| Manually Configured | Hostname, Risk Level and Risk Score, where these have been set. |
Check the AWS Tags panel first. The values shown there are what your Policy Group Match Criteria select on.
Classify and Enforce
Classify Workloads by AWS Instance Tags
AWS instance tags arrive in IdentityGraph as workload tags, so instances classify themselves from metadata your teams already apply in AWS. Navigate to Policy > Policy Groups and open the Workload Policy Groups tab. On the Match Criteria tab of a Policy Group, add a criterion of type CSP Workload on the Tags attribute with the operator Equals, and enter the tag values that identify the tier.
A criterion accepts several tag values, so a Policy Group can absorb more than one naming convention without a rule for each. Elisity imposes no tag naming scheme of its own; the criterion selects on whatever values are present on the instances. The Group Tag Value shown under Workload Group Details identifies the Policy Group, and it appears in the name of the Security Group Elisity creates in AWS.
Because classification is driven by tags rather than by cloud, a Policy Group written for one provider absorbs workloads from every other provider carrying the same tags. The Assets tab lists the current members with their workload tags, interface identifiers and addresses.
An existing Policy Group that already classifies Azure, Google Cloud Platform or Kubernetes workloads by tag therefore picks up newly discovered EC2 instances with no change at all. An instance that matches no criterion lands in the Unassigned Workload Policy Group, which has consequences described below.
How Policy Becomes AWS Security Groups
Write policy in the Policy Matrix exactly as you do for any other workload. Navigate to Policy > Matrix and set both Side A and Side B to Workloads. The cells at the intersection of two workload Policy Groups are the ones that drive AWS enforcement.
Cloud Control Center translates those cells into native AWS objects as follows.
- For every Policy Group with members in a VPC, Elisity creates one Security Group in that VPC, named
Elisity_<group>_<vpc>. Membership in that Security Group is Policy Group membership. - A matrix cell allowing traffic from group A to group B on a port becomes two rules: an ingress rule on B's Security Group permitting A's Security Group on that port, and an egress rule on A's Security Group permitting B's Security Group. No rule contains an IP address. The rules reference the other Security Group directly, so they stay correct as instances are created, terminated and readdressed.
- A deny writes nothing. In AWS a Security Group rule can only permit, so a deny is expressed as the absence of an allow.
- Elisity places exactly one Security Group on each managed network interface and removes the default rule that allows all egress, so denies hold.
- Security Groups are stateful. Return traffic for an allowed flow is permitted automatically, so a workload-to-workload cell does not require a matching cell in the opposite direction.
A Policy Group with no policy still receives a Security Group, with an empty rule list. Because unclassified instances land in the Unassigned Workload Policy Group, an instance that matches no Match Criteria is isolated until it is classified. Confirm your Match Criteria cover every instance in the selected VPCs before you rely on enforcement. An interface with no Policy Group at all is returned to the default Security Group of its VPC.
Confirming Enforcement on an Interface
Enforcement is applied per network interface, so the interface view is where you confirm it. Open a workload and select the Network Interfaces tab.
Each interface is listed by its elastic network interface identifier, with an Enforcement IP field above five panels. Network Context shows the MAC address, subnet CIDR, source and destination check, virtual network and route table. Policy Details names the Policy Group the interface is classified into and its Policy Set. Security Groups lists the Security Groups attached to the interface, where the Elisity group appears under its Elisity_<group>_<vpc> name. AWS Interface Tags (Read only) and Elisity Interface Tags show the tags carried on the interface itself, as distinct from the instance tags.
The Security Group name confirms three things at once: that the group is Elisity's, which Policy Group it represents, and which VPC it belongs to.
Verify
Confirm the outcome in the Policy Matrix rather than by testing connectivity from the instance itself. VPC Flow Log records state ACCEPT or REJECT explicitly, so rejected traffic is reported as well as allowed.
Navigate to Policy > Matrix, keep Side A and Side B set to Workloads, and turn on the traffic view from View Options. The matrix shades each cell according to the traffic observed in the selected window, which you set with the interval control and the pager beneath the matrix.
Green cells are intersections where allowed traffic was observed. Red cells are intersections where connection attempts were rejected, confirming that a deny is taking effect in AWS. A cell that stays empty means no traffic was observed between those two Policy Groups in the window, which may equally mean that the workloads did not communicate or that the VPC has no flow log.
After onboarding, confirm the following:
- The workload count under IdentityGraph > Workloads matches the running instances in the selected VPCs.
- Every discovered instance belongs to an intended Policy Group, and Unassigned Workload is empty.
- The Network Interfaces tab of a representative workload shows the expected
Elisity_<group>_<vpc>Security Group.
Limitations and Cautions
Because Elisity places exactly one Security Group on each managed interface, the instance's own outbound traffic is governed by the Policy Matrix as well. Administrative access such as SSH and Systems Manager, and outbound package updates, are subject to the same policy. Verify enforcement results in the flow log data surfaced by Cloud Control Center rather than over an SSH session that the policy may itself be denying.
- Intra-VPC enforcement only. Peered VPCs, transit gateway paths, and traffic to or from outside the VPC are not enforced.
- One Security Group per managed interface. Elisity replaces the Security Groups on the interfaces it manages, so groups that you maintain yourself cannot be kept alongside the Elisity group. Place instances whose Security Groups must remain under your control in a VPC this Virtual Edge Node does not cover.
- Long-lived access key. Authentication uses an IAM access key. Rotate it on your normal schedule and update it in the Virtual Edge Node configuration. Support for STS AssumeRole is planned.
- Traffic visibility depends on your flow logs. A VPC without a flow log delivering to S3 is discovered and enforced, but reports no traffic.
- Unclassified instances are isolated. An instance that matches no Policy Group Match Criteria receives a Security Group with no rules.