3.3 Performance Improvement
Official task mapping
SAP-C02 task 3.3: Performance metrics and global services knowledge; bottleneck analysis and remediation tests. This lesson applies the official task to an original design exercise; it is not an exhaustive exam syllabus.
Prerequisites
Review performance design, global networking and rightsizing. Be able to explain the relevant failure boundary and access/cost model before choosing a service.
Diagnose the limiting stage
Use percentiles and representative load, not only averages. Separate network delay, application processing, cache misses, database waits and queue delay. A faster instance can be ineffective if contention or serial downstream work dominates.
Compute Optimizer recommends supported resource configurations from utilization evidence. Its use of machine learning is not a dedicated ML model-inference instance-selection service. Confirm data sufficiency, workload cycles and constraints; guest memory requires appropriate metrics.
CloudFront caches eligible content near viewers; Global Accelerator routes supported TCP/UDP traffic over the AWS network without caching. Static addresses depend on accelerator type/address-family configuration; do not assume one IPv4-only address count for all configurations. Outposts, Local Zones and Wavelength solve particular placement/latency requirements with regional service and operational constraints.
Tools and placement comparison
| Option | Optimizes | Does not automatically solve |
|---|---|---|
| Compute Optimizer | Supported resource sizing | Application SQL, licensing or future business changes |
| CloudWatch custom metrics | Workload-specific measurement | Missing instrumentation or bad aggregation |
| Composite alarms | Combine relevant alarm states | Root cause without evidence |
| CloudFront / edge functions | Eligible content delivery/edge logic | Database locality or unsafe cache keys |
| Global Accelerator | Supported network paths/endpoints | Object caching |
| Outposts | Supported AWS infrastructure on-premises | Local operations/capacity constraints |
| Local Zones / Wavelength | Supported location-sensitive workloads | Universal service parity or data architecture |
A recommendation marked over-provisioned, under-provisioned or optimized is a workload/resource observation, not proof an untested resize meets a latency target. Test both peak and failure conditions.
If serial stages take 30 ms network + 50 ms application + 220 ms database, total is 300 ms. Halving application time yields 275 ms, not 150 ms; halving database time yields 190 ms. Use this simple bottleneck calculation to justify the test order. Percentiles across dependent stages cannot always be added as if they were one sample; use traces for correlated tail behavior.
Scenario and rationale
European users see 500-ms p99 response time while in-Region users see 80 ms. Tracing shows network delay for session traffic and repeated downloads of static assets. Evaluate CloudFront for cacheable assets and appropriate regional/network routing for dynamic sessions. Confirm data residency and replicated-state behavior before deploying a second Region.
Reject caching personalized session responses without a safe cache key. Reject blindly upsizing the backend when network delay dominates. Reject Global Accelerator as an object cache.
Practice drill
Decompose a supplied latency histogram into stages. Compare one network-path change, one cache-policy change and one database-query improvement. Set p99, error-rate, correctness and cost criteria, including cold-cache behavior and accelerator/transfer charges. Design an A/B test and rollback; do not promise a latency gain without measurement.
References
- Official Domain 3 task guide
- Compute Optimizer recommendations
- Global Accelerator types
- CloudFront caching
Return to Domain 3. The drill is proposed study work, not a claim of a completed deployment.