> 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/about-cortex-cloud-outposts.md). # About Cortex Cloud outposts ### **Overview** Outposts are a cornerstone of the Cortex Cloud architecture. They extend the reach of Cortex Cloud, enabling it to securely scan resources across cloud service providers’ SaaS services and on-premises environments. Outposts allow Palo Alto Networks to establish a trust relationship with your cloud environments, and provide a secure, localized point for scanning. The outpost allows Cortex Cloud to scan assets within the monitored customer cloud account with minimal resources created on that account. This approach ensures security analysis is performed without impacting the performance or integrity of the live workloads, while also helping to maintain data residency and compliance. This document describes how Cortex Cloud outposts work and interact with cloud service providers (CSPs). By explaining the overall concepts and presenting various outpost architectural configurations, you can plan how to configure your own cloud environment to best implement scanning for your needs. ### **What Is an outpost?** The outpost is a demarcated area where Cortex Cloud access occurs. The outpost comprises a set of infrastructure resources that are used in tandem to interact with your cloud environment, and more specifically, with data resources in that environment. These resources include, for example: * IAM roles, which have sufficient permissions to call CSP APIs and collect data. * Networks (VMs), where scanners extract and classify metadata and findings from your data. The outpost’s set of dedicated infrastructure services enable scanning your workloads while respecting data security and residence requirements. ### **The shared responsibility model** Outposts provide an opportunity for you, the customer, and Cortex Cloud to share security responsibilities. The level of control you maintain is flexible and is determined by the scan mode you choose to configure. {% hint style="info" %} **Note**:\ This document mainly describes and addresses the outpost scan mode as opposed to the cloud scan mode. {% endhint %} #### **Determining responsibilities by scan mode** The choice between the two scan modes defines the shared responsibility model: You can also explore the advantages of using each mode under [Plan workload requirements based on quotas](/cortex-cloud-outposts/outpost-planning.md#plan-workload-requirements-based-on-quotas). * **Cloud scan:** In this model, Cortex manages your security in a dedicated managed account using outpost-style infrastructure owned and operated by Palo Alto Networks. This provides you with less maintenance and lower costs. The entire scanning and classification process takes place within the Cortex Cloud environment, and no additional setup is needed. The Cloud Scan infrastructure, which is a Cortex-managed outpost, is deployed as a single-tenant environment dedicated to you as the customer. In this mode, copies of the data, such as disk snapshots, are securely shared from your CSP account to the Palo Alto Networks-owned outpost account for analysis and classification. The scanning process then occurs entirely within this dedicated Cortex Cloud environment. Diagram: Cloud scan {% hint style="info" %} **Tip**:\ Behind the scenes, the cloud scan infrastructure also uses an outpost-style infrastructure, the only difference being that the infrastructure is owned and operated by Palo Alto Networks. Therefore, any diagrams in this document related to outpost scan can be applied to cloud scan. {% endhint %} * **Outpost scan**: This model allows you to keep your data within your own boundaries by deploying a customer-managed outpost in your own cloud account. You take on more responsibility for configuring and managing the outpost to meet your specific security and compliance needs. Scanning is performed on an outpost infrastructure deployed to a CSP account you own. For an outpost scan, Palo Alto Networks requires that it is mandatory for the CSP account to be a dedicated account for the outpost, free from other resources. Each CSP cloud account (AWS account, Azure subscription, GCP project) can host only one outpost. An individual outpost instance is strictly bound to a single Cortex Cloud tenant and cannot be used to scan resources belonging to a different tenant or organization. This mode requires additional cloud provider permissions and may incur additional cloud costs. Note, however, that an “idle” (unused) outpost, with no scanning activity, incurs practically no cost (perhaps only a few dollars per year for certain CSPs). Calculators for determining costs can be requested from Palo Alto Networks on-demand. As this type of outpost infrastructure and scanning is not managed by Cortex, it is also known as a “customer-managed” or “unmanaged” scan.

Diagram: Outpost scan

