2.4 - Performance, throughput and integration services

AWS Solutions Architect Professional objective 2.4 covers designing for performance, throughput, and service integration. You protect backend Lambdas with API Gateway throttling limits plus usage plans and API keys for per-partner quotas, and process each order exactly once in order with an SQS FIFO queue using a deduplication ID and a message group ID. Kinesis Data Streams scales by adding shards and gives each consumer a dedicated pipe with enhanced fan-out, DynamoDB gets microsecond reads from DynamoDB Accelerator (DAX) without changing API calls, and a Tape Gateway virtual tape library retires physical tape with minimal change. Latency-based routing sends users to the closest Region, step scaling adds instances in graduated bands, AWS Global Accelerator plus latency routing front Regional NLBs, a Glue crawler auto-discovers tables for Athena, and the EventBridge schema registry with discovery lets consumers generate typed code. Expect scenarios about exactly-once ordering, a lagging stream consumer, or microsecond reads, and ask which throughput or integration feature fits.

Memory hook
Exactly-once, ordered per customer = SQS FIFO with dedup ID + message group ID. Give each stream consumer its own read pipe = Kinesis enhanced fan-out. Microsecond DynamoDB reads, no code change = DAX.

Practice questions

1. A new web tier must survive the loss of an entire Availability Zone with no manual action. Which design achieves this?

  • An Auto Scaling group spanning multiple AZs behind an Application Load Balancer (correct answer)
  • A single large EC2 instance with an Elastic IP reattached on failure
  • Instances in one AZ with hourly AMIs copied to another AZ
  • A Multi-AZ RDS database fronting stateless instances in one AZ

An ASG across multiple AZs behind an ALB automatically replaces lost instances and the ALB stops routing to the failed AZ, so an AZ loss is handled with no manual step. The other options concentrate compute in one AZ or rely on manual/slow recovery.

2. A public REST API will be built on Amazon API Gateway backed by Lambda. Architects must protect backend functions from traffic spikes and abusive clients while giving registered partners predictable request quotas. Which TWO API Gateway features address these needs? (Choose TWO.)

  • Deploy each Lambda function inside a dedicated VPC with private subnets and custom route tables
  • Configure throttling limits (steady-state rate and burst) on the stage or method (correct answer)
  • Attach usage plans with API keys to enforce per-partner quotas and rate limits (correct answer)
  • Enable AWS X-Ray active tracing on the API to visualize request latency

Stage or method throttling caps the steady rate and burst, shielding Lambda from spikes and abuse, while usage plans tied to API keys give each partner a predictable quota and rate limit. Putting Lambda in a VPC does not limit inbound API traffic, and X-Ray only observes latency without controlling load.

3. A serverless API sees traffic bursts that briefly exceed the backend's safe capacity, and the team wants the API layer to smooth requests to a fixed rate and reject the overflow with a clear error. Which API Gateway setting does this?

  • Method-level throttling that returns HTTP 429 above the configured rate (correct answer)
  • A longer integration timeout so slow bursts are absorbed by the backend
  • Caching every response for a few seconds to avoid hitting the backend
  • Switching the endpoint type from regional to edge-optimized for lower latency

Method-level throttling enforces a fixed request rate and returns HTTP 429 (Too Many Requests) for overflow, smoothing bursts before they reach the backend. A longer timeout does not limit rate, caching only helps identical repeat reads, and endpoint type changes latency, not throughput protection.

4. A latency-sensitive Lambda function suffers cold starts during traffic ramps, and a separate, less important function in the same account sometimes consumes so much concurrency that the sensitive one gets throttled. Which combination fixes both issues?

  • Increase the memory size of the sensitive function and enable SnapStart on the noisy neighbor function
  • Provisioned concurrency on the sensitive function and reserved concurrency to cap the noisy one (correct answer)
  • Move the sensitive function to $LATEST and raise the account concurrency quota
  • Add an SQS queue in front of the sensitive function so requests are buffered

Provisioned concurrency keeps warm execution environments ready so the sensitive function avoids cold starts, and reserved concurrency on the noisy function both guarantees it a share and caps it so it cannot starve the sensitive one. More memory does not stop noisy-neighbor throttling, $LATEST does not add capacity, and buffering with SQS adds latency without fixing cold starts.

5. A CloudFront distribution must run lightweight logic on every viewer request to rewrite URLs and add security headers at massive scale, with the lowest possible latency and cost, and it needs no network calls to other services. Which option fits best?

  • Lambda@Edge functions on the origin-request event running in regional edge caches
  • CloudFront Functions running JavaScript at edge locations on viewer events (correct answer)
  • A dedicated Lambda function invoked from the origin for every incoming request
  • An EC2 fleet behind the origin that rewrites URLs and injects headers per request

CloudFront Functions run tiny JavaScript at the edge on viewer request/response events with sub-millisecond startup and very low cost, ideal for URL rewrites and header manipulation with no network calls. Lambda@Edge is more powerful but heavier and higher latency, and origin-side Lambda or EC2 defeat the edge, low-latency goal.

6. A Step Functions task calls a downstream service that intermittently throttles. The architect wants automatic retries with exponential backoff and then a routed failure path if retries are exhausted. What should be configured on the task state?

  • A Retry field with backoff plus a Catch to a handler state (correct answer)
  • A try/catch block written inside the Lambda code that rethrows every error back to the state machine engine
  • A Parallel state wrapping the task so a second branch silently retries whenever the first branch happens to fail
  • A longer Lambda timeout, relying on API Gateway to retry the whole workflow on any 5xx response it observes

Step Functions has native Retry (with IntervalSeconds, BackoffRate, MaxAttempts) and Catch fields on a state, so throttling is retried with exponential backoff and, once exhausted, the Catch routes to a handler state. Handling retries only inside Lambda loses the state machine's declarative control, a Parallel state does not model retry, and API Gateway does not orchestrate Step Functions retries.

Related objectives