If you choose to deploy more than one vSensor, they are deployed across multiple Availability Zones for high-availability. For more information, see Regions and Availability Zones.

This guide is for database administrators, enterprise architects, system administrators, and developers who want to run Darktrace vSensor probes in a highly-available Amazon Elastic Compute Cloud (Amazon EC2) environment.

The Quick Start now uses AWS Systems Manager Parameter Store to hold the configuration and secrets for Darktrace vSensor. This is due to EC2 instance user data being unencrypted.

Create separate "Secure String" SSM Parameters in the expected AWS region for each of the following:

You will provide the parameter names to the CloudFormation template, for the vSensor to automatically decrypt these values on start up.

Using SSM parameters provides the benefit that configurations can be more easily cycled out using the Auto Scaling Group Instance Refresh features, without having to redeploy the Quick Start template.

Register a new push token to enable connection between vSensor probes and an existing Darktrace on-premise or cloud instance. All of the vSensor instances in this deployment share the same push token.

If your Darktrace Instance is behind a firewall, you must grant access to the instance from the IP addresses of your NAT Gateways after deployment. For more information, see Post deployment steps, later in this guide.

It is important you must understand the different traffic mirroring options available before deploying.

A new option CrossZoneLBEnable has been provided to reduce bandwidth costs for traffic ingestion.

If "No" is set (the default), the load balancer will only send mirrored traffic to vSensors in the same Availability Zone as the mirror source. The same is true for osSensor traffic.

This option reduces costs by preventing mirror traffic from crossing zones, which can be substantial in large bandwidth environments.

If "Yes" is set, it is possible to reduce the vSensor count as low as 1 without loss of traffic mirroring, this may be suited to small traffic environments.

If your Darktrace instance is behind a firewall, you must grant access to the instance from the IP addresses of your NAT gateways. For a new VPC deployment, use the NatGatewayEIPs on the Outputs tab of the stack in the AWS CloudFormation console. For an existing VPC deployment, use the IP addresses of the existing NAT gateways.

To add your existing EC2 instances to be mirrored and monitored, configure a traffic mirror session. For more information, see Traffic mirror sessions. When doing this, use the traffic mirror target and filter IDs on the Outputs tab of the stack in the AWS CloudFormation console. You can automate the process of adding your existing EC2 instances to this deployment. For more information, contact your Darktrace representative for scripts and guidance to do this.

VPC Traffic Mirroring is only supported on AWS Nitro-based EC2 instance types and some non-Nitro instance types. For more information, see Amazon VPC Traffic Mirroring is now supported on select non-Nitro instance types.

To monitor EC2 instance types that do not support VPC Traffic Mirroring, configure them with Darktrace osSensors. When doing this, use the DNS name of the Network Load Balancer on the Outputs tab of the stack in the CloudFormation console. For more information about configuring osSensors, visit the Darktrace Customer Portal.

After deployment, verify that all vSensors are listed in the Probes section of the System Config screen in the Darktrace Threat Visualizer. After adding the Traffic Mirror Sessions of EC2 instances that you wish to monitor, or configured osSensors to communicate with the vSensors, verify that they display in the Threat Visualizer.

This deployment follows AWS security best practices for network security. The vSensor instances are deployed in private subnets. They are only accessible from the internet using SSH to connect to bastion hosts in the private subnets. For existing VPC deployments, it is important that security groups only allow SSH access from trusted sources. It is not recommended to allow direct SSH access to vSensors from the internet. For more information, see Best Practices for Security, Identity, & Compliance.

To gain root access to vSensor instances, use the ubuntu user name and the EC2 key pair parameter you entered during deployment as the private key path. Then sudo to root. The EC2 key pair is also required to access ec2-user of the bastion hosts. For more information, see Connect to your Linux instance using SSH.

The bastion hosts deployed by this Quick Start are set to update automatically. The deployed vSensors are configured to receive the latest security and product updates daily from Darktrace and Ubuntu package repositories.

When connecting via the AWS Systems Manager Session Manager it is recommended to use the session/preferences document created by the template.

This will make sure that the session is encrypted and logged (in the same CloudWatch Log group as the vSensors logs). That is the same kms key that is used for encrypting log data in CloudWatch Logs.

For the Systems Manager Session Manager allowed users you can Enforce a session document permission check for the AWS CLI. The name of the session/preferences document is in the Outputs.

Example: aws ssm start-session --target <instance_id> --document-name <session_manager_preferences_name>.

In the Sessions Manager web console, each user must set their Session Manager Preferences to use the KMS Key ID and Log Group if encrypted sessions and logging are required.

In scenarios of invalid configuration parameters, upstream internet access blocked and other cases of the EC2 images failing to install and configure Darktrace vSensor, the ASG will fail to deploy.

Viewing the Auto Scaling Group "Instance Management" page via the CloudFormation resources page will show terminating or no instances in this situation.

In most situations, logging will be available from the vSensor start up in CloudWatch. View "Log Groups", find the group named [SHORTID]-vSensor-Logs and look for Log Streams ending in -userdata.

If the configuration provided by SSM Parameters is seen as invalid in these logs, edit the SSM parameters to rectify the problem. Then perform a "instance refresh" on the ASG to attempt again with the new configuration options.

If no userdata logging is provided, you may need to connect directly to the vSensor via SSH or AWS Systems Manager and retrieve /var/log/userdata.log directly. "Detach" the vSensor from the ASG to prevent it terminating during this procedure.

For situations where the error is not clear, contact Darktrace Customer Support via the Darktrace Customer Portal, provide CloudFormation stack errors and one of the above userdata logs if available.