Troubleshooting and Optimization
Measured Performance, Concurrency, Filtering, and Caching
ImportantProfile applications and optimize concurrency, resource sizing, message delivery, edge cache keys, and application caching from measured bottlenecks.
Aligned to AWS Certified Developer - Associate (DVA-C02) Version 2.1, verified August 23, 2026.
Why this matters
Optimization is a constraint-matching exercise. Increasing every resource, caching everything, or retrying throttled calls can worsen cost, correctness, and downstream pressure. Measure the bottleneck and change the control that owns it.
Must Know
- Concurrency is the number of in-flight executions. For Lambda, a useful estimate is request rate multiplied by average duration; it is not simply requests per minute.
- Profile CPU, memory, I/O, initialization, dependency time, serialization, and repeated work before changing resource settings.
- Select the lowest memory/compute setting that satisfies measured performance and reliability requirements, not always the smallest or largest value.
- Reserved Lambda concurrency can isolate capacity and cap pressure on a downstream dependency; memory and provisioned concurrency solve different problems.
- SNS subscription filter policies select messages by attributes or message-body properties at the subscription so uninterested consumers do not receive them.
- A CloudFront cache key should include values that actually change the representation and omit irrelevant headers, cookies, and query strings to preserve cache reuse.
- Application-level caching needs an access pattern, source of truth, key design, freshness bound, TTL or invalidation, tenant boundary, and failure behavior.
- Use structured duration and resource data to isolate bottlenecks, then change code, integration, cache, filter, or resource configuration at that boundary.
Compare and Distinguish
- Concurrency vs throughput: concurrency counts simultaneous in-flight work; throughput counts completed work over time.
- Reserved concurrency vs memory/compute: concurrency caps or reserves parallel work; memory changes per-invocation compute allocation.
- SNS subscription filtering vs consumer discard: filter policies prevent unwanted delivery; consumer filtering pays to receive and process irrelevant messages.
- CloudFront cache-key header vs forwarded-only value: cache policy controls cache variation; origin request policy can forward values that need not split the cache.
- Edge cache vs application cache: CloudFront caches viewer responses at the edge; an application cache stores reusable application or data results nearer the code.
- Cache vs source-store redesign: caching accelerates repeated reads but does not remove source-of-truth and invalidation requirements.
Scenario examples
- Scenario: A Lambda function receives 40 requests per second and averages half a second. Expect roughly 20 concurrent executions before accounting for variation and headroom.
- Scenario: Three SNS subscribers need different event types. Configure per-subscription filters instead of delivering and discarding most messages in every consumer.
- Scenario: An origin varies content only by language. Include the normalized representation-changing language value in the CloudFront cache key, not every request header.
- Scenario: A repeated database read tolerates bounded staleness. Add a tenant-aware cache with explicit TTL/invalidation and retain the database as source of truth.
Exam traps
- Provisioned concurrency reduces startup latency; it is not the primary cap that protects a downstream connection pool.
- Increasing timeout or retries can prolong pressure without fixing the bottleneck.
- SNS filter changes are eventually consistent; do not assume every subscription uses a new policy instantly.
- Forwarding every header in the CloudFront cache key fragments the cache.
- A cache without invalidation and tenant-aware keys can return wrong or unauthorized data.
- Do not optimize from price trivia, arbitrary limits, or guesses when the scenario supplies measurements.
Key takeaways
- Measure before changing resources or code.
- Match concurrency controls to parallel-capacity and isolation requirements.
- Filter messages before delivery when subscriptions need different subsets.
- Keep cache keys minimal but complete for representation correctness.
- Treat source truth, freshness, invalidation, security, and hit pattern as one cache design.
How it works
- Telemetry and profiling identify the constrained resource or repeated expensive work.
- The developer changes the owning control: concurrency, resource size, message filter, cache policy, or application logic.
- Load and correctness tests compare latency, errors, resource use, and outputs before and after the change.
- The chosen setting remains only if it satisfies reliability and correctness constraints.
When to use it
- Use reserved concurrency to isolate a function or cap parallel access to a limited dependency.
- Use SNS subscription filters when each subscriber needs a defined subset of published messages.
- Use CloudFront caching for reusable viewer responses and control variation through cache policy.
- Use ElastiCache or an application cache pattern for repeated application/data results with explicit freshness.
- Use profiling and structured duration logs before code or resource optimization.
Security and governance implications
- Never use a shared cache key across tenants or authorization contexts that can return different allowed results.
- Avoid sensitive and unbounded values in message filters, cache keys, logs, and metric dimensions.
- Keep cache access and invalidation permissions scoped to the owning application.
- Do not weaken authorization or validation to improve measured latency.
Failure signals and diagnosis
- For Lambda throttling, compare concurrent executions, reserved limits, event-source limits, account capacity, and downstream limits.
- For low cache hit ratio, inspect which headers, cookies, and query strings fragment the key without changing content.
- For stale cache data, inspect source updates, invalidation, TTL, key versioning, and regional/application cache layers.
- For unexpected SNS delivery, inspect filter scope, message fields, policy match, propagation delay, and subscription endpoint.
More detail
- Performance optimization can change code, configuration, delivery volume, resource size, or cache behavior; pick the boundary identified by evidence.
- A high cache-hit ratio depends on avoiding cache-key values that do not change the response.
- SNS filters can evaluate message attributes or message body properties according to the configured policy scope.
- Application logs with operation durations and correlation IDs can reveal bottlenecks that infrastructure averages hide.
Ready for the quiz?
- How do request rate and duration affect concurrency?
- Which control caps Lambda pressure on a dependency?
- Why is subscription filtering better than consumer discard for irrelevant messages?
- Which request values belong in a CloudFront cache key?
- What correctness rules must an application cache preserve?
Related objectives
- D4.3 — Optimize applications by using AWS services and features
- 4.3.1 — Define concurrency
- 4.3.2 — Profile application performance
- 4.3.3 — Determine minimum memory and compute power for an application
- 4.3.4 — Use subscription filter policies to optimize messaging
- 4.3.5 — Cache content based on request headers
- 4.3.6 — Implement application-level caching to improve performance
- 4.3.7 — Optimize application resource usage
- 4.3.8 — Analyze application performance issues
- 4.3.9 — Use application logs to identify performance bottlenecks