> For the complete documentation index, see [llms.txt](https://docs.fusion.vectra.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.fusion.vectra.ai/cloud-onboarding/fusion-onboarding-for-cloud-engineers.md). # Fusion Onboarding for Cloud Engineers ## Quick introduction to Vectra AI and Fusion This guide helps cloud engineers answer these questions: 1. [Who is Vectra AI?](#who-is-vectra-ai) 2. [What is Vectra Fusion?](#what-is-fusion) 3. [Why is the cloud team involved?](#why-your-team-is-involved) 4. [What are the deployment options and details for my cloud(s)?](#cloud-specific-deployment-guidance) {% hint style="info" icon="forward" %} **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. {% endhint %} ## Who is Vectra AI? {% embed url="" %} 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 {% columns %} {% column %} #### 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. {% endcolumn %} {% column %} #### 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. {% endcolumn %} {% endcolumns %} ## 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 {% stepper %} {% step %} ## Which cloud(s)? AWS, Azure, GCP, OCI, IBM {% endstep %} {% step %} ## 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 {% endstep %} {% step %} ## 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 {% endstep %} {% step %} ## Deployment method * Cloud configuration: Vectra-provided automation, Customer-developed automation, Manual console/CLI steps * Fusion configuration: Fusion console, Fusion API, Fusion CLI {% endstep %} {% step %} ## Validate ingest Confirm logs and context are being successfully ingested to Fusion. {% endstep %} {% step %} ## Use in Vectra Fusion Search, dashboards, alerting, investigations. {% endstep %} {% step %} ## Tune scope Add or modify scope (e.g. new OUs, accounts, VPCs, etc.). {% endstep %} {% endstepper %} ## 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). {% tabs %} {% tab title="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](/cloud-onboarding/aws-cloud-onboarding/neto-onboarding-aws.md) | | 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? {% endtab %} {% tab title="Azure" %} **VNet flow logs, cloud context** #### Deployment options | Option | Best for | Next steps | | ---------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Manual onboarding | Organizations with a small number of VNets and subscriptions that rarely change, or for an initial PoC. |

Azure Cloud Onboarding

Azure Virtual network (VNet) Flow Log Setup

Azure Context Integration

Quickstart: Azure

| | Vectra onboarding automation | Organizations that want a complete, supported, end-to-end solution for managing flow log configuration and onboarding to Fusion. | [Vectra Terraform Cloud Onboarding for Azure Tenants](/cloud-onboarding/azure-cloud-onboarding/neto-onboarding-azure.md) | | Custom IaC automation | Organizations experienced with Azure IaC that already provision VNets or flow log configurations through automation and want to extend that workflow to Fusion. |

Azure Cloud Onboarding

| #### Decisions * What deployment method will be used? * Which tenant, management groups, subscriptions, and VNets are in scope? * Which subscription should host the Azure storage accounts that receive VNet flow logs? * Is Network Watcher enabled in the required subscriptions? * What cloud context enrichment model will be used? * Read-only Entra ID application * Azure Function {% endtab %} {% tab title="GCP" %} **VPC flow logs, Cloud DNS logs, cloud context** #### Deployment options | Option | Best for | Next steps | | ---------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Manual onboarding | Organizations with a small number of projects that rarely change, or for an initial PoC. |

GCP Cloud Onboarding

GCP VPC Flow Logs via Pub/Sub Setup

GCP Cloud DNS Logs via Pub/Sub Setup

GCP Context Integration

Quickstart: GCP

| | Vectra onboarding automation | Organizations that want a complete, supported, end-to-end solution for managing flow log configuration and onboarding to Fusion. | [Vectra Terraform Cloud Onboarding for GCP Organizations](/cloud-onboarding/gcp-cloud-onboarding/neto-onboarding-gcp.md) | | Custom IaC automation | Organizations experienced with GCP IaC that already provision VPCs, DNS logging, or related resources through automation and want to extend that workflow to Fusion. |

GCP Cloud Onboarding

| #### Decisions * What deployment method should be used? * Which organization, folders, projects, and VPCs are in scope? * What log sink architecture will be used? See [Aggregated sink design patterns](https://docs.fusion.vectra.ai/ingest-network-traffic-logs/flow-logs/gcp-flow-logs-via-pubsub#id-3-create-a-cloud-logging-sink-pubsub). {% endtab %} {% tab title="OCI" %} **VCN flow logs, cloud context** #### Deployment options | Option | Best for | Next steps | | --------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Manual onboarding | Organizations with a small number of VCNs that rarely change, or for an initial PoC. |

OCI Cloud Onboarding
Oracle Cloud VCN Flow Logs via Cloud Object Storage Setup

OCI Context Integration

| | Custom IaC automation | Organizations experienced with OCI IaC that already provision resources or log configurations through automation and want to extend that workflow to Fusion. | [OCI Cloud Onboarding](/cloud-onboarding/oci-cloud-onboarding.md) | #### Decisions * What deployment method should be used? * Which tenancy, compartments, and VCNs are in scope? {% endtab %} {% endtabs %} ## 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]. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.fusion.vectra.ai/cloud-onboarding/fusion-onboarding-for-cloud-engineers.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.