AWS Certified Generative AI Developer – Professional
Amazon Bedrock model invocation logging for AIP-C01
Model invocation logging records the full request, response and metadata of Converse, ConverseStream, InvokeModel and InvokeModelWithResponseStream calls in one account and Region. It is off by default and writes to CloudWatch Logs, S3 or both, in the same account and Region only. Content that a guardrail blocks still appears in plain text in these logs.
What it captures and where
Logging covers calls on the bedrock-runtime endpoint. You choose which modalities to log: text, image, embedding and video. Destinations are CloudWatch Logs, S3, or both. Only destinations in the same account and Region are supported, and an S3 bucket must be in the same account and Region as the logging configuration.
In S3, logs arrive as gzipped JSON files. In both destinations, input and output bodies up to 100 KB are inside the log record. Larger bodies and binary data go to S3 under a data prefix. You configure logging with PutModelInvocationLoggingConfiguration.
Central collection and retention
Because the destination must be in the same account, a multi-account setup logs to a bucket in each application account and then uses S3 replication to a central bucket. Replication needs versioning on the source and destination buckets, and the destination owner must grant the source owner permission in a bucket policy.
For records that no one may delete for a fixed time, write logs to a bucket with S3 Object Lock and a default retention period in compliance mode. In compliance mode no user, including the root user, can overwrite or delete a protected object version, and the retention period can't be shortened. After the period ends, the objects can be deleted.
Logging and guardrails
All content blocked by guardrail policies appears in plain text in model invocation logs if logging is enabled. Blocking a prompt that contains a card number does not keep the number out of the log. AWS's stated option is to disable invocation logging if you do not want blocked content stored in plain text.
Where the exam catches people
Believing each account can log straight to a central bucket in another account: destinations must be in the same account and Region, so replicate from a local bucket.
Believing a guardrail block keeps the blocked text out of the logs: blocked content appears in plain text in invocation logs.
Believing a deny bucket policy or MFA delete stops the root user deleting logs: S3 Object Lock in compliance mode does.
Believing invocation logging is on by default: it is disabled until you configure it.
Believing encrypting the log bucket meets a rule that card numbers must not be stored: the numbers are still stored, only encrypted.