> 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-runtime-security/onboard-and-configure/deployment-steps-and-checklist/cloud-service-provider-csp-onboarding/amazon-web-services-cloud-onboarding/post-deployment-custom-byob-audit-log-collection.md). # Post-deployment: Custom (BYOB) and Control Tower audit log collection If you selected **Custom (BYOB)** or **Custom Control Tower** audit log collection, you must configure your S3 bucket to forward event notifications to the SQS queue created by the template. The steps differ depending on your deployment method. {% tabs %} {% tab title="CloudFormation Custom (BYOB)" %} The CloudFormation stack creates the SQS queue in your account. You must manually configure your S3 bucket to send event notifications to it. 1. In the AWS CloudFormation console, open the stack and select the **Outputs** tab. 2. Note the `sqs_url` output value. 3. Derive the SQS queue ARN from the URL (format: `arn:aws:sqs:::`), or retrieve it from the AWS SQS console. 4. In the AWS Management Console, navigate to your S3 bucket. 5. Under **Properties → Event notifications**, add a notification: * **Event types:** `s3:ObjectCreated:*` * **Destination:** SQS queue. Enter the ARN from step 3. 6. Save the notification configuration. {% endtab %} {% tab title="CloudFormation Custom Control Tower" %} The Control Tower BYOB CloudFormation stack deploys the SQS queue and SNS subscription automatically via CloudFormation StackSets into the account where your SNS topic resides. No manual S3 event notification configuration is required. The SNS-to-SQS subscription is created by the StackSet. After the stack completes, you can verify the following in the AWS Management Console: 1. In the SNS topic account, confirm that the SQS queue named `` (the prepopulated parameter value in the CloudFormation template) exists and has an active subscription to your CloudTrail SNS topic. 2. In the logging account, confirm that the IAM role named `` (the prepopulated parameter value in the CloudFormation template) exists and has the correct trust policy and S3 read permissions. 3. In Cortex Cloud, verify that the cloud instance transitions from **Pending** to **Connected**. {% hint style="warning" %} #### Important If you are using Control Tower for audit log collection and you choose to encrypt your logs with a KMS key, you must [grant cross-account KMS key access](/cortex-cloud-runtime-security/onboard-and-configure/deployment-steps-and-checklist/cloud-service-provider-csp-onboarding/amazon-web-services-cloud-onboarding/grant-cross-account-kms-key-access-for-control-tower-byob-log-collection.md). {% endhint %} {% endtab %} {% tab title="Terraform (account scope)" %} The Terraform template creates the SQS queue in your account. You must manually configure your S3 bucket to send event notifications to it. 1. In the `terraform apply` output, note the `sqs_url` value. 2. Derive the SQS queue ARN from the URL (format: `arn:aws:sqs:::`), or retrieve it from the AWS SQS console. 3. In the AWS Management Console, navigate to your S3 bucket. 4. Under **Properties → Event notifications**, add a notification: * **Event types:** `s3:ObjectCreated:*` * **Destination:** SQS queue. Enter the ARN from step 2. 5. Save the notification configuration. {% endtab %} {% endtabs %} ### Troubleshooting custom audit log collection Use this section to diagnose issues with custom (BYOB) audit log collection after deploying the authentication template. The most common causes of failure are: * **S3 event notifications not configured or misconfigured**: For Terraform and standard CloudFormation deployments, you must manually configure your S3 bucket to forward `s3:ObjectCreated:*` events to the SQS queue created by the template. If this step is skipped or the wrong SQS ARN is used, logs will not reach Cortex Cloud. * **Cross-region resources**: The S3 bucket, SNS topic, SQS queue, and authentication template deployment must all be in the same AWS region. Cross-region configurations are not supported. * **KMS key policy not updated**: (Only relevant for Custom Control Tower audit log collection) If your S3 bucket is encrypted with a customer-managed KMS key, you must manually update the KMS key policy to allow the Cortex log-collector IAM role to call `kms:Decrypt`. This cannot be done automatically by the template. * **Instance remains in Pending state**: This indicates the template deployed successfully but the notification to Cortex Cloud did not complete. You can connect the instance manually from the Cortex Cloud pending instances panel. See [Manually connect a cloud instance](/cortex-cloud-runtime-security/onboard-and-configure/deployment-steps-and-checklist/cloud-service-provider-csp-onboarding/manually-connect-a-cloud-instance.md) for more details. Select the tab for your deployment method for specific troubleshooting steps. {% tabs %} {% tab title="CloudFormation Custom (BYOB)" %}
SymptomLikely causeResolution
Stack creation fails with IAM permission errorsAWS credentials lack required CloudFormation or IAM permissionsEnsure your AWS credentials have permissions to create CloudFormation stacks, IAM roles, SQS queues, and the resources required by your selected capabilities.
CloudTrailSnsArn parameter rejectedSNS ARN format is incorrectThe ARN must match arn:(aws|aws-us-gov):sns:<region>:<account-id>:<topic-name>.
CloudTrailKmsArn parameter rejectedKMS ARN format is incorrectThe ARN must match arn:(aws|aws-us-gov):kms:<region>:<account-id>:key/<uuid>. Leave the field empty if no KMS key is used.
Instance remains in Pending state after stack creationLambda notification to Cortex Cloud failedCheck the Lambda function logs in CloudWatch for errors. If the notification failed, connect the instance manually: select the pending instance, click Connect manually, and provide the CortexPlatformRole ARN and External ID shown in the CloudFormation stack Outputs tab.
Logs not appearing in Cortex Cloud after stack creationS3 event notification not configured, or configured with wrong SQS ARNConfirm you have configured the S3 bucket event notification to send s3:ObjectCreated:* events to the SQS queue. Retrieve the correct SQS ARN from the sqs_url value in the CloudFormation stack Outputs tab. Ensure the S3 bucket, SNS topic, and CloudFormation stack are all in the same AWS region.
KMS decryption errors in Cortex CloudKMS key policy does not allow the CortexLogsReadRole to call kms:DecryptUpdate the KMS key policy to allow kms:Decrypt for the CortexLogsReadRole-* IAM role created by the stack. This must be done manually after the stack is deployed.

