Design highly available and/or fault-tolerant architectures

Copperleaf Delivery runs an order flow across an API Gateway REST API, four Lambda functions, an SQS queue, and a DynamoDB table. Customers report that some orders take over 8 seconds to confirm, but each service's own CloudWatch metrics look healthy and the logs for a single order are spread across six log groups. The team wants to see, for an individual slow request, how long each service and downstream call took and where errors originated.

Which service should the team use?

1. AEnable AWS X-Ray tracing on API Gateway and the Lambda functions and use the service map and trace view to inspect slow requests.X-Ray is the distributed tracing service: it follows a request across services, records segment timings for each hop and downstream call, and highlights where latency and errors arise.
2. BEnable detailed monitoring on the Lambda functions and the API stage to get 1-minute CloudWatch metrics for every service.Finer-grained aggregate metrics still describe each service in isolation and cannot follow one request across services.
3. CCreate a CloudWatch dashboard that shows the average duration of each Lambda function side by side.Averages hide the few slow requests and the dashboard does not correlate a single order across the services it touched.
4. DEnable AWS CloudTrail data events for the DynamoDB table and search for slow PutItem calls.CloudTrail records API activity for auditing; it does not record latency breakdowns of application requests.

Fallowmere Credit Union has 120 EBS volumes, 14 RDS DB instances, 6 DynamoDB tables, and 3 EFS file systems across two accounts in an AWS Organization. Auditors require daily backups retained for 35 days, a monthly backup retained for 7 years, and a copy of every backup in a second AWS Region. Today each team runs its own snapshot scripts and coverage gaps have been found.

Which solution will meet these requirements with the LEAST operational overhead?

1. AStandardize the existing snapshot scripts in a shared repository, add cross-Region copy steps, and run them for both accounts from a central EC2 instance with cron.Scripts still require maintenance per service, do not enforce coverage, and the central instance becomes a single point of failure for the backup process.
2. BCreate AWS Backup plans with daily and monthly rules, 35-day and 7-year retention, cross-Region copy actions, and assign resources by tag through an Organization backup policy.AWS Backup centrally schedules, retains, copies across Regions, and reports on backups for EBS, RDS, DynamoDB, EFS, and more, and Organization backup policies enforce the plan across accounts.
3. CEnable Amazon Data Lifecycle Manager for the EBS volumes and rely on automated backups for RDS and point-in-time recovery for DynamoDB.These per-service features do not provide one view of compliance, do not cover EFS, and automated RDS backups cannot be retained for 7 years.
4. DUse AWS Config rules to detect resources without a recent snapshot and notify the teams to take one.Config detects gaps but does not create backups, so the teams are still responsible for performing and copying them.

Vexley Commerce runs its order database on an Amazon Aurora MySQL cluster in us-east-1. A regulatory review requires that if the entire us-east-1 Region becomes unavailable, the database must be writable in eu-west-1 within 1 minute with no more than 1 second of data loss. Vexley also wants to serve read-only reporting queries from eu-west-1 during normal operation.

Which solution will meet these requirements?

1. ACreate an Aurora MySQL cross-Region read replica in eu-west-1 using MySQL binary log replication.Binlog-based cross-Region replicas typically lag by seconds or more and promotion is a slower manual process, so the 1-second RPO and 1-minute RTO are not reliably met.
2. BEnable automated backups and copy snapshots to eu-west-1 every 5 minutes.Snapshot copies give an RPO of minutes at best and a restore takes far longer than 1 minute.
3. CConvert the cluster to an Aurora Global Database with a secondary cluster in eu-west-1 and use managed failover during a Regional outage.Aurora Global Database replicates at the storage layer with typical lag under 1 second and can promote the secondary Region to full read/write in under a minute, while the secondary serves reads in the meantime.
4. DDeploy a second independent Aurora cluster in eu-west-1 and use AWS Database Migration Service for ongoing replication.DMS change data capture adds its own latency and operational burden and provides no fast managed promotion of the target cluster.

Skylark Mobility operates a scooter-sharing app with riders in North America, Europe, and Asia. Ride and unlock events are stored in an Amazon DynamoDB table named Rides in us-west-2. Riders in Europe and Asia experience high write latency, and the company wants the application to keep accepting writes in every Region even if one Region is unavailable. The application already uses the DynamoDB API and can be deployed in multiple Regions.

Which solution will meet these requirements with the LEAST operational overhead?

1. ACreate separate DynamoDB tables in each Region and use DynamoDB Streams with Lambda functions to copy writes between them.This is a self-built replication system that must handle conflicts, retries, and monitoring, which is far more overhead than the managed feature.
2. BPlace the application behind AWS Global Accelerator with endpoints in each Region so that all Regions write to the table in us-west-2 over the AWS backbone.Global Accelerator improves network path performance but every write still travels to a single Region, which remains a single point of failure and keeps cross-continent latency.
3. CDeploy a DynamoDB Accelerator (DAX) cluster in us-west-2 in front of Rides and have the European and Asian deployments read and write through it.DAX is an in-Region cache that accelerates reads; writes still travel to us-west-2 with the same latency, and nothing can be written if us-west-2 is unavailable.
4. DConvert Rides to a DynamoDB global table with replicas in us-west-2, eu-central-1, and ap-southeast-1, and have each Region's application write to its local replica.Global tables provide fully managed multi-active replication, so each Region reads and writes locally with low latency and continues operating if another Region fails.