Fusion Onboarding for Cloud Engineers

A guide to Vectra Fusion for cloud engineers who have been asked by the security team to assist with onboarding.

Quick introduction to Vectra AI and Fusion

This guide helps cloud engineers answer these questions:

1. Who is Vectra AI?

2. What is Vectra Fusion?

3. Why is the cloud team involved?

4. What are the deployment options and details for my cloud(s)?

TL;DR: You will need to configure logging and permissions in the cloud, and then onboard those sources to Fusion

1. You configure in-scope logs to be written to a compatible logging destination (typically S3 in AWS, storage blobs in Azure, Pub/Sub topics in GCP, and object storage in OCI) and provide Fusion with the permission to read those logs.

2. You configure context enrichment by either providing cross-account permission for Fusion to read resource metadata from your cloud or by deploying a cloud function that reads resource metadata from within your cloud and then pushes it to the Fusion API.

3. You onboard log sources to Fusion by creating traffic source(s) in Fusion using the Fusion portal, API, or CLI. You onboard context enrichment to Fusion by creating context integration(s) in Fusion using the Fusion portal, API, or CLI, OR by deploying a cloud function that uses a Fusion API key.

4. Vectra provides Terraform-based cloud onboarding automation for AWS, Azure, and GCP that can handle onboarding to Fusion and context enrichment for you. It can also manage flow log and DNS log configuration according to a policy you define, if you want it to. Vectra also provides guides for manual configuration and onboarding, and examples for integrating with your IaC.

Who is Vectra AI?

Vectra AI | Cybersecurity AI That Stops Attacks Others Can’twww.vectra.ai

Security teams use Vectra AI for detecting and responding to threats.

Vectra helps security teams understand attacker behavior across network, identity, cloud, and SaaS environments. It is not a firewall, a CSPM, SIEM, or a general-purpose logging platform — it is a detection and response layer that uses telemetry from multiple environments to surface meaningful attacker signals and support analyst investigation workflows.

When cloud teams get involved

• A request from the security team to connect cloud logs to an external platform

• A need for IAM role approval, logging configuration, log routing, or IaC deployment

• A conversation about scope, permissions, cost, and governance

What is Vectra Fusion?

Vectra Fusion is used to collect and process cloud logs, including VPC flow logs, DNS resolver logs, and cloud context metadata. That data can then be used for search, analytics, dashboards, retention, and alerting.

Fusion is closest to a managed network log ingestion and analytics layer. It is not a replacement for your cloud logging platform, data lake, Terraform pipeline, or cloud governance process. It fits alongside tools and patterns your team already knows.

Fusion is a SaaS; there is no backend or sensor deployment to the cloud involved.

Familiar tool / concept	How Fusion relates
Cloud logging (CloudWatch, Azure Monitor, Cloud Logging, OCI Logging)	Fusion consumes selected logs and metadata for security use cases
SIEM	Fusion can complement downstream security workflows and alerts; some organizations decide to stop sending high-volume network metadata log sources directly to these sinks and have Vectra send prioritized events at low volume instead
Terraform / CloudFormation / IAC	Deployment should happen through customer-controlled IaC or approved cloud-native methods; for a POC or small environments this could be done with manual configuration
IAM / RBAC	Permissions are reviewed, scoped, and approved by the cloud team
VPC / VNet flow logs	Fusion uses flow logs for providing network observability and detection without the need to use traffic mirroring, packet brokers, or agents
DNS logs	Fusion can use cloud DNS resolver logs as context for traffic and investigation
Dashboards / observability tools	Fusion can also be used as its own standalone search and analytics platform for ingested telemetry

What is cloud context?

Context is resource metadata from the cloud provider that is combined with flow logs in Fusion. In addition to ingesting flow logs and DNS logs, Vectra Fusion enriches the logs with context from the cloud environment. For example, in AWS, a flow log may tell you that IP 1.2.3.4 in VPC vpc-01234567 is the source IP. Describing the resources in that AWS account can determine that this IP belongs to an EC2 instance, along with a name and other attributes that provide valuable context about that traffic.

Two deployment options for context enrichment

Option 1: Cross-account access

You provide read-only permission for Vectra Fusion to read asset metadata from your cloud.

This is accomplished with a cross-account IAM role in AWS, an Entra ID app in Azure, and a service account in GCP and OCI.

Option 2: Cloud-deployed function

You deploy a cloud function that reads asset metadata from your cloud and then uses a Vectra Fusion API key to upload this context to Vectra Fusion.

This is accomplished with a Lambda function in AWS, an Azure Function in Azure, and a Cloud Function in GCP. These can be deployed as part of Vectra Fusion cloud onboarding automation or through your own IaC. The source code for these functions is provided in the automation repo.

Why your team is involved

The security team needs the data, but cloud teams usually own the path to it.

Security teams often need visibility into cloud traffic, DNS activity, and cloud context. But they typically do not own the infrastructure required to enable, route, scope, or govern that telemetry. That is why the cloud team is part of this conversation — because the logging path runs through infrastructure you own and operate.

