A company uses GPS trackers to document migration patterns of thousands of sea turtles. Trackers check every 5 minutes and, if a turtle moved more than 100 yards (91.4 meters), they send new coordinates to a web application running on three Amazon EC2 instances across multiple Availability Zones in one AWS Region. Recently the web application was overwhelmed by an unexpected volume of tracker data, and data was lost with no way to replay events. A solutions architect must prevent this from happening again with the least operational overhead. What should the solutions architect do?

The correct answer is to use an Amazon SQS queue. SQS is a fully managed message queuing service that decouples sending and receiving components. When the web application is overwhelmed, SQS can buffer the incoming tracker data, preventing data loss and allowing the EC2 instances to process messages at their own pace. This provides elasticity and fault tolerance with minimal operational overhead. Storing data in an Amazon S3 bucket would require the application to constantly scan for new objects, which is inefficient for real-time data streams and adds complexity. An Amazon API Gateway endpoint with AWS Lambda could process data concurrently, but API Gateway has payload size limits and Lambda has execution duration limits, which might be problematic for large, continuous streams of data, and it doesn't inherently provide a buffer for overwhelming traffic like SQS does. Using an Amazon DynamoDB table to store data would require the application to poll the table for new items, which is less efficient for a queueing pattern and adds unnecessary read/write operations compared to SQS.