AWSAWS Certified Generative AI Developer - Professional2026-103.2 Implement data security and privacy controls
Verify privacy before enabling invocation logs
Completed by the knowledge check
Learning objective
Explain Amazon Bedrock native privacy controls and its explicitly enabled Model Invocation Logging setting.
Core idea
For an architect approving a Bedrock workload, privacy requires separate answers to separate questions: who can access inference content, whether AWS retains it for a model’s operating requirements, and whether you copy it into your own observability stores. Disabling model invocation logging answers only the last question for that logging feature.
Amazon Bedrock provides native privacy boundaries, while model-specific retention and customer-configured logging remain explicit design decisions. Do not turn a statement about model-provider access into a claim about zero storage everywhere. Application histories, agent traces, source documents, and downstream tools have their own data lifetimes; see 3.2.9 and 3.2.10.
How it works
Understand the native boundary
Bedrock deploys provider models into AWS-owned and AWS-operated Model Deployment Accounts. The provider does not have access to those accounts or to customer prompts, completions, and Bedrock logs in them. The Bedrock FAQ also states that AWS and third-party providers do not use Bedrock inputs or outputs to train Amazon Nova, Amazon Titan, or third-party models.
These are distinct guarantees. Provider isolation concerns access to hosted inference content. The training statement concerns how inference data is used. Neither means your application can ignore authorization, logging, or data minimization.
The data-protection documentation requires TLS 1.2 and recommends TLS 1.3 for communication. You remain responsible for content and security configuration under the shared responsibility model. Private API paths and encryption permissions are covered in 3.2.1 and 3.2.5; they complement privacy controls rather than replacing the retention decision.
Verify model-specific retention
AWS documents zero operator access and zero data retention as Bedrock’s default data-security models, with explicit abuse-detection exceptions. The blanket claim that Bedrock never stores prompts or completions does not describe every supported model.
For example, the abuse-detection page specifies that classifier-flagged traffic for the listed OpenAI models can be retained for up to 30 days. For Anthropic Claude Fable 5 and Claude Fable 5.1, it specifies retention of all traffic for up to 30 days, with possible AWS human review of classifier-flagged traffic. The page also describes eligibility-based zero-retention arrangements. These are model-specific conditions, not a setting created by enabling invocation logging.
Retained content stays within AWS and is not shared with third-party model providers. For these models, cross-region inference can store retained input and output in the destination Region where inference executes. Verify processing and storage together; see 2.3.8 for residency routing evidence.
Bedrock exposes retention modes per Region. Projects exist only on the bedrock-mantle endpoint; bedrock-runtime requests cannot be project-scoped. For project-scoped requests, resolution uses the project setting first, then the account setting, then the model default. inherit defers to the broader scope. Runtime requests use the regional account setting, falling back to the model default. A setting in one Region does not propagate to another. A request falls back through its endpoint’s scopes to the model default.
The documented modes include:
none: no request or response content written to durable storage by AWS; incompatible models are blocked.default: the model’s retention policy applies, including any required abuse-detection retention.aws_review: permits AWS retention and human review when required for the selected model.provider_data_share: a legacy mode; AWS documents that it does not cause provider sharing and recommendsaws_reviewfor configurations that need review permission.
On the bedrock-mantle endpoint, PUT /v1/data_retention sets the account mode and GET /v1/data_retention checks it. For bedrock-runtime calls, set and check the regional account mode through the Bedrock control-plane API using PUT and GET at https://bedrock.REGION.amazonaws.com/data-retention, replacing REGION with the AWS Region. A model lookup on bedrock-mantle through GET /v1/models/{model_id} exposes data_retention.mode, source, and allowed_modes. The Bedrock control plane does not expose that per-model signal. If a runtime request targets a model requiring aws_review while the effective mode is none or default, the documented outcome is ValidationException.
Choose an approved compatible model instead of silently relaxing retention after a failure. Even the Responses API’s store=false is not a universal zero-retention guarantee; the retention documentation distinguishes customer-retrievable stored responses from retention for safety review.
Enable invocation logging deliberately
Model invocation logging is disabled by default. When enabled, it can collect request data, response data, and invocation metadata for supported calls in an AWS account and Region. Supported destinations are CloudWatch Logs and S3 in that same account and Region.
Use PutModelInvocationLoggingConfiguration to configure delivery, GetModelInvocationLoggingConfiguration to inspect it, and DeleteModelInvocationLoggingConfiguration to remove the configuration. The request’s loggingConfig contains cloudWatchConfig and s3Config destinations plus modality flags such as textDataDeliveryEnabled, imageDataDeliveryEnabled, and embeddingDataDeliveryEnabled.
This is an account-and-Region logging configuration, not a private debugging flag on one application’s request. Review the other workloads sharing that scope before enabling a modality. AWS documents logging for all models supporting the selected modalities.
Coverage is also endpoint-specific. The feature supports calls through bedrock-runtime, including Converse, ConverseStream, InvokeModel, and InvokeModelWithResponseStream. Calls through other endpoints, including bedrock-mantle, are not captured by this invocation-logging feature.
CloudWatch invocation events can contain input and output JSON bodies up to 100 KB. Larger bodies and binary data require S3 delivery; cloudWatchConfig.largeDataDeliveryS3Config supplies that destination for large payloads. Review both stores rather than assuming the log group contains the complete retention surface. See 1.6.4 for invocation-log evidence and configuration.
Deleting the logging configuration stops further delivery; records already in your log group and bucket remain under those destinations’ retention settings. Define CloudWatch log retention and S3 Lifecycle rules separately; see 3.2.10 for destination retention and deletion. Also, Guardrails masking is not a substitute for this decision: the sensitive-information documentation says invocation-log inputs contain the original unmodified request. See 3.2.9.
Key distinctions and trade-offs
Provider isolation versus AWS retention: A provider cannot access the deployment account, while AWS can retain content under documented model-specific conditions. These statements can both be true.
Service retention versus customer logging: Retention modes govern service-side handling. Invocation logging creates customer-managed copies for observability. Turning off one does not establish the state of the other.
Payload evidence versus minimized observability: Full bodies help investigate failures but expand the sensitive-data surface. Decide which evidence is necessary, who can read it, and how long each destination keeps it before enabling delivery.
Architecture / decision scenario
A financial assistant must use an approved zero-retention model and retain operational diagnostics without customer text. The assistant uses Converse through bedrock-runtime. The team sets and checks the regional account retention mode as none through the Bedrock control-plane API, then verifies the candidate model’s allowed modes through the bedrock-mantle model lookup. Project overrides do not apply to this runtime path. A model requiring review is rejected rather than becoming an automatic fallback.
The team leaves invocation logging disabled and emits sanitized application diagnostics. A separate, approved evaluation environment enables text delivery using PutModelInvocationLoggingConfiguration, after reviewing all workloads in that account and Region. It configures destination access and retention for both CloudWatch and any large-data S3 path.
The review records three results independently: effective service retention, invocation-logging configuration, and application storage behavior. An empty log group alone would prove none of them.
Common exam traps
- Treating disabled invocation logging as a guarantee of universal zero retention.
- Confusing provider isolation with the absence of AWS abuse-detection retention.
- Assuming
store=falseoverrides every model’s retention requirements. - Applying one Region’s retention configuration to every inference route.
- Expecting invocation logging to capture calls through every Bedrock endpoint.
- Removing the logging configuration and declaring delivered data deleted.
What to remember
- Verify provider access, model retention, and customer logging separately.
- Retention is model-sensitive and configured by scope and Region.
- Invocation logging is disabled by default and explicitly configured.
- Logging destinations contain sensitive copies with independent access and lifetimes.
Knowledge check
A financial assistant calls Converse through bedrock-runtime. Its policy says AWS must not write request or response content to durable storage. Model invocation logging is already disabled. What else does the policy require?
none , with a model that allows itstore=false to suppress service-side retentionstore=false is not a universal zero-retention guarantee.With the regional retention mode set to none, requests to a newly approved model return ValidationException. The model’s allowed_modes start at aws_review. What should the team do under its zero-retention policy?
aws_review for every workloadaws_review for the runtime callsnoneinherit so that the model default appliesbedrock-mantle , not to bedrock-runtime requests, and deferring to the model default still permits its required retention.A team enables model invocation logging in its account and Region, but no records appear for an application that calls the Responses API on the bedrock-mantle endpoint. What explains the gap?
bedrock-runtimebedrock-runtime calls such as Converse and InvokeModel , and calls through other endpoints, including bedrock-mantle , are not captured. Either destination, CloudWatch Logs or S3, is enough on its own.Invocation logging delivers to CloudWatch Logs with a largeDataDeliveryS3Config destination. An auditor reviews the log group and finds that some long prompts have no inline body. Where are those bodies?
After a review, the team deletes the model invocation logging configuration and reports that all previously logged prompts are erased. What is still true?
none