> 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-xsiam/configure-cortex-xsiam/cortex-xsiam-data-sources/cloud-service-provider-csp-onboarding/amazon-web-services-cloud-onboarding/how-to-onboard-amazon-web-services-with-foundational-configuration.md).

# How to onboard Amazon Web Services with foundational configuration

{% hint style="info" %}

#### License type

Onboarding Amazon Web Services (AWS) using the foundational configuration is included with Cortex XSIAM NG SIEM, Cortex XSIAM Enterprise, and Cortex XSIAM Enterprise+ licenses. For more details on the CSP onboarding tiers and licensing, see [Understand CSP onboarding tiers and licensing](/cortex-xsiam/configure-cortex-xsiam/cortex-xsiam-data-sources/cloud-service-provider-csp-onboarding/understand-csp-onboarding-tiers-and-licensing.md).
{% endhint %}

This procedure describes foundational onboarding, which includes support of asset discovery and audit log collection. For the procedure describing comprehensive onboarding, see [How to onboard Amazon Web Services](/cortex-cloud-posture-management/onboard-and-configure/deployment-steps-and-checklist/cloud-service-provider-csp-onboarding/amazon-web-services-cloud-onboarding/how-to-onboard-amazon-web-services.md).

After completing the [prerequisites](/cortex-xsiam/configure-cortex-xsiam/cortex-xsiam-data-sources/cloud-service-provider-csp-onboarding/amazon-web-services-cloud-onboarding/prerequisites-for-onboarding-aws.md), follow these instructions to onboard your Amazon Web Services (AWS) environment to Cortex XSIAM.

### Access the AWS onboarding wizard in Cortex XSIAM: <a href="#access-the-aws-onboarding-wizard-in-cortex-xsiam" id="access-the-aws-onboarding-wizard-in-cortex-xsiam"></a>

1. In Cortex XSIAM, select **Settings → Data Sources & Integrations**.
2. On the Data Sources & Integrations page, click **+ Add New**.
3. On the Add Data Sources or Integrations page, search for Amazon Web Services (AWS), then hover over it and click **Add** or **Add Another Instance**.

### Select the scope

Select the scope for this cloud instance:

* **Organization:** (Default) A collection of AWS accounts that are managed centrally.
* **Organizational Unit:** A group of AWS accounts within an organization. An organizational unit can also contain other organizational units.
* **Account:** A single AWS account.

### Configure advanced settings (optional)

Click **Show advanced settings** to define the following advanced settings:

