The requirement is specifically to validate critical user journeys and API endpoints after each deployment and before routing traffic . The most direct AWS-native way to test “real” user flows and endpoints automatically is CloudWatch Synthetics canaries , which can run scripted checks (HTTP/API and browser-style journeys).

Option D minimizes operational overhead because it uses a straightforward managed pattern:

Canaries run against the new deployment to validate endpoints and journeys.

CloudWatch alarms trigger when the canaries fail (objective signal of broken journeys/APIs).

The solution then uses alarm-driven rollback (the intent here is automated rollback without writing custom analysis code or managing multi-service workflows).

Why the other options have more overhead or miss the “user journey/API validation” goal as cleanly:

A focuses on ECS task states (healthy/unhealthy tasks). That can detect deployment failures, but it doesn’t validate critical user journeys or API correctness . Also requires custom Lambda logic for analysis + rollback control.

B adds even more moving parts (Application Insights + alarms + EventBridge + Step Functions). Also, monitoring KPIs is not the same as explicitly validating journeys/endpoints before routing traffic .

C is the highest overhead: canaries plus X-Ray instrumentation across all microservices, trace exporting, custom Lambda analysis, etc. That’s heavy compared to canary + alarm.

So D best matches: “validate journeys/endpoints” + “automated detect + rollback” with least operational overhead by relying on managed canaries and alarms rather than custom code/workflows.