# Data protection in AWS Transform
The AWS [shared responsibility model](http://aws.amazon.com/compliance/shared-responsibility-model/) applies to data protection in AWS Transform. As described in this model, AWS is responsible for protecting the global infrastructure that runs all of the AWS Cloud. You are responsible for maintaining control over your content that is hosted on this infrastructure. You are also responsible for the security configuration and management tasks for the AWS services that you use. For more information about data privacy, see the [Data Privacy FAQ](http://aws.amazon.com/compliance/data-privacy-faq). For information about data protection in Europe, see the [AWS Shared Responsibility Model and GDPR](http://aws.amazon.com/blogs/security/the-aws-shared-responsibility-model-and-gdpr) blog post on the *AWS Security Blog*.
For data protection purposes, we recommend that you protect AWS account credentials and set up individual users with AWS Identity and Access Management (IAM). That way each user is given only the permissions necessary to fulfill their job duties. We also recommend that you secure your data in the following ways:
+ Use multi-factor authentication (MFA) with each account.
+ Use SSL/TLS to communicate with AWS resources. We recommend TLS 1.2 or later.
+ Set up API and user activity logging with AWS CloudTrail.
+ Use AWS encryption solutions, along with all default security controls within AWS services.
+ Use advanced managed security services such as Amazon Macie, which assists in discovering and securing sensitive data that is stored in Amazon S3.
+ If you require FIPS 140-2 validated cryptographic modules when accessing AWS through a command line interface or an API, use a FIPS endpoint. For more information about the available FIPS endpoints, see [Federal Information Processing Standard (FIPS) 140-2](http://aws.amazon.com/compliance/fips/).
We strongly recommend that you never put confidential or sensitive information, such as your customers' email addresses, into [tags](https://docs.aws.amazon.com/tag-editor/latest/userguide/security_data-protection.html) or free-form text fields such as a **Name** field. This includes when you work with AWS Transform or other AWS services using the AWS Management Console, API, AWS Command Line Interface (AWS CLI), or AWS SDKs. Any data that you enter into tags or free-form text fields used for names may be used for billing or diagnostic logs. For more information about how AWS Transform uses content, see [AWS Transform service improvement](service-improvement.md).
AWS Transform stores your questions, its responses, and additional context, such as console metadata and code in your IDE, to generate responses to your questions. For information about how data is encrypted, see [Data encryption in AWS Transform](data-encryption.md). For information about how AWS may use some questions that you ask AWS Transform and its responses to improve our services, see [AWS Transform service improvement](service-improvement.md).
In AWS Transform, your data is stored in the AWS Region where your AWS Transform profile was created.
With cross-inferencing, your requests to AWS Transform may be processed in a different Region within the geography where your data is stored. For more information, see [Cross-Region inference](cross-region-processing.md#cross-region-inference).
**Topics**
+ [Cross-region processing in AWS Transform](cross-region-processing.md)
+ [Data encryption in AWS Transform](data-encryption.md)
+ [AWS Transform service improvement](service-improvement.md)
# Cross-region processing in AWS Transform
The following sections describe how cross-region inference and cross-region calls are used to provide the AWS Transform service.
## Cross-region inference
AWS Transform is powered by Amazon Bedrock, and uses cross-region inference to distribute traffic across different AWS Regions to enhance large language model (LLM) inference performance and reliability. With cross-region inference, you get:
+ Increased throughput and resilience during high demand periods
+ Improved performance
+ Access to newly launched AWS Transform capabilities and features that rely on the most powerful LLMs hosted on Amazon Bedrock
Cross-region inference requests are kept within the AWS Regions that are part of the geography where the data originally resides. For example, a request made from a AWS Transform configuration in the US is kept within the AWS Regions in the US. Although cross-region inferencing doesn’t change where your data is stored, your requests and output results may move outside of the Region where the data originally resides. All data will be encrypted while transmitted across Amazon's secure network. There's no additional cost for using cross-region inference.
Cross region inference doesn’t affect where your data is stored. For information on where data is stored when you use AWS Transform, see [Data protection in AWS Transform](data-protection.md).
### Supported regions for AWS Transform cross-region inference
Certain requests you make to AWS Transform might require cross-region calls. The following table describes what Regions your requests may be routed to depending on the geography where the request originated.
| Source Region | Destination Regions |
| --- | --- |
| US East (N. Virginia) (us-east-1) | US East (N. Virginia) (us-east-1)US East (Ohio) (us-east-2)US West (Oregon) (us-west-2) |
| Europe (Frankfurt) (eu-central-1) | Europe (Frankfurt) (eu-central-1)Europe (Stockholm) (eu-north-1)Europe (Milan) (eu-south-1)Europe (Spain) (eu-south-2)Europe (Ireland) (eu-west-1)Europe (Paris) (eu-west-3) |
| Asia Pacific (Mumbai) (ap-south-1) | Asia Pacific (Tokyo) (ap-northeast-1)Asia Pacific (Seoul) (ap-northeast-2)Asia Pacific (Osaka) (ap-northeast-3)Asia Pacific (Mumbai) (ap-south-1)Asia Pacific (Hyderabad) (ap-south-2)Asia Pacific (Singapore) (ap-southeast-1)Asia Pacific (Sydney) (ap-southeast-2)Asia Pacific (Melbourne) (ap-southeast-4) |
| Asia Pacific (Tokyo) (ap-northeast-1) | Asia Pacific (Tokyo) (ap-northeast-1)Asia Pacific (Osaka) (ap-northeast-3) |
| Asia Pacific (Seoul) (ap-northeast-2) | Asia Pacific (Tokyo) (ap-northeast-1)Asia Pacific (Seoul) (ap-northeast-2)Asia Pacific (Osaka) (ap-northeast-3)Asia Pacific (Mumbai) (ap-south-1)Asia Pacific (Hyderabad) (ap-south-2)Asia Pacific (Singapore) (ap-southeast-1)Asia Pacific (Sydney) (ap-southeast-2)Asia Pacific (Melbourne) (ap-southeast-4) |
| Asia Pacific (Sydney) (ap-southeast-2) | Asia Pacific (Sydney) (ap-southeast-2)Asia Pacific (Melbourne) (ap-southeast-4) |
| Europe (London) (eu-west-2) | Europe (Frankfurt) (eu-central-1)Europe (Stockholm) (eu-north-1)Europe (Milan) (eu-south-1)Europe (Spain) (eu-south-2)Europe (Ireland) (eu-west-1)Europe (London) (eu-west-2)Europe (Paris) (eu-west-3) |
| Canada (Central) (ca-central-1) | Commercial AWS Regions \$1 Canada (Central) (ca-central-1) |
For a complete list of Regions where you can use AWS Transform, see [Supported Regions for AWS Transform](regions.md).
## Cross-Region knowledge
When you ask a general question about AWS Transform services, transformation workflows, or related AWS documentation, AWS Transform might make cross-region requests to US East (Virginia) (us-east-1) for US regions or Europe (Frankfurt) (eu-central-1) for all other regions to retrieve documentation and fulfill your request. For example, when you ask questions about how to use other AWS services such as Lambda, AWS Transform might make a cross-region call to retrieve relevant AWS documentation to respond to your question. The following table describes what Regions your requests may be routed to depending on the geography where the request originated.
| Source Region | Destination Regions |
| --- | --- |
| US East (N. Virginia) (us-east-1) | US East (N. Virginia) (us-east-1) |
| Europe (Frankfurt) (eu-central-1) | Europe (Frankfurt) (eu-central-1) |
| Europe (London) (eu-west-2) | Europe (Frankfurt) (eu-central-1) |
| Asia Pacific (Tokyo) (ap-northeast-1) | Europe (Frankfurt) (eu-central-1) |
| Asia Pacific (Sydney) (ap-southeast-2) | Europe (Frankfurt) (eu-central-1) |
| Asia Pacific (Seoul) (ap-northeast-2) | Europe (Frankfurt) (eu-central-1) |
| Asia Pacific (Mumbai) (ap-south-1) | Europe (Frankfurt) (eu-central-1) |
| Canada (Central) (ca-central-1) | Europe (Frankfurt) (eu-central-1) |
This setting is enabled by default. An account administrator can modify this setting. Disabling this feature results in the loss of access to features that require AWS Transform to retrieve knowledge from other regions. This might result in less accurate responses.
To disable cross-region calls made by AWS Transform:
1. When first setting up AWS Transform, navigate to the **Get Started** page and complete the configuration. For for an existing AWS Transform configuration, navigate to the **Settings** page.
1. Toggle **Enable cross-region calls to answer general AWS related questions** to the *off* position.
## AWS Transform for Windows cross-region inference
The following table shows the source Regions from which you can call the inference profile and the destination Regions to which the requests can be routed:
| Source Region | Inference Destination Regions |
| --- | --- |
| US East (N. Virginia) (us-east-1) | US East (N. Virginia) (us-east-1)US East (Ohio) (us-east-2)US West (Oregon) (us-west-2) |
| Europe (Frankfurt) (eu-central-1) | Europe (Frankfurt) (eu-central-1)Europe (Stockholm) (eu-north-1)Europe (Milan) (eu-south-1)Europe (Spain) (eu-south-2)Europe (Ireland) (eu-west-1)Europe (Paris) (eu-west-3) |
| Asia Pacific (Tokyo) (ap-northeast-1) | Asia Pacific (Tokyo) (ap-northeast-1)Asia Pacific (Osaka) (ap-northeast-3) |
| Asia Pacific (Sydney) (ap-southeast-2) | Asia Pacific (Sydney) (ap-southeast-2)Asia Pacific (Melbourne) (ap-southeast-4) |
| Asia Pacific (Seoul) (ap-northeast-2) | All commercial regions |
| Asia Pacific (Mumbai) (ap-south-1) | All commercial regions |
| Canada (Central) (ca-central-1) | All commercial regions |
## AWS Transform for Migrations cross-region inference
The following table shows the source Regions from which you can call the inference profile and the destination Regions to which the requests can be routed:
| Source Region | Inference Destination Regions |
| --- | --- |
| US East (N. Virginia) (us-east-1) | All commercial regions |
| Europe (Frankfurt) (eu-central-1) | All commercial regions |
| Europe (London) (eu-west-2) | All commercial regions |
| Asia Pacific (Tokyo) (ap-northeast-1) | Asia Pacific (Tokyo) (ap-northeast-1)Asia Pacific (Osaka) (ap-northeast-3) |
| Asia Pacific (Sydney) (ap-southeast-2) | Asia Pacific (Sydney) (ap-southeast-2)Asia Pacific (Melbourne) (ap-southeast-4) |
| Asia Pacific (Seoul) (ap-northeast-2) | All commercial regions |
| Asia Pacific (Mumbai) (ap-south-1) | All commercial regions |
| Canada (Central) (ca-central-1) | All commercial regions |
## AWS Transform Custom
AWS Transform custom is available in US East (N. Virginia) (us-east-1) and Europe (Frankfurt) (eu-central-1) and uses Amazon Bedrock geographic cross-region inference. This means that some of your calls might be routed to AWS Regions outside of your source region within the same geographic region. You can access AWS Transform custom features from workspaces deployed in supported regions.
| Source Region | Inference Destination Regions |
| --- | --- |
| US East (N. Virginia) (us-east-1) | US East (N. Virginia) (us-east-1)US East (Ohio) (us-east-2)US West (Oregon) (us-west-2) |
| Europe (Frankfurt) (eu-central-1) | Europe (Frankfurt) (eu-central-1)Europe (Stockholm) (eu-north-1)Europe (Milan) (eu-south-1)Europe (Spain) (eu-south-2)Europe (Ireland) (eu-west-1)Europe (Paris) (eu-west-3) |
| Europe (London) (eu-west-2) | n/a |
| Asia Pacific (Tokyo) (ap-northeast-1) | n/a |
| Asia Pacific (Sydney) (ap-southeast-2) | n/a |
| Asia Pacific (Seoul) (ap-northeast-2) | n/a |
| Asia Pacific (Mumbai) (ap-south-1) | n/a |
| Canada (Central) (ca-central-1) | n/a |
# Data encryption in AWS Transform
This topic provides information specific to AWS Transform about encryption in transit and encryption at rest.
AWS Transform provides encryption by default to protect sensitive customer data at rest with encryption using AWS owned keys.
## Encryption types
### Encryption in transit
Communication between customers and AWS Transform and between AWS Transform and its downstream dependencies is protected using TLS 1.2 or higher connections.
**Important**
When you [Connect a discovery account](https://docs.aws.amazon.com/transform-vmware-connect-discovery-account.html), AWS Transform creates an Amazon S3 bucket on your behalf in that account. That bucket does not have `SecureTransport` enabled by default. If you want the bucket policy to include secure transport you must update the policy. For more information, see [Security best practices for Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/security-best-practices.html).
### Encryption at rest
AWS Transform stores data at rest using Amazon DynamoDB and Amazon Simple Storage Service (Amazon S3). The data at rest is encrypted using AWS encryption solutions by default. AWS Transform encrypts your data with encryption using AWS owned keys from AWS Key Management Service (AWS KMS). You don’t have to take any action to protect the AWS managed keys that encrypt your data. For more information, see [AWS owned keys](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#aws-owned-cmk) in the *AWS Key Management Service Developer Guide*.
| Data type | AWS-owned key encryption | Customer managed key encryption (Optional) |
| --- | --- | --- |
| Customer bucket data Customer inputs and outputs such as code and documentation stored in an Amazon S3 bucket | Enabled | Enabled |
| Artifact Store Intermediate artifacts as part of code transformation stored in an S3 bucket | Enabled | Enabled |
| Job Objective The customer's intent for the job stored in an Amazon S3 bucket | Enabled | Enabled |
| Chat messages Messages between the customer and AWS Transform stored in an Amazon S3 bucket | Enabled | Enabled |
| Chat Knowledge Base Indexed data relevant to AWS Transform and customer chat stored in Amazon OpenSearch and processed via AWS Bedrock | Enabled | Enabled |
Note: The customer can register their own Customer Managed Key (CMK) to be used for encrypting all of the above data types.
Customer managed keys are KMS keys in your AWS account that you create, own, and manage to directly control access to your data by controlling access to the KMS key. Only symmetric keys are supported. For information on creating your own KMS key, see [Creating keys](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html) in the *AWS Key Management Service Developer Guide*.
When you use a customer managed key, AWS Transform makes use of KMS grants, allowing authorized users, roles, or applications to use a KMS key. When an AWS Transform administrator chooses to use a customer managed key for encryption during configuration, a grant is created for them. This grant is what allows the end user to use the encryption key for data encryption at rest. For more information on grants, see [Grants in AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/grants.html).
#### AWS Owned Keys (Default)
**Note**
**AWS owned keys** — AWS Transform uses these keys by default to automatically encrypt personally identifiable data. You can't view, manage, or use AWS owned keys, or audit their use. However, you don't have to take any action or change any programs to protect the keys that encrypt your data. For more information, see AWS owned keys in the AWSKey Management Service Developer Guide.
Encryption of data at rest by default helps reduce the operational overhead and complexity involved in protecting sensitive data. At the same time, it enables you to build secure applications that meet strict encryption compliance and regulatory requirements.
While you can't disable this layer of encryption or select an alternate encryption type, you can add a second layer of encryption over the existing AWS owned encryption keys by choosing a customer managed key when you create your transformation:
#### Customer managed keys (Optional)
**Customer managed keys **— AWS Transform supports the use of a symmetric customer managed key that you create, own, and manage to add a second layer of encryption over the existing encryption using AWS owned keys. Because you have full control of this layer of encryption, you can perform such tasks as:
+ Establishing and maintaining key policies
+ Establishing and maintaining IAM policies and grants
+ Enabling and disabling key policies
+ Rotating key cryptographic material
+ Adding tags
+ Creating key aliases
+ Rotating key cryptographic material
+ Adding tags
+ Creating key aliases
+ Scheduling keys for deletion
+ For more information, see [customer managed key](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#customer-cmk) in the *AWS Key Management Service Developer Guide*.
**Note**
AWS Transform automatically enables encryption at rest using AWS owned keys to protect personally identifiable data at no charge. However, AWS KMS charges apply for using a customer managed key. For more information about pricing, see the [AWS Key Management Service pricing](https://docs.aws.amazon.com/kms/pricing/).
For more information on AWS KMS, see [What is AWS Key Management Service?](https://docs.aws.amazon.com/kms/latest/developerguide/overview.html)
### How AWS Transform uses grants in AWS Key Management Service
AWS Transform requires a grant to use your customer managed key.
When you create a [Resource Name] encrypted with a customer managed key, AWS Transform creates a grant on your behalf by sending a CreateGrant request to AWS Key Management Service. Grants in AWS Key Management Service are used to give AWS Transform access to a KMS key in a customer account.
AWS Transform requires the grant to use your customer managed key for the following internal operations:
+ Send [KMS API] requests to AWS KMS to verify that the symmetric customer managed KMS key ID entered when creating [Resource Name] is valid.
+ Send [KMS API] requests to AWS KMS to generate data keys encrypted by your customer managed key.
+ Send [KMS API] requests to AWS KMS to decrypt the encrypted data keys so that they can be used to encrypt your data.
You can revoke access to the grant, or remove the service's access to the customer managed key at any time. If you do, AWS Transform won't be able to access any of the data encrypted by the customer managed key, which affects operations that are dependent on that data. For example, if you attempt to get [Resource Name] from an encrypted [Resource Name]that AWS Transform can't access, then the operation would return an AccessDeniedException error.
## Create a customer managed key
You can create a symmetric customer managed key by using the AWS Management Console, or the AWS Key Management Service APIs.
To create a symmetric customer managed key, follow the steps for [Creating symmetric customer managed key](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html#create-symmetric-cmk) in the *AWS Key Management Service Developer Guide*.
To use your customer managed key with your AWS Transform resources, the following API operations must be permitted in the key policy:
kms:CreateGrant – Adds a grant to a customer managed key. Grants control access to a specified KMS key, which allows access to grant operations AWS Transform requires. For more information about [Using Grants](https://docs.aws.amazon.com/), see the *AWS Key Management Service Developer Guide*.
This allows AWS Transform to do the following:
+ Call [KMS API ([GenerateDataKeyWithoutPlainText](https://docs.aws.amazon.com/kms/latest/APIReference/API_GenerateDataKeyWithoutPlaintext)/[GenerateDatakey](https://docs.aws.amazon.com//kms/latest/APIReference/API_GenerateDataKey)) to generate an encrypted data key and store it, because the data key isn't immediately used to encrypt.
+ Call [KMS API ([Decrypt](https://docs.aws.amazon.com/kms/latest/APIReference/API_Decrypt))] to use the stored encrypted data key to access encrypted data.
+ Set up a retiring principal to allow the service to [RetireGrant](https://docs.aws.amazon.com//kms/latest/APIReference/API_RetireGrant).
+ [kms:DescribeKey](https://docs.aws.amazon.com/kms/latest/APIReference/API_DescribeKey) – Provides the customer managed key details to allow [Service Name] to validate the key.
### Encryption for SQL modernization
During the [SQL Server modernization](sql-server-modernization.md) process AWS Transform creates resources in your account, such as EC2 instances, ECS clusters, ECR images and S3 objects. You have the option of providing a customer managed key to encrypt data in your account. You will need to tag your KMS key with key **CreatedFor** and value **AWSTransform** . This example policy lists the minimum permissions required in your key policy if you don’t have a default key policy. If you have a default key policy, you still need to manually update the KMS key in addition to your default key policy to allow ECS to use your key.
```
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:root"
},
"Action": [
"kms:Decrypt",
"kms:GenerateDataKey"
],
"Resource": "*",
"Condition": {
"StringLike": {
"kms:ViaService": "s3.*.amazonaws.com",
"kms:EncryptionContext:aws-transform": "*"
},
"ArnLike": {
"aws:PrincipalArn": "arn:aws:iam::*:role/*AWSTransform*"
}
}
},
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:root"
},
"Action": [
"kms:Decrypt",
"kms:GenerateDataKey",
"kms:GenerateDataKeyWithoutPlaintext",
"kms:ReEncrypt*"
],
"Resource": "*",
"Condition": {
"StringLike": {
"kms:ViaService": "ec2.*.amazonaws.com"
},
"ArnLike": {
"aws:PrincipalArn": "arn:aws:iam::*:role/*AWSTransform*"
}
}
},
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:root"
},
"Action": "kms:CreateGrant",
"Resource": "*",
"Condition": {
"StringLike": {
"kms:ViaService": [
"ec2.*.amazonaws.com",
"ecr.*.amazonaws.com"
]
},
"Bool": {
"kms:GrantIsForAWSResource": "true"
},
"ArnLike": {
"aws:PrincipalArn": "arn:aws:iam::*:role/*AWSTransform*"
}
}
},
{
"Effect": "Allow",
"Principal": {
"Service": "fargate.amazonaws.com"
},
"Action": "kms:GenerateDataKeyWithoutPlaintext",
"Resource": "*",
"Condition": {
"StringLike": {
"kms:EncryptionContext:aws:ecs:clusterName": "AWSTransform*"
}
}
},
{
"Effect": "Allow",
"Principal": {
"Service": "fargate.amazonaws.com"
},
"Action": "kms:CreateGrant",
"Resource": "*",
"Condition": {
"StringLike": {
"kms:EncryptionContext:aws:ecs:clusterName": "AWSTransform*"
},
"ForAllValues:StringEquals": {
"kms:GrantOperations": "Decrypt"
}
}
}
]
```
### Encryption for database migration
During the database migration process, AWS Transform uses AWS Database Migration Service (DMS) to migrate your database data. You can optionally provide a customer managed key to encrypt your database data during migration.
The following policy contains three statements. The first statement grants root account permissions for the AWS KMS key. The second statement allows the connector role to validate the key during discovery. The third statement allows the connector role to use the key for DMS operations.
```
"Statement": [
{
"Sid": "Enable IAM User Permissions",
"Effect": "Allow",
"Principal": { "AWS": "arn:aws:iam::111122223333:root" },
"Action": "kms:*",
"Resource": "*"
},
{
"Sid": "Allow connector role to validate key during discovery",
"Effect": "Allow",
"Principal": { "AWS": "connector-role-arn" },
"Action": "kms:DescribeKey",
"Resource": "*"
},
{
"Sid": "Allow connector role to use key via DMS",
"Effect": "Allow",
"Principal": { "AWS": "connector-role-arn" },
"Action": [
"kms:CreateGrant",
"kms:Decrypt",
"kms:DescribeKey",
"kms:Encrypt",
"kms:GenerateDataKey*",
"kms:ReEncrypt*"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"kms:ViaService": "dms.us-east-1.amazonaws.com"
}
}
}
]
```
## Using customer managed KMS keys
After creating a customer managed KMS key, an AWS Transform administrator must provide the key in the AWS Transform console to use it to encrypt data.
To set up a customer managed key to encrypt data in AWS Transform, administrators need permissions to use AWS KMS.
To use functionality that is encrypted with a customer managed key, users need permissions to allow AWS Transform to access the customer managed key.
If you see an error related to KMS grants while using AWS Transform, you likely need to update your permissions to allow AWS Transform to create grants. To automatically configure the needed permissions, go to the AWS Transform console and choose **Update permissions** in the banner at the top of the page. In order to allow AWS Transform to create grants, you need to update the permissions on the AWS Transform console page.
## Allow AWS Transform access to customer managed keys
The following example policy statement grants users permissions to access features encrypted with a customer managed key by allowing AWS Transform access to the key. This policy is required to use AWS Transform if an administrator has set up a customer managed key for encryption.
**Note**
This information does not apply to SQL Server modernization deployment workflow using CMK.
```
"Statement": [
{
"Sid": "QKMSDecryptGenerateDataKeyPermissions",
"Effect": "Allow",
"Action": [
"kms:Decrypt",
"kms:GenerateDataKey",
"kms:GenerateDataKeyWithoutPlaintext",
"kms:ReEncryptFrom",
"kms:ReEncryptTo"
],
"Resource": [
"arn:aws:kms:arn:aws::111122223333:key/[[key_id]]"
],
"Condition": {
"StringLike": {
"kms:ViaService": [
"q.us-east-1.amazonaws.com"
]
}
}
}
]
```
# AWS Transform service improvement
To help AWS Transform provide the most relevant information, we may use certain content from AWS Transform, such as questions that you ask AWS Transform and its responses, for service improvement. This page explains what content we use and how to opt out.
## AWS Transform content used for service improvement
We may use certain content from AWS Transform for service improvement. AWS Transform may use this content, for example, to provide better responses to common questions, fix AWS Transform operational issues, for de-bugging, or for model training.
Content that AWS may use for service improvement includes, for example, your questions to AWS Transform and the responses and code that AWS Transform generates.
## How to opt out
The way you opt out of AWS Transform using content for service improvement depends on the environment where you use AWS Transform.
For AWS Transform configure an AI services opt-out policy in AWS Organizations. For more information, see [AI services opt-out policies](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_ai-opt-out.html) in the *AWS Organizations User Guide*.
To opt out of sharing your content in Visual Studio IDE, use the following procedure.
Go to **Tools** -> **Options** -> **AWS Toolkit** -> **Amazon Q**
Toggle **Share Amazon Q Content with AWS** to **True** or **False**.
To opt out of sharing your telemetry data in the AWS Toolkit for Visual Studio, use this procedure:
1. Under **Tools**, choose **Options**.
1. In the **Options** pane, choose **AWS Toolkit**, and then choose **General**.
1. Deselect **Allow AWS Toolkit to collect usage information**.