{% endtab %} {% tab title="CloudFormation Custom Control Tower" %} | Symptom | Likely cause | Resolution | | ------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | StackSet operation fails with `OPERATION_NOT_FOUND` or permission errors | AWS Organizations service-managed StackSets not enabled, or the management account does not have trusted access enabled for CloudFormation | In AWS Organizations, enable trusted access for AWS CloudFormation StackSets. See the [AWS documentation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/stacksets-orgs-enable-trusted-access.html). | | SQS queue not created in the SNS topic account | `SnsTopicOuId` does not contain the account where the SNS topic resides | Verify that the OU ID entered for `SnsTopicOuId` is the OU that directly contains the SNS topic account. The StackSet uses `AccountFilterType: INTERSECTION` and will not deploy if the account is not in the specified OU. | | IAM role not created in the logging account | `LoggingAccountOuId` does not contain the logging account | Verify that the OU ID entered for `LoggingAccountOuId` is the OU that directly contains the logging account where the S3 bucket resides. | | `LoggingAccountId` parameter rejected | Account ID format is incorrect | The value must be a 12-digit AWS account ID with no hyphens or spaces. | | `LoggingAccountOuId` or `SnsTopicOuId` parameter rejected | OU ID format is incorrect | The value must match the format `ou--` (for example, `ou-ab12-cd34ef56`). | | `SqsQueueName` parameter rejected | Queue name contains invalid characters or exceeds 80 characters | Queue names may only contain alphanumeric characters, hyphens, and underscores, and must be 80 characters or fewer. | | Logs not appearing in Cortex Cloud after stack creation | SNS-to-SQS subscription not active, or S3 event notification not forwarding to SNS | In the SNS topic account, verify the SQS queue exists and has an active subscription to the CloudTrail SNS topic. Confirm that the S3 bucket is configured to send `s3:ObjectCreated:*` event notifications to the SNS topic (not directly to SQS — the SNS topic fans out to the SQS queue). | | KMS decryption errors in Cortex Cloud | KMS key policy does not allow the `CloudTrailReadRoleName` role in the logging account to call `kms:Decrypt` | Update the KMS key policy in the logging account to allow `kms:Decrypt` for the IAM role named ``. This must be done manually after the StackSet deploys the role. | | {% endtab %} | | | {% tab title="Terraform" %} | Symptom | Likely cause | Resolution | | ---------------------------------------------------------------------------- | ---------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `terraform init` fails with provider download errors | No outbound internet access to the Terraform registry | Ensure outbound HTTPS access to `registry.terraform.io` and `releases.hashicorp.com` is allowed from your local machine. | | `terraform apply` fails with IAM permission errors | AWS credentials lack required permissions | Ensure your AWS credentials have permissions to create IAM roles, policies, and the resources required by your selected capabilities. | | `cloud_trail_sns_arn` validation error | SNS ARN format is incorrect | The ARN must match `arn:(aws\|aws-us-gov):sns:::`. | | `cloud_trail_kms_arn` validation error | KMS ARN format is incorrect | The ARN must match `arn:(aws\|aws-us-gov):kms:::key/`. Leave the field empty if no KMS key is used. | | Tag validation errors during apply | Custom tags contain invalid characters | AWS tag keys and values may only contain Unicode letters, digits, whitespace, and the following symbols: `_ . : / = + - @`. Remove any other characters from your custom tags in the onboarding wizard. | | Instance remains in Pending state after apply | Notification to Cortex Cloud failed | The notification requires outbound HTTPS access to `*.storage.googleapis.com`. If the notification failed, connect the instance manually: select the pending instance, click **Connect manually**, and provide the `CortexPlatformRole` ARN and External ID shown in the Terraform output. | | Logs not appearing in Cortex Cloud after S3 event notification is configured | SQS queue ARN entered incorrectly in S3 event notification | Verify the ARN in the S3 bucket event notification matches the `sqs_url` output from `terraform apply`. Ensure the S3 bucket, SNS topic, and SQS queue are all in the same AWS region. | | {% endtab %} | | | | {% endtabs %} | | | --- # 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-cloud-runtime-security/onboard-and-configure/deployment-steps-and-checklist/cloud-service-provider-csp-onboarding/amazon-web-services-cloud-onboarding/post-deployment-custom-byob-audit-log-collection.md?ask=&goal= ``` `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.