Option A is correct because the problem is not total model runtime; the problem is perceived UI responsiveness. AWS documentation states that the Amazon Bedrock InvokeModelWithResponseStream API returns the model response as a stream. AWS also explains that streaming allows an application to access responses in chunks without waiting for the entire result. This lets the frontend display generated content as tokens or chunks arrive, improving the user experience even when the total inference duration remains unchanged.

This option also preserves the stated constraints. It does not require changing the foundation model, increasing token counts, provisioning extra compute, or reducing the model’s actual inference time. Instead, it changes how the response is delivered to the user. This is exactly the right pattern when users perceive slowness because the interface waits for the full completion before rendering anything. AWS examples for Bedrock streaming show applications processing response streams in real time, which supports interactive applications during high-concurrency periods.

The monitoring portion of option A is also aligned with AWS guidance. Amazon Bedrock runtime publishes CloudWatch metrics for invocation volume, latency, token consumption, error rates, and model invocation logging delivery. CloudWatch GenAI observability can track invocation count, token usage, and errors using built-in views. This supports audit and compliance visibility across Regions.

Option B adds caching of partially processed fraud explanations, which can be risky for regulated transaction-specific explanations and does not solve the UI issue for unique requests. Option C changes inputs by condensing them, which violates the constraint not to modify token counts or inputs. Option D focuses on Lambda concurrency and log retention, which does not address waiting for the full model response. Therefore, response streaming with CloudWatch and tracing is the correct solution.