> 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/aws-cloud-onboarding/neto-onboarding-aws.md).
# Vectra Terraform / CloudFormation StackSet Cloud Onboarding Automation for AWS Organizations
{% hint style="info" %}
This page is a mirror from the private Github repo for Vectra Fusion's cloud onboarding automation. For direct access to this github repo or a release package of it, reach out to your Vectra contact.
{% endhint %}
## Overview
The automation can perform these functions for onboarding AWS (you may choose to use all or a subset of these):
1. Deploy all the infrastructure required to integrate to Fusion across multiple accounts and regions in an AWS organization.
2. Enable and configure VPC flow logging to S3 based on a policy and tags that defines which VPC are in scope.
3. Add VPCs configured for flow logging to Vectra Fusion as traffic sources.
4. Push AWS context labels to Vectra Fusion for context enrichment.
5. Monitor for VPC changes and trigger enabling, configuring, and onboarding to Fusion new VPCs that are in scope.
## Architecture Diagram
## Deployment Components
### Terraform deployment
* `aws/terraform/deployments/neto-onboard-aws-full` - terraform to deploy the modules below; all configuration is set here
* `aws/terraform/deployments/vectra-onboard-aws-cfn` - Vectra CloudFormation-oriented deployment path that can be run with Terraform or launched manually in the AWS console from hosted template URLs
### Terraform modules
* `aws/terraform/modules/hub_orchestration_account` - deploys the Lambda function and EventBridge event bus to automatically enable flow logs, add the flow source to Vectra Fusion, and send AWS resource context to Fusion for context enrichment.
* `aws/terraform/modules/centralized_org_logging_account` - create an s3 bucket per AWS region in this account to store logs. Using a separate bucket per region reduces cost.
* `aws/terraform/modules/management_account` - applies the CloudFormation StackSet to the management account for the AWS organization, which then deploys the necessary permissions and events in each child account in the organization.
### CloudFormation Templates
* `aws/cloudformation` - CloudFormation templates used by AWS onboarding deployments, including the versioned StackSet templates used by the full Terraform deployment.
* `aws/cloudformation/cfn_only` - CloudFormation templates used by the CloudFormation-only deployment.
### AWS Lambda Function
* `NetoFlowLogActivator` - the Lambda function discovers changes in VPCs, enables (or disables) flow logs, enables (or disables) Route53 dns logs, adds (or removes) flow sources to Vectra Fusion, and if `context_enrichment` is enabled, discovers resources associated with IP addresses and sends context to Fusion. It is triggered by EventBridge upon a VPC change, runs on a schedule, and/or is manually triggered.
### Terraform Deployment and Modules README
* `terraform/deployments/neto-onboard-aws-full/README.md`
* `terraform/deployments/vectra-onboard-aws-cfn/README.md`
* `terraform/modules/hub_orchestration_account/README.md`
* `terraform/modules/centralized_org_logging_account/README.md`
* `terraform/modules/management_account/README.md`
## Prerequisites
To simplify checking and configuring prerequisites, a set of scripts are provided in the `scripts/` directory that wrap the `aws` CLI.
See `scripts/README.md` for more details on the scripts. It assumes you have `aws` installed and configured with a profile that has the necessary permissions to run the script actions.
### 1. Account administrator access on the AWS organization management account
Required to deploy the CloudFormation StackSet.
### 2. AWS Organization has `all features` enabled
AWS Organizations with only consolidated billing features can not be used (see ).
### 3. AWS Accounts designated as the orchestration hub account and centralized logging account
You need to create or identify the AWS accounts in your organization that you want to use for the orchestration hub (where the Lambda function is created) and the centralized logging (where the S3 buckets for each region are created that flow logs are written to).
You can use the same account for orchestration and logging if you prefer.
### 4. AWS Regions enabled
The default settings apply to all commercially available regions (both standard and opt-in regions) (excluding `cn` and `gov` partitions). This can be modified in the tfvars `logging_regions` variable. See the *AWS Regions* section below for more details.
The logging account and hub orchestration account must have:
1. Every opt-in region set in `logging_regions` enabled. You must manually enable the opt-in regions in the account.
2. STS active in every region. STS is active by default in all regions, but can be manually disabled in standard regions (opt-in regions will always have STS active and can not be disabled). If it has been manually disabled by any standard regions, you must re-enable it.
### 5. Service control policy (SCP) permits automation deployment and orchestration
If you have a service control policy applied to your AWS organization, it could restrict the permissions of the automation to create the resources it needs to work, even if you are an account administrator. This could require updating the service control policy to give the automation the permissions required. See the **AWS Roles** section below for more details.
### 6. Vectra Fusion API Key (`netosecret`)
You will need to create a Vectra Fusion API key. See: [API Keys](/settings/user-management/index.md#user-management---api-keys)
This value is set in `terraform.tfvars` (or via an environment variable) and terraform will store it in AWS SSM as the `netosecret` parameter in the orchestration account.
Store and export it in your environment for using later in the deployment:
```sh
export NETOSECRET=your-api-key
```
On a Mac, you can copy it from your clipboard directly by running:
```sh
export NETOSECRET=$(pbpaste)
```
### 7. Vectra Fusion CLI tool
It is helpful to use the neto CLI tool as part of deploying to validate its operation. This package is in the repo `/neto/` directory.
See `../neto/README.md` for more details.
To install this into a Python virtual environment (recommended - this will ensure you don't have any conflicts, and allows you to run `neto` wheneveer you have activated this environment):
From the root of repo directory `neto-onboarding/`, run:
```sh
python3 -m venv venv
source venv/bin/activate
cd neto
pip install .
neto --version
neto -h
```
To exit the virtual environment, run `deactivate`.
To enter the virtual environment again, from repo root `neto-onboarding` run `source venv/bin/activate`.
### 8. Basic terraform knowledge
This automation has been built for engineers with basic familiarity using terraform.
## AWS Regions
The automation can detect, enable, and onboard VPC flow logs in all available commercially available regions (excluding `cn` and `gov` partitions). Regions to include are defined in the `logging_regions` variable in your `terraform.tfvars` file. Ensure that all opt-in regions included in `logging_regions` are enabled in your logging account.
If you remove regions from the `logging_regions` variable, you may wish to ensure you have another control in place that restricts the ability to enable new regions or VPCs in new regions (i.e. a service control policy is in place with region restrictions) in order to prevent a coverage gap.
#### Removing a region from automation
If you do not want to monitor all default regions, you can select a subset of regions to deploy to by modifying `logging_regions` in your tfvars.
#### Adding a new region to automation
As AWS adds new regions, Vectra will add them to the automation. When this occurs, follow these steps:
1. Enable the new region in the logging account.
2. Update to the latest `neto-onboarding` version that includes the new region.
3. Add the new region to the `logging_regions` variable in your tfvars (if you are not using the default value).
4. Re-deploy the automation.
If you ever need to manually add a region, follow these steps:
1. In `aws/terraform/modules/centralized_org_logging_account/main.tf`, add a module block for the new region, following the pattern of the existing regions.
2. In `aws/terraform/modules/centralized_org_logging_account/provider.tf`, add a provider block for the new region, following the pattern of the existing regions.
3. Add the new region to `logging_regions` in your tfvars.
4. Re-deploy the automation.
#### DNS Query Logging Regions
If the `ingest_dns` terraform variable is enabled, the automation will enable DNS query logging in the same regions as flow logs are enabled. However, some regions in AWS do not support query logging (ususally the newest regions). To exclude these regions, use the `dns_exclude_regions` variable in your tfvars file. The default should be sufficient for most cases.
## Configuring the scope of OUs and Accounts to onboard
### Scope Policy
The scope policy determines whether an account is in-scope for orchestration. The scope policy is defined in JSON, containing a list of rules. To make every account in your AWS organization in scope, add the Root OU to the scope policy. Example scope policies are provided in the `aws/terraform/deployments/neto-onboard-aws-full` directory. Copy one of these to `scope-policy.json` and edit it to define the OUs and accounts in scope for your deployment.
Each rule has a **type** (`OU` or `Account`), **action** (`include` or `exclude`), and **members** (list of IDs).
```json
{
"comment": "Sample AWS scope policy.",
"tip": "Run 'neto policy validate --file scope-policy.json' to validate the policy after changing it.",
"policy": [
{
"comment": "Rule to include all accounts that are descendants of an OU in members list. Use the Root OU to include all accounts",
"format-help": "Use the OU ID",
"type": "OU",
"action": "include",
"members": [
"ou-zzzz-abcdefg123",
"ou-zzzz-hijklmn456"
],
},
{
"comment": "Rule to include specific accounts.",
"format-help": "Use the ID of the account",
"type": "account",
"action": "include",
"members": [
"999999999999",
"999999999999",
],
}
]
}
```
Policy rules are always inherited, with the most closely scoped rule to the account having precedence (eg account rules take precedence over a rule for its parent OU which takes precedence over a rule for the root OU.)
### Configuring VPC and Subnet Scope
Within an account rule, you can use **subpolicies** to control which VPCs and subnets are in scope, and to override configuration at the VPC or subnet level. Subpolicy rules are evaluated against VPCs and subnets discovered in each in-scope account.
Each subpolicy rule has a **type** (`vpc` or `subnet`), **members** (list of VPC or subnet IDs), and a **config** block. Subnet rules also require a **vpc** field to specify which VPC the subnet belongs to, and can optionally include a **regions** field to restrict the rule to specific regions.
#### Excluding a VPC
To exclude a specific VPC from onboarding, add a subpolicy rule with `"enable": false` in the config:
```json
{
"type": "account",
"action": "include",
"members": ["123456789012"],
"subpolicy": [
{
"type": "vpc",
"members": ["vpc-0abc123def456"],
"config": {
"enable": false
}
}
]
}
```
#### Setting flow sampling per VPC
To set a specific flow sampling rate for a VPC:
```json
{
"type": "account",
"action": "include",
"members": ["123456789012"],
"config": {
"flowSampling": 0.1
},
"subpolicy": [
{
"type": "vpc",
"members": ["vpc-0abc123def456"],
"config": {
"flowSampling": 0.5
}
}
]
}
```
#### Subnet-level configuration
Subnet rules require a **vpc** field and can optionally restrict to specific **regions**:
```json
{
"type": "account",
"action": "include",
"members": ["123456789012"],
"subpolicy": [
{
"comment": "Override sampling for a specific subnet",
"type": "subnet",
"vpc": ["vpc-0abc123def456"],
"members": ["subnet-0aaa111bbb222"],
"config": {
"flowSampling": 0.3
}
},
{
"comment": "Only applies to subnets in us-east-1",
"type": "subnet",
"vpc": ["vpc-0abc123def456"],
"members": ["subnet-0aaa111bbb222"],
"regions": ["us-east-1"],
"config": {
"flowSampling": 0.4
}
}
]
}
```
Subpolicy rules are evaluated in order. The first matching rule wins. If no subpolicy matches, the account-level config applies.
## Deploying the full automation
{% stepper %}
{% step %}
## 1. Apply `neto-onboard-aws-full` Terraform Project
* This terraform project is targeted towards your organization's management, orchestration, and centralized logging accounts
* From the root directory of this repository: `cd aws/terraform/deployments/neto-onboard-aws-full`
* Change the `backend.tf` file to the backend your organization uses
* `cp terraform.tfvars.template terraform.tfvars` and define the variables in the file.
* `cp scope-policy.json.example scope-policy.json` and define the OUs and accounts in scope for your deployment.
* `terraform init`
* `terraform apply`
{% endstep %}
{% step %}
## 2. Onboarding existing VPCs
* Trigger the `FlowLogActivator` Lambda (it will be named `ACCOUNTID--NetoFlowLogActivator` to execute in the hub orchestration account to evaluate all VPCs in all configured regions in all child accounts in the organization (or in the targeted OUs if you specified a list of OUs during deployment) and to enable, configure, and on-board VPC flow logs for all in scope VPCs.
You can either use `scripts/run` or the AWS console to trigger the function and view the logs.
Simple all in one onboarding:
```sh
scripts/run all
```
Step by step onboarding:
```sh
# Start log tail (run this in separate terminal to keep logs visible)
scripts/tail -c &
# Initial onboarding of accounts
scripts/run onboard
read -p "Press enter to continue once function execution completes"
# Get logs and review after execution completes
scripts/log -n 15 -c
read -p "Press enter to continue to next step once you have reviewed the logs"
# Initial orchestration of flow logs
scripts/run orchestrate
read -p "Press enter to continue once function execution completes"
# Get logs and review after execution completes
scripts/log -n 15 -c
```
```sh
Usage: ./run [options] [aws options]
Triggers the AWS Lambda function to run
Commands:
all Run full flow log activator (onboarding, orchestration, offboarding) and context enrichment function
onboard (or 1) Onboarding step 1: Create EventBridge rules in each region in in-scope accounts
orchestrate (or 2) Flow log orchestration for onboarded accounts
context (or 3) Context enrichment for onboarded accounts
offboard (or 4) Offboarding of out of scope accounts (disable flow logs, remove EventBridge rules)
destroy Destroy all resources created by function (complete offboarding before a terraform destroy)
show Show the current AWS account, region, function name, and log group
Options:
-a Target a single account for the function run (default: all in-scope accounts)
-s Synchronous execution (default: asynchronous)
-v Verbose output
-h, --help Show this help message
-- [aws options] Additional options to pass to the AWS CLI
Ensure that your AWS CLI is configured with the correct profile and region where the Lambda function is deployed.
```
From AWS Console:
* From your AWS hub orchestration account, go to the Functions page of the AWS Lambda console (), choose the `FlowLogActivator` function, Test`tab, under`Test event`select`Create new event\`, and use the following event JSON:
```json
{
"detail-type": "Scheduled Event"
}
```
* View the logs by going to CloudWatch Logs and selecting the log group that ends in `-FlowLogActivator`.
#### Live tail the function logs
Start a live tail of the function logs before triggering the function, by opening a new terminal and running `scripts/tail`.
```sh
Usage: ./tail [options] -- [AWS options]
View logs related to AWS Lambda functions.
Options:
-i Use AWS interactive mode for live log tail
-f Pretty text format for logs (default)
-t Unparsed text format for logs
-j JSON format for logs
-c Enable color output for logs (only applies with -f)
-k KEYWORDS Highlight specified keywords in color (implies -f and -c)
-e Show only ERROR logs
-w Show WARNING and ERROR logs
-p Print function name, log group, and other AWS details
-v Enable verbose output
-h Show this help message
-- [AWS options] Additional options to pass to the AWS CLI
Environment Variables:
NETO_FORMAT Output format (default: pretty). Valid values: pretty, json, text.
NETO_COLOR Set to True to enable color output for logs by default.
NETO_THEME Color theme for parsed logs (default: basic). Use python3 --list-themes to view themes.
NETO_KEYWORD Additional keywords to highlight in parsed logs (adds to -k).
Tips:
- Ensure your AWS CLI is configured with the correct profile and region where the Lambda function is deployed.
```
#### Review logs after function executes
You can get the logs from command line using `scripts/log` or using CloudWatch Logs in the AWS Console.
```sh
Usage: ./log [options] -- [AWS options]
View logs from AWS Lambda functions.
Options:
-n MINUTES Shortcut for --after MINUTESm --before 0m
--after DURATION Start offset from now (e.g. 2h15m means "from 2h15m ago")
--before DURATION End offset from now (e.g. 30m means "until 30m ago", default: 0m)
-o OUTPUT_FILE Specify output file name (default: neto-aws-TIMESTAMP.log)
-s Save logs but do not view output (default: save and view output)
-f Pretty text format for logs (default)
-t Unparsed text format for logs
-j JSON format for logs
-c Enable color output for logs (only applies with -f)
-k KEYWORDS Highlight specified keywords in color (implies -f and -c)
-e Show only ERROR logs
-w Show WARNING and ERROR logs
-v Enable verbose output
-h Show this help message
-- [AWS options] Additional options to pass to the AWS CLI
Environment Variables:
NETO_FORMAT Output format (default: pretty). Valid values: pretty, json, text.
NETO_COLOR Set to True to enable color output for logs by default.
NETO_THEME Color theme for parsed logs (default: basic). Use python3 --list-themes to view themes.
NETO_KEYWORD Additional keywords to highlight in parsed logs (adds to -k).
NETO_CLI_PAGER Pager for output (default: code if available, else less). Use cat to disable paging.
Tips:
- To remove color from logs generated with -c, use:
awk '{ gsub(/\x1b\[[0-9;]*m/, ""); print }' neto.log
- Ensure your AWS CLI is configured with the correct profile.
- Example window: --after 2h15m --before 30m
```
{% endstep %}
{% step %}
## 3. Running Context Enrichment One Time
Context enrichment should be run on a scheduled basis, but before enabling the schedule, it is prudent to run it and verify that it is fully working.
To run context enrichment manually:
```sh
scripts/run context
```
{% endstep %}
{% step %}
## 4. Enabling Schedules
Once the initial onboarding of existing VPCs is complete and you have tested the context lambda is properly populating context labels into Fusion, you should enable the Lambda function to run on a scheduled basis.
In `terraform.tfvars` set `enable_schedule = true`. The schedule interval is defined by `lambda_schedule` (default: hourly).
When the Lambda runs on a schedule it will onboard new in-scope accounts, orchestrate VPCs (supplementing event triggers to ensure nothing is missed), remove Fusion flow sources for inactive VPCs that exceed the `inactive_vpc_timeout`, and if `context_enrichment = true`, discover new and changed resources and deliver updated context labels to Fusion.
{% endstep %}
{% step %}
## 5. Tear Down
Command Line:
* Trigger the function by running `scripts/run destroy`
* Note: This will disable the `NetoFlowLogTagTimerRule` before triggering the function, to prevent the next scheduled run from re-onboarding resources. You can re-enable the scheduler by running `aws events enable-rule --name NetoFlowLogTagTimerRule`.
* WARNING: Terraform will not re-enable the scheduler when running an apply if it is disabled via the `aws` CLI. If you disable it by running destroy, then re-onboard resources, the scheduler will be disabled until you manually enable it.
AWS Console:
* To avoid the scheduled Lambda from re-onboarding resources when it runs on a schedule the next time, first go to EventBridge in the AWS Console, select Buses, Rules, then select the `NetoFlowLogTagTimerRule` and click *Disable*.
* From your AWS hub orchestration account, go to the Functions page of the AWS Lambda console (), choose the `FlowLogActivator` function, Test`tab, under`Test event`select`Create new event\`, and use the following event JSON:
```json
{
"detail-type": "Offboard Event"
}
```
After this completes, run `terraform destroy` to remove remaining resources.
{% endstep %}
{% endstepper %}
### Deploying only context enrichment (without flow log orchestration)
If you only want to deploy context enrichment (i.e., you already have onboarded your flow logs or have separate automation to manage that), follow the same deployment steps above but set these feature toggles in `terraform.tfvars`:
```
ingest_flow = false
orchestrate_flow = false
context_enrichment = true
```
Then follow steps 3-4 to run context enrichment manually and enable the schedule.
## Configuration Options
### `inactive_vpc_timeout`
Traffic sources will be created in Vectra Fusion when flow logs are enabled for a VPC. However, you may have many VPCs (such as default VPCs) in your AWS organization that do not generate any traffic. In this case, Fusion will be continually polling looking for flow logs for VPCs that have never produced flow logs and may never.
To limit the traffic sources in Fusion to only active VPCs with flow logs, the `inactive_vpc_timeout` is used to check each VPC that has been previously enabled by the automation to see if it has ever generated any flow logs (by identifying if the directory structure is created by AWS upon writing the logs to the log bucket). If a VPC has a traffic source in Fusion, but has never generated a flow log in AWS, it will be removed from Fusion after this timeout period.
If an inactive VPC generates flow logs at any point in the future, the automation will identify that and re-add the VPC as a traffic source to Fusion on its next scheduled function run.
To disable this behavior, set `inactive_vpc_timeout = 0` in the `terraform.tfvars`.
### `ingest_dns`
If you want to ingest DNS query logs from Route 53, set `ingest_dns = true` in the `terraform.tfvars`. This will enable DNS query logging in the same regions as flow logs are enabled. Some regions do not support DNS query logging, and these are excluded by default. If you want to exclude additional regions, set the `dns_exclude_regions` variable in the `terraform.tfvars` to a list of regions to exclude.
### AWS Roles
The automation creates and uses the following roles. Please note that if you have Service Control Policy (SCP) policy in your organization, you need to add these roles and their permissions to the allowlist (see below).
| Roles | Policy | Accounts | Purpose |
| ------------------------------------- | --------------------------------------- | --------------------- | ----------------------------------- |
| `NetoListOrgAccountsAssumeRole` | `NetoListAccountsPolicy` | Management Account | List accounts in the organization |
| `NetoFlowLogActivatorRole` | `NetoFlowLogActivatorPolicy` | Orchestration Account | Assume into accounts to orchestrate |
| `NetoFlowLogBucketValidatorRole` | `NetoS3AccessPolicy` | Logging Account | Check if logs exist in S3 buckets |
| `NetoFlowLogReader` | `NetoS3AccessPolicy` | Logging Account | Allow Vectra to read logs |
| `NetoFlowLogHubAssumeRole` | `NetoVPCFlowLogEnablerPolicy` | In-Scope Accounts | Enable flow logs, read context |
| `NetoFlowLogTagSpokeRuleDeliveryRole` | `NetoFlowLogTagSpokeRuleDeliveryPolicy` | In-Scope Accounts | Send events to hub event bus |
#### Management Account Role
* `NetoListOrgAccountsAssumeRole` - Created in the AWS organization management account. This role allows the Lambda function in the Hub Orchestration Account to assume it to list accounts in the organization/OUs to operate against. The policy for this role is:
```json
statement {
actions = [
"organizations:ListAccounts",
"organizations:ListAccountsForParent",
"organizations:ListOrganizationalUnitsForParent",
"organizations:ListChildren"
]
resources = ["*"]
}
```
#### Hub Orchestration Account Role
* `NetoFlowLogActivatorRole` - Role the Flow Log Activator Lambda function runs as. It gives `sts:AssumeRole` permissions to the `NetoFlowLogHubAssumeRole` in in-scope accounts and `NetoListOrgAccountsAssumeRole` in the management account.
#### Logging Account Roles
* `NetoFlowLogReader` - Role assumed by Vectra Fusion in Vectra's AWS account to read flow logs from S3.
* `NetoFlowLogBucketValidatorRole` - Role assumed by FlowLogActivator Lambda function to read the S3 buckets to check if logs have been written to the bucket for a VPC.
#### In-Scope / Child Account Roles
The roles for child accounts are created by the `NetoIntegrationStackSet` CloudFormation StackSet `cloudformation/vectra_stackset_14.yaml` that is automatically deployed to all accounts within the tfvars `scope_root_ou` OU. This is what gives permissions throughout the organization to perform orchestration.
* `NetoFlowLogHubAssumeRole` - Role assumed by FlowLogActivator Lambda function to enable flow logs for the VPC, describe assets to retrieve context, and create EventBridge rules to trigger the function.
* `NetoFlowLogTagSpokeRuleDeliveryRole` - Role used to send EventBridge events to the hub orchestration account Event Bus when a VPC is created, deleted, or tagged.
#### Service Control Policy (SCP)
If you receive an error indicating you are `not authorized to perform` an action due to `service control policy`, you need to add `Allow` statements to your service control policy to allow the automation to perform those actions. In addition to allowing the initial automation resources to be created, you may also need allow the actions defined in the IAM policies for the roles described in the **AWS Roles** section.
The permissions described below are intended as a starting point for adjusting your organization's Service Control Policy, and you should ensure you fully understand the intended behavior and changes to a Service Control Policy before applying.
For the `hub_orchestration_account` terraform:
```json
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowRequiredServicesForTerraform",
"Effect": "Allow",
"Action": [
"iam:CreateRole",
"iam:PutRolePolicy",
"lambda:CreateFunction",
"lambda:AddPermission",
"lambda:InvokeFunction",
"logs:CreateLogGroup",
"logs:PutMetricFilter",
"cloudwatch:PutMetricAlarm",
"sns:CreateTopic",
"sns:SetTopicAttributes",
"sns:Subscribe",
"cloudwatch:PutRule",
"cloudwatch:PutTargets",
"events:PutRule",
"events:PutTargets",
"events:CreateEventBus",
"events:PutEventBusPolicy",
"sts:AssumeRole",
"ec2:CreateVpc",
"ec2:DeleteVpc",
"organizations:ListAccounts"
],
"Resource": "*"
}
]
}
```
For the `centralized_org_logging_account` terraform:
```json
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowS3AndRelatedServices",
"Effect": "Allow",
"Action": [
"s3:*",
"iam:CreateRole",
"iam:AttachRolePolicy",
"iam:PutRolePolicy",
"iam:PassRole",
"cloudwatch:PutMetricAlarm",
"logs:CreateLogGroup",
"logs:CreateLogStream",
"logs:PutLogEvents",
"organizations:ListAccounts"
],
"Resource": "*"
}
]
}
```
For the `management_account` terraform:
```json
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"cloudformation:CreateStackSet",
"cloudformation:CreateStackInstances",
"cloudformation:DeleteStackInstances",
"cloudformation:DeleteStackSet",
"cloudformation:DescribeStackSet",
"cloudformation:DescribeStackSetOperation",
"cloudformation:ListStackInstances",
"cloudformation:UpdateStackSet",
"cloudformation:UpdateStackInstances",
"iam:CreateRole",
"iam:DeleteRole",
"iam:GetRole",
"iam:PassRole",
"iam:PutRolePolicy",
"iam:AttachRolePolicy",
"iam:DetachRolePolicy",
"iam:DeleteRolePolicy",
"organizations:ListAccounts",
"organizations:ListAccountsForParent",
"sts:AssumeRole",
"s3:*"
],
"Resource": "*"
}
]
}
```
See:
### S3 Prefixes
* Each VPC's flow log is represented as a single flow source in Vectra. When a flow source is created in AWS, it is automatically configured to send to a specific prefix in the S3 Bucket matching the region where that flowlog is coming from. This prefix is then used to create the Flow Source in Vectra Fusion so that Fusion can look in that specific prefix for the flow source for that VPC.
* Example: Your company is called `netocustomer` and the environment you want to apply this automation to is `production`. The `centralized_org_logging_account` would create a bucket for each AWS commercial region. One such bucket will be called `netocustomer-neto-production-us-east-1`. This assumes you assign the `customer_name` variable to `NetoCustomer` and the `environment` variable `production`.
* VPC `vpc-09e7a3a9639646404` in Region `us-east-1` is created in account `208426436839`.
* The flow logs will be sent to the S3 prefix `s3://netocustomer-neto-production-us-east-1/208426436839/us-east-1/vpc-09e7a3a9639646404`
---
# 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/aws-cloud-onboarding/neto-onboarding-aws.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.