> 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-xdr-5.x/configure-cortex-xdr/cortex-xdr-data-sources/cloud-service-provider-csp-onboarding/amazon-web-services-cloud-onboarding/aws-resource-inventory.md).

# AWS resource inventory

The onboarding process creates AWS resources in the onboarding account (the management account for Organization or Organizational Unit scope). The exact set of resources depends on the onboarding scope and the security capabilities selected during the process. The resources fall into three categories: base resources (created for every cloud instance), scanning resources (created based on selected capabilities), and log collection resources (created when audit log collection is enabled).

## **Base resources**

The following tables detail the AWS resources created as part of every cloud instance, according to scope.

### Account onboarding scope

The following resources are created as part of every cloud instance, regardless of which security capabilities are enabled.

| **Resource type**         | **Resource name**                           | **Purpose**                                                                                                                                                                                                                                                                                                                                                                                                               |
| ------------------------- | ------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| AWS::IAM::Role            | **CortexPlatformRole**                      | Primary IAM role assumed by Cortex Cloud using sts:AssumeRole. Attached: **ReadOnlyAccess**, **AmazonMemoryDBReadOnlyAccess**, **SecurityAudit**, **AmazonSQSReadOnlyAccess**, **AWSOrganizationsReadOnlyAccess**. Trust policy: principal = OutpostRoleArn with mandatory sts:ExternalId condition. Optional add-on capabilities (Discovery, ADS, DSPM, Kubernetes, Automation) attach additional policies to this role. |
| AWS::IAM::Role            | **CortexTemplateCustomLambdaExecutionRole** | Execution role for the custom Lambda function. Attached managed policy: **AWSLambdaBasicExecutionRole.**                                                                                                                                                                                                                                                                                                                  |
| Custom::PublishRoleDetail | (CloudFormation-generated name)             | CloudFormation custom resource that triggers the Lambda function to report stack outputs back to Cortex (ephemeral).                                                                                                                                                                                                                                                                                                      |
| AWS::Lambda::Function     | (CloudFormation-generated name)             | To complete the handshake, this Lambda function sends the CloudFormation Identifiers (role ARN, account ID, external ID) back to the Cortex Cloud platform via HTTPS PUT. For Org and OU scopes, it also sends two identifiers: the AWS Organization ID, and the targeting scope ID - the Organization root ID for Org scope, or the Organizational Unit (OU) ID for OU scope.                                            |

### Organization and organizational unit (OU) onboarding scopes

The following resources are in addition to the resources created for account scope when onboarding at the organization or organizational unit (OU) scope.

| **Resource type**             | **Resource name**                         | **Purpose**                                                                                                                                                                                                                                                                                         |
| ----------------------------- | ----------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| AWS::CloudFormation::StackSet | **CortexPlatformCloudRoleStackSetMember** | Service-managed StackSet that deploys **CortexPlatformRole** (and **CortexPlatformScannerRole** if any scanner capability is enabled) plus selected scanning policies to every member account in the target OU. Automatic deployment onboards new accounts and removes stacks from offboarded ones. |

### Scope differences

Organization and OU onboarding scopes follow the same workflow and create the same resources. In both cases, you launch the CloudFormation template from your AWS Organization management account. This is required by AWS for any deployment that targets multiple member accounts.The only difference between the two scopes is which accounts receive the Cortex Cloud resources:

* **Organization scope**: Deploys Cortex Cloud resources to every account in your AWS Organization, including any accounts you add later.
* **OU scope**: Deploys Cortex Cloud resources only to the accounts inside a specific OU that you choose, plus any sub-OUs nested underneath it

In both cases, the AWS Organization management account also receives Cortex Cloud resources because it hosts the audit-log collection infrastructure that Cortex Cloud needs to access. Two smaller differences also apply:

