4 of the 6 questions we have for this objective, shown with the answer and the reasoning.
Determine opportunities for modernization and enhancements
Saltmarsh Brokerage is replacing a migrated IBM MQ queue manager that carries account ledger updates between two applications. Both applications are being rewritten during the migration to use the AWS SDK, so no JMS or other broker protocol needs to be preserved. Updates for the same account must be processed in the order they were sent and must not be applied twice, while updates for different accounts can be processed in parallel. Peak volume is 1,500 messages per second, and the team wants a fully managed, serverless service with no broker instances to size, patch, or fail over.
Which solution should the solutions architect recommend?
- AAn Amazon SQS standard queue with consumers that sort messages by timestampStandard queues provide at-least-once delivery and best-effort ordering, so duplicates and reordering can occur, and sorting in the consumer cannot reliably fix ordering across consumers.
- BAn Amazon MQ for ActiveMQ active/standby broker with a JMS queue and message groups keyed on the account IDAmazon MQ can provide ordered JMS delivery and suits migrations that must keep a broker protocol, but it runs broker instances that must be sized and that receive maintenance windows, and protocol compatibility is not required here.
- CAn Amazon SQS FIFO queue that uses the account ID as the message group ID and a deduplication ID for each updateFIFO queues preserve order within a message group and discard duplicates within the deduplication interval. Using the account ID as the group keeps per-account order while letting different accounts process in parallel.
- DAmazon EventBridge with a rule that sends updates to an AWS Lambda functionEventBridge routes events by content but does not guarantee ordering or exactly-once delivery to targets.
Why: When an existing messaging system enforces ordering and deduplication, the managed replacement must provide the same guarantees. SQS FIFO queues provide ordering per message group and exactly-once processing within the 5-minute deduplication interval, and message groups allow parallelism across keys, which matches the per-account requirement. Throughput of 1,500 messages per second is within FIFO limits, especially with high throughput mode. The deciding constraint between SQS FIFO and Amazon MQ is protocol: Amazon MQ is the right choice when applications must keep JMS, AMQP, or MQTT without code changes, but these applications are being rewritten to the AWS SDK and the team wants no brokers, which points to SQS. Standard queues and EventBridge favor scale and flexibility over strict ordering.
Determine opportunities for modernization and enhancements
Ravelin Photo rehosted its monolithic web application to a single Auto Scaling group of Amazon EC2 instances. When customers upload large batches of images, the same instances resize the images synchronously, CPU reaches 100 percent, and page requests time out. Uploads arrive in bursts of up to 30,000 images in 10 minutes, and each resize must eventually complete even if a worker fails.
Which two changes should the solutions architect recommend? Each correct answer presents part of the solution.
- AHave the web tier store each upload in Amazon S3 and send a resize message to an Amazon SQS queue instead of resizing synchronously.The queue buffers bursts and holds each message until a worker deletes it after success, so the web tier returns quickly and no resize is lost when a worker fails.
- BMove resizing to a separate Auto Scaling group of worker instances that scales on queue backlog per instance.A separate worker tier can scale independently of web traffic. Scaling on backlog per instance, derived from ApproximateNumberOfMessagesVisible, tracks the work waiting to be done.
- CChange the instance type of the existing Auto Scaling group to a larger compute-optimized size.Larger instances delay the saturation point but keep web requests and resizing competing for the same CPU, so bursts still cause timeouts.
- DPublish each upload to an Amazon SNS topic with an HTTP subscription that points at the web tier load balancer.SNS pushes messages immediately, so bursts would hit the same instances at the same rate. It adds fan-out but no buffering between the components.
- EEnable sticky sessions on the Application Load Balancer so that each user's uploads go to the same instance.Sticky sessions change which instance serves a user but not how much work each instance does, and they concentrate a large batch on one instance.
Why: Synchronous coupling between a user-facing tier and slow background work is a common problem after a lift-and-shift. Introducing a queue lets the web tier accept work at burst speed, while a separate worker tier processes it at its own pace and scales on backlog. SQS visibility timeouts and message retention ensure work is retried rather than lost if a worker fails. Vertical scaling and push-based messaging leave the two kinds of work competing for the same resources.
Determine opportunities for modernization and enhancements
Juniper Clinics has containerized a stateless patient-scheduling API that previously ran on two on-premises Linux servers. The two-person team wants to deploy the container image to AWS with an HTTPS endpoint and automatic scaling, without configuring load balancers, clusters, or servers themselves. The company is new to AWS and has never used AWS App Runner.
Which service should the solutions architect recommend?
- AAWS App RunnerApp Runner fits this shape of workload, but it is no longer open to new customers, so a company that has never used it cannot adopt it. AWS directs new users to Amazon ECS Express Mode.
- BAn Amazon ECS Express Mode serviceAn Express Mode service needs only a container image, a task execution role, and an infrastructure role, then creates a Fargate-based ECS service with an HTTPS load balancer, a URL, auto scaling, and monitoring, while leaving the resources accessible for later tuning.
- CAn Amazon EKS cluster with managed node groupsEKS gives full Kubernetes control, but the team would need to manage cluster add-ons, ingress, and node groups, which is far more than a small team running one API needs.
- DAmazon EC2 instances in an Auto Scaling group running DockerThis recreates the on-premises servers in AWS and leaves patching, scaling configuration, and load balancer setup to the team.
Why: For a single stateless web API and a small team, the best container service is the one with the fewest moving parts to configure. Amazon ECS Express Mode applies production defaults across Fargate, Elastic Load Balancing, auto scaling, and CloudWatch from a container image, with no additional charge beyond the resources it creates. App Runner was the usual answer for this pattern but is no longer open to new customers, and EKS and self-managed EC2 add operational work the scenario wants to avoid.
Determine opportunities for modernization and enhancements
Velmora Shop stores shopping carts and user sessions in tables of a relational database that it migrated to Amazon RDS for MySQL. Every request reads or writes a single item by user ID, there are no joins, and traffic jumps from 2,000 to 80,000 requests per second during flash sales. The cart service needs consistent single-digit millisecond latency at any scale and the team wants no capacity planning.
Which database should the solutions architect recommend for the cart and session data?
- AAmazon DynamoDB in on-demand capacity modeDynamoDB is a key-value and document database that delivers single-digit millisecond latency at any scale, and on-demand mode absorbs sudden traffic spikes without capacity planning.
- BAmazon NeptuneNeptune is a graph database for highly connected data and relationship queries, which this key-value access pattern does not need.
- CAmazon Aurora MySQL with additional read replicasRead replicas scale reads but not writes, and cart updates are writes. Aurora would still require instance sizing for flash-sale peaks.
- DAmazon Timestream for LiveAnalyticsTimestream is built for time-series measurements such as metrics and sensor data, not for updating individual cart items by key.
Why: Purpose-built databases match the engine to the access pattern. Cart and session data are accessed by a single key with no joins, which is a key-value workload. DynamoDB delivers consistent single-digit millisecond performance at virtually any scale, and on-demand capacity mode handles sudden spikes without capacity planning. Relational, graph, and time-series engines each optimize for other patterns.