KEYSIGHT TECHNOLOGIES
Verified July 2026 on real AWS

CloudLens Autopilot for AWS

Deploy CloudLens sensors to your EC2 instances in 5 to 10 minutes (small deployments) or 30 to 60 minutes (thousands of instances). A full 3-component stack (vController + KVO + vPB) was launched live in AWS us-east-1 and reached CREATE_COMPLETE. Linux, Windows, fully automated.

1 Launch Stack CloudFormation, one click 2 Open in CloudShell One curl command 3 Pull Docker Image Laptop or CI/CD
Ubuntu 20/22/24 RHEL 7/8/9 Windows 2019/2022 3/3 verified
deploy-stack.sh

Don't have vController, KVO, or vPB yet?

Deploy them from AWS Marketplace in one click before running sensor deployments.

⚡ Deploy the full CloudLens Stack (recommended)

One CloudFormation stack. Provisions vController + KVO + vPB into a shared VPC with purpose-built mgmt, data, and tool subnets. About 15 minutes from click to ready.

  • One shared VPC with mgmt / data / tool subnets
  • vController + KVO + vPB deployed together, each with its own Elastic IP
  • Instance types fixed to what each AMI is qualified on (t3.xlarge vController, c5.2xlarge KVO, t3.xlarge vPB)
  • Code: CloudFormation template · Terraform stack module · deploy-stack.sh
▶ Launch CloudLens Stack

Or deploy each product separately:

CloudLens vController formerly CLMS

Central management for sensors. Required for any sensor deployment.

  • Version from the Marketplace AMI (CLMS_6.12.x)
  • One instance, t3.xlarge, ready in about 15 minutes
  • Access: web UI over HTTPS (appliance shell uses password auth, not your key pair)
  • Code: Terraform module · CloudFormation template
  • Web UI: https://<vcontroller-ip>
  • UI login: admin / Cl0udLens@dm!n (change on first login)
▶ Launch vController

Vision Orchestrator (KVO) NEW

Optional. Centralizes the vPB fleet and automates AWS VPC Traffic Mirroring.

  • Version from the Marketplace AMI (KVO 2.13.x)
  • One instance, c5.2xlarge (Marketplace-fixed)
  • SSH: ssh -p 9022 admin@<kvo-ip> (port 9022, not 22)
  • Code: Terraform module · CloudFormation template
  • Web UI: https://<kvo-ip>
  • UI login: admin / admin (change on first login)
▶ Launch KVO

Virtual Packet Broker (vPB)

Optional. For inline traffic processing and VXLAN aggregation.

  • Version from the Marketplace AMI (vPB-KVO 3.13.x)
  • One instance, t3.xlarge, multi-ENI layout
  • SSH: ssh -p 9022 admin@<vpb-ip> (NOT port 22)
  • Bootstrap runs automatically at first boot (EC2 user data): kubeconfig + sudo vpb ready on first SSH
  • Code: Terraform module · CloudFormation template
  • CLI access: sudo vpb (works the moment you SSH in)
▶ Launch vPB

After vController finishes initializing (about 15 minutes), open the UI, create a project, copy the project key, then return here to run the sensor deployment.

Prefer Terraform?

vController, KVO, and vPB are all available as Terraform modules in deploy/terraform. The stack module composes all three; the per-component modules deploy them individually: clms (vController), kvo, vpb. Same Marketplace AMIs, IaC-friendly for pipelines and repeatable deployments. The CloudFormation equivalents live in deploy/cloudformation.

cd deploy/terraform/stack
terraform init
terraform apply -var key_name=my-keypair -var deploy_kvo=true -var deploy_vpb=true

One command, full stack

vController, KVO, and vPB plus sensors. End to end. From a single paste.

curl -sSL https://raw.githubusercontent.com/Keysight-Tech/cloudlens-ansible-aws/main/deploy/deploy-stack.sh | bash

Prompts for region and key pair, accepts Marketplace terms, deploys vController, waits for initialization, optionally adds KVO and vPB, then chains to sensor deployment. Run from AWS CloudShell or any machine with the AWS CLI.

Bash (recommended)

One paste, end to end. Best for: trying it the first time, or onboarding a new customer.

Terraform Stack Module

Single command, vController plus KVO and vPB. Best for: IaC pipelines and repeatable infra.

cd deploy/terraform && terraform init && terraform apply \
  -var key_name=my-keypair -var deploy_kvo=true -var deploy_vpb=true

Browse the Terraform code on GitHub →

Printable Runbook

Executive-friendly PDF guide. Best for: customer CTO, procurement, training.

Download Runbook