The goal is not to bypass cloud governance. The goal is to help the SOC get useful telemetry through a deployment model the cloud team can approve and operate. Every permission, scope decision, and deployment method is subject to your team's approval and action.

Key ownership areas

• IAM / RBAC Your team reviews and approves all IAM roles, trust relationships, RBAC assignments, and custom role definitions before deployment proceeds.

• IaC pipelines All infrastructure changes occur through your existing IaC and cloud configuration pipelines. If you use Vectra's Terraform-based cloud onboarding automation, you can optionally let it make logging configuration changes through a deployed cloud function according to a policy.

• Log routing Your team controls where logs land, how they are routed, what gets sent, and what retention and cost guardrails apply at every stage.

• Scope decisions Which accounts, regions, VPCs, and supported log types are included is defined as part of the deployment. Vectra works within the boundary you define.

Activation journey

1

Which cloud(s)?

AWS, Azure, GCP, OCI, IBM

2

Define initial scope

• AWS: Org, OUs, Accounts, Regions, VPCs

• Azure: Tenant, Management Groups, Subscriptions, Regions, VNets

• GCP: Org, Folders, Projects, VNets, Subnets

• OCI: Tenancy, Compartments, VCNs

3

Data source types

• AWS: VPC flow logs, transit Gateway flow logs, Route 53 DNS logs, cloud context

• Azure: VNet flow logs, cloud context

• GCP: VPC flow logs, Cloud DNS logs, cloud context

• OCI: VCN flow logs, cloud context

4

Deployment method

• Cloud configuration: Vectra-provided automation, Customer-developed automation, Manual console/CLI steps

• Fusion configuration: Fusion console, Fusion API, Fusion CLI

5

Validate ingest

Confirm logs and context are being successfully ingested to Fusion.

6

Use in Vectra Fusion

Search, dashboards, alerting, investigations.

7

Tune scope

Add or modify scope (e.g. new OUs, accounts, VPCs, etc.).

Cloud-specific deployment guidance

Each cloud has its own logging model, IAM system, deployment tooling, and logging path. Select the tab for your environment(s).

AWS

AWS VPC flow logs, AWS Transit Gateway flow logs, AWS Route 53 DNS resolver logs, AWS cloud context

Deployment options

Option	Best for	Next steps
Manual onboarding	Organizations with a small number of VPCs that rarely change, or for an initial PoC.	AWS Cloud Onboarding AWS VPC via S3 Setup (AWS Console method) AWS VPC via S3 Setup (CloudFormation method) AWS Route 53 DNS Logs via S3 Setup (Console) AWS Context Integration Quickstart: AWS
Vectra onboarding automation	Organizations that want a complete, supported, end-to-end solution for managing flow log configuration and onboarding to Fusion.	Vectra Terraform / CloudFormation StackSet Cloud Onboarding Automation for AWS Organizations
Custom IaC automation	Organizations experienced with AWS IaC that already provision VPCs or flow log configurations through automation and want to extend that workflow to Fusion.	AWS Custom IAC Onboarding for Cloud Automation Engineers AWS VPC CloudFormation Stack Automation

Decisions to make

• What deployment method will be used?

• What OUs, accounts, and VPCs are in scope for the initial deployment?

• What log ingest method will be used?

  • S3 — recommended

  • Kinesis — alternative

• What cloud context enrichment model will be used?

  • Cross-account read-only IAM role

  • Lambda cloud function

• Is there a centralized logging account, or will one be designated for this purpose?

Azure

GCP

OCI

Success Criteria

A successful first onboarding is validated, and useful.

A good first onboarding is measured by whether the security team can do something useful with the data, whether the cloud team understands and can modify what was deployed, and whether the next tuning decision is clear. For larger organizations, start with a narrow, well-understood scope and validate, then expand.

• Cloud team understands what Vectra is and what Fusion does

• Deployment method is approved and executed through the IaC pipeline

• IAM and RBAC permissions are reviewed and scoped by the cloud team

• Initial scope is agreed to

• Flow logs, DNS logs, if applicable, and cloud context are flowing and confirmed in Vectra Fusion

• Log volume is understood

• Initial use case(s) are validated

• Next tuning/scoping decision is clear and owned

Working session planner

Build the activation plan together. Use this section as a lightweight planning tool during a working session between the security and cloud teams.

Field	Options / Notes
Primary cloud	AWS / Azure / GCP / OCI / Multi-cloud
Cloud team owner	Name and team responsible for deployment, IAM, and operational support
Security team owner	Name and team responsible for validation, use case, and ongoing analysis
Deployment method	Vectra onboarding automation, Custom IaC, Console/CLI
Initial scope	Org/OU/Account/VPC; Tenant/Management Group/VNet; Org/Folder/Project/VPC; Org/Compartment/VCN
Telemetry sources	Flow logs / DNS logs / Cloud context metadata
Initial use case	Security team cloud network observability

Generated activation summary format:

We will start with [cloud] for [initial use case]. The cloud team owner is [team]. The SOC owner is [team]. The initial deployment method is [method]. The first scope is [scope]. The telemetry sources are [sources]. Next step: [action].