Testing application resilience with Amazon SQS and AWS Fault Injection Service

This article demonstrates how to use AWS Fault Injection Service (FIS) and Systems Manager Automation to test application resilience by simulating SQS access failures with progressively longer disruption phases.

• Structure resilience experiments with clear hypotheses and measurable success criteria before testing
• Use scoped IAM deny policies to block SQS data-plane operations while preserving queue management capabilities
• Execute four escalating impairment phases (2, 5, 7, and 15 minutes) separated by recovery periods to surface different failure modes
• Monitor producer-side behavior (circuit breakers, buffering, fail-fast) and consumer-side behavior (backlog accumulation, recovery rates)
• Interpret CloudWatch metrics like NumberOfMessagesSent, ApproximateNumberOfMessagesVisible, and ApproximateAgeOfOldestMessage to assess resilience mechanisms
• Set stop conditions on customer-impact metrics rather than queue metrics to prevent premature experiment termination
• Implement retry logic with exponential backoff, circuit breakers, and dead-letter queues as resilience patterns

By testing application behavior under SQS access loss, teams can identify gaps in failure handling, validate recovery mechanisms, and improve observability before production incidents occur.