Validate Model Invocation Log Destination Ownership

Sign in to the AWS Management Console.

Navigate to Amazon Bedrock console available at https://console.aws.amazon.com/bedrock/.

In the main navigation panel, select Settings to access the account level settings available for Amazon Bedrock.

In the Model invocation logging section, verify that the Model invocation logging toggle switch is enabled, then identify the configured log destination(s) under Select the logging destinations. Note the S3 location (destination bucket name) and/or the Log group name used for delivery.

If an S3 location is configured, navigate to the Amazon S3 console at https://console.aws.amazon.com/s3/ and check the Buckets list. If the destination bucket is not listed among the buckets in your account, the bucket is owned by a different AWS account, therefore the log destination configuration is not compliant.

Click on the name of the destination S3 bucket, then select the Permissions tab. In the Block public access (bucket settings) section, check the status of Block all public access. If Block all public access is set to Off (or any of the four individual settings is disabled), the destination bucket is publicly accessible, therefore the log destination configuration is not compliant. In addition, review the Access column status shown for the bucket in the Buckets list — if it reads Public, the invocation logs are exposed to public access.

If a CloudWatch Logs destination is configured, navigate to the CloudWatch console at https://console.aws.amazon.com/cloudwatch/, select Log groups under Logs, and confirm that the configured log group exists within your account and region. If the log group is not present in your account, the log destination configuration is not compliant.

Change the AWS cloud region from the console navigation bar and repeat steps no. 3 – 7 for each region where Amazon Bedrock model invocation logging is configured.

Run get-caller-identity command (OSX/Linux/UNIX) to return the ID of the AWS account that owns your Amazon Bedrock resources:

aws sts get-caller-identity
--query 'Account'

The command output should return the requested AWS account ID:

"123456789012"

Run get-model-invocation-logging-configuration command (OSX/Linux/UNIX) with custom output filters to describe the log destination configured for Amazon Bedrock model invocation logging in the selected AWS region:

aws bedrock get-model-invocation-logging-configuration
--region us-east-1
--query 'loggingConfig.{S3Bucket:s3Config.bucketName,LogGroup:cloudWatchConfig.logGroupName}'

The command output should return the configured Amazon S3 bucket name and/or CloudWatch Logs log group name:

{
    "S3Bucket": "cc-bedrock-invocation-logs",
    "LogGroup": "cc-bedrock-modelinvocations"
}

If the output returns null, model invocation logging is not enabled in the selected region and there is no destination to validate.

Run head-bucket command (OSX/Linux/UNIX) using the destination bucket name returned at the previous step, together with the account ID returned at step no. 2 as the value of the --expected-bucket-owner parameter, to verify that the destination bucket is owned by your AWS account (the command does not produce an output on success):

aws s3api head-bucket
--bucket cc-bedrock-invocation-logs
--expected-bucket-owner 123456789012

If the head-bucket command returns an "An error occurred (403)" (Forbidden) response, the destination bucket is not owned by the expected AWS account, therefore the log destination configuration is not compliant:

An error occurred (403) when calling the HeadBucket operation: Forbidden

Run get-public-access-block command (OSX/Linux/UNIX) using the destination bucket name as the identifier parameter to return the S3 Block Public Access feature configuration set for the log destination bucket:

aws s3api get-public-access-block
--bucket cc-bedrock-invocation-logs
--query 'PublicAccessBlockConfiguration'

The command output should return the requested configuration information:

{
    "BlockPublicAcls": false,
    "IgnorePublicAcls": false,
    "BlockPublicPolicy": false,
    "RestrictPublicBuckets": false
}

If the get-public-access-block command output returns false for any of the four settings (as shown in the example above), or returns the "NoSuchPublicAccessBlockConfiguration" error, the S3 Block Public Access feature is not fully enabled for the destination bucket, therefore the log destination is publicly accessible and the configuration is not compliant.

(Optional) Run get-bucket-policy-status command (OSX/Linux/UNIX) using the destination bucket name as the identifier parameter to confirm whether the destination bucket is currently evaluated as public:

aws s3api get-bucket-policy-status
--bucket cc-bedrock-invocation-logs
--query 'PolicyStatus.IsPublic'

If the command output returns true, the destination bucket policy grants public access, therefore the log destination configuration is not compliant.

If a CloudWatch Logs destination is configured, run describe-log-groups command (OSX/Linux/UNIX) using the configured log group name as the value of the --log-group-name-prefix parameter to confirm that the log group exists within your AWS account and region:

aws logs describe-log-groups
--region us-east-1
--log-group-name-prefix cc-bedrock-modelinvocations
--query 'logGroups[*].logGroupName'

If the command output returns an empty array, the configured log group does not exist in your account and the log destination configuration is not compliant.

Change the AWS cloud region by updating the --region command parameter value and repeat steps no. 3 – 9 for each region where Amazon Bedrock model invocation logging is configured.

Sign in to the AWS Management Console.

Navigate to Amazon S3 console at https://console.aws.amazon.com/s3/.

Click on the name of the Amazon Bedrock log destination bucket that you want to reconfigure (see Audit section part I to identify the right resource).

Select the Permissions tab from the S3 console menu to access the bucket permissions.

In the Block public access (bucket settings) section, choose Edit, select the Block all public access checkbox to activate all four feature settings, and choose Save changes.

In the Edit Block public access (bucket settings) dialog box, type confirm in the appropriate box, then choose Confirm to apply the configuration changes.

If the current destination bucket is not owned by your AWS account, navigate to the Amazon Bedrock console at https://console.aws.amazon.com/bedrock/, select Settings from the main navigation panel, and in the Model invocation logging section choose Edit. Under Select the logging destinations, update the S3 location (and/or Log group name) to a trusted, account-owned destination, then choose Save settings.

Change the AWS cloud region from the console navigation bar and repeat steps no. 3 – 7 for each region where a non-compliant model invocation log destination is configured.

Run put-public-access-block command (OSX/Linux/UNIX) using the name of the destination bucket that you want to reconfigure as the identifier parameter (see Audit section part II to identify the right resource), to enable the S3 Block Public Access feature for the log destination bucket (the command does not produce an output):

aws s3api put-public-access-block
--region us-east-1
--bucket cc-bedrock-invocation-logs
--public-access-block-configuration BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true

If the configured destination is not owned by your AWS account, run put-model-invocation-logging-configuration command (OSX/Linux/UNIX) to reconfigure Amazon Bedrock model invocation logging to deliver logs to a trusted, account-owned Amazon S3 bucket (the command does not produce an output):

aws bedrock put-model-invocation-logging-configuration
--region us-east-1
--logging-config 's3Config={bucketName="cc-bedrock-invocation-logs",keyPrefix="invocation-logs"},textDataDeliveryEnabled=true,imageDataDeliveryEnabled=true,embeddingDataDeliveryEnabled=true'

Change the AWS cloud region by updating the --region command parameter value and repeat steps no. 1 and 2 for each region where a non-compliant model invocation log destination is configured.