Verify it end-to-end on disposable VMs

For SE demos or first-call verification: stand up 3 throwaway workload EC2 instances (Ubuntu 22.04 + RHEL 9 + Windows Server 2022) tagged with a discovery tag, then run the stack with the matching tag flags. Proves sensors install on every supported OS in one pass.

# 1. Stand up the 3 test workload instances (default tag: cloudlens=yes)
curl -sSL https://raw.githubusercontent.com/Keysight-Tech/cloudlens-ansible-aws/main/scripts/deploy-test-workload-vms.sh | bash

# 2. Deploy the CloudLens stack, then run sensor deployment against the tagged instances
curl -sSL https://raw.githubusercontent.com/Keysight-Tech/cloudlens-ansible-aws/main/deploy/deploy-stack.sh | bash

# 3. Cleanup when done
aws cloudformation delete-stack --stack-name cloudlens-test-vms --region us-east-1

The fixture launches three instances tagged cloudlens=yes with an os tag per platform. The sensor deployment installs on all three and they register with vController. Total round trip: about 25 to 30 minutes. Override the tag pair with TESTVMS_TAG_KEY / TESTVMS_TAG_VALUE environment variables if you want to mirror a customer's existing convention.

Run from Docker

Pinned image with Ansible, the AWS SDKs, and pywinrm. Works from your laptop, a CI runner, or any container host.

docker run --rm -it \
  -v $(pwd)/customer_input.yaml:/work/customer_input.yaml \
  -v $HOME/.ssh:/root/.ssh:ro \
  -e AWS_ACCESS_KEY_ID -e AWS_SECRET_ACCESS_KEY \
  -e AWS_DEFAULT_REGION \
  ghcr.io/keysight-tech/cloudlens-ansible-aws:latest

AWS credentials are passed via environment variables (use scripts/setup_aws_creds.sh to configure a profile). Same behavior as the CloudShell quickstart, just packaged for CI/CD or repeat customer deployments.

Image registry

Image is published to GitHub Container Registry on every push to main: ghcr.io/keysight-tech/cloudlens-ansible-aws.

View on ghcr.io

Build locally

Prefer to build your own image instead of pulling? The Dockerfile is in the repo root.

git clone https://github.com/Keysight-Tech/cloudlens-ansible-aws.git
cd cloudlens-ansible-aws
docker build -t cloudlens-ansible-aws .

CI/CD pattern

Drop the same docker run into GitHub Actions, GitLab CI, Jenkins, or CodeBuild. Mount your customer_input.yaml as a build artifact.

Get started in 5 steps

Most deployments under 50 instances complete in 5 to 10 minutes.

  1. Check prerequisites 2 minutes

    You need these in place before deploying:

    • AWS account with EC2 and CloudFormation permissions in your target region
    • CloudLens vController (formerly CLMS) deployed and reachable from your target instances
    • A project key from vController (Settings, Projects, API Keys)
    • An EC2 key pair (for SSH targets) or SSM enabled (for Windows targets)

    If you do not have vController deployed yet, use the Launch vController button above.

  2. Tag your EC2 instances 5 minutes

    The deployment discovers instances by tag. Apply these to every target instance:

    TagValue
    cloudlensyes
    osubuntu or rhel or windows
    envprod (or dev, qa)

    Tag a single instance:

    aws ec2 create-tags --resources i-0123456789abcdef0 \
  --tags Key=cloudlens,Value=yes Key=os,Value=ubuntu Key=env,Value=prod
  3. Build your config file 1 minute

    Use the wizard below to fill the fields and download customer_input.yaml.

    Jump to wizard ↓

    Tip: the wizard shows the YAML rendering live as you type. Each field has inline help so you know exactly what to enter.

  4. Deploy 5 to 60 minutes

    Place your downloaded customer_input.yaml in your working directory, then pick one of the three deploy paths.

    Tier 1: CloudFormation

    One click. No local tools. Best for: trying it for the first time.

    Launch Stack

    Tier 2: CloudShell

    Already authenticated. One curl command. Best for: most customers.

    curl -sSL https://raw.githubusercontent.com/Keysight-Tech/cloudlens-ansible-aws/main/quickstart.sh | bash

    Tier 3: Docker

    Reproducible. Pinned versions. Best for: CI or repeat deployments.

    docker run --rm -it -v $(pwd)/customer_input.yaml:/work/customer_input.yaml ghcr.io/keysight-tech/cloudlens-ansible-aws:latest
  5. Verify in vController 2 minutes

    Open your vController web UI and confirm:

    • Each tagged instance appears as a registered sensor (under Sensors)
    • Custom tags from your config match what you see in vController
    • Sensors show as connected and reporting

    Stuck? See the troubleshooting section below or the full troubleshooting docs.

