> For the complete documentation index, see [llms.txt](https://cortex-docs.paloaltonetworks.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://cortex-docs.paloaltonetworks.com/cortex-cloud-outposts/outpost-creation.md).

# Outpost creation

This section explains what to expect in terms of the resources and components generated on the outpost as well as roles and permissions that are automatically set up for you.

To create an outpost, follow the instructions in the [Cortex Cloud technical documentation](https://cortex-docs.paloaltonetworks.com/cortex-cloud-posture-management/onboard-and-configure/deployment-steps-and-checklist/cloud-service-provider-csp-onboarding/outpost-onboarding/outpost-creation-workflow).

If you are deploying a custom outpost, review Outpost Customization and Determine Level of Customization before you begin. The customization mode cannot be changed after deployment.

* **BYOA (Azure only)**: To create a BYOA (Bring Your Own App) outpost, create the Entra ID app registration before running the Create Outpost wizard. 
* **BYON**: BYON (Bring Your Own Network) is a feature that is generally available as of the Cortex Cloud 2.3 release. It allows you to deploy the outpost into network infrastructure that you create, own, and manage, rather than the network the standard deployment provisions. 

For more information, see "Create a custom outpost" in the relevant guide:<br>

* [Cortex Cloud Posture Management](https://cortex-docs.paloaltonetworks.com/cortex-cloud-posture-management/onboard-and-configure/deployment-steps-and-checklist/cloud-service-provider-csp-onboarding/outpost-onboarding/working-with-custom-outposts)
* [Cortex Cloud Runtime Security](https://cortex-docs.paloaltonetworks.com/cortex-cloud-runtime-security/onboard-and-configure/deployment-steps-and-checklist/cloud-service-provider-csp-onboarding/outpost-onboarding/working-with-custom-outposts)
* [Cortex XSIAM Documentation](https://cortex-docs.paloaltonetworks.com/cortex-xsiam/configure-cortex-xsiam/cortex-xsiam-data-sources/cloud-service-provider-csp-onboarding/outpost-onboarding/working-with-custom-outposts)
* [Cortex XDR Documentation](https://cortex-docs.paloaltonetworks.com/cortex-xdr/configure-cortex-xdr/cortex-xdr-data-sources/cloud-service-provider-csp-onboarding/outpost-onboarding/working-with-custom-outposts)
* [Cortex Data Security Documentation](https://cortex-docs.paloaltonetworks.com/data-security-documentation/onboard-and-configure/csp-onboarding/outpost-onboarding/working-with-custom-outposts)

### **Onboarding steps**

1. Customer runs template.
2. Customer provisions role/trust/external ID.

**Note**: Cortex stores only non-secret connector metadata.

### **Configuration**

After the outpost is created, you can change the configuration of the outpost, such as adding custom tags to ensure resources match their organizational policies. Note that this only affects new resources, not existing resources.

### **Outpost anatomy**

After outpost creation, the outpost generally includes:

* An IAM role (AWS), role definition (Azure), or Cloud IAM role (GCP), assumed by SaaS applications
* Additional roles or role definitions, assigned to VMs running in the outpost

Additionally, for each region, the outpost comprises:

* A virtual network (such as a VPC or VNet) with wide classless inter-domain routing (CIDR)
* Two subnets, in different availability zones (or zones, in the case of GCP)
* A security group (AWS), network security group (Azure), or firewall rules with network tags (GCP) applied to scanners
* Two buckets (AWS), blob containers (Azure), or cloud storage buckets (GCP)
* A notification subscription on the communication bucket

### **Regions**

Resources are deployed to all regions by default, but you can limit the deployment to specific regions to meet data residency requirements or to control infrastructure costs. This is managed by filtering the master region list using Terraform variables.

Adjusting these variables determines where the outpost creates virtual networks, subnets, and scanner VMs. Because regional scanning VMs represent the majority of the compute footprint, configuring this list is a standard part of the outpost onboarding process to align the deployment with the actual resources in the customer environment.

### **Resources**

The outpost requires various infrastructure resources to operate, all of which are defined in the cloud infrastructure code provided by Cortex and deployed by the customer. This deployment creates the necessary resources—from multiple identities, roles, and policies to differentiate between different types of scanner VMs, to security group rules to strictly allow or prohibit network connectivity, and so on—all while keeping your outposts secure. Cortex, for the most part, configures every region separately to ensure data residency and minimize cross-region traffic and data transfer. (Exceptions include global resources like the GCP Pub/Sub service, which is used for bucket/blob notifications.)

Also outposts are designed to keep resource costs as low as possible. All resources deployed using Terraform should not incur excessive charges.

Every CSP needs a different set of resources so the deployed resources are configured accordingly.


---

# 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 by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://cortex-docs.paloaltonetworks.com/cortex-cloud-outposts/outpost-creation.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

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.