Introduction and requirements
Prerequisites and sizing guidance for deploying Vectra AWS vSensors, including sizing, SRT setup, VPC/subnet planning, and security group requirements.
Introduction
This document describes the pre-requisites, specifications, and steps required to deploy a Vectra Sensor in an AWS account to monitor cloud Infrastructure-as-a-Service workloads. These Sensors can be paired to Vectra Brains of any type (physical, virtual, cloud) if the required connectivity is in place.
The input to an AWS Sensor can be Amazon VPC traffic mirroring set up on an Amazon elastic network interface or from a VXLAN-based 3rd party packet brokers.
AWS vSensors can be used in both Respond UX and Quadrant UX deployments. For more detail on Respond UX vs Quadrant UX please see Vectra Analyst User Experiences (Respond vs Quadrant). One of the below guides should be the starting point for your overall Vectra deployment:
For additional guidance for AWS IaaS deployments of Vectra, see the following:
Requirements and Preparation
Sensor Registration Token (SRT)
The Configuration → COVERAGE → Data Sources → Network → Sensors area of your Vectra UI allows you to pair and manage network Sensors, configure a number of options related to Sensor pairing and registration, and change the CLI vectra user password for paired devices (Sensors and Stream). Navigate in this area to Sensor Configuration > Sensor Pairing and Registration.
During Sensor deployment a valid Sensor registration token must be presented to the Brain so that the Sensor can become Available to Pair. This token can be created in the Vectra UI or at the CLI of the Brain. It is valid for 24 hours and can be regenerated at any time.
For full details on pairing processes, please see pairing appliances.
If you have a valid token, you can Copy it here for later use using the link.
Otherwise, click the Generate New Sensor Registration Token link.
Use this token for Sensor deployment (tokens expire 24 hours after generation).
Sensor Sizing
AWS Sensors are available in a variety of sizes:
r5.large / r5n.large – 1 Gbps
r5.xlarge / r5n.xlarge – 2 Gbps
r5.2xlarge / r5n.2xlarge – 4 Gbps
r5.4xlarge / r5n.4xlarge – 8 Gbps
c5n.18xlarge – up to ~10 Gbps (Contact your Vectra sales team for guidance)
The r5n instances guarantee networking performance and as a result it is recommended, but may not be available in all AWS regions. The r5 instances deliver the same performance without the guarantee. The c5n.18xlarge instance is a dedicated instance which also has the benefit of a 100 session traffic mirror destination limit vs the 10 session limit on the other instances. The c5n.18xlarge may not hit 10 Gbps in some scenarios as there are many factors to consider. Please engage your Vectra sales team for additional guidance for your specific network architecture.
Vectra periodically updates our AWS Marketplace listing to include additional instance choices. Please work with your Vectra account team for guidance on new options.
The Sensor instances can be deployed either stand alone, or with a Network Load Balancer (Vectra currently supports 1 Sensor per NLB). Currently, multiple Sensors cannot be deployed in a single Auto Scale Group.
SSH Key Pair
An SSH key pair will need to be created for the Sensor to allow an administrator to SSH to the CLI as the “vectra” user. The public key will be set in the CloudFormation template during deployment. Guidance for key pair generation is here: Amazon EC2 key pairs and Linux instances
After the Sensor is deployed, you can login to the Sensor CLI via SSH using the private key:
You may need to make the key readable to you using a command such as:
chmod 400 VectraSensorPrivateKey.pem
Example login command:
ssh -i <private key path> vectra@SensorHostnameOrIP
VPC and Subnets
You will either need to create a new VPC and Management / Traffic Subnets for use with the Sensor you are deploying or re-use an existing one. You will choose these when filling out the CloudFormation template. Some AWS documentation is available at the following links:
Security Groups
The CloudFormation template will create empty security groups, or you may select existing security groups to use.
mgtSecurityGroup - Used for the management interface of the Sensor.
This security group must allow inbound TCP/22 from the Brain and allow outbound TCP/443 and TCP/22 to the Brain for management.
trafficSecurityGroup - Used for the traffic capture interface of the Sensor.
In case of ingesting from a packet broker, ensure that VxLAN traffic is permitted inbound on UDP/4789.
If deploying a Network Load Balancer in front of the Sensor, inbound TCP/80 must also be permitted from the NLB for the health-check from the load balancer to succeed.
Last updated
Was this helpful?