* **AWS organization metadata access**: Organization scope grants Cortex Cloud read-only access to your AWS Organizations metadata (organization ID, account list) so it can identify which organization you have onboarded. OU scope does not grant this access.
* **CloudTrail audit logs**: If you enable audit log collection, both scopes provision the collection infrastructure in the management account. With organization scope, CloudTrail is configured as an organization trail, meaning a single trail in the management account captures events from every member account automatically.

## **Scanning and automation resources**

For organization and OU scopes, the **CortexPlatformRole**, the **CortexPlatformScannerRole**, and all selected capability policies are propagated to every member account using the member account StackSet. The onboarding helper function, handshake resource, and audit log resources are created only in the management account.

<table data-header-hidden><thead><tr><th></th><th></th><th width="260.28515625"></th><th></th></tr></thead><tbody><tr><td><strong>Resource type</strong></td><td><strong>Resource name</strong></td><td><strong>Purpose</strong></td><td><strong>Relevant security capabilities</strong></td></tr><tr><td><strong>AWS::IAM::Role</strong></td><td><strong>CortexPlatformScannerRole</strong></td><td>IAM role for scanner operations. Attached managed policy: <strong>ReadOnlyAccess</strong>. Trust policy allows scanner identity ARNs populated dynamically from outpost resources data.</td><td>Any of the following: DSPM, serverless scanning, registry scanning</td></tr><tr><td><strong>AWS::IAM::ManagedPolicy</strong></td><td><strong>Cortex-DISCOVERY-Policy</strong></td><td>Managed policy attached to <strong>CortexPlatformRole</strong>. Grants read access to additional AWS services not covered by <strong>ReadOnlyAccess</strong>.</td><td>Always included</td></tr><tr><td><strong>AWS::IAM::ManagedPolicy</strong></td><td><strong>Cortex-ADS-Policy</strong></td><td>Managed policy <strong>Cortex-ADS-Policy</strong> attached to <strong>CortexPlatformRole</strong>. Grants EC2 snapshot operations plus KMS support. Write actions are gated by the <strong>managed_by: paloaltonetworks</strong> tag condition.</td><td>Agentless disk scanning</td></tr><tr><td><strong>AWS::IAM::ManagedPolicy</strong></td><td><strong>Cortex-DSPM-Policy</strong></td><td>Managed policy <strong>Cortex-DSPM-Policy</strong> attached to <strong>CortexPlatformRole</strong>. Grants permissions for data classification and sensitive-data discovery. Includes a scoped <strong>iam:PassRole</strong> to <strong>rds.amazonaws.com</strong> for snapshot-export workflows. Adds <strong>export.rds.amazonaws.com</strong> as a trusted service on the role's trust policy, and creates an inline policy <strong>Cortex-DSPM-Scanner-Policy</strong> on <strong>CortexPlatformScannerRole</strong>.</td><td>DSPM</td></tr><tr><td>Inline policy</td><td><strong>Cortex-DSPM-Scanner-Policy</strong></td><td>Inline policy on CortexPlatformScannerRole. Grants the permissions that actually read customer data for sensitive data classification.</td><td>DSPM</td></tr><tr><td><strong>AWS::IAM::ManagedPolicy</strong></td><td><strong>Cortex-Automation-Policy</strong></td><td>Managed policy <strong>Cortex-Automation-Policy</strong> attached to <strong>CortexPlatformRole</strong>. Grants permissions across a broad range of AWS services for automated remediation, active response, and enrichment. Statements are scoped by action; resources are *.</td><td>Automation</td></tr><tr><td><strong>AWS::IAM::ManagedPolicy</strong></td><td><strong>Cortex-K8s-Security-Policy</strong></td><td>Managed policy <strong>Cortex-K8s-Security-Policy</strong> attached to <strong>CortexPlatformRole</strong>. Grants scoped EKS access-entry management, all conditioned on the <strong>managed_by: paloaltonetworks</strong> tag. Bound Kubernetes permission is the AWS-managed <strong>AmazonEKSAdminViewPolicy</strong> (read-only Kubernetes API access)</td><td>Kubernetes security</td></tr><tr><td>Inline policy</td><td><strong>ECRAccessPolicy</strong></td><td>Inline policy on <strong>CortexPlatformScannerRole</strong>. Grants three ECR actions (BatchGetImage, GetDownloadUrlForLayer, GetAuthorizationToken) for container image pull.</td><td>Registry scanning</td></tr><tr><td>Inline policy</td><td><strong>LAMBDAAccessPolicy</strong></td><td>Inline policy on <strong>CortexPlatformScannerRole</strong>. Grants three Lambda read actions (GetFunction, GetFunctionConfiguration, GetLayerVersion) for serverless code retrieval</td><td>Serverless scanning</td></tr></tbody></table>

