AWSAWS Certified Generative AI Developer - Professional2026-102.3 Design and implement enterprise integration architectures

Verify residency across every processing route

Completed by the knowledge check

Learning objective

Design data residency using Regions, Outposts, Wavelength, and hybrid routing; verify actual processing and storage locations.

Core idea

Residency is a property of the complete data path. An application deployed in an approved Region can send prompts to another Region, copy evidence to a different storage location, or place sensitive outputs in a log destination. A local frontend does not prove local inference.

For an architect designing a constrained enterprise workload, separate four questions: where data is received, where it is processed, where it is stored, and where it can move during failure or recovery. Then verify the route’s configured possibilities and the locations observed at runtime.

AWS Regions, Outposts, and Wavelength provide different placement options. They do not turn every service call into a local operation. A hybrid network route determines connectivity; the selected service and inference configuration determine where processing occurs.

How it works

Specify the boundary before choosing placement

Write the allowed location for each data class and operation. A policy allowing processing anywhere within an approved geography is different from one requiring processing in a single Region or on customer premises. Treat raw documents, retrieved passages, prompts, generated outputs, and operational logs as separate entries if their rules differ.

For each hop, record the source, destination service, configured resource location, processing route, and storage destination. Record the failure path too. This inventory is application architecture evidence, not an AWS API that proves the entire workload compliant in one call.

A useful release question is whether every reachable route satisfies the policy. A runtime observation that one request stayed in an approved location cannot establish that all possible destinations are approved. Conversely, approved configuration does not prove that an application actually used it. You need both types of evidence.

Verify regional inference and cross-Region routes

Amazon Bedrock cross-Region inference uses inference profiles that define a model and destination Regions. Geographic profiles route within a specified geography; global profiles can route across supported commercial Regions worldwide. See 1.2.4 for the invocation and authorization comparison. Here, the deciding factor is the allowed processing boundary.

A geographic label is not enough for verification. Call GetInferenceProfile from every intended source Region with inferenceProfileIdentifier and inspect the Regions in models[].modelArn. AWS documents that destinations can differ with the source Region. Compare every returned destination with the approved list before admitting that configuration.

If policy requires one Region, do not treat a multi-Region geographic profile as equivalent. Select an eligible regional inference route or a separately hosted model that meets the required boundary. If the necessary model lacks an eligible route, the design must change; a gateway cannot make an incompatible processing destination compliant by hiding it behind a local URL.

A service control policy (SCP) that blocks a destination Region without an inference-profile exception makes the profile request fail; it does not trim the profile to the permitted subset. If the SCP carries an inference-profile exception, the profile can still route to the excepted Regions. Review the exception as part of the residency boundary; see 1.2.4. AWS also documents possible storage of prompts and results in destination opt-in Regions for abuse detection; include this in the storage review.

For actual cross-Region processing evidence, CloudTrail records requests in the source Region. Inspect additionalEventData.inferenceRegion to identify the processing Region. Keep the configured destination set and the observed processing Region as different audit fields. The first bounds what can happen; the second records what happened.

Place local processing deliberately

AWS Outposts extends AWS infrastructure to customer premises and provides local compute and storage. An Outpost is managed as part of an AWS Region. Its service link connects it to the associated Region. An Outposts rack’s local gateway connects it with the on-premises network; an Outposts server uses a local network interface for that connection.

Use local compute for a processing step only after verifying the required resource and capability on the selected Outposts form factor. The rack and server service matrices differ. An EC2 instance placed locally can still send sensitive input to a regional service, so inspect its downstream calls rather than inferring locality from the instance’s subnet.

Wavelength places compute and storage at the edge of communications service provider networks. A Wavelength Zone is associated with a parent Region and managed by that Region’s control plane. It supports resources including EC2 instances, EBS volumes, VPC subnets, and carrier gateways.

The carrier gateway supports traffic to and from the carrier network and outbound traffic to the internet. Regional services remain reachable through the connected VPC. Choose Wavelength when the carrier-edge placement serves the workload’s latency or resiliency needs, then verify each processing and storage hop. It is not interchangeable with customer-premises placement through Outposts.

Neither an Outposts placement nor a Wavelength placement, by itself, establishes the location of a Bedrock invocation. A call from local or edge compute still needs an eligible managed-service route. Distinguish locally hosted processing from a locally hosted caller of remote processing.

Review hybrid routing and retained copies

AWS Direct Connect provides virtual interfaces to public AWS services or a VPC. A public virtual interface reaches public services; a private virtual interface reaches a VPC. A connection in a public Region can provide access to public AWS services in other public Regions. Therefore, private connectivity and a nearby connection location are not proofs of regional processing.

Verify the application endpoint and destination resource separately from the network path. Define which routes may carry each data class and reject unintended destinations in the application’s routing policy. For a required local operation, a network failure must not silently redirect sensitive input to a regional model. Choose a denied or deferred outcome if no approved route is available.

Bedrock model invocation logging can retain full request and response data in CloudWatch Logs or S3. Its supported destinations must be in the same account and Region as the logging configuration. It is disabled by default, and its capture support is scoped to the bedrock-runtime endpoint. Review the logging configuration and destination resource rather than assuming operational logs contain only harmless metadata.

Inventory application logs, source stores, vector projections, and recovery copies as well. Their placement requires evidence from their own configurations. The Bedrock inference processing field does not certify those independent storage paths.

Key distinctions and trade-offs

Region versus geography: A permitted geography can contain several Regions. A geography-bounded inference profile does not satisfy a policy demanding one specific Region unless all possible destinations meet it.

Outposts versus Wavelength: Outposts provides customer-premises placement. Wavelength provides carrier-edge placement linked to a parent Region. Choose by the physical processing requirement and supported resources, not by the generic word “edge.”

Connectivity versus residency: Direct Connect controls the network connection to AWS. It does not limit every service invocation to the connection’s associated Region.

Processing evidence versus storage evidence: inferenceRegion records cross-Region inference processing. Resource and logging configurations establish separate storage destinations.

Architecture / decision scenario

A manufacturer has three policies: raw plant records remain on premises, a mobile support application needs carrier-edge responsiveness, and sanitized summaries may be processed within an approved geography.

You evaluate supported Outposts compute for the local transformation and keep the raw-record processing path on premises. You place the mobile application’s eligible compute in a Wavelength Zone, but review its parent-Region and downstream calls separately. Direct Connect carries approved enterprise traffic; its virtual-interface configuration does not replace destination checks.

For sanitized summaries, you inspect the Bedrock profile from each source Region and approve only its verified destination set. Production audit records the CloudTrail processing Region and the configured log destinations. A simulated outage confirms that the plant branch defers work rather than sending raw data to the summary route.

Common exam traps

Assuming the request’s source Region is its inference processing Region.
Using a geographic profile label instead of inspecting destinations.
Treating Outposts and Wavelength as identical physical locations.
Assuming Direct Connect restricts calls to one Region.
Verifying inference while ignoring prompt, output, and log storage.
Allowing emergency fallback to bypass the residency policy.

What to remember

Define permitted receipt, processing, storage, and recovery locations separately.
Inspect profile destinations from every intended source Region.
Use additionalEventData.inferenceRegion for observed cross-Region processing.
Verify local and edge service support and downstream calls.
Test failure routes against the same residency policy as normal routes.