Details regarding how your data is handled, and how long your data is stored on the outpost, are provided below, as well as under [Scanners](/cortex-cloud-outposts/scanners.md). #### **Outpost shared responsibilities** The following table presents the scenario for sharing security responsibilities using a customer-managed outpost. | **Security domain** | **Customer responsibilities** | **Palo Alto Networks (Cortex) responsibilities** | | ---------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Infrastructure & environment | Owns and provisions the CSP account (subscription, project), the Virtual Private Cloud (VPC or VNet), and the subnets. Manages most associated cloud costs. | Provides the software and configuration templates for the outpost infrastructure.Provisions some network infrastructure on-demand, such as private service connections (for example, VPC endpoints, Private Service Access, or private endpoints) and an egress proxy VM. Essentially, all resources with hourly costs are provisioned dynamically. | | Roles & permissions | Creates and manages the IAM roles with the specific permissions needed for Cortex to operate. | Provides the list of necessary permissions (read, write, action) for the Outpost to function. | | Data & assets | Owns all data and controls where it resides. Manages the artifact buckets for data export and analysis. | Provisions and manages the temporary scanner VMs, snapshots, and images needed for the scan operation. Ensures that data is deleted immediately after analysis. | | Network & security | Manages the network configuration, including security groups and firewall rules, to allow communication between the outpost components. | Scans the data and provides metadata results to Cortex Cloud for remediation. Data is never executed. | | Monitoring & logging | Monitors the CSP environment and outpost infrastructure for activity and potential issues. | Provides notification subscriptions to fetch scan results from the communication buckets in real time so you can inspect the bucket content to make sure sensitive data doesn’t leave your boundaries. | ### **Terminology** This section defines the key concepts used throughout this document to describe outposts and maps the generic architectural terms that we intend to use throughout this document to their specific Cloud Service Provider (CSP) equivalents. #### **General outpost terminology** The following table outlines the foundational terminology and specific components that make up the Cortex Cloud Outpost architecture.
TermDescription
BYOA (Bring Your Own App)An Azure-only customization in which you provide the Entra ID app registration. BYOA is an advanced setting in Azure standard outposts.
BYON (Bring Your Own Network)A customization in which you provide the network infrastructure the outpost runs in. This feature is generally available as of the Cortex Cloud 2.3 release.
Cortex CloudThe Cortex Cloud software system, running in the cloud and operated by Palo Alto Networks. Cortex Cloud processes data, such as metadata and findings from scans.
Cortex regionA specific, geographically-defined data center location where Cortex Cloud processes data, such as metadata and findings from scans The Cortex Cloud software runs in one single Cortex region and communicates from there with all of your outposts.
Custom outpostAn outpost in which you supply one or more infrastructure components yourself, and Cortex Cloud deploys the remainder. Current custom options are BYOA and BYON.
Customer cloud account regionThe specific geographic location within a Cloud Service Provider (CSP) such as AWS, Azure, or GCP where your company's own cloud resources are located. For example, this would be the AWS us-east-1 region if that's where your EC2 instances are running, or the Azure East US region if that's where your databases are hosted.
Monitored accountA cloud account that is onboarded onto Cortex Cloud for the purpose of monitoring, scanning, and applying security value. The monitored account is under your control.
Outpost accountA cloud account that is used for security operations. The outpost is a secure, localized point for scanning and classifying. The outpost may or may not be under your control.
Outpost regionAn outpost region is a specific CSP region where an outpost deploys its own set of regional resources to conduct scanning operations. Outposts are designed with "regional symmetry," meaning they create a parallel set of resources (such as VPCs, subnets, and temporary scanner VMs) in every cloud region by default. This design ensures that scanning activities happen locally to your data.
Standard outpostAn outpost in which Cortex Cloud provides the complete infrastructure definition, and the deployment creates all required resources in your outpost account. This is the recommended deployment, and the default.
#### **Cross-provider generic terminology** Because outposts span multiple cloud environments, this document frequently uses generic terms to describe cross-platform infrastructure concepts. The following table maps these generic terms to their specific technical equivalents in AWS, GCP, and Azure to help you accurately translate these requirements into your specific environment. | **Generic term** | **AWS equivalent** | **GCP equivalent** | **Azure equivalent** | | --------------------------- | --------------------------- | -------------------------------- | ----------------------- | | Block storage | EBS volume | Persistent disk | Disk | | Cloud environment | AWS account | GCP project | Azure subscription | | Compute instance | EC2 instance | VM instance | Virtual machine | | Compute zone | Availability zone | Zone | Availability zone | | Event notification system | S3 bucket notification | Pub/Sub notification | Event Grid system topic | | Managed NoSQL database | DynamoDB | Bigtable | CosmosDB | | Managed relational database | RDS / Aurora | CloudSQL | Azure SQL | | Message queue | SQS queue | Pub/Sub topic | Storage queue | | Network security rule | Security group | Firewall rules with network tags | Network security group | | Object storage | Bucket | Cloud storage bucket | Blob container | | Private service connection | VPC endpoint | Private Service Access | Private endpoint | | Secret management service | AWS Secrets Manager | Secret Manager | Azure Key Vault | | Service identity | IAM role | Cloud IAM role | Role definition | | Virtual network | Virtual Private Cloud (VPC) | VPC network | Virtual Network (VNet) | | Volume snapshot | EBS snapshot | Disk snapshot | Snapshot | --- # 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/about-cortex-cloud-outposts.md?ask=&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.