Study guide
Performance Tuning for Existing Workloads
AWS Certified Solutions Architect - Professional SAP-C02
Track your progress as you read
Finished sections get a check mark.
1 Introduction and SAP-C02 Exam Facts
Current SAP-C02 Exam Facts Exam Format, Scoring, and Retakes Candidate Profile and Four Exam Domains
2 Multi-Account Governance
Multi-Account Strategy, Account Topologies, and OU Hierarchies Service Control Policies, Inheritance, and Permission Guardrails Control Tower, Landing Zones, Central Logging, and Resource Sharing
3 Hybrid and Inter-VPC Connectivity
Transit Gateway, VPC Connectivity, and PrivateLink Direct Connect, VPN, and Hybrid Redundancy Hybrid DNS with Route 53 Resolver Segmentation, Traffic Monitoring, and Service Endpoints
4 Identity Federation and Cross-Account Access
IAM Identity Center, External IdPs, and Workforce Federation Cross-Account Roles, STS, and Resource Policies Permissions Boundaries, Delegated Administration, and Least Privilege at Scale
5 Data Protection, Encryption, and Compliance
KMS, Multi-Region Keys, Envelope Encryption, and Certificates Encryption in Transit, Security Groups, NACLs, and VPC Endpoints Centralized Audit, Security Hub, GuardDuty, Inspector, and Access Analyzer
6 Deployment, Compute, Containers, and Serverless
Infrastructure as Code, CI/CD, Change Management, and Rollback EC2 Families, Auto Scaling, and Managed Compute ECS, EKS, Fargate, and ECR at Enterprise Scale Lambda, Step Functions, API Gateway, and Configuration Management
7 Storage, Caching, and Edge Performance
S3 Storage Classes, Object Lock, Replication, and Access Paths EBS, EFS, FSx Family, and Storage Gateway CloudFront Behaviors, Origin Access, Edge Compute, and Global Accelerator ElastiCache, MemoryDB, DAX, and Buffering versus Cache versus Replicas
8 Purpose-Built and Global Databases
Aurora Storage, Replicas, and Global Database DynamoDB Keys, Global Tables, and DAX Purpose-Built Database Selection
9 Integration, Messaging, and Streaming
API Gateway Architectures Decoupled Messaging with Amazon SQS and Amazon SNS Event-Driven Design with Amazon EventBridge Streaming Analytics with Amazon Kinesis and Amazon MSK
10 Resilience and Disaster Recovery
Disaster Recovery Patterns Route 53 Routing and Application Recovery Controller Backup, Replication, and Service Quotas High Availability, Failover, Chaos, and Self-Healing
11 Operational Excellence and Automation
CloudWatch Centralized Telemetry Distributed Tracing with AWS X-Ray Systems Manager Automation Deployment Strategies and Auto-Remediation
12 Cost Optimization and Visibility
Cost Explorer, Budgets, CUR, and Allocation Tags Savings Plans, Reserved Instances, Coverage, and Sharing Spot, Mixed Auto Scaling, Compute Optimizer, and Storage Lens Data Transfer Modeling: NAT, Endpoints, CloudFront, and Hybrid
13 Improve Security and Performance
Secrets, Least Privilege Audits, and Traceability Config Rules, Patching, Backup, and Regulatory Controls Performance Tuning for Existing Workloads
14 Migration Assessment and Wave Planning
Seven Migration Strategies (7 Rs) and Workload Selection Application Discovery, Migration Hub, and Migration Evaluator Wave Planning, Prioritization, and Assessment Governance
15 Migration Tools and Data Transfer
AWS Application Migration Service (MGN) AWS DMS, SCT, and Change Data Capture Large-Scale Data Transfer and Landing-Zone Prerequisites
16 Target Architecture, Modernization, and Cutover
Selecting Compute, Storage, and Database Platforms for Migrated Workloads Container Modernization: ECS, EKS, Fargate, ECR, and Strangler Fig Serverless, Decoupling, Purpose-Built Databases, and Integration Services Cutover, Rollback, and Unscored Emerging AI Topics
Performance Tuning for Existing Workloads
Key Takeaways Explain This Topic AI
Measure first with Amazon CloudWatch KPIs on the live stack; AWS X-Ray is only a pointer to the observability chapter when you need traces, not a replacement for metrics.
AWS Compute Optimizer requires opt-in and analyzes the last 14 days by default; 32-day lookback needs no extra Compute Optimizer payment, and 93 days requires paid enhanced infrastructure metrics.
Amazon CloudFront caches HTTP GETs at the edge; AWS Global Accelerator provides two static anycast IPv4 addresses and terminates TCP at the edge for uncacheable APIs, with a 340-second TCP idle timeout.
Cluster placement groups pack instances in one Availability Zone and can raise enhanced-networking single-flow traffic to 10 Gbps versus 5 Gbps outside the group; rack-spread groups allow seven running instances per AZ.
Change instance families, mixed-instance Auto Scaling or EC2 Fleet, and managed-service substitutions only after dashboards show the bottleneck; do not treat Compute Optimizer as a same-day resize mandate.
Last updated: September 2026
Tune the fleet that is already taking traffic
Quick Answer: Measure HarborPay's live stack with Amazon CloudWatch first, glance at AWS X-Ray only to locate a chatty hop (tracing depth is in the observability chapter), then rightsize with AWS Compute Optimizer , add Amazon CloudFront or AWS Global Accelerator , retune Amazon EC2 Auto Scaling or an EC2 Fleet , and only then move tightly coupled nodes into placement groups .
New-solution performance chapters ask how you would place storage, edge, and compute on day one. Task 3.3 asks how you improve a fleet that already serves authorizations. HarborPay's checkout p95 climbed after a holiday sale, and nobody saved a baseline. Independent SAP-C02 study material by ExamFinch keeps that contrast explicit: design-time performance versus measure-then-change .
SLAs, KPIs, bottleneck tests, and CloudWatch
Write the service-level agreement (SLA) and key performance indicators (KPIs) in business language—for example authorization p99 under 200 milliseconds and HTTP 5xx under 0.1 percent. AWS does not publish HarborPay's numbers. Map each KPI to CloudWatch: ALB TargetResponseTime and HTTPCode_Target_5XX_Count , EC2 CPUUtilization , network in and out, EBS VolumeQueueLength , RDS CPUUtilization and DatabaseConnections , ElastiCache evictions.
Amazon CloudWatch is the monitoring toolset for this chapter. Use dashboards, alarms, anomaly detection, and Contributor Insights on access logs. Enable detailed monitoring (1-minute metrics) on the Auto Scaling group when 5-minute basic metrics hide spikes. Load-test in a non-production account that mirrors instance families. A test that only hits a cached CloudFront path will lie about POST authorization latency.
AWS X-Ray is the pointer for distributed traces across ALB, containers, Lambda, and SDK calls. Do not design sampling rules here. When latency is somewhere in the app, open a trace to name the hop, then return to CloudWatch to size CPU, disk, or network.
Rightsizing, instance families, fleets, and Auto Scaling
AWS Compute Optimizer must be opted in . After opt-in it analyzes CloudWatch for the last 14 days by default. Rightsizing preferences allow 14 (default), 32, or 93 days . AWS documents that 14-day and 32-day lookbacks need no additional Compute Optimizer payment; the 93-day option requires paid enhanced infrastructure metrics . The management account can opt in the whole organization; AWS states that new member accounts are opted in automatically after that. Compute Optimizer recommends for EC2, Auto Scaling groups, EBS, Lambda, ECS on Fargate, Aurora and RDS, and other resource types in the current service list. Recommendations are not orders: a memory-heavy JVM can look idle on CPU.
Rightsizing a running stack means changing instance families after evidence:
Compute-optimized (C) when the bottleneck is CPU.
Memory-optimized (R or X) when heap, page cache, or in-memory stores dominate.
Network-capable types with Elastic Network Adapter when east-west throughput or placement-group single-flow limits dominate.
Burstable (T) only when CPU credit balance stays healthy under the KPI load test.
Replace a homogeneous Auto Scaling group with a mixed instances policy or an EC2 Fleet so HarborPay can span sizes and purchase options without a greenfield rewrite. Amazon EC2 Auto Scaling can use target tracking, step, scheduled, or predictive scaling. Attach the existing ALB target group and health checks before you lower min . Predictive scaling needs traffic history; do not enable it on a group that has three days of metrics.
Propose managed services when the bottleneck is undifferentiated heavy lifting: self-managed MySQL on EC2 to Amazon RDS or Aurora, self-managed Redis to ElastiCache (if HarborPay already has ElastiCache, tune node type and replicas instead of preaching a new cache), a homegrown TCP proxy to ALB or a Network Load Balancer. That is Task 3.3 proposing managed services for an existing workload, not a lecture on launching RDS for a new app.
CloudFront and Global Accelerator on existing apps
Amazon CloudFront is a content delivery network for HTTP and HTTPS. Put it in front of an existing ALB or Amazon S3 origin to cache GET and HEAD of static assets and cacheable API responses at edge locations. It will not make uncacheable POST authorization calls correct or fast if you set a 24-hour default time-to-live; you will serve stale or wrong financial results.
AWS Global Accelerator provides two static anycast IPv4 addresses by default (four addresses for dual-stack: two IPv4 and two IPv6). It terminates TCP at the nearest edge and opens a second connection to regional Network Load Balancer, ALB, EC2, or Elastic IP endpoints over the AWS backbone. Idle timeouts are 340 seconds for TCP and 30 seconds for UDP and are not customizable. Use traffic dials (percentage of traffic already directed to an endpoint group) and endpoint weights (0–255, default 128 ) to shift an existing multi-Region API without changing client DNS records. Bring-your-own-IP is supported for IPv4. Deleting the accelerator releases the static addresses. Security groups and WAF rules on the ALB keep working. Choose Global Accelerator when the pain is handshake time and internet path for non-cacheable APIs; choose CloudFront when the pain is repeatable GETs.
Placement groups for an existing HPC or low-latency fleet
Placement groups are free to create. An instance lives in one group; groups cannot be merged; Dedicated Hosts cannot launch in placement groups; a Spot Instance configured to stop or hibernate on interruption cannot use them. AWS documents a maximum of 500 placement groups per Region.
Strategy Placement Published limits Existing-fleet use
Cluster Pack close in one Availability Zone Enhanced networking: up to 10 Gbps single-flow inside the group versus 5 Gbps outside; internet and Direct Connect from the group limited to 5 Gbps ; not for burstable T2, Mac1, or M7i-flex Tightly coupled risk-batch HPC after you measure east-west latency
Partition Distinct racks per partition Seven partitions per AZ (two if Dedicated Instances); instance count limited by account quotas Kafka, HDFS, Cassandra-style replica isolation
Spread (rack) Distinct racks Seven running instances per AZ ; host-level spread is Outposts-only A small set of critical nodes that must not share a rack
To move existing instances, stop them, change instance placement, and start them, or replace the Auto Scaling group or EC2 Fleet with a launch template that names the group. Launch the needed capacity in one request with the same instance type . If capacity fails, AWS documents stopping and starting all instances in a cluster group so they can pack onto hardware that fits. Prefer an On-Demand Capacity Reservation in the cluster group ; zonal Reserved Instances do not pin capacity inside a placement group. Cluster groups cannot span Availability Zones. If HarborPay wanted Multi-AZ high availability, a cluster placement group is the wrong tool. Precision time placement groups exist for microsecond clocks; use them only when the KPI is timestamp accuracy, not bulk throughput.
Run this improvement sequence:
Freeze KPIs and CloudWatch dashboards; load-test a replica; open X-Ray only long enough to name the slow hop.
Opt in Compute Optimizer at the organization; wait for 14 days of history or choose 32 days for monthly peaks; then change families and mixed fleets.
Add CloudFront for cacheable GETs or Global Accelerator for sticky anycast TCP; do not add both as a reflex.
For the single-AZ HPC fleet, create a cluster placement group and migrate during a window, with a Capacity Reservation if the last sale exhausted the AZ.
Re-measure. If CPU is idle and disk queue is deep, stop scaling EC2 and fix EBS or the database.
Traps: shrinking every instance to t3.micro without metrics; caching POSTs at CloudFront; merging placement groups; launching Dedicated Hosts into a placement group; treating Compute Optimizer as a mandatory resize the hour you opt in; using a cluster placement group to add high availability across AZs.
Official resources
What is AWS Compute Optimizer?
- Rightsizing recommendation preferences
- Placement groups for Amazon EC2
- Placement strategies
- How AWS Global Accelerator works
- Amazon CloudFront product documentation