How to Trace ECS Microservice Purchase Latency with AWS X-Ray?

SOA-C03 By islever Editorial Last updated Oct 20, 2026

Identify and remediate issues by using monitoring and availability metrics. Implement metrics, alarms, and filters by using AWS monitoring and logging services.

Short answer

A Deploy the AWS X-Ray daemon as an ECS sidecar, instrument with the X-Ray SDK, and use the service map to trace purchase latency across microservices.

Question

An ecommerce company runs a microservices application on Amazon ECS. Customers sometimes experience high latency when the customers attempt to complete a purchase through the application.
A CloudOps engineer needs a solution to track individual transactions across multiple services to identify where latency is occurring. The solution must require minimal code changes and must provide a visual representation of service dependencies.
Which solution will meet these requirements?

Set up the AWS X-Ray daemon as a sidecar container. Instrument the application code by using the X-Ray SDK. Use the service map to visualize request flows to identify latency. Correct Answer
Configure an Amazon CloudWatch agent on ECS containers as a sidecar container. Create custom metrics for each service. Set up CloudWatch dashboards to monitor response times.
Use Amazon VPC Flow Logs to collect logs for microservices that run on the ECS container. Monitor network traffic, and use the service map to identify latency between microservices.
Use Amazon CloudWatch Container Insights as a sidecar container to collect container metrics. Monitor response times, and visualize request flows to identify latency.

Key Takeaways

The exam tests whether you can distinguish distributed tracing and a service map from metrics-only or network-flow tools; the trap is choosing CloudWatch Container Insights or VPC Flow Logs for per-transaction latency.

This SOA-C03 scenario asks for end-to-end transaction tracing across ECS microservices with minimal code changes and a visual dependency map. The correct solution is AWS X-Ray with the daemon sidecar, SDK instrumentation, and the service map.

Common mistake: A common mistake is picking CloudWatch Container Insights because it monitors ECS, but it provides container resource metrics and logs, not end-to-end request traces or a service dependency map.

Expert Analysis

Why the Answer Is Correct

AWS X-Ray is the AWS distributed tracing service designed to follow a single request across microservices, which directly matches the requirement to track individual purchase transactions. Running the X-Ray daemon as a sidecar container on ECS lets the application send trace segments without managing a separate daemon fleet. The X-Ray SDK adds trace headers and instrumentation with targeted code changes, and the service map visualizes service dependencies and highlights where latency accumulates. The one available learner comment also aligns with this choice, with Bad_Mat selecting X-Ray "as a sidecar container" for request-flow visualization. Therefore A is the best fit.

Why the Other Options Are Wrong

B uses CloudWatch custom metrics and dashboards; it can show response times per service but requires custom instrumentation and does not natively assemble one transaction across services or produce a service map. C uses VPC Flow Logs, which capture IP-level network metadata, not application transaction spans, and there is no X-Ray-style service map tied to microservice requests. D incorrectly treats Container Insights as a tracing sidecar; Container Insights collects container and cluster metrics/logs but does not visualize request flows or trace individual transactions. None of these options provides the end-to-end dependency map required for locating purchase latency.

Community Comment Notes

Only one learner response is present: Bad_Mat chose A and described setting up the X-Ray daemon as a sidecar plus using the service map to visualize request flows. That reasoning matches the question's demand for distributed transaction tracing across services. There is no contrary community evidence to weigh, so the technical analysis remains decisive.

Official Reference

These links open the official vendor documentation in a new tab.

Exam Strategy

When an SOA-C03 question asks for individual transactions, end-to-end tracing, or a service dependency map, look for AWS X-Ray rather than CloudWatch metrics or VPC Flow Logs. Verify that the option includes the X-Ray daemon and service map, not just container monitoring.

Frequently Asked Questions

Why not use CloudWatch Container Insights for ECS transaction tracing?

Container Insights reports container and cluster metrics and logs, but it does not trace one request across services or generate an X-Ray-style service dependency map.

Does Amazon VPC Flow Logs provide a service map for microservice latency?

No. VPC Flow Logs capture network flow metadata, not application transaction spans, so they cannot show per-request latency between microservices.

More SOA-C03 FAQ →

Discussion 1 contributions

Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.

From public community threads 1

Bad_Mat 👍 1 Answered A

A. Set up the AWS X-Ray daemon as a sidecar container. Instrument the application code by using the X-Ray SDK. Use the service map to visualize request flows to identify latency.

Reader comments & corrections

No reader corrections yet — spotted an error or have a note? Share it below.

Practice All SOA-C03 Questions

Access 100 questions with complete answers and detailed explanations.

View Full SOA-C03 Practice Test →

← Back to SOA-C03 Study Guide