Domain 4 of 4 · Chapter 3 of 3

Application Optimization

Unlock the complete study guide + 1,040 practice questions across 16 full exams.

Bundled into the existing AWS Certified Developer - Associate premium course — no separate purchase.

Included in this chapter:

  • Caching: serve a stored result instead of recomputing it
  • Lambda performance: memory is the dial, cold starts are the tax
  • Reduce the calls before you scale the backend: batching, paging, backoff
  • Cost-vs-latency tradeoffs and right-sizing: exam patterns

AWS caching layers: what each one caches and where

CacheWhat it cachesWhere it sitsCode change to adoptReach for it when
Amazon CloudFrontHTTP responses (static and dynamic objects)Edge locations near the viewerNone: front the origin with a distribution; tune cache key on headers/cookies/queryGlobally distributed users hit the same URLs
API Gateway cachingEndpoint responses keyed on the requestAt the API stage, in front of the backend integrationNone: enable caching per stage/method and set TTLRepeated identical API calls re-invoke an expensive backend
Amazon ElastiCache (Redis OSS / Memcached)Any data the app chooses to store (query results, sessions, computed values)In-memory cluster the application reads/writes directlyYes: app code must read-through and populate the cacheGeneral-purpose caching or session store across services
Amazon DynamoDB Accelerator (DAX)DynamoDB item and query/scan results (read-through, write-through)In front of a DynamoDB tableMinimal: swap to the DAX client; same API surfaceRead-heavy DynamoDB needs microsecond reads, eventual consistency OK

Decision tree

Caching read-heavy DynamoDB reads, eventual consistency OK? Yes DAX DynamoDB Accelerator No Global viewers request the same HTTP URLs? Yes CloudFront caches HTTP at the edge No Repeated identical API calls re-invoke an expensive backend? Yes API Gateway caching per-stage response cache + TTL No ElastiCache general-purpose in-memory (Redis OSS / Memcached) DAX and CloudFront adopt with little or no code change; ElastiCache requires read-through logic in app code. A cache only pays off when the same data is read far more often than it changes, so pair every layer with a TTL (staleness budget). Never cache write-heavy or strongly-consistent reads — they mostly miss or serve stale values.
Cheat sheet

Cheat sheet

  • Cache only pays off when reads vastly outnumber writes
  • Pick the cache by what it caches and where it sits
  • Use CloudFront to cache HTTP responses at the edge
  • Cache content based on request headers by adding them to the cache key
  • Turn on API Gateway stage caching to skip repeat backend calls
  • Use ElastiCache when the data source is not DynamoDB
  • Use DAX for microsecond DynamoDB reads with no app rewrite
  • A strongly consistent read bypasses the cache entirely
  • Lambda memory is the single dial. It sets CPU too
  • A cold start is the one-time init of a fresh execution environment
  • Provisioned concurrency removes cold starts but bills idle
  • Reserved concurrency caps capacity: it does NOT pre-warm
  • SnapStart is free only for Java runtimes
  • Initialize clients and connections outside the handler to reuse them
  • Batch DynamoDB operations instead of looping single-item calls
  • Batch SQS messages to cut request count on both ends
  • Paginate large result sets; never Scan a whole table on the hot path
  • Keep the SDK's default exponential backoff with jitter for AWS calls
  • Right-size with measurement first, then the right tool for the scope
  • Commit to ElastiCache Reserved Nodes only for steady, always-on caches
  • Trade ongoing cost for lower latency only when traffic is predictable
  • Prefer managed and serverless services to delete operational overhead
  • Reduce calls before scaling the backend or adding a cache
  • CloudFront Minimum TTL overrides shorter origin Cache-Control, and Default TTL applies when the origin sends none
  • Version file names to push updates immediately instead of paying for CloudFront invalidations
  • Combine write-through with lazy loading and a TTL to keep ElastiCache fresh and lean
  • Rising ElastiCache Evictions with near-100% memory means scale up the node or add shards
  • High EngineCPUUtilization with low CPUUtilization is Redis's single command thread saturating
  • Measure API Gateway caching with CacheHitCount/CacheMissCount, and add query strings as cache key parameters
  • Multi-AZ DB cluster gives sub-35s failover and readable standbys; read replicas scale reads

Unlock with Premium — includes all practice exams and the complete study guide.

Also tested in

References

  1. What is Amazon CloudFront?
  2. Enabling API caching to enhance responsiveness (API Gateway)
  3. What is Amazon ElastiCache?
  4. DynamoDB Accelerator (DAX) concepts
  5. Configuring Lambda function memory
  6. Best practices for working with AWS Lambda functions
  7. Configuring provisioned concurrency for Lambda
  8. Improving startup performance with Lambda SnapStart
  9. Modifying the runtime environment (AWS_LAMBDA_EXEC_WRAPPER)
  10. BatchGetItem API reference (DynamoDB)
  11. BatchWriteItem API reference (DynamoDB)
  12. Amazon SQS batch actions
  13. Querying tables in DynamoDB
  14. Error retries and exponential backoff in AWS
  15. What is AWS Compute Optimizer?
  16. Amazon ElastiCache reserved nodes