Which solution meets these requirements?

By:
In: SAP-C02
Tagged:
With: 2 Comments
A company has developed a mobile game.The backend for the game runs on several virtual machines located in an on-premises data center.The business logic is exposed using a REST API with multiple functions.Player session data is stored in central file storage.Backend services use different API keys for throttling and to distinguish between live and test traffic.The load on the game backend varies throughout the day.During peak hours, the server capacity is not sufficient.There are also latency issues when fetching player session data.Management has asked a solutions architect to present a cloud architecture that can handle the game’s varying load and provide low-latency data access.The API model should not be changed.

Which solution meets these requirements?

Implement the REST API using a Network Load Balancer (NLB). Run the business logic on an Amazon EC2 instance behind the NLB. Store player session data in Amazon Aurora Serverless.

Implement the REST API using an Application Load Balancer (ALB). Run the business logic in AWS Lambda. Store player session data in Amazon DynamoDB with on-demand capacity.

Implement the REST API using Amazon API Gateway. Run the business logic in AWS Lambda. Store player session data in Amazon DynamoDB with on-demand capacity.

Implement the REST API using AWS AppSync. Run the business logic in AWS Lambda. Store player session data in Amazon Aurora Serverless.

Explanations:

Using a Network Load Balancer (NLB) and running business logic on Amazon EC2 does not efficiently handle varying loads, as EC2 instances require manual scaling. Storing player session data in Amazon Aurora Serverless could help with latency, but the overall architecture does not meet the requirement for low-latency and flexible scaling under varying loads.

An Application Load Balancer (ALB) with AWS Lambda can handle variable loads and provide low-latency access. However, AWS Lambda is stateless and would require changes to the API model, which is not allowed. Additionally, while storing player session data in Amazon DynamoDB with on-demand capacity offers scalability, the need to change the API model disqualifies this option.

Implementing the REST API using Amazon API Gateway allows for seamless scaling and low-latency access. Running the business logic in AWS Lambda provides automatic scaling and cost-effectiveness. Storing player session data in Amazon DynamoDB with on-demand capacity ensures quick access and flexibility during varying loads. This option meets all the specified requirements without changing the API model.

While AWS AppSync can facilitate data access and run business logic in AWS Lambda, it introduces GraphQL, which changes the API model that the management wants to maintain as a REST API. Additionally, using Amazon Aurora Serverless for player session data does not provide the same low-latency capabilities as DynamoDB, making this option less suitable.

2026-03-19

2 Comments

  1. Karen
    Author

    I map out that the answer is:
    Implement the REST API using Amazon API Gateway. Run the business logic in AWS Lambda. Store player session data in Amazon DynamoDB with on-demand capacity.

  2. Mary
    Author

    I categorize that the answer is:
    Implement the REST API using Amazon API Gateway. Run the business logic in AWS Lambda. Store player session data in Amazon DynamoDB with on-demand capacity.

Leave a Reply to Karen Cancel reply

Your email address will not be published. Required fields are marked *

four − one =