--- title: "Migrate Legacy Amazon Web Service (AWS) Integrations" slug: "migrate-legacy-amazon-web-service-aws-integrations" updated: 2026-09-10T19:46:49Z published: 2026-09-10T19:46:49Z canonical: "docs.redcanary.com/migrate-legacy-amazon-web-service-aws-integrations" --- > ## Documentation Index > Fetch the complete documentation index at: https://docs.redcanary.com/llms.txt > Use this file to discover all available pages before exploring further. # Migrate Legacy Amazon Web Service (AWS) Integrations In Q2 2025, Zscaler MDR introduced an improved version of the AWS integration that features GuardDuty findings ingestion via an S3 bucket, better control for including and excluding AWS accounts, and a new autodetect feature to speed up onboarding. If you’re using the earlier [legacy integration](/doc/docs/integrate-amazon-web-services-aws-with-zscaler-mdr), we recommend that you upgrade to the [latest version](/doc/docs/integrate-amazon-web-services-with-red-canary) by following these instructions. > [!NOTE] > Important > > If your existing AWS integration includes GuardDuty, you’ll need to set up GuardDuty to export its findings to an S3 bucket before you run the migration. Alternatively, you can skip over the GuardDuty part of the migration and add it later once you’ve configured the S3 export. ## 1 Zscaler MDR | Start the Migration 1. In the Zscaler MDR portal, go to the **Integrations** page then click on the name of the integration you want to migrate. ![](https://cdn.document360.io/75147bee-bf0d-444c-8afb-6e83b11ec0ef/Images/Documentation/awsmigrate-1_01.png?sv=2026-02-06&spr=https&st=2026-11-09T11%3A54%3A26Z&se=2026-11-09T12%3A54%3A26Z&sr=c&sp=r&sig=itnkrqGd3kQO0mfh66iCJ5bczbSgCUa6RVF1V4M6qXo%3D) 2. Click the **Upgrade Integration** button. ![](https://cdn.document360.io/75147bee-bf0d-444c-8afb-6e83b11ec0ef/Images/Documentation/awsmigrate-1_02.png?sv=2026-02-06&spr=https&st=2026-11-09T11%3A54%3A26Z&se=2026-11-09T12%3A54%3A26Z&sr=c&sp=r&sig=itnkrqGd3kQO0mfh66iCJ5bczbSgCUa6RVF1V4M6qXo%3D) 3. Follow the steps in the [Integrate Amazon Web Services (AWS) with Zscaler MDR](/doc/docs/integrate-amazon-web-services-with-red-canary) guide to configure the new integration. > [!WARNING] > Important > > The migration process will use your existing configuration to automatically pre-fill as many of the integration values as possible. This includes setting the scope of the integration and pre-filling the necessary ARN values in the CloudTrail section. **However, you must still provide ARN values for the GuardDuty section (if using GuardDuty) and provision the IAM role as described in the** [**Integration guide**](/doc/docs/integrate-amazon-web-services-with-red-canary)**.** You can use the **Autodetect** feature to help populate the GuardDuty ARNs if necessary. ![](https://cdn.document360.io/75147bee-bf0d-444c-8afb-6e83b11ec0ef/Images/Documentation/awsmigrate-1_03.png?sv=2026-02-06&spr=https&st=2026-11-09T11%3A54%3A26Z&se=2026-11-09T12%3A54%3A26Z&sr=c&sp=r&sig=itnkrqGd3kQO0mfh66iCJ5bczbSgCUa6RVF1V4M6qXo%3D) > [!NOTE] > Note > > The migration process will use your existing configuration to automatically choose the scope of the integration and pre-fill the necessary ARN values in the CloudTrail section. You just need to provide ARN values in the GuardDuty section and provision the IAM role. You can use the **Autodetect** feature to help populate the GuardDuty ARNs if necessary. After you complete and save the configuration, it’ll take approximately 20 minutes for Zscaler MDR to fully migrate and provision the integration. ## 2 AWS | Remove the Legacy Integration AWS Policies The legacy AWS integration required you to create resource policies for your CloudTrail S3 bucket, SNS topic, and KMS key. Once the new integration has fully provisioned, these policies are no longer needed and you can safely remove them. ### S3 Policy 1. In the **AWS Console**, navigate to the **Amazon S3** > **Buckets** page. 2. Open the S3 bucket you’re using for CloudTrail logs and go to the **Permissions** tab. 3. In the **Bucket policy** panel, click **Edit**. 4. Locate the `RCPartnerAccessControl` statement with the following pattern and delete it. ```Custom {  "Sid": "RCPartnerAccessControl",  "Principal": {  "AWS": "arn:aws:iam::186109445163:role/rc-partner-access-control"  },  "Effect": "Allow",  "Action": [  "s3:ListBucket",  "s3:GetObject",  "s3:GetObjectAttributes",  "s3:GetObjectVersion"  ],  "Resource": [  "arn:aws:s3:::example-cloudtrail-logs-123456",  "arn:aws:s3:::example-cloudtrail-logs-123456/*"  ] } ``` 5. Click **Save changes**. ### SNS Topic Policy 1. In the **AWS Console**, navigate to the **Amazon SNS** > **Topics** page. 2. Open the topic you’re using for CloudTrail log event notifications and click **Edit**. 3. In the **Access policy** panel, locate the `RCPartnerAccessControl` statement with the following pattern and delete it. ```Custom {  "Sid": "RCPartnerAccessControl",  "Effect": "Allow",  "Principal": {  "AWS": "arn:aws:iam::186109445163:root"  },  "Action": "SNS:Subscribe",  "Resource": "arn:aws:sns:us-east-2:123456789012:example-sns-topic-name" } ``` 4. Click **Save changes**. ### KMS Key Policy 1. In the **AWS Console**, navigate to the **Key Management Service (KMS)** > **Customer managed keys** page. 2. Open the key you’re using for the CloudTrail S3 bucket and click **Edit** on the **Key Policy** tab. 3. Locate the `RCPartnerAccessControl` statement with the following pattern and delete it. ```Custom {  "Sid": "RCPartnerAccessControl",  "Effect": "Allow",  "Principal": {  "AWS": "arn:aws:iam::186109445163:role/rc-partner-access-control"  },  "Action": [  "kms:Decrypt",  "kms:DescribeKey"  ],  "Resource": "*" } ``` 4. Click **Save changes**. ## 3 AWS | Remove the Legacy Zscaler MDR IAM Role The legacy IAM access role you created for Zscaler MDR in AWS is no longer needed and you can remove it once the migration is complete. 1. In the **AWS Console**, navigate to the **Identity and Access Management (IAM)** > **Roles** page. 2. Find the `rc-partner-access-control` role and delete it. > [!NOTE] > Note > > The role may have a different name if you chose to override the suggested default. > > If you propagated the role using CloudFormation or Terraform, you can also remove it across accounts by deleting the CloudFormation stack or reversing the Terraform apply as appropriate. > [!WARNING] > Warning > > Be careful not to delete the new IAM role created during the migration process (`redcanary-partner-access`).