## **Log collection resources**

The following resources are deployed in the onboarding account (the management account for organization or OU scope). Log collection resources are never propagated to member accounts via the StackSet. In automated log collection mode, Cortex Cloud provisions the resources listed below. In [custom (BYOB) log collection](#custom-byob-log-collection) mode, only four resources are created: the SQS queue, SNS subscription to your existing topic, queue policy, and the CloudTrailReadRole.

### Automated log collection resources

<table data-header-hidden><thead><tr><th width="180.71875"></th><th width="213.359375"></th><th></th></tr></thead><tbody><tr><td><strong>Resource type</strong></td><td><strong>Resource name</strong></td><td><strong>Purpose</strong></td></tr><tr><td>AWS::KMS::Key</td><td><strong>CloudTrailKMSKey</strong></td><td>Customer Managed Key (CMK) that encrypts CloudTrail logs at rest. The key policy grants the AWS account root full access (kms:), allows the CloudTrail service to encrypt new log objects (kms:GenerateDataKey and kms:Encrypt), and allows kms:Decrypt, kms:ReEncrypt, kms:GenerateDataKey*, and kms:DescribeKey for any IAM principal in the AWS account. This lets authorized roles such as the audit log reader role (default name: CloudTrailReadRole) decrypt the logs.</td></tr><tr><td>AWS::S3::Bucket</td><td><strong>CloudTrailLogsBucket</strong></td><td>S3 bucket (default name pattern: cortex-ct-logs-${AWS::AccountId}, with a tenant suffix appended at template generation) for storing CloudTrail logs. KMS-encrypted with a 7-day lifecycle expiration policy</td></tr><tr><td>AWS::S3::BucketPolicy</td><td><strong>CloudTrailLogsBucketPolicy</strong></td><td>Bucket policy that grants the CloudTrail service permission to write log files to the bucket (s3:PutObject with the bucket-owner-full-control ACL condition) and to read the bucket ACL (s3:GetBucketAcl). All other access is governed by IAM policies in the AWS account.</td></tr><tr><td>AWS::SQS::Queue</td><td><strong>CloudTrailLogsQueue</strong></td><td>SQS queue (default name pattern: cortex-ct-logs-queue-${AWS::AccountId}, with a tenant suffix appended at template generation) for receiving SNS notifications about new CloudTrail log files.</td></tr><tr><td>AWS::SNS::Topic</td><td><strong>CloudTrailSNSTopic</strong></td><td>SNS topic (default name pattern: cortex-ct-logs-notification-${AWS::AccountId}, with a tenant suffix appended at template generation) for CloudTrail log delivery notifications. It receives S3 event notifications and forwards the notifications to the SQS queue.</td></tr><tr><td>AWS::SNS::TopicPolicy</td><td><strong>CloudTrailSNSTopicPolicy</strong></td><td>Enables the CloudTrail service to publish notifications to the SNS topic.</td></tr><tr><td>AWS::SNS::Subscription</td><td><strong>CloudTrailSNSTopicSubscription</strong></td><td>Subscribes the SQS queue to the SNS topic for message delivery.</td></tr><tr><td>AWS::SQS::QueuePolicy</td><td><strong>SNSPolicy</strong></td><td>Enables the SNS topic to send messages to the SQS queue.</td></tr><tr><td>AWS::IAM::Role</td><td><strong>CloudTrailReadRole</strong></td><td>Enables Cortex Cloud to read logs from S3 and poll SQS. Trust policy uses Google web identity federation (Federated: accounts.google.com) with sts:AssumeRoleWithWebIdentity, scoped to a specific audience and Google service-account identifier so that only Cortex Cloud's collector can assume the role.. Inline policy grants S3 read on the logs bucket, SQS receive/delete/get-attributes on the queue, and KMS decrypt.</td></tr><tr><td>AWS::IAM::Role</td><td><strong>EmptyBucketLambdaExecutionRole</strong></td><td>Execution role for the Lambda function that empties the S3 bucket during stack deletion.Inline policy grants S3 list and delete on the logs bucket.</td></tr><tr><td>AWS::Lambda::Function</td><td><strong>EmptyBucketLambda</strong></td><td>Lambda function that empties the S3 bucket on CloudFormation stack deletion to enable clean removal.</td></tr><tr><td>Custom::EmptyBucketDetails</td><td><strong>EmptyBucketCustomResource</strong></td><td><p>CloudFormation custom resource that triggers Bucket cleanup function during stack deletion to clean up the S3 bucket (ephemeral).</p><p>CloudFormation custom resource that triggers during stack deletion to clean up the S3 bucket (ephemeral).</p></td></tr><tr><td>AWS::CloudTrail::Trail</td><td><strong>CloudTrail</strong></td><td><p>Creates a multi-region CloudTrail trail (default name pattern: cortex-trail-${AWS::AccountId}, with a tenant suffix appended at template generation).</p><p>Captures management events only (IncludeManagementEvents: true); data events such as S3 object access or Lambda invocations are not collected by default. Global service events are included (IncludeGlobalServiceEvents: true).</p></td></tr></tbody></table>

### Custom (BYOB) log collection

When custom (BYOB) log collection is configured, you provide the existing S3 bucket and CloudTrail trail in your account. Cortex Cloud provisions the following four resources: CloudTrailReadRole (`cortex-logs-ingestion-access`), CloudTrail logs queue (`cortex-ct-logs-queue-byob-<AccountId>`), SNS-to-SQS subscription, and the Queue policy for the CloudTrail logs queue.

### Custom Control Tower (BYOB) log collection

Custom Control Tower (BYOB) audit log collection is designed for AWS organizations where CloudTrail is provisioned and managed through an AWS Control Tower landing zone. When Control Tower manages your organization's CloudTrail setup, it centralizes all audit logs in a dedicated logging account, a separate AWS account that Control Tower provisions specifically to store logs from across the organization. Because the S3 bucket resides in this logging account rather than in the management account and the SNS topic resides in a designated audt account, the standard custom (BYOB) log collection setup cannot subscribe to the SNS topic across account boundaries without additional configuration.

The custom Control Tower (BYOB) option handles this automatically. Cortex Cloud deploys the IAM role into the logging account and creates the SQS queue in the account where the Control Tower SNS topic resides, enabling seamless cross-account log ingestion without requiring manual IAM trust configuration.

When custom Control Tower log collection is configured for an AWS organization, Cortex Cloud provisions the following resources. The SQS queue, SNS subscription, and queue policy are provisioned in the same account that hosts the customer's CloudTrail SNS topic.

<table><thead><tr><th width="155.83203125">Resource type</th><th width="161.76953125">Resource name</th><th width="126.8125">Account</th><th>Purpose</th></tr></thead><tbody><tr><td><code>AWS::SQS::Queue</code></td><td><code>cortex-ct-logs-byoct-&#x3C;tenant-id></code></td><td>Customer's SNS topic account</td><td>Receives SNS notifications from the Control Tower-provisioned SNS topic about new CloudTrail log files</td></tr><tr><td><code>AWS::SNS::Subscription</code></td><td><em>(inline)</em></td><td>Customer's SNS topic account</td><td>Subscribes the SQS queue to the customer-provided Control Tower SNS topic</td></tr><tr><td><code>AWS::SQS::QueuePolicy</code></td><td><code>SNSPolicy</code></td><td>Customer's SNS topic account</td><td>Allows the Control Tower SNS topic to send messages to the SQS queue</td></tr><tr><td><code>AWS::IAM::Role</code></td><td><code>cortex-logs-ingestion-access-&#x3C;resource-suffix></code></td><td>Logging account</td><td>Grants Cortex Cloud read access to the centralized S3 bucket and SQS queue using Google OIDC federation (<code>accounts.google.com</code>). Inline policy grants: <code>s3:GetObject</code>, <code>s3:ListBucket</code> on the Control Tower S3 bucket; <code>sqs:ReceiveMessage</code>, <code>sqs:DeleteMessage</code>, <code>sqs:GetQueueAttributes</code>, <code>sqs:ChangeMessageVisibility</code> on the SQS queue; <code>kms:Decrypt</code> on the KMS ARN (if provided).</td></tr></tbody></table>

Cortex Cloud does not create: a new S3 bucket, CloudTrail trail, SNS topic, or KMS key. These already exist in the Control Tower environment and are managed by AWS.

## **Naming convention for Cortex Cloud-managed AWS resources**

All resources created during the onboarding deployment follow a deterministic naming pattern: Cortex`<resource>`-\<scan-mode>-`<scope>`-`<tenant-id>`. The two IAM roles created in every deployment are:

* **CortexPlatformRole-\<scan-mode>-\<scope>-\<tenant-id>**: The primary access role Cortex Cloud uses to read and protect your AWS environment.
* **CortexPlatformScannerRole-\<scan-mode>-\<scope>-\<tenant-id>**: The role used by Cortex Cloud scanners (DSPM, registry, serverless) for data-plane reads.

Where:

* **\<scan-mode>** is **m** for cloud scan or **o** for outpost scan.
* **\<scope>** is **a** for account scope or **o** for organization/OU-scope deployments. The scope is fixed at template generation time.
* **\<tenant-id>** is the unique numeric identifier of your Cortex Cloud tenant.

Most Cortex Cloud-managed resources are tagged `managed_by=paloaltonetworks` for inventory and lifecycle tracking. Resources that do not support AWS tagging (such as S3 bucket policies, SNS subscriptions, and SQS queue policies) are not tagged but are managed under the parent resource's lifecycle. The same naming pattern applies to audit-log resources (`cortex-ct-logs-`…), KMS keys, and SQS queues created by the stack.

{% hint style="info" %}
Because role names are deterministic, you cannot deploy two cloud instances of the same scope and the same scan mode into the same AWS account.
{% endhint %}

### Audit log resource naming: Custom vs Control Tower BYOB

The two custom audit log collection modes create resources with different names and in different accounts:

* **Custom (BYOB):** The SQS queue is named `cortex-ct-logs-queue-byob-<AccountId>` and the IAM role is named `cortex-logs-ingestion-access-<resource-suffix>`. Both resources are created in the management account.
* **Custom Control Tower (BYOB):** The SQS queue is named `cortex-ct-logs-byoct-<tenant-id>`. The IAM role is named `cortex-logs-ingestion-access-ingestion-access-<resource-suffix>` and is deployed into the dedicated logging account.


---

# 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, and the optional `goal` query parameter:

```
GET https://cortex-docs.paloaltonetworks.com/cortex-xdr-5.x/configure-cortex-xdr/cortex-xdr-data-sources/cloud-service-provider-csp-onboarding/amazon-web-services-cloud-onboarding/aws-resource-inventory.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.