Why this exists

Customers told us deploying CloudLens at scale on AWS felt manual. We made it boring.

Automated end to end

Discovery, bootstrap, install, register. One command, one playbook run, zero per-instance steps.

Works for any instance

Ubuntu, RHEL, Rocky, Alma, Windows Server. Public IP, jumpbox, SSM Session Manager, or CloudShell.

Scales to 5,000+ instances

Auto tunes Ansible forks based on inventory size. Sharded execution past 2,000 instances, AWX beyond 10,000.

Build your customer_input.yaml

Fill in four fields. Download the file. Run quickstart. That is the whole flow.

1

CloudLens vController

Where do I find this?

The IP or hostname of your vController deployment. You can find it in the AWS console under the vController EC2 instance details, or in the Outputs of your CloudFormation stack.

2

Project key

Where do I find this?

In the vController web UI: Settings, Projects, API Keys, copy the key for the project you want sensors to register under.

3

Custom tags

What does this do?

These tags are attached to each registered sensor and visible in vController. Use them to filter and group sensors (for example: Customer=Acme, Region=us-east-1). Space-separated key=value pairs.

4

Regions

What goes here?

The AWS regions the deployment scans for tagged EC2 instances. List one or more, comma-separated. Defaults to us-east-1.

Live architecture flow

A single Ansible control point authenticates to AWS, discovers EC2 instances by tag, and routes each host to the right OS lane. The CloudLens sensor on each EC2 instance mirrors traffic (mirror / VXLAN) to the vPB, which forwards to your monitoring tool. Every sensor self registers with vController on first start.

Flow: CloudLens sensor on EC2 to mirror / VXLAN to vPB to monitoring tool. The dotted line shows sensor registration traffic back to vController.

How does it scale?

Drag the slider to see the estimated deployment time for your fleet size.

Instances 100
Forks 50
Sharded No
Estimated time 15 to 30 min
1 to 505 to 10 min
50 to 50015 to 30 min
500 to 2,00030 to 60 min
2,000 to 10,00030 to 60 min (sharded)
10,000+1 to 2 hr (AWX)

Verified against real AWS

A full 3-component stack was launched via CloudFormation in us-east-1 and reached CREATE_COMPLETE, July 2026.

3 / 3 Stack components live vController, KVO, vPB
CREATE_
COMPLETE CloudFormation status Region us-east-1
3 AMIs Correct Marketplace AMIs t3.xlarge / c5.2xlarge / t3.xlarge
July 2026 Last verified Live CloudFormation launch
ComponentResultInstance type
CloudLens vController (control plane)CREATE_COMPLETEt3.xlarge
Vision Orchestrator (KVO)CREATE_COMPLETEc5.2xlarge
Virtual Packet Broker (vPB)CREATE_COMPLETEt3.xlarge
Full stack (stack.yaml)3/3 live in us-east-1Shared VPC

vController configuration (one-time)

Once CloudFormation or Terraform finishes, configure the Keysight products via their web UIs. One-time setup, about 15 minutes end to end. vController was formerly named CLMS.

1

Accept the KVO EULA

KVO blocks all access, including the API, until the EULA is accepted in the browser. Open https://<kvo-ip>, read the Keysight Software EULA, click Agree, then log in with admin / admin.

This must be done in the browser. The CLI cannot accept the EULA on your behalf.
2

Activate licenses on KVO

Navigate to Settings, Product Licensing, Activate. Three licenses must be enabled: vPB Advanced, CloudLens Enterprise, and KVO perpetual. If the license server is unreachable, copy the offline activation key from your Keysight portal.

3

Adopt vController into KVO

From KVO: Inventory, CloudLens Manager, Discover. Enter the vController private IP (the 10.0.1.x address from the stack Outputs) and the admin credentials (admin / Cl0udLens@dm!n). Status must turn CONNECTED before proceeding.

4

Onboard the vPB to KVO

SSH to the vPB on port 9022 (not 22), then run sudo vpb and:

configure terminal
kvo
ip <kvo-private-ip>
port 443
enable
monitored
end
write memory

Back in KVO, the vPB shows up under Inventory, Devices. Adopt it with Control the adopted device enabled (default).

5

Create the AWS Cloud Config

On KVO: Cloud Fabric, Cloud Configs, New, AWS. Paste the IAM access key and secret (from the stack Outputs), click Connect, pick the target region and VPC, set the deployment instance type to c5.2xlarge, choose the subnets, and commit. KVO auto-deploys collector Service VMs.

