# Data protection
The AWS [shared responsibility model](https://aws.amazon.com/compliance/shared-responsibility-model/) applies to data protection in Amazon Bedrock. 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](https://aws.amazon.com/compliance/data-privacy-faq/). For information about data protection in Europe, see the [AWS Shared Responsibility Model and GDPR](https://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 IAM Identity Center or 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 require TLS 1.2 and recommend TLS 1.3.
+ Set up API and user activity logging with AWS CloudTrail. For information about using CloudTrail trails to capture AWS activities, see [Working with CloudTrail trails](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-trails.html) in the *AWS CloudTrail User Guide*.
+ 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-3 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-3](https://aws.amazon.com/compliance/fips/).
We strongly recommend that you never put confidential or sensitive information, such as your customers' email addresses, into tags or free-form text fields such as a **Name** field. This includes when you work with Amazon Bedrock or other AWS services using the console, API, 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. If you provide a URL to an external server, we strongly recommend that you do not include credentials information in the URL to validate your request to that server.
For more information on how your data is processed for abuse detection, see [Amazon Bedrock abuse detection](https://docs.aws.amazon.com/bedrock/latest/userguide/abuse-detection.html).
Amazon Bedrock has a concept of a Model Deployment Account—in each AWS Region where Amazon Bedrock is available, there is one such deployment account per model provider. These accounts are owned and operated by the Amazon Bedrock service team. Model providers don't have any access to those accounts. After delivery of a model from a model provider to AWS, Amazon Bedrock will perform a deep copy of a model provider’s inference and training software into those accounts for deployment. Because the model providers don't have access to those accounts, they don't have access to Amazon Bedrock logs or to customer prompts and completions.
**Topics**
+ [Data encryption](data-encryption.md)
+ [Protect your data using Amazon VPC and AWS PrivateLink](usingVPC.md)
# Data encryption
Amazon Bedrock uses encryption to protect data at rest and data in transit.
**Encryption in transit**
Within AWS, all inter-network data in transit supports TLS 1.2 encryption.
Requests to the Amazon Bedrock API and console are made over a secure (SSL) connection. You pass AWS Identity and Access Management (IAM) roles to Amazon Bedrock to provide permissions to access resources on your behalf for training and deployment.
**Encryption at rest**
Amazon Bedrock provides [Encryption of custom models](encryption-custom-job.md) at rest.
## Key management
Use the AWS Key Management Service to manage the keys that you use to encrypt your resources. For more information, see [AWS Key Management Service concepts](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#master_keys). You can encrypt the following resources with a KMS key.
+ Through Amazon Bedrock
+ Model customization jobs and their output custom models – During job creation in the console or by specifying the `customModelKmsKeyId` field in the [CreateModelCustomizationJob](https://docs.aws.amazon.com/bedrock/latest/APIReference/API_CreateModelCustomizationJob.html) API call.
+ Agents – During agent creation in the console or by specifying the `customerEncryptionKeyArn` field in the [CreateAgent](https://docs.aws.amazon.com/bedrock/latest/APIReference/API_agent_CreateAgent.html) API call.
+ Data source ingestion jobs for knowledge bases – During knowledge base creation in the console or by specifying the `kmsKeyArn` field in the [CreateDataSource](https://docs.aws.amazon.com/bedrock/latest/APIReference/API_agent_CreateDataSource.html) or [UpdateDataSource](https://docs.aws.amazon.com/bedrock/latest/APIReference/API_agent_UpdateDataSource.html) API call.
+ Vector stores in Amazon OpenSearch Service – During vector store creation. For more information, see [Creating, listing, and deleting Amazon OpenSearch Service collections](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/serverless-manage.html) and [Encryption of data at rest for Amazon OpenSearch Service](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/encryption-at-rest.html).
+ Model evaluations jobs – When you create a model evaluation job in console or by specify a key ARN in ` customerEncryptionKeyId` in the [CreateEvaluationJob ](https://docs.aws.amazon.com/bedrock/latest/APIReference/API_CreateEvaluationJob.html) API call.
+ Through Amazon S3 – For more information, see [Using server-side encryption with AWS KMS keys (SSE-KMS).](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingKMSEncryption.html)
+ Training, validation, and output data for model customization
+ Data sources for knowledge bases
+ Through AWS Secrets Manager – For more information, see [Secret encryption and decryption in AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/security-encryption.html)
+ Vector stores for third-party models
After you encrypt a resource, you can find the ARN of the KMS key by selecting a resource and viewing its **Details** in the console or by using the following `Get` API calls.
+ [GetModelCustomizationJob](https://docs.aws.amazon.com/bedrock/latest/APIReference/API_GetModelCustomizationJob.html)
+ [GetAgent](https://docs.aws.amazon.com/bedrock/latest/APIReference/API_agent_GetAgent.html)
+ [GetIngestionJob](https://docs.aws.amazon.com/bedrock/latest/APIReference/API_agent_GetIngestionJob.html)
# Encryption of custom models
Amazon Bedrock uses your training data with the [CreateModelCustomizationJob](https://docs.aws.amazon.com/bedrock/latest/APIReference/API_CreateModelCustomizationJob.html) action, or with the [console](model-customization-submit.md), to create a custom model which is a fine tuned version of an Amazon Bedrock foundational model. Your custom models are managed and stored by AWS.
Amazon Bedrock uses the fine tuning data you provide only for fine tuning an Amazon Bedrock foundation model. Amazon Bedrock doesn't use fine tuning data for any other purpose. Your training data isn't used to train the base Titan models or distributed to third parties. Other usage data, such as usage timestamps, logged account IDs, and other information logged by the service, is also not used to train the models.
None of the training or validation data you provide for fine tuning is stored by Amazon Bedrock, once the fine tuning job completes.
Note that fine-tuned models can replay some of the fine tuning data while generating completions. If your app should not expose fine tuning data in any form, then you should first filter out confidential data from your training data. If you already created a customized model using confidential data by mistake, you can delete that custom model, filter out confidential information from the training data, and then create a new model.
For encrypting custom models (including copied models), Amazon Bedrock offers you two options:
1. **AWS owned keys** – By default, Amazon Bedrock encrypts custom models with AWS owned keys. 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](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#aws-owned-cmk) in the *AWS Key Management Service Developer Guide*.
1. **Customer managed keys** – You can choose to encrypt custom models with customer managed keys that you manage yourself. For more information about AWS KMS keys, see [Customer managed keys](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#customer-cmk) in the *AWS Key Management Service Developer Guide*.
**Note**
Amazon Bedrock automatically enables encryption at rest using AWS owned keys at no charge. If you use a customer managed key, AWS KMS charges apply. For more information about pricing, see [AWS Key Management Service pricing](https://aws.amazon.com/kms/pricing/).
For more information about AWS KMS, see the [AWS Key Management Service Developer Guide](https://docs.aws.amazon.com/kms/latest/developerguide/).
**Topics**
+ [How Amazon Bedrock uses grants in AWS KMS](#encryption-br-grants)
+ [Understand how to create a customer managed key and how to attach a key policy to it](#encryption-key-policy)
+ [Permissions and key policies for custom and copied models](#encryption-cm-statements)
+ [Monitor your encryption keys for the Amazon Bedrock service](#encryption-monitor-key)
+ [Encryption of training, validation, and output data](#encryption-custom-job-data)
## How Amazon Bedrock uses grants in AWS KMS
If you specify a customer managed key to encrypt a custom model for a model customization or model copy job, Amazon Bedrock creates a **primary** KMS [grant](https://docs.aws.amazon.com/kms/latest/developerguide/grants.html) associated with the custom model on your behalf by sending a [CreateGrant](https://docs.aws.amazon.com/kms/latest/APIReference/API_CreateGrant.html) request to AWS KMS. This grant allows Amazon Bedrock to access and use your customer managed key. Grants in AWS KMS are used to give Amazon Bedrock access to a KMS key in a customer’s account.
Amazon Bedrock requires the primary grant to use your customer managed key for the following internal operations:
+ Send [DescribeKey](https://docs.aws.amazon.com/kms/latest/APIReference/API_DescribeKey.html) requests to AWS KMS to verify that the symmetric customer managed KMS key ID you entered when creating the job is valid.
+ Send [GenerateDataKey](https://docs.aws.amazon.com/kms/latest/APIReference/API_GenerateDataKey.html) and [Decrypt](https://docs.aws.amazon.com/kms/latest/APIReference/API_Decrypt.html) requests to AWS KMS to generate data keys encrypted by your customer managed key and decrypt the encrypted data keys so that they can be used to encrypt the model artifacts.
+ Send [CreateGrant](https://docs.aws.amazon.com/kms/latest/APIReference/API_CreateGrant.html) requests to AWS KMS to create scoped down secondary grants with a subset of the above operations (`DescribeKey`, `GenerateDataKey`, `Decrypt`), for the asynchronous execution of model customization, model copy, or Provisioned Throughput creation.
+ Amazon Bedrock specifies a retiring principal during the creation of grants, so the service can send a [RetireGrant](https://docs.aws.amazon.com/kms/latest/APIReference/API_RetireGrant.html) request.
You have full access to your customer managed AWS KMS key. You can revoke access to the grant by following the steps at [Retiring and revoking grants](https://docs.aws.amazon.com/kms/latest/developerguide/grant-manage.html#grant-delete) in the [AWS Key Management Service Developer Guide](https://docs.aws.amazon.com/kms/latest/developerguide/) or remove the service’s access to your customer managed key at any time by modifying the [key policy](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html). If you do so, Amazon Bedrock won’t be able to access the custom model encrypted by your key.
### Life cycle of primary and secondary grants for custom models
+ **Primary grants** have a long lifespan and remain active as long as the associated custom models are still in use. When a custom model is deleted, the corresponding primary grant is automatically retired.
+ **Secondary grants** are short-lived. They are automatically retired as soon as the operation that Amazon Bedrock performs on behalf of the customers is completed. For example, once a model copy job is finished, the secondary grant that allowed Amazon Bedrock to encrypt the copied custom model will be retired immediately.
## Understand how to create a customer managed key and how to attach a key policy to it
To encrypt an AWS resource with a key that you create and manage, you perform the following general steps:
1. (Prerequisite) Ensure that your IAM role has permissions for the [CreateKey](https://docs.aws.amazon.com/kms/latest/APIReference/API_CreateKey.html) action.
1. Follow the steps at [Creating keys](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html) to create a customer managed key by using the AWS KMS console or the [CreateKey](https://docs.aws.amazon.com/kms/latest/APIReference/API_CreateKey.html) operation.
1. Creation of the key returns an `Arn` for the key that you can use for operations that require using the key (for example, when [submitting a model customization job](model-customization-submit.md) or [running model inference](inference-invoke.md)).
1. Create and attach a key policy to the key with the required permissions. To create a key policy, follow the steps at [Creating a key policy](https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-overview.html) in the AWS Key Management Service Developer Guide.
## Permissions and key policies for custom and copied models
After you create a KMS key, you attach a key policy to it. Key policies are [resource-based policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_identity-vs-resource.html) that you attach to your customer managed key to control access to it. Every customer managed key must have exactly one key policy, which contains statements that determine who can use the key and how they can use it. You can specify a key policy when you create your customer managed key. You can modify the key policy at any time, but there might be a brief delay before the change becomes available throughout AWS KMS. For more information, see [Managing access to customer managed keys](https://docs.aws.amazon.com/kms/latest/developerguide/control-access-overview.html#managing-access) in the [AWS Key Management Service Developer Guide](https://docs.aws.amazon.com/kms/latest/developerguide/).
The following KMS [actions](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awskeymanagementservice.html#awskeymanagementservice-actions-as-permissions) are used for keys that encrypt custom and copied models:
1. [kms:CreateGrant](https://docs.aws.amazon.com/kms/latest/APIReference/API_CreateGrant.html) – Creates a grant for a customer managed key by allowing the Amazon Bedrock service principal access to the specified KMS key through [grant operations](https://docs.aws.amazon.com/kms/latest/developerguide/grants.html#terms-grant-operations). For more information about grants, see [Grants in AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/grants.html) in the [AWS Key Management Service Developer Guide](https://docs.aws.amazon.com/kms/latest/developerguide/).
**Note**
Amazon Bedrock also sets up a retiring principal and automatically retires the grant after it is no longer required.
1. [kms:DescribeKey](https://docs.aws.amazon.com/kms/latest/APIReference/API_DescribeKey.html) – Provides the customer managed key details to allow Amazon Bedrock to validate the key.
1. [kms:GenerateDataKey](https://docs.aws.amazon.com/kms/latest/APIReference/API_GenerateDataKey.html) – Provides the customer managed key details to allow Amazon Bedrock to validate user access. Amazon Bedrock stores generated ciphertext alongside the custom model to be used as an additional validation check against custom model users.
1. [kms:Decrypt](https://docs.aws.amazon.com/kms/latest/APIReference/API_Decrypt.html) – Decrypts the stored ciphertext to validate that the role has proper access to the KMS key that encrypts the custom model.
As a best security practice, we recommend that you include the [kms:ViaService](https://docs.aws.amazon.com/kms/latest/developerguide/conditions-kms.html#conditions-kms-via-service) condition key to limit access to the key to the Amazon Bedrock service.
Although you can only attach one key policy to a key, you can attach multiple statements to the key policy by adding staements to the list in the `Statement` field of the policy.
The following statements are relevant to encrypting custom and copied models:
### Encrypt a model
To use your customer managed key to encrypt a custom or copied model, include the following statement in a key policy to allow encryption of a model. In the `Principal` field, add accounts that you want to allow to encrypt and decrypt the key to the list that the `AWS` subfield maps to. If you use the `kms:ViaService` condition key, you can add a line for each Region, or use *\$1* in place of *\$1\$1region\$1* to allow all Regions that support Amazon Bedrock.
```
{
"Sid": "PermissionsEncryptDecryptModel",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::${account-id}:role/${role}"
]
},
"Action": [
"kms:Decrypt",
"kms:GenerateDataKey",
"kms:DescribeKey",
"kms:CreateGrant"
],
"Resource": "*",
"Condition": {
"StringLike": {
"kms:ViaService": [
"bedrock.${region}.amazonaws.com"
]
}
}
}
```
### Allow access to an encrypted model
To allow access to a model that has been encrypted with a KMS key, include the following statement in a key policy to allow decryption of the key. In the `Principal` field, add accounts that you want to allow to decrypt the key to the list that the `AWS` subfield maps to. If you use the `kms:ViaService` condition key, you can add a line for each Region, or use *\$1* in place of *\$1\$1region\$1* to allow all Regions that support Amazon Bedrock.
```
{
"Sid": "PermissionsDecryptModel",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::${account-id}:role/${role}"
]
},
"Action": [
"kms:Decrypt"
],
"Resource": "*",
"Condition": {
"StringLike": {
"kms:ViaService": [
"bedrock.${region}.amazonaws.com"
]
}
}
}
```
To learn about the key policies that you need to create, expand the section that corresponds to your use case:
### Set up key permissions for encrypting custom models
If you plan to encrypt a model that you customize with a KMS key, the key policy for the key will depend on your use case. Expand the section that corresponds to your use case:
#### The roles that will customize the model and the roles that will invoke the model are the same
If the roles that will invoke the custom model are the same as the roles that will customize the model, you only need the statement from [Encrypt a model](#encryption-key-policy-encrypt). In the `Principal` field in the following policy template, add accounts that you want to allow to customize and invoke the custom model to the list that the `AWS` subfield maps to.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Id": "PermissionsCustomModelKey",
"Statement": [
{
"Sid": "PermissionsEncryptCustomModel",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::111122223333:role/Role"
]
},
"Action": [
"kms:Decrypt",
"kms:GenerateDataKey",
"kms:DescribeKey",
"kms:CreateGrant"
],
"Resource": "*",
"Condition": {
"StringLike": {
"kms:ViaService": [
"bedrock.us-east-1.amazonaws.com"
]
}
}
}
]
}
```
------
#### The roles that will customize the model and the roles that will invoke the model are different
If the roles that will invoke the custom model are different from the role that will customize the model, you need both the statement from [Encrypt a model](#encryption-key-policy-encrypt) and [Allow access to an encrypted model](#encryption-key-policy-decrypt). Modify the statements in the following policy template as follows:
1. The first statement allows encryption and decryption of the key. In the `Principal` field, add accounts that you want to allow to customize the custom model to the list that the `AWS` subfield maps to.
1. The second statement allows only decryption of the key. In the `Principal` field, add accounts that you want to only allow to invoke the custom model to the list that the `AWS` subfield maps to.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Id": "PermissionsCustomModelKey",
"Statement": [
{
"Sid": "PermissionsEncryptCustomModel",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::111122223333:role/Role"
]
},
"Action": [
"kms:Decrypt",
"kms:GenerateDataKey",
"kms:DescribeKey",
"kms:CreateGrant"
],
"Resource": "*",
"Condition": {
"StringLike": {
"kms:ViaService": [
"bedrock.us-east-1.amazonaws.com"
]
}
}
},
{
"Sid": "PermissionsDecryptModel",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::111122223333:role/Role"
]
},
"Action": [
"kms:Decrypt"
],
"Resource": "*",
"Condition": {
"StringLike": {
"kms:ViaService": [
"bedrock.us-east-1.amazonaws.com"
]
}
}
}
]
}
```
------
### Set up key permissions for copying custom models
When you copy a model that you own or that has been shared with you, you might have to manage up to two key policies:
#### Key policy for key that will encrypt a copied model
If you plan to use a KMS key to encrypt a copied model, the key policy for the key will depend on your use case. Expand the section that corresponds to your use case:
##### The roles that will copy the model and the roles that will invoke the model are the same
If the roles that will invoke the copied model are the same as the roles that will create the model copy, you only need the statement from [Encrypt a model](#encryption-key-policy-encrypt). In the `Principal` field in the following policy template, add accounts that you want to allow to copy and invoke the copied model to the list that the `AWS` subfield maps to:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Id": "PermissionsCopiedModelKey",
"Statement": [
{
"Sid": "PermissionsEncryptCopiedModel",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::111122223333:role/Role"
]
},
"Action": [
"kms:Decrypt",
"kms:GenerateDataKey",
"kms:DescribeKey",
"kms:CreateGrant"
],
"Resource": "*",
"Condition": {
"StringLike": {
"kms:ViaService": [
"bedrock.us-east-1.amazonaws.com"
]
}
}
}
]
}
```
------
##### The roles that will copy the model and the roles that will invoke the model are different
If the roles that will invoke the copied model are different from the role that will create the model copy, you need both the statement from [Encrypt a model](#encryption-key-policy-encrypt) and [Allow access to an encrypted model](#encryption-key-policy-decrypt). Modify the statements in the following policy template as follows:
1. The first statement allows encryption and decryption of the key. In the `Principal` field, add accounts that you want to allow to create the copied model to the list that the `AWS` subfield maps to.
1. The second statement allows only decryption of the key. In the `Principal` field, add accounts that you want to only allow to invoke the copied model to the list that the `AWS` subfield maps to.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Id": "PermissionsCopiedModelKey",
"Statement": [
{
"Sid": "PermissionsEncryptCopiedModel",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::111122223333:role/Role"
]
},
"Action": [
"kms:Decrypt",
"kms:GenerateDataKey",
"kms:DescribeKey",
"kms:CreateGrant"
],
"Resource": "*",
"Condition": {
"StringLike": {
"kms:ViaService": [
"bedrock.us-east-1.amazonaws.com"
]
}
}
},
{
"Sid": "PermissionsDecryptCopiedModel",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::111122223333:role/Role"
]
},
"Action": [
"kms:Decrypt"
],
"Resource": "*",
"Condition": {
"StringLike": {
"kms:ViaService": [
"bedrock.us-east-1.amazonaws.com"
]
}
}
}
]
}
```
------
#### Key policy for key that encrypts the source model to be copied
If the source model that you will copy is encrypted with a KMS key, attach the statement from [Allow access to an encrypted model](#encryption-key-policy-decrypt) to the key policy for the key that encrypts the source model. This stamtement allows the model copy role to decrypt the key that encrypts the source model. In the `Principal` field in the following policy template, add accounts that you want to allow to copy the source model to the list that the `AWS` subfield maps to:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Id": "PermissionsSourceModelKey",
"Statement": [
{
"Sid": "PermissionsDecryptModel",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::111122223333:role/Role"
]
},
"Action": [
"kms:Decrypt"
],
"Resource": "*",
"Condition": {
"StringLike": {
"kms:ViaService": [
"bedrock.us-east-1.amazonaws.com"
]
}
}
}
]
}
```
------
## Monitor your encryption keys for the Amazon Bedrock service
When you use an AWS KMS customer managed key with your Amazon Bedrock resources, you can use [AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html) or [Amazon CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html) to track requests that Amazon Bedrock sends to AWS KMS.
The following is an example AWS CloudTrail event for [CreateGrant](https://docs.aws.amazon.com/kms/latest/APIReference/API_CreateGrant.html) to monitor KMS operations called by Amazon Bedrock to create a primary grant:
```
{
"eventVersion": "1.09",
"userIdentity": {
"type": "AssumedRole",
"principalId": "AROAIGDTESTANDEXAMPLE:SampleUser01",
"arn": "arn:aws:sts::111122223333:assumed-role/RoleForModelCopy/SampleUser01",
"accountId": "111122223333",
"accessKeyId": "EXAMPLE",
"sessionContext": {
"sessionIssuer": {
"type": "Role",
"principalId": "AROAIGDTESTANDEXAMPLE",
"arn": "arn:aws:iam::111122223333:role/RoleForModelCopy",
"accountId": "111122223333",
"userName": "RoleForModelCopy"
},
"attributes": {
"creationDate": "2024-05-07T21:46:28Z",
"mfaAuthenticated": "false"
}
},
"invokedBy": "bedrock.amazonaws.com"
},
"eventTime": "2024-05-07T21:49:44Z",
"eventSource": "kms.amazonaws.com",
"eventName": "CreateGrant",
"awsRegion": "us-east-1",
"sourceIPAddress": "bedrock.amazonaws.com",
"userAgent": "bedrock.amazonaws.com",
"requestParameters": {
"granteePrincipal": "bedrock.amazonaws.com",
"retiringPrincipal": "bedrock.amazonaws.com",
"keyId": "arn:aws:kms:us-east-1:111122223333:key/1234abcd-12ab-34cd-56ef-123456SAMPLE",
"operations": [
"Decrypt",
"CreateGrant",
"GenerateDataKey",
"DescribeKey"
]
},
"responseElements": {
"grantId": "0ab0ac0d0b000f00ea00cc0a0e00fc00bce000c000f0000000c0bc0a0000aaafSAMPLE",
"keyId": "arn:aws:kms:us-east-1:111122223333:key/1234abcd-12ab-34cd-56ef-123456SAMPLE"
},
"requestID": "ff000af-00eb-00ce-0e00-ea000fb0fba0SAMPLE",
"eventID": "ff000af-00eb-00ce-0e00-ea000fb0fba0SAMPLE",
"readOnly": false,
"resources": [
{
"accountId": "111122223333",
"type": "AWS::KMS::Key",
"ARN": "arn:aws:kms:us-east-1:111122223333:key/1234abcd-12ab-34cd-56ef-123456SAMPLE"
}
],
"eventType": "AwsApiCall",
"managementEvent": true,
"recipientAccountId": "111122223333",
"eventCategory": "Management"
}
```
## Encryption of training, validation, and output data
When you use Amazon Bedrock to run a model customization job, you store the input files in your Amazon S3 bucket. When the job completes, Amazon Bedrock stores the output metrics files in the S3 bucket that you specifed when creating the job and the resulting custom model artifacts in an S3 bucket controlled by AWS.
The output files are encrypted with the encryption configurations of the S3 bucket. These are encrypted either with [SSE-S3 server-side encryption](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingServerSideEncryption.html) or with [AWS KMS SSE-KMS encryption](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingKMSEncryption.html), depending on how you set up the S3 bucket.
# Encryption of imported custom models
Amazon Bedrock supports creating custom models through two methods that both use the same encryption approach. Your custom models are managed and stored by AWS:
+ **Custom model import jobs** — For importing customized open-source foundation models (such as Mistral AI or Llama models).
+ **Create custom model** — For importing Amazon Nova models that you customized in SageMaker AI.
For encryption of your custom models, Amazon Bedrock provides the following options:
+ **AWS owned keys** – By default, Amazon Bedrock encrypts imported custom models with AWS owned keys. 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](https://docs.aws.amazon.com//kms/latest/developerguide/concepts.html#aws-owned-cmk) in the *AWS Key Management Service Developer Guide*.
+ **Customer managed keys (CMK)** – You can choose to add a second layer of encryption over the existing AWS owned encryption keys by choosing a customer managed key(CMK). You create, own, and manage your customer managed keys.
Because you have full control of this layer of encryption, in it you can perform the following tasks:
+ Establish and maintain key policies
+ Establish and maintain IAM policies and grants
+ Enable and disable key policies
+ Rotate key cryptographic material
+ Add tags
+ Create key aliases
+ Schedule keys for deletion
For more information, see [customer managed keys](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#customer-cmk) in the *AWS Key Management Service Developer Guide*.
**Note**
For all the custom models that you import, Amazon Bedrock automatically enables encryption at rest using AWS owned keys to protect customer data at no charge. If you use a customer managed key, AWS KMS charges apply. For more information about pricing, see [AWS Key Management Service Pricing.](https://docs.aws.amazon.com/).
## How Amazon Bedrock uses grants in AWS KMS
If you specify a customer managed key to encrypt the imported model. Amazon Bedrock creates a **primary** AWS KMS [grant](https://docs.aws.amazon.com/) associated with the imported model on your behalf by sending a [CreateGrant](https://docs.aws.amazon.com//kms/latest/APIReference/API_CreateGrant.html) request to AWS KMS. This grant allows Amazon Bedrock to access and use your customer managed key. Grants in AWS KMS are used to give Amazon Bedrock access to a KMS key in a customer’s account.
Amazon Bedrock requires the primary grant to use your customer managed key for the following internal operations:
+ Send [DescribeKey](https://docs.aws.amazon.com/kms/latest/APIReference/API_DescribeKey.html) requests to AWS KMS to verify that the symmetric customer managed KMS key ID you entered when creating the job is valid.
+ Send [GenerateDataKey](https://docs.aws.amazon.com//kms/latest/APIReference/API_GenerateDataKey.html) and [Decrypt](https://docs.aws.amazon.com//kms/latest/APIReference/API_Decrypt.html) requests to AWS KMS to generate data keys encrypted by your customer managed key and decrypt the encrypted data keys so that they can be used to encrypt the model artifacts.
+ Send [CreateGrant](https://docs.aws.amazon.com//kms/latest/APIReference/API_CreateGrant.html) requests to AWS KMS to create scoped down secondary grants with a subset of the above operations (`DescribeKey`, `GenerateDataKey`, `Decrypt`), for the asynchronous execution of model import and for on-demand inference.
+ Amazon Bedrock specifies a retiring principal during the creation of grants, so the service can send a [RetireGrant](https://docs.aws.amazon.com//kms/latest/APIReference/API_RetireGrant.html) request.
You have full access to your customer managed AWS KMS key. You can revoke access to the grant by following the steps at [Retiring and revoking grants](https://docs.aws.amazon.com//kms/latest/developerguide/grant-manage.html#grant-delete) in the *AWS Key Management Service Developer Guide* or remove the service’s access to your customer managed key at any time by modifying the key policy. If you do so, Amazon Bedrock won’t be able to access the imported model encrypted by your key.
### Life cycle of primary and secondary grants for custom imported models
+ **Primary grants** have a long lifespan and remain active as long as the associated custom models are still in use. When a custom imported model is deleted, the corresponding primary grant is automatically retired.
+ **Secondary grants** are short-lived. They are automatically retired as soon as the operation that Amazon Bedrock performs on behalf of the customers is completed. For example, once a custom model import job is finished, the secondary grant that allowed Amazon Bedrock to encrypt the custom imported model will be retired immediately.
# Using customer managed key (CMK)
If you are planning to use customer managed key to encrypt your custom imported model, complete the following steps:
1. Create a customer managed key with the AWS Key Management Service.
1. Attach a [resource-based policy](https://docs.aws.amazon.com//IAM/latest/UserGuide/access_policies_identity-vs-resource.html) with permissions for the specified-roles to create and use custom imported models.
**Create a customer managed key**
First ensure that you have `CreateKey` permissions. Then follow the steps at [creating keys](https://docs.aws.amazon.com//kms/latest/developerguide/create-keys.html) to create a customer managed keys either in the AWS KMS console or the [CreateKey](https://docs.aws.amazon.com/kms/latest/APIReference/API_CreateKey.html) API operation. Make sure to create a symmetric encryption key.
Creation of the key returns an `Arn` for the key that you can use as the `importedModelKmsKeyId ` when importing a custom model with custom model import.
**Create a key policy and attach it to the customer managed key**
Key policies are [resource-based policy](https://docs.aws.amazon.com//IAM/latest/UserGuide/access_policies_identity-vs-resource.html) that you attach to your customer managed key to control access to it. Every customer managed key must have exactly one key policy, which contains statements that determine who can use the key and how they can use it. You can specify a key policy when you create your customer managed key. You can modify the key policy at any time, but there might be a brief delay before the change becomes available throughout AWS KMS. For more information, see [Managing access to customer managed keys](https://docs.aws.amazon.com//kms/latest/developerguide/control-access-overview.html#managing-access) in the *AWS Key Management Service Developer Guide*.
**Encrypt an imported custom model**
To use your customer managed key to encrypt an imported custom model, you must include the following AWS KMS operations in the key policy:
+ [kms:CreateGrant](https://docs.aws.amazon.com/kms/latest/APIReference/API_CreateGrant.html) – creates a grant for a customer managed key by allowing the Amazon Bedrock service principal access to the specified KMS key through [grant operations](https://docs.aws.amazon.com/kms/latest/developerguide/grants.html#terms-grant-operations). For more information about grants, see [Grants in AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/grants.html) in the *AWS Key Management Service Developer Guide*.
**Note**
Amazon Bedrock also sets up a retiring principal and automatically retires the grant after it is no longer required.
+ [kms:DescribeKey](https://docs.aws.amazon.com/kms/latest/APIReference/API_DescribeKey.html) – provides the customer managed key details to allow Amazon Bedrock to validate the key.
+ [kms:GenerateDataKey](https://docs.aws.amazon.com/kms/latest/APIReference/API_GenerateDataKey.html) – Provides the customer managed key details to allow Amazon Bedrock to validate user access. Amazon Bedrock stores generated ciphertext alongside the imported custom model to be used as an additional validation check against imported custom model users
+ [kms:Decrypt](https://docs.aws.amazon.com/kms/latest/APIReference/API_Decrypt.html) – Decrypts the stored ciphertext to validate that the role has proper access to the KMS key that encrypts the imported custom model.
The following is an example policy that you can attach to a key for a role that you'll use to encrypt models that you import:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Id": "KMS key policy for a key to encrypt an imported custom model",
"Statement": [
{
"Sid": "Permissions for model import API invocation role",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:user/role"
},
"Action": [
"kms:Decrypt",
"kms:GenerateDataKey",
"kms:DescribeKey",
"kms:CreateGrant"
],
"Resource": "*"
}
]
}
```
------
**Decrypt an encrypted imported custom model**
If you're importing a custom model that has already been encrypted by another customer managed key, you must add `kms:Decrypt` permissions for the same role, as in the following policy:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Id": "KMS key policy for a key that encrypted a custom imported model",
"Statement": [
{
"Sid": "Permissions for model import API invocation role",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:user/role"
},
"Action": [
"kms:Decrypt"
],
"Resource": "*"
}
]
}
```
------
# Monitoring your encryption keys for the Amazon Bedrock service
When you use an AWS KMS customer managed key with your Amazon Bedrock resources, you can use [AWS CloudTrail](https://docs.aws.amazon.com//awscloudtrail/latest/userguide/cloudtrail-user-guide.html) or [Amazon CloudWatch Logs](https://docs.aws.amazon.com//AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html) to track requests that Amazon Bedrock sends to AWS KMS.
The following is an example AWS CloudTrail event for [CreateGrant](https://docs.aws.amazon.com/kms/latest/APIReference/API_CreateGrant.html) to monitor AWS KMS operations called by Amazon Bedrock to create a primary grant:
```
{
"eventVersion": "1.09",
"userIdentity": {
"type": "AssumedRole",
"principalId": "AROAIGDTESTANDEXAMPLE:SampleUser01",
"arn": "arn:aws:sts::111122223333:assumed-role/RoleForModelImport/SampleUser01",
"accountId": "111122223333",
"accessKeyId": "EXAMPLE",
"sessionContext": {
"sessionIssuer": {
"type": "Role",
"principalId": "AROAIGDTESTANDEXAMPLE",
"arn": "arn:aws:iam::111122223333:role/RoleForModelImport",
"accountId": "111122223333",
"userName": "RoleForModelImport"
},
"attributes": {
"creationDate": "2024-05-07T21:46:28Z",
"mfaAuthenticated": "false"
}
},
"invokedBy": "bedrock.amazonaws.com"
},
"eventTime": "2024-05-07T21:49:44Z",
"eventSource": "kms.amazonaws.com",
"eventName": "CreateGrant",
"awsRegion": "us-east-1",
"sourceIPAddress": "bedrock.amazonaws.com",
"userAgent": "bedrock.amazonaws.com",
"requestParameters": {
"granteePrincipal": "bedrock.amazonaws.com",
"retiringPrincipal": "bedrock.amazonaws.com",
"keyId": "arn:aws:kms:us-east-1:111122223333:key/1234abcd-12ab-34cd-56ef-123456SAMPLE",
"operations": [
"Decrypt",
"CreateGrant",
"GenerateDataKey",
"DescribeKey"
]
},
"responseElements": {
"grantId": "0ab0ac0d0b000f00ea00cc0a0e00fc00bce000c000f0000000c0bc0a0000aaafSAMPLE",
"keyId": "arn:aws:kms:us-east-1:111122223333:key/1234abcd-12ab-34cd-56ef-123456SAMPLE"
},
"requestID": "ff000af-00eb-00ce-0e00-ea000fb0fba0SAMPLE",
"eventID": "ff000af-00eb-00ce-0e00-ea000fb0fba0SAMPLE",
"readOnly": false,
"resources": [
{
"accountId": "111122223333",
"type": "AWS::KMS::Key",
"ARN": "arn:aws:kms:us-east-1:111122223333:key/1234abcd-12ab-34cd-56ef-123456SAMPLE"
}
],
"eventType": "AwsApiCall",
"managementEvent": true,
"recipientAccountId": "111122223333",
"eventCategory": "Management"
}
```
Attach the following resource-based policy to the KMS key by following the steps at [Creating a policy](https://docs.aws.amazon.com//kms/latest/developerguide/key-policy-overview.html). The policy contains two statements.
1. Permissions for a role to encrypt model customization artifacts. Add ARNs of the imported custom model builder roles to the `Principal` field.
1. Permissions for a role to use the imported custom model in inference. Add ARNs of imported custom model user roles to the `Principal` field.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Id": "KMS Key Policy",
"Statement": [
{
"Sid": "Permissions for imported model builders",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::123456789012:user/role"
},
"Action": [
"kms:Decrypt",
"kms:GenerateDataKey",
"kms:DescribeKey",
"kms:CreateGrant"
],
"Resource": "*"
},
{
"Sid": "Permissions for imported model users",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::123456789012:user/role"
},
"Action": "kms:Decrypt",
"Resource": "*"
}
]
}
```
------
# Encryption in Amazon Bedrock Data Automation
Amazon Bedrock Data Automation (BDA) uses encryption to protect your data at rest. This includes the blueprints, projects, libraries, and extracted insights stored by the service. BDA offers two options for encrypting your data:
1. AWS owned keys – By default, BDA encrypts your data with AWS owned keys. 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](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#aws-owned-cmk) in the AWS Key Management Service Developer Guide.
1. Customer managed keys – You can choose to encrypt your data with customer managed keys that you manage yourself. For more information about AWS KMS keys, see [Customer managed keys](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#customer-cmk) in the AWS Key Management Service Developer Guide. BDA does not support customer managed keys for use in the Amazon Bedrock console, only for API operations.
Amazon Bedrock Data Automation automatically enables encryption at rest using AWS owned keys at no charge. If you use a customer managed key, AWS KMS charges apply. For more information about pricing, see AWS KMS [pricing](https://aws.amazon.com/kms/pricing/).
## How Amazon Bedrock uses grants in AWS KMS
If you specify a customer managed key for encryption of your BDA when calling invokeDataAutomationAsync or CreateDataAutomationLibrary, the service creates a grant associated with your resources on your behalf by sending a CreateGrant request to AWS KMS. This grant allows BDA to access and use your customer managed key. The grant created by CreateDataAutomationLibrary is not utilized if the customer ingests vocabulary entities into the library.
BDA uses the grant for your customer managed key for the following internal operations:
+ DescribeKey — Send requests to AWS KMS to verify that the symmetric customer managed AWS KMS key ID you provided is valid.
+ GenerateDataKey and Decrypt — Send requests to AWS KMS to generate data keys encrypted by your customer managed key and decrypt the encrypted data keys so that they can be used to encrypt your resources.
+ CreateGrant — Send requests to AWS KMS to create scoped down grants for the asynchronous execution of operations. The grant operations vary by API:
+ InvokeDataAutomationAsync: DescribeKey, GenerateDataKey, Decrypt
+ CreateDataAutomationLibrary: DescribeKey, GenerateDataKey, Decrypt, CreateGrant
You have full access to your customer managed AWS KMS key. You can revoke access to the grant by following the steps at Retiring and revoking grants in the AWS KMS Developer Guide or remove the service's access to your customer managed key at any time by modifying the key policy. If you do so, BDA won't be able to access the resources encrypted by your key.
If you initiate a new invokeDataAutomationAsync call after revoking a grant, BDA will recreate the grant.
The grants created by invokeDataAutomationAsync are retired by BDA after 30 hours.
The grants created by CreateDataAutomationLibrary are retired by BDA when the library is deleted.
## Creating a customer managed key and attaching a key policy
To encrypt BDA resources with a key that you create and manage, follow these general steps:
1. (Prerequisite) Ensure that your IAM role has permissions for the CreateKey action.
1. Follow the steps at [ Creating keys ](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html) to create a customer managed key using the AWS KMS console or the CreateKey operation.
1. Creation of the key returns an ARN that you can use for operations that require using the key (for example, when creating a project or blueprint in BDA), like the invokeDataAutomationAsync operation.
1. Create and attach a key policy to the key with the required permissions. To create a key policy, follow the steps at [ Creating a key policy ](https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-create.html) in the AWS KMS Developer Guide.
## Permissions and key policies for Amazon Bedrock Data Automation resources
After you create a AWS KMS key, you attach a key policy to it. The following AWS KMS actions are used for keys that encrypt BDA resources:
1. kms:CreateGrant – Creates a grant for a customer managed key by allowing the BDA service access to the specified AWS KMS key through grant operations, needed for InvokeDataAutomationAsync and CreateDataAutomationLibrary.
1. kms:DescribeKey – Provides the customer managed key details to allow BDA to validate the key.
1. kms:GenerateDataKey – Provides the customer managed key details to allow BDA to validate user access.
1. kms:Decrypt – Decrypts the stored ciphertext to validate that the role has proper access to the AWS KMS key that encrypts the BDA resources.
**Key policy for Amazon Bedrock Data Automation**
To use your customer managed key to encrypt BDA resources, include the following statements in your key policy and replace `${account-id}`, `${region}`, and `${key-id}` with your specific values:
```
{
"Version": "2012-10-17",
"Id": "KMS key policy for a key to encrypt data for BDA resource",
"Statement": [
{
"Sid": "Enable DescribeKey, Decrypt, GenerateDataKey",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:role/Role"
},
"Action": [
"kms:DescribeKey",
"kms:GenerateDataKey",
"kms:Decrypt"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"kms:ViaService": "bedrock.us-east-1.amazonaws.com"
}
}
},
{
"Sid": "Enable CreateGrant",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:role/Role"
},
"Action": "kms:CreateGrant",
"Resource": "*",
"Condition": {
"StringEquals": {
"kms:ViaService": "bedrock.us-east-1.amazonaws.com"
},
"ForAllValues:StringEquals": {
"kms:GrantOperations": [
"CreateGrant",
"GenerateDataKey",
"Decrypt",
"DescribeKey"
]
}
}
}
]
}
```
**IAM role permissions**
The IAM role used to interact with BDA and AWS KMS should have the following permissions, replace `${region}`, `${account-id}`, and `${key-id}` with your specific values:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"kms:GenerateDataKey",
"kms:Decrypt",
"kms:DescribeKey",
"kms:CreateGrant"
],
"Resource": "arn:aws:kms:us-east-1:123456789012:key/KeyId",
"Condition": {
"StringLike": {
"kms:ViaService": [
"bedrock.us-east-1.amazonaws.com"
]
}
}
}
]
}
```
------
## Amazon Bedrock Data Automation encryption context
For all DataAutomationLibrary operations including InvokeDataAutomationLibraryIngestionJob, BDA uses below encryption context in all AWS KMS cryptographic operations, where the key is `aws:bedrock:data-automation-library-arn` and the value is the `libraryArn`.
```
"encryptionContext": {
"aws:bedrock:data-automation-library-arn": ""
}
```
For DataAutomationProject operations, BDA uses below encryption context:
```
"encryptionContext": {
"DataAutomationProjectArn": ""
}
```
For Blueprint operations, BDA uses below encryption context:
```
"encryptionContext": {
"BlueprintArn": ""
}
```
For all other operations, BDA uses below encryption context:
```
"encryptionContext": {
"aws:bedrock:data-automation-customer-account-id": "111122223333"
}
```
**Using encryption context for monitoring**
When you use a symmetric customer managed key to encrypt your data, you can also use the encryption context in audit records and logs to identify how the customer managed key is being used. The encryption context also appears in logs generated by AWS CloudTrail or Amazon CloudWatch Logs.
**Using encryption context to control access to your customer managed key**
You can use the encryption context in key policies and IAM policies as conditions to control access to your symmetric customer managed key. You can also use encryption context constraints in a grant. BDA uses an encryption context constraint in grants to control access to the customer managed key in your account or Region. The grant constraint requires that the operations that the grant allows use the specified encryption context.
The following are example key policy statements to grant access to a customer managed key for a specific encryption context. The condition in this policy statement requires that the grants have an encryption context constraint that specifies the encryption context.
```
[
{
"Sid": "Enable DescribeKey",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:role/ExampleRole"
},
"Action": ["kms:DescribeKey"],
"Resource": "*",
"Condition": {
"StringLike": {
"kms:ViaService": [
"bedrock.${region}.amazonaws.com"
]
}
}
},
{
"Sid": "Enable Decrypt, GenerateDataKey",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:role/ExampleRole"
},
"Action": [
"kms:GenerateDataKey",
"kms:Decrypt"
],
"Resource": "*",
"Condition": {
"StringLike": {
"kms:ViaService": [
"bedrock.${region}.amazonaws.com"
],
"kms:EncryptionContext:aws:bedrock:data-automation-customer-account-id": "111122223333"
}
}
},
{
"Sid": "Enable CreateGrant",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:role/ExampleRole"
},
"Action": "kms:CreateGrant",
"Resource": "*",
"Condition": {
"StringLike": {
"kms:ViaService": [
"bedrock.${region}.amazonaws.com"
],
"kms:EncryptionContext:aws:bedrock:data-automation-customer-account-id": "111122223333"
},
"StringEquals": {
"kms:GrantOperations": ["Decrypt", "DescribeKey", "GenerateDataKey"]
}
}
}
]
```
When calling `CreateDataAutomationLibrary`, attach the following policy to grant BDA the necessary permission for accessing your customer managed key.
```
[
{
"Sid": "Enable CreateGrant for CreateDataAutomationLibrary",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:role/ExampleRole"
},
"Action": "kms:CreateGrant",
"Resource": "*",
"Condition": {
"StringLike": {
"kms:ViaService": [
"bedrock.${region}.amazonaws.com"
]
},
"StringEquals": {
"kms:GrantOperations": ["Decrypt", "DescribeKey", "GenerateDataKey", "CreateGrant"]
}
}
}
]
```
## Monitoring your encryption keys for Amazon Bedrock Data Automation
When you use an AWS KMS customer managed key with your Amazon Bedrock Data Automation resources, you can use [AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html) or [Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html) to track requests that Amazon Bedrock Data Automation sends to AWS KMS. The following is an example AWS CloudTrail event for [CreateGrant](https://docs.aws.amazon.com/kms/latest/APIReference/API_CreateGrant.html) to monitor AWS KMS operations called by Amazon Bedrock Data Automation to create a primary grant:
```
{
"eventVersion": "1.09",
"userIdentity": {
"type": "AssumedRole",
"principalId": "AROAIGDTESTANDEXAMPLE:SampleUser01",
"arn": "arn:aws:sts::111122223333:assumed-role/RoleForDataAutomation/SampleUser01",
"accountId": "111122223333",
"accessKeyId": "EXAMPLE",
"sessionContext": {
"sessionIssuer": {
"type": "Role",
"principalId": "AROAIGDTESTANDEXAMPLE",
"arn": "arn:aws:iam::111122223333:role/RoleForDataAutomation",
"accountId": "111122223333",
"userName": "RoleForDataAutomation"
},
"attributes": {
"creationDate": "2024-05-07T21:46:28Z",
"mfaAuthenticated": "false"
}
},
"invokedBy": "bedrock.amazonaws.com"
},
"eventTime": "2024-05-07T21:49:44Z",
"eventSource": "kms.amazonaws.com",
"eventName": "CreateGrant",
"awsRegion": "us-east-1",
"sourceIPAddress": "bedrock.amazonaws.com",
"userAgent": "bedrock.amazonaws.com",
"requestParameters": {
"granteePrincipal": "bedrock.amazonaws.com",
"retiringPrincipal": "bedrock.amazonaws.com",
"keyId": "arn:aws:kms:us-east-1:111122223333:key/1234abcd-12ab-34cd-56ef-123456SAMPLE",
"constraints": {
"encryptionContextSubset": {
"aws:bedrock:data-automation-customer-account-id": "000000000000"
}
},
"operations": [
"Decrypt",
"CreateGrant",
"GenerateDataKey",
"DescribeKey"
]
},
"responseElements": {
"grantId": "0ab0ac0d0b000f00ea00cc0a0e00fc00bce000c000f0000000c0bc0a0000aaafSAMPLE",
"keyId": "arn:aws:kms:us-east-1:111122223333:key/1234abcd-12ab-34cd-56ef-123456SAMPLE"
},
"requestID": "ff000af-00eb-00ce-0e00-ea000fb0fba0SAMPLE",
"eventID": "ff000af-00eb-00ce-0e00-ea000fb0fba0SAMPLE",
"readOnly": false,
"resources": [
{
"accountId": "111122223333",
"type": "AWS::KMS::Key",
"ARN": "arn:aws:kms:us-east-1:111122223333:key/1234abcd-12ab-34cd-56ef-123456SAMPLE"
}
],
"eventType": "AwsApiCall",
"managementEvent": true,
"recipientAccountId": "111122223333",
"eventCategory": "Management"
}
```
# Encryption of agent resources
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.
Amazon Bedrock uses default AWS-owned keys to automatically encrypt agent's information. This includes control plane data and session data. You can't view, manage, or audit the use of AWS owned keys. For more information, see [AWS owned keys](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#aws-owned-cmk).
While you can't disable this layer of encryption, you can choose to use customer managed keys instead of AWS-owned keys to encrypt agent's information. Amazon Bedrock supports the use of a symmetric customer managed keys (CMK) that you can create, own, and manage instead of the default AWS owned encryption. For more information, see [Customer managed keys](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#customer-cmk).
**Important**
Amazon Bedrock automatically encrypts your agent's session information using AWS owned keys at no charge.
AWS KMS charges apply for using a customer managed keys. For more information about pricing, see [AWS Key Management Service Pricing](https://aws.amazon.com/kms/pricing/).
If you've created your agent *before* January 22, 2025 and want to use customer managed key for encrypting agent resources, follow instructions for [Encryption of agent resources for agents created before January 22, 2025](encryption-agents.md).
# Encryption of agent resources with customer managed keys (CMK)
You can at any time create a customer managed key to encrypt your agent’s information using the following agent information provided when building your agent.
**Note**
The following agent resources will only be encrypted for the agents created after January 22, 2025.
****
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/bedrock/latest/userguide/cmk-agent-resources.html)
To use a customer managed key, complete the following steps:
1. Create customer managed key with the AWS Key Management Service.
1. Create a key policy and attach to the customer managed key
## 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.
First make sure that you have `CreateKey` permissions and then, 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*.
**Key policy** - key policies control access to your customer managed key . Every customer managed key must have exactly one key policy, which contains statements that determine who can use the key and how they can use it. When you create your customer managed key, you can specify a key policy. For more information, see [Managing access to customer managed key](https://docs.aws.amazon.com/kms/latest/developerguide/overview.html) in the *AWS Key Management Service Developer Guide*.
If you have created your agent after January 22, 2025 and want to use customer managed key to encrypt your agent's information, make sure that the user or the role calling the agent API operations has the following permissions in the key policy:
+ [kms:GenerateDataKey](https://docs.aws.amazon.com/kms/latest/APIReference/API_GenerateDataKey.html) – returns a unique symmetric data key for use outside of AWS KMS.
+ [kms:Decrypt](https://docs.aws.amazon.com/kms/latest/APIReference/API_Decrypt.html) – decrypts ciphertext that was encrypted by a KMS key.
Creation of the key returns an `Arn` for the key that you can use as the `customerEncryptionKeyArn`, when creating your agent.
## Create a key policy and attach it to the customer managed key
If you encrypt agent resources with a customer managed key, you must set up an identity-based policy and a resource-based policy to allow Amazon Bedrock to encrypt and decrypt the agent resources on your behalf.
**Identity-based policy**
Attach the following identity-based policy to an IAM role or user with permissions to make calls to agent APIs that encrypt and decrypt agent resources on your behalf. This policy validates the user making API call has AWS KMS permissions. Replace the `${region}`, `${account-id}`, `${agent-id}`, and `${key-id}` with the appropriate values.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "EncryptAgents",
"Effect": "Allow",
"Action": [
"kms:GenerateDataKey",
"kms:Decrypt"
],
"Resource": "arn:aws:kms:us-east-1:123456789012:key/${key-id}",
"Condition": {
"StringEquals": {
"kms:EncryptionContext:aws:bedrock:arn": "arn:aws:bedrock:us-east-1:123456789012:agent/${agent-id}"
}
}
}
]
}
```
------
**Resource-based policy**
Attach the following resource-based policy to your AWS KMS key *only* if you are creating action groups where the schema in Amazon S3 is encrypted. You do not need to attach resource-based policy for any other use cases.
To attach the following resource-based policy, change the scope of the permissions as necessary and replace the `${region}`, `${account-id}`, `${agent-id}`, and `${key-id}` with the appropriate values.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "Allow account root to modify the KMS key, not used by Amazon Bedrock.",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:root"
},
"Action": "kms:*",
"Resource": "arn:aws:kms:us-east-1:123456789012:key/${key-id}"
},
{
"Sid": "Allow Amazon Bedrock to encrypt and decrypt Agent resources on behalf of authorized users",
"Effect": "Allow",
"Principal": {
"Service": "bedrock.amazonaws.com"
},
"Action": [
"kms:GenerateDataKey",
"kms:Decrypt"
],
"Resource": "arn:aws:kms:us-east-1:123456789012:key/${key-id}",
"Condition": {
"StringEquals": {
"kms:EncryptionContext:aws:bedrock:arn": "arn:aws:bedrock:us-east-1:123456789012:agent/${agent-id}"
}
}
}
]
}
```
------
## Changing the customer managed key
Amazon Bedrock agents do not support re-encryption of versioned agents when the customer managed key associated with the *DRAFT* agent is changed or when you move from customer managed key to AWS owned key. Only the data for the *DRAFT* resource will be re-encrypted with the new key.
Make sure you are not deleting or removing permissions for any keys for a versioned agent if using it to serve production data.
To view and verify the keys being used by a version, call [GetAgentVersion](https://docs.aws.amazon.com//bedrock/latest/APIReference/API_agent_GetAgentVersion.html) and check the `customerEncryptionKeyArn` in the response.
# Encrypt agent sessions with customer managed key (CMK)
If you've enabled memory for your agent and if you encrypt agent sessions with a customer managed key, you must configure the following key policy and the calling identity IAM permissions to configure your customer managed key.
**Customer managed key policy**
Amazon Bedrock uses these permissions to generate encrypted data keys and then use the generated keys to encrypt agent memory. Amazon Bedrock also needs permissions to re-encrypt the the generated data key with different encryption contexts. Re-encrypt permissions are also used when customer managed key transitions between another customer managed key or service owned key. For more information, see [Hierarchical Keyring](https://docs.aws.amazon.com//database-encryption-sdk/latest/devguide/use-hierarchical-keyring.html).
Replace the `$region`, `account-id`, and `${caller-identity-role}` with appropriate values.
```
{
"Version": "2012-10-17",
{
"Sid": "Allow access for bedrock to enable long term memory",
"Effect": "Allow",
"Principal": {
"Service": [
"bedrock.amazonaws.com",
],
},
"Action": [
"kms:GenerateDataKeyWithoutPlainText",
"kms:ReEncrypt*"
],
"Condition": {
"StringEquals": {
"aws:SourceAccount": "$account-id"
},
"ArnLike": {
"aws:SourceArn": "arn:aws:bedrock:$region:$account-id:agent-alias/*"
}
}
"Resource": "*"
},
{
"Sid": "Allow the caller identity control plane permissions for long term memory",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::${account-id}:role/${caller-identity-role}"
},
"Action": [
"kms:GenerateDataKeyWithoutPlainText",
"kms:ReEncrypt*"
],
"Resource": "*",
"Condition": {
"StringLike": {
"kms:EncryptionContext:aws-crypto-ec:aws:bedrock:arn": "arn:aws:bedrock:${region}:${account-id}:agent-alias/*"
}
}
},
{
"Sid": "Allow the caller identity data plane permissions to decrypt long term memory",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::${account-id}:role/${caller-identity-role}"
},
"Action": [
"kms:Decrypt"
],
"Resource": "*",
"Condition": {
"StringLike": {
"kms:EncryptionContext:aws-crypto-ec:aws:bedrock:arn": "arn:aws:bedrock:${region}:${account-id}:agent-alias/*",
"kms:ViaService": "bedrock.$region.amazonaws.com"
}
}
}
}
```
**IAM permissions to encrypt and decrypt agent memory**
The following IAM permissions are needed for the identity calling Agents API to configure KMS key for agents with memory enabled. Amazon Bedrock agents use these permissions to make sure that the caller identity is authorized to have permissions mentioned in the key policy above for APIs to manage, train, and deploy models. For the APIs that invoke agents, Amazon Bedrock agent uses caller identity's `kms:Decrypt` permissions to decrypty memory.
Replace the `$region`, `account-id`, and `${key-id}` with appropriate values.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AgentsControlPlaneLongTermMemory",
"Effect": "Allow",
"Action": [
"kms:GenerateDataKeyWithoutPlaintext",
"kms:ReEncrypt*"
],
"Resource": "arn:aws:kms:us-east-1:123456789012:key/KeyId",
"Condition": {
"StringLike": {
"kms:EncryptionContext:aws-crypto-ec:aws:bedrock:arn": "arn:aws:bedrock:us-east-1:123456789012:agent-alias/*"
}
}
},
{
"Sid": "AgentsDataPlaneLongTermMemory",
"Effect": "Allow",
"Action": [
"kms:Decrypt"
],
"Resource": "arn:aws:kms:us-east-1:123456789012:key/KeyId",
"Condition": {
"StringLike": {
"kms:EncryptionContext:aws-crypto-ec:aws:bedrock:arn": "arn:aws:bedrock:us-east-1:123456789012:agent-alias/*"
}
}
}
]
}
```
------
# Preventative security best practice for agents
The following best practices for Amazon Bedrock service can help prevent security incidents:
**Use secure connections**
Always use encrypted connections, such as those that begin with `https://` to keep sensitive information secure in transit.
**Implement least priviledge access to resources**
When you create custom policies for Amazon Bedrock resources, grant only the permissions required to perform a task. It's recommended to start with a minimum set of permissions and grant additional permissions as needed. Implementing least privilege access is essential to reducing the risk and impact that could result from errors or malicious attacks. For more information, see [Identity and access management for Amazon Bedrock](security-iam.md).
**Do not include PII in any of the agent resources containing customer data**
When creating, updating, and deleting agents resources (for example, when using [CreateAgent](https://docs.aws.amazon.com//bedrock/latest/APIReference/API_agent_CreateAgent.html) ) do not include personally-identifiable information (PII) in any fields that do not support using customer managed key such as action group names and knowledgebase names. For the list of fields that support using customer managed key, see [Encryption of agent resources with customer managed keys (CMK)](cmk-agent-resources.md)
# Encryption of agent resources for agents created before January 22, 2025
**Important**
If you've created your agent *after* January 22, 2025, follow instructions for [Encryption of agent resources](encryption-agents-new.md)
Amazon Bedrock encrypts your agent's session information. By default, Amazon Bedrock encrypts this data using an AWS managed key. Optionally, you can encrypt the agent artifacts using a customer managed key.
For more information about AWS KMS keys, see [Customer managed keys](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#customer-cmk) in the *AWS Key Management Service Developer Guide*.
If you encrypt sessions with your agent with a custom KMS key, you must set up the following identity-based policy and resource-based policy to allow Amazon Bedrock to encrypt and decrypt agent resources on your behalf.
1. Attach the following identity-based policy to an IAM role or user with permissions to make `InvokeAgent` calls. This policy validates the user making an `InvokeAgent` call has KMS permissions. Replace the *\$1\$1region\$1*, *\$1\$1account-id\$1*, *\$1\$1agent-id\$1*, and *\$1\$1key-id\$1* with the appropriate values.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "EncryptDecryptAgents",
"Effect": "Allow",
"Action": [
"kms:GenerateDataKey",
"kms:Decrypt"
],
"Resource": "arn:aws:kms:us-east-1:123456789012:key/key-id",
"Condition": {
"StringEquals": {
"kms:EncryptionContext:aws:bedrock:arn": "arn:aws:bedrock:us-east-1:123456789012:agent/agent-id"
}
}
}
]
}
```
------
1. Attach the following resource-based policy to your KMS key. Change the scope of the permissions as necessary. Replace the *\$1\$1region\$1*, *\$1\$1account-id\$1*, *\$1\$1agent-id\$1*, and *\$1\$1key-id\$1* with the appropriate values.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowRootModifyKMSKey",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::123456789012:root"
},
"Action": "kms:*",
"Resource": "arn:aws:kms:us-east-1:123456789012:key/KeyId"
},
{
"Sid": "AllowBedrockEncryptAgent",
"Effect": "Allow",
"Principal": {
"Service": "bedrock.amazonaws.com"
},
"Action": [
"kms:GenerateDataKey",
"kms:Decrypt"
],
"Resource": "arn:aws:kms:us-east-1:123456789012:key/KeyId",
"Condition": {
"StringEquals": {
"kms:EncryptionContext:aws:bedrock:arn": "arn:aws:bedrock:us-east-1:123456789012:agent/AgentId"
}
}
},
{
"Sid": "AllowRoleEncryptAgent",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::123456789012:role/Role"
},
"Action": [
"kms:GenerateDataKey*",
"kms:Decrypt"
],
"Resource": "arn:aws:kms:us-east-1:123456789012:key/KeyId"
},
{
"Sid": "AllowAttachmentPersistentResources",
"Effect": "Allow",
"Principal": {
"Service": "bedrock.amazonaws.com"
},
"Action": [
"kms:CreateGrant",
"kms:ListGrants",
"kms:RevokeGrant"
],
"Resource": "*",
"Condition": {
"Bool": {
"kms:GrantIsForAWSResource": "true"
}
}
}
]
}
```
------
# Encryption of Amazon Bedrock Flows resources
Amazon Bedrock encrypts your data at rest. By default, Amazon Bedrock encrypts this data using an AWS managed key. Optionally, you can encrypt the data using a customer managed key.
For more information about AWS KMS keys, see [Customer managed keys](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#customer-cmk) in the *AWS Key Management Service Developer Guide*.
If you encrypt data with a custom KMS key, you must set up the following identity-based policy and resource-based policy to allow Amazon Bedrock to encrypt and decrypt data on your behalf.
1. Attach the following identity-based policy to an IAM role or user with permissions to make Amazon Bedrock Flows API calls. This policy validates the user making Amazon Bedrock Flows calls has KMS permissions. Replace the *\$1\$1region\$1*, *\$1\$1account-id\$1*, *\$1\$1flow-id\$1*, and *\$1\$1key-id\$1* with the appropriate values.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "EncryptFlow",
"Effect": "Allow",
"Action": [
"kms:GenerateDataKey",
"kms:Decrypt"
],
"Resource": "arn:aws:kms:us-east-1:123456789012:key/${key-id}",
"Condition": {
"StringEquals": {
"kms:EncryptionContext:aws:bedrock-flows:arn": "arn:aws:bedrock:us-east-1:123456789012:flow/${flow-id}",
"kms:ViaService": "bedrock.us-east-1.amazonaws.com"
}
}
}
]
}
```
------
1. Attach the following resource-based policy to your KMS key. Change the scope of the permissions as necessary. Replace the *\$1IAM-USER/ROLE-ARN\$1*, *\$1\$1region\$1*, *\$1\$1account-id\$1*, *\$1\$1flow-id\$1*, and *\$1\$1key-id\$1* with the appropriate values.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowRootModifyKMSId",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::123456789012:root"
},
"Action": "kms:*",
"Resource": "arn:aws:kms:us-east-1:123456789012:key/KeyId"
},
{
"Sid": "AllowRoleUseKMSKey",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::123456789012:role/RoleName"
},
"Action": [
"kms:GenerateDataKey",
"kms:Decrypt"
],
"Resource": "arn:aws:kms:us-east-1:123456789012:key/${key-id}",
"Condition": {
"StringEquals": {
"kms:EncryptionContext:aws:bedrock-flows:arn": "arn:aws:bedrock:us-east-1:123456789012:flow/FlowId",
"kms:ViaService": "bedrock.us-east-1.amazonaws.com"
}
}
}
]
}
```
------
1. For [flow executions](flows-create-async.md), attach the following identity-based policy to a [service role with permissions to create and manage flows](flows-permissions.md). This policy validates that the your service role has AWS KMS permissions. Replace the *region*, *account-id*, *flow-id*, and *key-id* with the appropriate values.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "EncryptionFlows",
"Effect": "Allow",
"Action": [
"kms:GenerateDataKey",
"kms:Decrypt"
],
"Resource": "arn:aws:kms:us-east-1:123456789012:key/key-id",
"Condition": {
"StringEquals": {
"kms:EncryptionContext:aws:bedrock-flows:arn": "arn:aws:bedrock:us-east-1:123456789012:flow/flow-id",
"kms:ViaService": "bedrock.us-east-1.amazonaws.com"
}
}
}
]
}
```
------
# Encryption of knowledge base resources
Amazon Bedrock encrypts resources related to your knowledge bases. By default, Amazon Bedrock encrypts this data using an AWS-owned key. Optionally, you can encrypt the model artifacts using a customer managed key.
Encryption with a KMS key can occur with the following processes:
+ Transient data storage while ingesting your data sources
+ Passing information to OpenSearch Service if you let Amazon Bedrock set up your vector database
+ Querying a knowledge base
The following resources used by your knowledge bases can be encrypted with a KMS key. If you encrypt them, you need to add permissions to decrypt the KMS key.
+ Data sources stored in an Amazon S3 bucket
+ Third-party vector stores
For more information about AWS KMS keys, see [Customer managed keys](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#customer-cmk) in the *AWS Key Management Service Developer Guide*.
**Note**
Amazon Bedrock knowledge bases uses TLS encryption for communication with third-party data source connectors and vector stores where the provider permits and supports TLS encryption in transit.
**Topics**
+ [Encryption of transient data storage during data ingestion](#encryption-kb-ingestion)
+ [Encryption of information passed to Amazon OpenSearch Service](#encryption-kb-oss)
+ [Encryption of information passed to Amazon S3 Vectors](#encryption-kb-s3-vector)
+ [Encryption of knowledge base retrieval](#encryption-kb-runtime)
+ [Permissions to decrypt your AWS KMS key for your data sources in Amazon S3](#encryption-kb-ds)
+ [Permissions to decrypt an AWS Secrets Manager secret for the vector store containing your knowledge base](#encryption-kb-3p)
+ [Permissions for Bedrock Data Automation (BDA) with AWS KMS encryption](#encryption-kb-bda)
## Encryption of transient data storage during data ingestion
When you set up a data ingestion job for your knowledge base, you can encrypt the job with a custom KMS key.
To allow the creation of a AWS KMS key for transient data storage in the process of ingesting your data source, attach the following policy to your Amazon Bedrock service role. Replace the example values with your own AWS Region, account ID, and AWS KMS key ID.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"kms:GenerateDataKey",
"kms:Decrypt"
],
"Resource": [
"arn:aws:kms:us-east-1:123456789012:key/key-id"
]
}
]
}
```
------
## Encryption of information passed to Amazon OpenSearch Service
If you opt to let Amazon Bedrock create a vector store in Amazon OpenSearch Service for your knowledge base, Amazon Bedrock can pass a KMS key that you choose to Amazon OpenSearch Service for encryption. To learn more about encryption in Amazon OpenSearch Service, see [Encryption in Amazon OpenSearch Service](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/serverless-encryption.html).
## Encryption of information passed to Amazon S3 Vectors
If you opt to let Amazon Bedrock create an S3 vector bucket and vector index in Amazon S3 Vectors for your knowledge base, Amazon Bedrock can pass a KMS key that you choose to Amazon S3 Vectors for encryption. To learn more about encryption in Amazon S3 Vectors, see [Encryption with Amazon S3 Vectors](https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-vectors-bucket-encryption.html).
## Encryption of knowledge base retrieval
You can encrypt sessions in which you generate responses from querying a knowledge base with a KMS key. To do so, include the ARN of a KMS key in the `kmsKeyArn` field when making a [RetrieveAndGenerate](https://docs.aws.amazon.com/bedrock/latest/APIReference/API_agent-runtime_RetrieveAndGenerate.html) request. Attach the following policy, replacing the example values with your own AWS Region, account ID, and AWS KMS key ID to allow Amazon Bedrock to encrypt the session context.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "bedrock.amazonaws.com"
},
"Action": [
"kms:GenerateDataKey",
"kms:Decrypt"
],
"Resource": "arn:aws:kms:us-east-1:123456789012:key/key-id"
}
]
}
```
------
## Permissions to decrypt your AWS KMS key for your data sources in Amazon S3
You store the data sources for your knowledge base in your Amazon S3 bucket. To encrypt these documents at rest, you can use the Amazon S3 SSE-S3 server-side encryption option. With this option, objects are encrypted with service keys managed by the Amazon S3 service.
For more information, see [Protecting data using server-side encryption with Amazon S3-managed encryption keys (SSE-S3)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingServerSideEncryption.html) in the *Amazon Simple Storage Service User Guide*.
If you encrypted your data sources in Amazon S3 with a custom AWS KMS key, attach the following policy to your Amazon Bedrock service role to allow Amazon Bedrock to decrypt your key. Replace the example values with your own AWS Region, account ID, and AWS KMS key ID.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"KMS:Decrypt"
],
"Resource": [
"arn:aws:kms:us-east-1:123456789012:key/key-id"
],
"Condition": {
"StringEquals": {
"kms:ViaService": [
"s3.us-east-1.amazonaws.com"
]
}
}
}
]
}
```
------
## Permissions to decrypt an AWS Secrets Manager secret for the vector store containing your knowledge base
If the vector store containing your knowledge base is configured with an AWS Secrets Manager secret, you can encrypt the secret with a custom AWS KMS key by following the steps at [Secret encryption and decryption in AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/security-encryption.html).
If you do so, you attach the following policy to your Amazon Bedrock service role to allow it to decrypt your key. Replace the example values with your own AWS Region, account ID, and AWS KMS key ID.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"kms:Decrypt"
],
"Resource": [
"arn:aws:kms:us-east-1:123456789012:key/key-id"
]
}
]
}
```
------
## Permissions for Bedrock Data Automation (BDA) with AWS KMS encryption
When using BDA to process multimodal content with customer-managed AWS KMS keys, additional permissions are required beyond the standard AWS KMS permissions.
Attach the following policy to your Amazon Bedrock service role to allow BDA to work with encrypted multimedia files. Replace the example values with your own AWS Region, account ID, and AWS KMS key ID.
```
{
"Sid": "KmsPermissionStatementForBDA",
"Effect": "Allow",
"Action": [
"kms:GenerateDataKey",
"kms:Decrypt",
"kms:DescribeKey",
"kms:CreateGrant"
],
"Resource": "arn:aws:kms:region:account-id:key/key-id",
"Condition": {
"StringEquals": {
"aws:ResourceAccount": "account-id",
"kms:ViaService": "bedrock.region.amazonaws.com"
}
}
}
```
The BDA-specific permissions include `kms:DescribeKey` and `kms:CreateGrant` actions, which are required for BDA to process encrypted audio, video, and image files.
# Protect your data using Amazon VPC and AWS PrivateLink
To control access to your data, we recommend that you use a virtual private cloud (VPC) with [Amazon VPC](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html). Using a VPC protects your data and lets you monitor all network traffic in and out of the AWS job containers by using [VPC Flow Logs](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html).
You can further protect your data by configuring your VPC so that your data isn't available over the internet and instead creating a VPC interface endpoint with [AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/what-is-privatelink.html) to establish a private connection to your data.
The following lists some features of Amazon Bedrock in which you can use VPC to protect your data:
+ Model customization – [(Optional) Protect your model customization jobs using a VPC](custom-model-job-access-security.md#vpc-model-customization)
+ Batch inference – [Protect batch inference jobs using a VPC](batch-vpc.md)
+ Amazon Bedrock Knowledge Bases – [Access Amazon OpenSearch Serverless using an interface endpoint (AWS PrivateLink)](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/serverless-vpc.html)
## Set up a VPC
You can use a [default VPC](https://docs.aws.amazon.com/vpc/latest/userguide/default-vpc.html) or create a new VPC by following the guidance at [Get started with Amazon VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-getting-started.html) and [Create a VPC](https://docs.aws.amazon.com/vpc/latest/userguide/create-vpc.html).
When you create your VPC, we recommend that you use the default DNS settings for your endpoint route table, so that standard Amazon S3 URLs (for example, `http://s3-aws-region.amazonaws.com/training-bucket`) resolve.
The following topics show how to set up VPC endpoint with the help of AWS PrivateLink and an example use case for using VPC to protect access to your S3 files.
**Topics**
+ [Set up a VPC](#create-vpc)
+ [Use interface VPC endpoints (AWS PrivateLink) to create a private connection between your VPC and Amazon Bedrock](vpc-interface-endpoints.md)
+ [(Example) Restrict data access to your Amazon S3 data using VPC](vpc-s3.md)
# Use interface VPC endpoints (AWS PrivateLink) to create a private connection between your VPC and Amazon Bedrock
You can use AWS PrivateLink to create a private connection between your VPC and Amazon Bedrock. You can access Amazon Bedrock as if it were in your VPC, without the use of an internet gateway, NAT device, VPN connection, or Direct Connect connection. Instances in your VPC don't need public IP addresses to access Amazon Bedrock.
You establish this private connection by creating an *interface endpoint*, powered by AWS PrivateLink. We create an endpoint network interface in each subnet that you enable for the interface endpoint. These are requester-managed network interfaces that serve as the entry point for traffic destined for Amazon Bedrock.
For more information, see [Access AWS services through AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/privatelink-access-aws-services.html) in the *AWS PrivateLink Guide*.
## Considerations for Amazon Bedrock VPC endpoints
Before you set up an interface endpoint for Amazon Bedrock, review [Considerations](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html#considerations-interface-endpoints) in the *AWS PrivateLink Guide*.
Amazon Bedrock supports making the following API calls through VPC endpoints.
****
| Category | Endpoint suffix |
| --- | --- |
| [Amazon Bedrock Control Plane API actions](https://docs.aws.amazon.com/bedrock/latest/APIReference/API_Operations_Amazon_Bedrock.html) | bedrock |
| [Amazon Bedrock Runtime API actions](https://docs.aws.amazon.com/bedrock/latest/APIReference/API_Operations_Amazon_Bedrock_Runtime.html) | bedrock-runtime |
| Amazon Bedrock Mantle API actions | bedrock-mantle |
| [Amazon Bedrock Agents Build-time API actions](https://docs.aws.amazon.com/bedrock/latest/APIReference/API_Operations_Agents_for_Amazon_Bedrock.html) | bedrock-agent |
| [Amazon Bedrock Agents Runtime API actions](https://docs.aws.amazon.com/bedrock/latest/APIReference/API_Operations_Agents_for_Amazon_Bedrock_Runtime.html) | bedrock-agent-runtime |
**Availability Zones**
Amazon Bedrock and Amazon Bedrock Agents endpoints are available in multiple Availability Zones.
## Create an interface endpoint for Amazon Bedrock
You can create an interface endpoint for Amazon Bedrock using either the Amazon VPC console or the AWS Command Line Interface (AWS CLI). For more information, see [Create an interface endpoint](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html#create-interface-endpoint-aws) in the *AWS PrivateLink Guide*.
Create an interface endpoint for Amazon Bedrock using any of the following service names:
+ `com.amazonaws.region.bedrock`
+ `com.amazonaws.region.bedrock-runtime`
+ `com.amazonaws.region.bedrock-mantle`
+ `com.amazonaws.region.bedrock-agent`
+ `com.amazonaws.region.bedrock-agent-runtime`
After you create the endpoint, you have the option to enable a private DNS hostname. Enable this setting by selecting Enable Private DNS Name in the VPC console when you create the VPC endpoint.
If you enable private DNS for the interface endpoint, you can make API requests to Amazon Bedrock using its default Regional DNS name. The following examples show the format of the default Regional DNS names.
+ `bedrock.region.amazonaws.com`
+ `bedrock-runtime.region.amazonaws.com`
+ `bedrock-mantle.region.api.aws`
+ `bedrock-agent.region.amazonaws.com`
+ `bedrock-agent-runtime.region.amazonaws.com`
## Create an endpoint policy for your interface endpoint
An endpoint policy is an IAM resource that you can attach to an interface endpoint. The default endpoint policy allows full access to Amazon Bedrock through the interface endpoint. To control the access allowed to Amazon Bedrock from your VPC, attach a custom endpoint policy to the interface endpoint.
An endpoint policy specifies the following information:
+ The principals that can perform actions (AWS accounts, IAM users, and IAM roles).
+ The actions that can be performed.
+ The resources on which the actions can be performed.
For more information, see [Control access to services using endpoint policies](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-access.html) in the *AWS PrivateLink Guide*.
**Example: VPC endpoint policy for Amazon Bedrock actions**
The following is an example of a custom endpoint policy. When you attach this resource-based policy to your interface endpoint, it grants access to the listed Amazon Bedrock actions for all principals on all resources.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Principal": "*",
"Effect": "Allow",
"Action": [
"bedrock:InvokeModel",
"bedrock:InvokeModelWithResponseStream"
],
"Resource":"*"
}
]
}
```
------
**Example: VPC endpoint policy for Amazon Bedrock Mantle actions**
The following is an example of a custom endpoint policy. When you attach this resource-based policy to your interface endpoint, it grants access to the listed Amazon Bedrock Mantle actions for all principals on all resources.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Principal": "*",
"Effect": "Allow",
"Action": [
"bedrock-mantle:CreateInference"
],
"Resource":"*"
}
]
}
```
# (Example) Restrict data access to your Amazon S3 data using VPC
You can use a VPC to restrict access to data in your Amazon S3 buckets. For further security, you can configure your VPC with no internet access and create an endpoint for it with AWS PrivateLink. You can also restrict access by attaching resource-based policies to the VPC endpoint or to the S3 bucket.
**Topics**
+ [Create an Amazon S3 VPC Endpoint](#vpc-s3-create)
+ [(Optional) Use IAM policies to restrict access to your S3 files](#vpc-policy-rbp)
## Create an Amazon S3 VPC Endpoint
If you configure your VPC with no internet access, you need to create an [Amazon S3 VPC endpoint](https://docs.aws.amazon.com/AmazonS3/latest/userguide/privatelink-interface-endpoints.html) to allow your model customization jobs to access the S3 buckets that store your training and validation data and that will store the model artifacts.
Create the S3 VPC endpoint by following the steps at [Create a gateway endpoint for Amazon S3](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-s3.html#create-gateway-endpoint-s3).
**Note**
If you don't use the default DNS settings for your VPC, you need to ensure that the URLs for the locations of the data in your training jobs resolve by configuring the endpoint route tables. For information about VPC endpoint route tables, see [Routing for Gateway endpoints](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/vpce-gateway.html#vpc-endpoints-routing).
## (Optional) Use IAM policies to restrict access to your S3 files
You can use [resource-based policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_identity-vs-resource.html) to more tightly control access to your S3 files. You can use any combination of the following types of resource-based policies.
+ **Endpoint policies** – You can attach endpoint policies to your VPC endpoint to restrict access through the VPC endpoint. The default endpoint policy allows full access to Amazon S3 for any user or service in your VPC. While creating or after you create the endpoint, you can optionally attach a resource-based policy to the endpoint to add restrictions, such as only allowing the endpoint to access a specific bucket or only allowing a specific IAM role to access the endpoint. For examples, see [Edit the VPC endpoint policy](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-s3.html#edit-vpc-endpoint-policy-s3).
The following is an example policy you can attach to your VPC endpoint to only allow it to access the bucket that you specify.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "RestrictAccessToTrainingBucket",
"Effect": "Allow",
"Principal": "*",
"Action": [
"s3:GetObject",
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::bucket",
"arn:aws:s3:::bucket/*"
]
}
]
}
```
------
+ **Bucket policies** – You can attach a bucket policy to an S3 bucket to restrict access to it. To create a bucket policy, follow the steps at [Using bucket policies](https://docs.aws.amazon.com/AmazonS3/latest/userguide/bucket-policies.html). To restrict access to traffic that comes from your VPC, you can use condition keys to specify the VPC itself, a VPC endpoint, or the IP address of the VPC. You can use the [aws:sourceVpc](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcevpc), [aws:sourceVpce](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcevpce), or [aws:VpcSourceIp](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-vpcsourceip) condition keys.
The following is an example policy you can attach to an S3 bucket to deny all traffic to the bucket unless it comes from your VPC.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "RestrictAccessToOutputBucket",
"Effect": "Deny",
"Principal": "*",
"Action": [
"s3:GetObject",
"s3:PutObject",
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::bucket",
"arn:aws:s3:::bucket/*"
],
"Condition": {
"StringNotEquals": {
"aws:sourceVpc": "vpc-11223344556677889"
}
}
}
]
}
```
------
For more examples, see [Control access using bucket policies](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-s3.html#bucket-policies-s3).