The Elisity Virtual Edge can be deployed as a cloud-hosted virtual appliance in Amazon Web Services (AWS), providing an alternative to on-premises and hypervisor-based deployments. This deployment model is functionally identical to other Virtual Edge deployments, and enables the Virtual Edge to onboard and manage enforcement points such as switches, wireless LAN controllers (WLCs), and firewalls running the Elisity Virtual Edge Node software.
The Virtual Edge is distributed as an Amazon Machine Image (AMI) that Elisity shares privately with your AWS account. The instance boots inside your Virtual Private Cloud (VPC), registers with Cloud Control Center over the internet, and is then managed exactly like any other Virtual Edge. The central requirement is network connectivity from the Virtual Edge Nodes to the Virtual Edge, typically via private IP through AWS Site-to-Site VPN, AWS Direct Connect, Transit Gateway, or VPC peering. The full set of required flows is listed under Connectivity Requirements.
For a comparable deployment in Microsoft Azure, see Azure Cloud-Hosted Virtual Edge.
Deployment Overview
The order of operations in this workflow matters. Once the image is available, the network interface is built first, so that its private IP address is known before anything else is configured. That address is what the Virtual Edge is registered against in Cloud Control Center, and the one-time passcode that Cloud Control Center issues is bound to it. The EC2 instance is launched last, attached to the interface that already exists and carrying the registration credentials in its user data.
The result is a single-shot deployment: the instance registers itself on first boot and comes Online with no SSH session, no manual registration, and no post-launch configuration.
| Step | Action | Produces |
|---|---|---|
| 0 | Confirm the Elisity Virtual Edge AMI has been shared with your AWS account | A private AMI visible in your account with a status of Available |
| 1 | Create the network interface in AWS and associate an Elastic IP address with it | A network interface ID (eni-...) and a static private IPv4 address |
| 2 | Create the Virtual Edge in Cloud Control Center using that private IP address | A Virtual Edge in Not Registered state |
| 3 | Retrieve the registration credentials from the Virtual Edge details page | A one-time passcode (OTP) and the Cloud Control Center URL |
| 4 | Launch the EC2 instance from the shared AMI, attaching the existing interface and supplying the credentials as user data | A running instance that registers itself on first boot |
| 5 | Verify registration in Cloud Control Center and confirm the data path to the Virtual Edge Nodes | A Virtual Edge in Online state, ready to onboard Virtual Edge Nodes |
Prerequisites
Important - Request Access to the Virtual Edge AMI First:
The Elisity Virtual Edge is distributed as a private Amazon Machine Image (AMI). It is not published in the AWS Marketplace and it does not appear in your account until Elisity explicitly shares it. No instance can be launched until that sharing is complete, so start this request before beginning any of the steps below.
Contact your Elisity CX Engineer to request the image, and have the following information ready:
- AWS Account ID - the 12-digit numeric account identifier that the image will be shared with. Provide the numeric ID, not the account alias.
- AWS region - the region in which the Virtual Edge will run.
- Elisity tenant - the Cloud Control Center tenant that the Virtual Edge will register with.
- Public IP address the Virtual Edge will register from - the Elastic IP address that will be associated with its network interface, or the public address of the NAT gateway serving its subnet. This is created in Step 1: Create the Network Interface in AWS; if it has not been allocated yet, request the image first and provide the address as soon as it is known.
NOTE - Cloud Control Center Access Restrictions: Tenants differ in how access to Cloud Control Center is controlled. Some restrict it entirely, while others maintain an allowlist of the source IP addresses permitted to reach the tenant - which must include the public IP address of every Virtual Edge that will register, with TCP port 443 open to it. The exact process varies by customer and is handled by your Elisity CX Engineer. Provide the tenant and the public IP address above when you request the image, so that both can be arranged together.
AWS Access
- Active AWS account with an existing VPC and subnet in the target region.
- Permissions to create and manage elastic network interfaces, launch EC2 instances, create or select security groups, and allocate and associate Elastic IP addresses.
EC2 Instance Specifications
| Resource | Specification |
|---|---|
| Instance Type (recommended) | c6in.2xlarge - network-optimized, up to 40 Gbps of network bandwidth |
| Instance Type (alternative) | c7i.2xlarge - newer-generation CPU at a lower cost, up to 12.5 Gbps of network bandwidth |
| vCPUs | 8 (both instance types) |
| Memory | 16 GB (both instance types) |
| Root Volume | Defined by the Elisity AMI. The default size does not need to be changed at launch. |
| Machine Image | Provided by Elisity as a private AMI shared with your AWS account |
Both instance types provide 8 vCPUs and 16 GB of memory. The Virtual Edge performs packet processing and policy enforcement, so the higher bandwidth and packet-per-second performance of the network-optimized c6in.2xlarge matters more than raw CPU speed, and it is the recommended default. Select c7i.2xlarge where expected throughput is modest and cost is the higher priority.
Additional Requirements
- An elastic network interface with a static private IPv4 address, created before the instance is launched.
- EC2 key pair for SSH access to the appliance for manual operations or troubleshooting.
- Outbound internet access for reaching Elisity Cloud Control Center (TCP port 443), through a NAT gateway or an Elastic IP address associated with the network interface.
- Routing or VPN connectivity to on-premises Virtual Edge Nodes (via AWS Site-to-Site VPN, AWS Direct Connect, Transit Gateway, or VPC peering).
Connectivity Requirements
The Virtual Edge must be able to reach Elisity Cloud Control Center and must be able to route traffic to and from connected Virtual Edge Nodes. The following flows must be permitted before the instance is launched. Review the Platform Connectivity Requirements article for the authoritative reference on flows between Elisity components.
| Flow | Protocol / Port | Requirement in AWS |
|---|---|---|
| Virtual Edge → Cloud Control Center | Outbound TCP 443 | Outbound internet access via a NAT gateway or an Elastic IP address associated with the network interface. Must not be blocked by security groups, network ACLs, or route table constraints. |
| Virtual Edge ↔ Virtual Edge Nodes | Vendor-specific; SSH (TCP 22) for most integrations | Must route over private IP in both directions, via Site-to-Site VPN, Direct Connect, Transit Gateway, or VPC peering. Return traffic to the Virtual Edge Nodes must also be permitted and routable. |
| Administrative access → Virtual Edge | Inbound TCP 22 | Permitted from your administrative ranges on the security group attached to the network interface. Not required for registration, but required for manual operations and troubleshooting. |
| Latency | ≤ 300 ms RTT per segment | Applies to both Cloud Control Center ↔ Virtual Edge and Virtual Edge ↔ Virtual Edge Node. Factor this into the choice of AWS region relative to your Cloud Control Center tenant and your on-premises sites. |
Common Connectivity Models
Option 1: Site-to-Site VPN or AWS Direct Connect
- Connects the VPC to on-premises infrastructure using a Virtual Private Gateway, Transit Gateway, or Direct Connect.
- Routing must support private IP reachability between the Virtual Edge and all Virtual Edge Nodes.
Option 2: Transit Gateway or VPC Peering
- Use Transit Gateway attachments or peered VPCs to enable private routing between the Virtual Edge and the networks where Virtual Edge Nodes reside.
Important - Permit the Source IP Before Launching:
Where the tenant restricts access by source IP address, as described in the Prerequisites section, that address must be permitted before the instance is launched. This workflow registers the Virtual Edge automatically on first boot, so an address that has not yet been permitted causes the first and only registration attempt to fail.
Step 0: Confirm Access to the Virtual Edge AMI
Nothing else in this workflow can be completed until the Elisity Virtual Edge image is visible in your AWS account, so confirm it has arrived before starting. If you have not yet requested it, see the Prerequisites section above.
Open the EC2 console, navigate to Images > AMIs, and set the filter to Private images. Filter on virtual-edge to locate the image, and confirm that Status is Available. Make a note of the AMI name, which identifies the Virtual Edge software version.
NOTE: Machine images are region-specific, and you are looking in the region the image was shared into. If the image does not appear, confirm you are viewing the correct region before raising it with your Elisity CX Engineer. To deploy Virtual Edges in more than one region, request the AMI in each region where an instance will run.
Step 1: Create the Network Interface in AWS
The Virtual Edge is registered against a specific private IP address, so that address must exist and be reserved before the Virtual Edge is created in Cloud Control Center. Creating an elastic network interface up front reserves the address, fixes the security groups, and allows an Elastic IP address to be associated before any instance exists.
Step 1. In the EC2 console, navigate to Network & Security > Network Interfaces and click Create network interface. Complete the form as follows:
- Description - a descriptive name, for example "Elisity Virtual Edge Interface".
- Subnet - the subnet that provides private routing to your Virtual Edge Nodes.
- Interface type - ENA.
- Private IPv4 address - select Custom and enter the address to assign to the Virtual Edge. This is the address you will register in Cloud Control Center.
- Security groups - select a security group that permits inbound SSH (TCP port 22) from your administrative ranges and outbound TCP port 443.
Click Create network interface.
NOTE: Security groups are a property of the network interface. Because the instance is launched against this interface, the security groups selected here are the ones that apply, and the security group fields in the launch wizard become read-only.
Associate an Elastic IP Address
The Virtual Edge must reach Cloud Control Center on TCP port 443. If the subnet already routes outbound traffic through a NAT gateway, skip this subsection. Otherwise, associate an Elastic IP address with the interface now, so that outbound connectivity is in place the moment the instance boots.
Step 2. Open the network interface you created and choose Actions > Associate address.
Step 3. Select the Elastic IP address to use and confirm that the Private IPv4 address matches the address assigned to the interface. Click Associate.
NOTE: An Elastic IP address provides outbound reachability only. Registration continues to use the private IP address of the Virtual Edge.
Record the Interface Details
Step 4. On the network interface summary page, copy and set aside both of the following. They are the two values that connect the AWS side of this deployment to the Cloud Control Center side.
-
Network interface ID (
eni-...) - selected in Step 4: Launch the EC2 Instance. - Private IPv4 address - entered in Step 2: Create the Virtual Edge in Cloud Control Center.
Step 2: Create the Virtual Edge in Cloud Control Center
Virtual Edges can be created individually, or created in bulk using a spreadsheet upload. See this article for details on bulk creation. The following steps show creating a single Virtual Edge.
Create a Virtual Edge Group
Virtual Edge Groups are required for provisioning a Virtual Edge. A Virtual Edge Group acts as an operational container for one or more Virtual Edges and their associated Virtual Edge Nodes. It defines site-level scope and enables high availability and failover between Virtual Edges.
NOTE - Recommended Practice: Create a dedicated Virtual Edge Group for the Virtual Edges hosted in each AWS region, named for that region - for example, "AWS VE GROUP US-EAST-1". All Virtual Edges within a group must have routability to the same infrastructure, because they serve as potential failover peers for one another. Grouping by region keeps failover peers inside the same VPC and routing domain, and keeps regional deployments cleanly separated as the environment grows.
- Navigate to Edge Management > Virtual Edges in Cloud Control Center.
- In the Virtual Edge Groups panel, click + Create Group.
- Provide a name that identifies the region (for example, "AWS VE GROUP US-EAST-1") and optionally assign it to a site.
- Click Save.
Follow this article for more information on Virtual Edge Group creation.
Add a Virtual Edge
Step 1. Navigate to Edge Management > Virtual Edges and click + Add Virtual Edge > Add Single Virtual Edge.
Step 2. On the Virtual Edge Type step, select Virtual Infrastructure, then click Next. Virtual Infrastructure is the correct type for an AWS deployment. Cloud Control Center reports this type as Hypervisor Hosted on the Virtual Edge details page.
Step 3. On the Virtual Edge Configuration step, select the regional Group you created, and enter the IP Address you recorded in Step 1: Create the Network Interface in AWS. Enter a Host Name and an optional Description, then click Next.
Important:
The IP address entered here must be the private IPv4 address of the network interface, exactly as assigned in Step 1: Create the Network Interface in AWS. The one-time passcode that Cloud Control Center issues is bound to this address, and public IP addresses do not authenticate during registration.
Step 4. Review the Summary of configurations, then click Finish to complete the provisioning.
Step 5. Confirm that the new Virtual Edge appears in the Virtual Edges list with a status of Not Registered. The status changes once the EC2 instance registers successfully.
Step 3: Retrieve the Registration Credentials
The Elisity Virtual Edge registers automatically using the EC2 user data mechanism. On first boot, the appliance reads the one-time passcode and the Cloud Control Center URL from instance metadata, registers with Cloud Control Center, and starts its services. No SSH session or manual input is required.
Step 1. In Edge Management > Virtual Edges, click the name of the Virtual Edge you created to open its details page. In the Additional Information panel, click Show Credentials next to OTP.
Step 2. The Virtual Edge Configuration dialog displays the Virtual Edge name, the Cloud Control Center URL, and the Client Secret. Click Show to reveal the client secret, which is the one-time passcode used for registration. Copy both values.
Required Format for the User Data Field
Assemble the two values into the following format. This is the exact content that goes into the User data field in Step 4: Launch the EC2 Instance.
OTP=<your-one-time-passcode>
CCC_URL=https://<your-cloud-control-center-url>NOTE: The user data should contain only these two lines. No YAML or cloud-init formatting is required. This method is compatible with any provisioning tool or interface that supports EC2 user data, including AWS CloudFormation and Terraform.
Step 4: Launch the EC2 Instance
With the image confirmed, the interface reserved, the Virtual Edge created, and the credentials in hand, the instance can now be launched in a single pass.
Step 1. Provide a Name for the instance. Under Application and OS Images (Amazon Machine Image), open the My AMIs tab, select Shared with me, and choose the Elisity Virtual Edge AMI.
Step 2. Under Instance type, select c6in.2xlarge for the recommended network-optimized configuration.
Alternatively, select c7i.2xlarge where expected throughput is modest and cost is the higher priority. Both types provide 8 vCPUs and 16 GiB of memory.
Step 3. Under Key pair (login), select an existing EC2 key pair or create a new one. SSH access is not needed for registration, but it is required for manual operations and troubleshooting.
Step 4. Under Network settings, click Edit, then expand Advanced network configuration. For Network interface 1, open the Network interface dropdown and select the eni-... interface you created in Step 1: Create the Network Interface in AWS instead of leaving it set to New interface.
Important:
Selecting the existing interface is what binds the instance to the private IP address the Virtual Edge was registered against. Once it is selected, the Subnet, Security groups, and Primary IP fields become read-only, because those properties now come from the interface. If those fields remain editable, the wizard is still set to create a new interface and the deployment will not register.
Step 5. Under Configure storage, leave the root volume at the size defined by the Elisity AMI. No change is required.
Step 6. Expand Advanced details and paste the two registration lines assembled in Step 3: Retrieve the Registration Credentials into the User data field. Leave User data has already been base64 encoded unchecked.
The completed entry looks like the following, with your own one-time passcode and tenant URL in place of the values shown:
OTP=k7Rq2mXvB9nL3sEwT5yZ8pA4dHjF6gC1
CCC_URL=https://yourtenant.elisity.ioStep 7. Review the complete configuration before launching. The AMI should be the shared Elisity image, the network interface should be the eni-... you created, and the user data should contain the OTP and Cloud Control Center URL.
Step 8. Click Launch instance.
Step 5: Verify Registration
No further action is required in AWS. The appliance reads the user data on first boot, registers itself with Cloud Control Center, and starts its services.
Open Edge Management > Virtual Edges and locate the Virtual Edge you created. Its status changes from Not Registered to Online once the instance completes registration. On the Virtual Edge details page, the Software Version, OS Software Version, and Resource Utilization fields populate at the same time, and Virtual Edge Type is reported as Hypervisor Hosted.
Then confirm the data path to the enforcement points:
- Ensure the Virtual Edge can communicate with the intended Virtual Edge Nodes.
- Check routing for private network connectivity between the VPC and the networks where Virtual Edge Nodes reside.
- Check that return traffic from the Virtual Edge to the Virtual Edge Nodes is permitted and routable.
Connecting to the Virtual Edge CLI (Manual Method)
If you did not supply user data at launch, register the Virtual Edge with Cloud Control Center manually over SSH.
-
SSH into the Virtual Edge:
ssh -i yourprivatekey.pem elisity@<ve-ip-address> -
Run the registration command:
register - When prompted, enter the Cloud Control Center URL and the one-time passcode, then select "Y" to all prompts that follow.
Important:
Use the private IP address of the Virtual Edge when registering. Public IP addresses are not accepted by the OTP system. This step is not required when user data is supplied during instance launch.
Troubleshooting
Cloud Control Center reports onboarding progress in the notification panel. Click the bell icon in the header to open it and review the entries for the Virtual Edge. The notifications indicate which step of the onboarding sequence failed, which is the fastest way to narrow down the cause before working through the checks below.
| Symptom | Checks |
|---|---|
| The Virtual Edge does not register and remains Not Registered | Work through the following, in order:
|
| The launch wizard will not let you set the subnet, security groups, or primary IP | This is expected. Those properties belong to the network interface you selected and are configured in Step 1: Create the Network Interface in AWS. To change them, edit the network interface itself. |
| SSH connection fails | Confirm the security group attached to the network interface permits inbound TCP port 22 from your source range, that the correct key pair was selected at launch, and that a route exists to the private IP address of the instance. |
At this point, the Virtual Edge is ready to onboard Virtual Edge Nodes for enforcement. Virtual Edge software upgrades are driven from Cloud Control Center in the same way as any other Virtual Edge, so moving to a later release does not require rebuilding the EC2 instance. For information on managing the Virtual Edge and onboarding Virtual Edge Nodes, see Managing Virtual Edges and Virtual Edge Nodes.