Preparing existing customer VMs

Skip this if you used the disposable test fixture, those instances are already configured. Deploying sensors to existing customer EC2 instances? Prep them with the included script in scan-then-fix mode.

IAM role

Auto-fix: Yes

Each instance needs AmazonSSMManagedInstanceCore attached to its instance profile. The prep script creates a CloudLens-SSM-Role and attaches it for you. If the instance already has an IAM role, the script adds the SSM policy to it instead of replacing.

SSM Agent

Auto-fix: Mostly

Pre-installed on Amazon Linux, Ubuntu 16.04+, Windows Server 2016+. Must be installed manually on RHEL/CentOS, commands below.

Tags

Auto-fix: Yes

The script auto-detects each instance OS and applies cloudlens=yes plus the correct os tag (ubuntu, rhel, or windows).

Step 1 - Scan your environment first

Run scan-only mode to see what is missing before changing anything:

./scripts/deploy.sh --region us-east-1 --profile customer --scan-only

Step 2 - Auto-fix every issue

Once you have reviewed the scan, run with --auto-fix to remediate every gap in one shot:

./scripts/deploy.sh --region us-east-1 --profile customer --auto-fix

Omit --auto-fix for interactive mode, the script prompts before each change.

Step 3 - Manual SSM Agent install (when Instance Connect is not available)

Ubuntu / Debian

sudo snap install amazon-ssm-agent --classic
sudo systemctl enable snap.amazon-ssm-agent.amazon-ssm-agent.service
sudo systemctl start snap.amazon-ssm-agent.amazon-ssm-agent.service

RHEL / CentOS

sudo dnf install -y \
  https://s3.amazonaws.com/ec2-downloads-windows/SSMAgent/latest/linux_amd64/amazon-ssm-agent.rpm
sudo systemctl enable amazon-ssm-agent
sudo systemctl start amazon-ssm-agent

Windows (PowerShell admin)

# SSM Agent is pre-installed on Windows Server 2016+
# If it is not responding, restart it:
Restart-Service AmazonSSMAgent
After installing SSM Agent, wait 30 to 60 seconds for it to register with AWS Systems Manager. Verify with: aws ssm describe-instance-information --region us-east-1

Sensor deployment via Ansible

Push CloudLens sensors to every tagged EC2 instance at fleet scale over SSH, SSM, or WinRM, with outbound HTTPS from each instance back to vController.

Tag targets first

Apply the marker tag cloudlens = yes and an os tag to every target instance. Without these the deployment skips the host.

OSTag os
Ubuntu / Debianubuntu
RHEL / CentOS / Amazon Linuxrhel
Windows Server 2016+windows

IAM role on every target

Each instance needs the managed policy AmazonSSMManagedInstanceCore attached to its instance profile for the SSM connection path. The included prep step can attach this for you and verify the SSM Agent is running.

SSM Agent reachability

Each instance must reach ssm.<region>.amazonaws.com, ec2messages.<region>.amazonaws.com, and ssmmessages.<region>.amazonaws.com on 443 outbound, or have a VPC endpoint to those services.

Run the deployment

# Deploy to ALL tagged targets in the region
bash quickstart.sh

# Or run the playbook directly with your customer_input.yaml
ansible-playbook deploy.yaml -e @customer_input.yaml

The playbook invokes the CloudLens sensor installer on every matching instance in parallel, Docker or Podman on Linux, MSI on Windows. Sensors register with vController on first start.

Verify in vController and mirroring

KVO natively manages AWS VPC Traffic Mirroring. It auto-deploys collector Service VMs, creates mirror filters, targets, and sessions, and auto-scales by tapped-interface count.

1. IAM ready out of the box

CloudFormation and Terraform provision an IAM user with the CloudLens mirroring policy, scoped with the cloudlens:monitored:vpcid condition tag. Includes EC2, Traffic Mirror, Auto Scaling, and Launch Template permissions.

2. Auto-mirror on new instances

Optional Lambda plus EventBridge rules fire on RunInstances, CreateTags, and instance state changes. New EC2 instances in watched VPCs are tagged for mirroring, and KVO starts mirroring instantly, no polling.

3. Confirm sensor registration

In vController, open Sensors. Each tagged instance should appear as connected and reporting, with your custom tags visible. This is the fastest end-to-end confirmation the pipeline is healthy.

4. Monitoring policies

In KVO: Cloud Fabric, Monitoring Policies, New. Pick the source (tag-based), the tool (vPB plus downstream analytics), and KVO deploys collector Service VMs, configures the mirror sessions, and routes packets.

