Performance Tuning for Existing Workloads

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 OpenExamPrep 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.

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:

1. Freeze KPIs and CloudWatch dashboards; load-test a replica; open X-Ray only long enough to name the slow hop.
2. 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.
3. Add CloudFront for cacheable GETs or Global Accelerator for sticky anycast TCP; do not add both as a reflex.
4. 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.
5. 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