A company runs an order-processing application on an Amazon EC2 instance that saves orders to an Amazon Aurora database. During peak traffic the application sometimes can't write orders fast enough. What should a solutions architect do to ensure orders are written reliably to the database as quickly as possible?

The correct solution uses Amazon SQS as a buffer, decoupling the order-processing application from the database. When traffic is high, orders are reliably queued in SQS. An Auto Scaling group of EC2 instances then processes these orders from the queue and writes them to the database. This prevents the database from being overwhelmed and ensures all orders are eventually processed. Increasing the EC2 instance size and using SNS with a database endpoint subscription is incorrect because SNS is a publish/subscribe messaging service, not designed for durable message queuing and direct database integration in this manner. Using SNS with an Auto Scaling group to read from the topic is incorrect because SNS is for message fan-out, not for persistent queues that multiple consumers can reliably pull from and delete. Writing to SQS only when the EC2 instance reaches CPU thresholds is incorrect because it's a reactive approach that doesn't fully address the underlying issue of the database being overwhelmed during peak times. The SQS queue should always be used to decouple the application from the database for reliable processing.