Teardown

Clean removal of sensors and infrastructure. Always run in this order, sensors first, infrastructure second.

Step 1 - Remove sensors

# Remove sensors from all tagged targets
bash cleanup.yaml

# Or via the playbook
ansible-playbook cleanup.yaml -e @customer_input.yaml

Step 2 - Destroy infrastructure

Terraform path:

cd deploy/terraform
terraform destroy

CloudFormation path:

aws cloudformation delete-stack \
  --stack-name cloudlens-stack \
  --region us-east-1

aws cloudformation wait stack-delete-complete \
  --stack-name cloudlens-stack \
  --region us-east-1

Appendix - reference

Default credentials, network topology, and Marketplace AMIs. Keep this open in a tab during deployment.

Default credentials

ProductUsernamePassword
KVOadminadmin
vControlleradminCl0udLens@dm!n
vPB SSH (port 9022)ec2-userkey pair

Change these on first login. Default passwords are not for production.

Network topology

SubnetCIDRPurpose
Management10.0.1.0/24SSH, HTTPS, REST API
Data10.0.2.0/24Sensor traffic (mirror / VXLAN)
Tool10.0.3.0/24Processed traffic to tools

CIDRs are configurable in the CloudFormation parameters.

Marketplace AMIs and instance types

ProductInstance
vController (CLMS_6.12.x)t3.xlarge
KVO (2.13.x)c5.2xlarge only
vPB-KVO (3.13.x)t3.xlarge

KVO has an AWS Marketplace instance-type restriction and cannot be changed.

Common issues

If something does not work, check these first.

I don't have vController (formerly CLMS) yet. Where do I start?

Use the Launch vController button at the top of this page, or launch the full stack with the Launch CloudLens Stack button above. vController comes from AWS Marketplace, deploys in about 15 minutes, and is ready before you start tagging your instances. While you are there, also deploy KVO if you want centralized fleet orchestration across multiple vPB instances.

vPB just deployed. Why can't I SSH yet?

The vPB image uses port 9022 for SSH, NOT the default port 22. Keysight CloudLens OS (KCOS) binds sshd only to 9022 on the public interface. Connections to :22 time out forever even after the instance is fully booted.

What to do: wait 10 to 15 minutes after deploy succeeds for KCOS to initialize, then:

ssh -p 9022 admin@<vpb-public-ip>   # OS shell
sudo vpb                                # vPB CLI

Security group rule: make sure the security group on the vPB management ENI allows inbound TCP on port 9022. The stack template opens this automatically; if you deployed via a custom path, add the rule manually.

Same vController note: the web UI on port 443 is usually ready within 60 seconds, but full system initialization (registry and project creation) takes around 15 minutes.

Inventory finds 0 instances

Cause: tags missing or misspelled.

Fix: verify with aws ec2 describe-tags --filters "Name=resource-id,Values=i-0123...". The cloudlens, os, and env tags must all be present.

SSH Permission denied

Cause: your key pair is not on the target instance, or the wrong SSH user.

Fix: use ubuntu for Ubuntu and ec2-user for RHEL/Amazon Linux, and confirm ssh_key_path in customer_input.yaml points at the right .pem. For no-key targets, use the SSM connection path instead.

WinRM or SSM timeout on Windows instances

Cause: for the SSM path, the SSM Agent is not registered or the instance lacks the SSM IAM role; for the WinRM path, ports 5985/5986 are closed.

Fix: prefer windows_connection: "ssm", attach AmazonSSMManagedInstanceCore, and confirm the instance appears in aws ssm describe-instance-information.

Sensor does not appear in vController

Cause: wrong project key, or sensor cannot reach vController on the network.

Fix: double-check the project key from the vController UI. Verify the instance can reach vController on port 443.

How long should this take?

1 to 50 instances: 5 to 10 minutes.

50 to 500 instances: 15 to 30 minutes.

500 to 2000 instances: 30 to 60 minutes.

Thousands: sharded automatically, 30 to 60 minutes for up to 10K.

What if I need help?

Open an issue on GitHub, or contact your Keysight account team for direct engineering support.

Docs and support

Everything you need to deploy with confidence.

Operations guide NEW

Every port, password, SSH gotcha, KVO adoption step, and security group rule. Read this before filing a support ticket.

Full README

Scenarios, architecture, scaling, and troubleshooting on GitHub.

PDF runbook

Printable customer-ready guide with screenshots and checklists.

Customer email template

Copy-paste handoff message for your account team.

GitHub Issues

Bug reports and feature requests, handled by Keysight engineering.