* **Instance Name:** Enter a unique instance name or leave it empty to be automatically populated. The automatic naming convention is ``AWS- or `AWS-`<organizationID>``. Cortex XSIAM does not prevent you from reusing instance names, but it is best practice to use a unique name for every cloud instance.
* **Scope Modifications:** Use these settings to fine-tune your AWS scope, you can modify the scope by including or excluding specific regions. If you selected a Government environment, only AWS GovCloud regions are displayed. Additionally, if you selected an organization or organizational unit as the scope, you can modify the scope by including or excluding specific organizational units or accounts. For more details, see [Apply region or account filters](/cortex-xsiam/configure-cortex-xsiam/cortex-xsiam-data-sources/cloud-service-provider-csp-onboarding.md#step-5-apply-region-or-account-filters-optional).
* **Additional Security Capabilities:** Choose which security capabilities you want to benefit from. Some security capabilities are enabled by default and can be modified. Adding security capability typically requires additional cloud provider permissions. For detailed information on the permissions required, see [Cloud service provider permissions](/cortex-xsiam/configure-cortex-xsiam/cortex-xsiam-data-sources/cloud-service-provider-csp-onboarding/amazon-web-services-cloud-onboarding/amazon-web-services-aws-provider-permissions.md).
  * **Automation:** Use automation to pre-configure a list of integrations and associated commands to automate security issue responses. Commands can be utilized individually or as part of custom playbooks for issue remediation.
* **Cloud Tags:** Define tags and tag values to be added to any new resource created by Cortex XSIAM in AWS. Note: The `managed_by = paloaltonetworks` tag is automatically added to all resources. This tag is mandatory. You cannot edit or remove this tag.
* **Log Collection Configuration:** To maximize security coverage, include the collection of audit logs using CloudTrail. Select the collection method:
  * **Automated:** Select this option to have Cortex XSIAM provisions CloudTrail, S3, SQS, SNS, and KMS key resources in your AWS environment to collect audit logs.
    * **Collect data events:** You can choose to collect data events, which captures S3 object-level and Lambda invocation events for enhanced visibility.
    * **Cost considerations:** Data events can generate high volumes in active environments (millions of events per day for busy S3 buckets). We recommend you review your CloudTrail pricing and expected event volume before enabling.
  * **Custom**: (Default) Use this option to use an existing Amazon S3 bucket for storing your CloudTrail logs.
    * When you deploy the authentication template, you will enter the following details: S3 bucket name, SNS topic ARN, KMS key ARN (optional, if bucket is encrypted). For CloudFormation, these are entered as stack parameters. For Terraform, you are prompted for these values when you run terraform apply.
    * Cortex XSIAM creates the SQS queue, the `cortex-logs-ingestion-access-*` IAM role, and the S3-to-SNS-to-SQS event notification infrastructure.
    * After you deploy the authentication template, you must configure the S3 bucket event notification to send to the Cortex XSIAM-created SQS queue.
  * **Custom Control Tower:** Select this option if your AWS Organization is managed by AWS Control Tower and uses a centralized Log Archive account where CloudTrail logs are stored in a dedicated account separate from the management account. This option is only available for organization scope and uses service-managed StackSets to deploy the IAM role into the Log Archive account and the SQS queue into the account where the Control Tower SNS topic resides.

    * When you deploy the authentication template in CloudFormation, you will enter the following details: S3 bucket name (the centralized Control Tower bucket in the Log Archive account), SNS topic ARN (the Control Tower-provisioned `aws-controltower-AllConfigNotifications` topic), KMS key ARN (optional), logging account ID (the AWS account ID of the Log Archive account), logging account OU ID (the OU ID of the organizational unit that directly contains the Log Archive account), and the SNS topic OU ID (the OU ID of the organizational unit that directly contains the account where the SNS topic resides).
    * Cortex XSIAM deploys the IAM role into the Log Archive account and creates the SQS queue in the same account that hosts the customer's CloudTrail SNS topic.

    <div data-gb-custom-block data-tag="hint" data-style="warning" class="hint hint-warning"><p><strong>Important</strong></p><p>It is critical to ensure that your KMS key region and SNS topic region are the exact same as the AWS region where you are deploying the authentication template. For custom Control Tower (BYOB), deploy the stack in the same region as your Control Tower home region, where the SNS topic resides.</p></div>

### Save the configuration <a href="#save-the-configuration" id="save-the-configuration"></a>

* Click **Save**. Cortex XSIAM generates an authentication template based on the settings you configured in the AWS onboarding wizard. Cortex XSIAM creates an instance in the pending state. For details on pending instances, see [Pending cloud instances](/cortex-xsiam/configure-cortex-xsiam/cortex-xsiam-data-sources/cloud-service-provider-csp-onboarding/pending-cloud-instances.md).

### Deploy the template <a href="#deploy-the-template" id="deploy-the-template"></a>

To complete the process, deploy the authentication template using one of the following methods:

1. **Automated:** (Recommended) Click **Execute in AWS** to be redirected to AWS CloudFormation to create the stack. Before you select **Automated**, verify that you are logged into the correct AWS account in your browser. For account scope, it is the account you are onboarding. For organization or OU scope, it is the management account. Deploying to the wrong account will cause deployment failures or create resources in the wrong location.

   You are redirected to the AWS CloudFormation console with the pre-populated template. Click through the wizard to create the stack.
2. **Generate template:** Download one of the setup files and deploy it in your AWS account:
   * Click **CloudFormation** to download the CloudFormation template file.
   * Click **Terraform** (account scope only) to download the Terraform template archive.
3. [Deploy the template in AWS](/cortex-xsiam/configure-cortex-xsiam/cortex-xsiam-data-sources/cloud-service-provider-csp-onboarding/amazon-web-services-cloud-onboarding/deploy-the-authentication-template-in-aws.md).


---

# 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-xsiam/configure-cortex-xsiam/cortex-xsiam-data-sources/cloud-service-provider-csp-onboarding/amazon-web-services-cloud-onboarding/how-to-onboard-amazon-web-services-with-foundational-configuration.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.