A city observability team needs to follow a single resident 311 GenAI request across API Gateway, Lambda, and Bedrock. Which integration practice supports that cross-service visibility?

Municipal observability for a resident 311 GenAI request requires following one call across API Gateway, Lambda, and Bedrock. The correct integration practice is propagating distributed tracing (for example AWS X-Ray) across every service on the foundation-model call path. Correlation of segments lets city operators see latency, faults, and dependency timing as one trace rather than disconnected log islands when a 311 answer is slow or wrong.

Disabling all request IDs so logs cannot be correlated across departments fails by concept: without identifiers, cross-service root-cause analysis collapses. Tracing only kiosk UI clicks and never the Bedrock invoke segment fails because the expensive and failure-prone FM hop remains invisible. Storing every token in a public S3 bucket without tracing identifiers fails on both security (public prompt/response exposure) and observability (no structured cross-service trace).

Exam caveat: tracing must respect data-handling rules—avoid putting raw PII or full prompts into unconstrained trace annotations when policy forbids it; use redaction or hashed correlation where required. X-Ray (or OpenTelemetry equivalents) should cover the Bedrock SDK client segment, not only the HTTP edge, or FM latency will still look like a black box.

Operational check: issue a single 311 GenAI request in a test account, open the trace map, and verify linked segments for API Gateway, Lambda, and Bedrock; inject a Bedrock delay or error and confirm the failing segment is identifiable; ensure logs include the same trace or request id for handoff between platform and application teams.