4 of the 7 questions we have for this objective, shown with the answer and the reasoning.
Determine a strategy to improve performance
Ulverton Software runs 200 m6i.2xlarge Linux instances for its API tier, with average CPU utilization of 14% over the last month. AWS Compute Optimizer currently shows many of these instances as optimized or offers only small savings, and the team suspects that it lacks the data to judge memory use. The company wants rightsizing recommendations that account for memory and reflect the traffic peak that occurs once per quarter at quarter end.
What should the solutions architect do?
- AInstall the CloudWatch agent to publish memory utilization from each instance and activate the Compute Optimizer enhanced infrastructure metrics feature to extend the lookback period to three months (93 days).Compute Optimizer uses memory metrics published by the CloudWatch agent, and enhanced infrastructure metrics extend the lookback from 14 days to three months so quarter-end peaks are included.
- BEnable EC2 detailed monitoring so that Compute Optimizer receives 1-minute metrics.Detailed monitoring increases the frequency of hypervisor metrics such as CPU, but it does not provide memory utilization.
- CDownsize every instance to m6i.large because CPU utilization is under 25%.Resizing on CPU alone risks memory exhaustion and ignores the quarter-end peak that the team must accommodate.
- DUse the AWS Trusted Advisor Low Utilization Amazon EC2 Instances check to choose new instance types.That check flags instances with low CPU and network use but does not consider memory or recommend specific instance types.
Why: Rightsizing is only as good as the metrics behind it. EC2 does not report memory utilization from the hypervisor, so Compute Optimizer needs the CloudWatch agent to publish it before it can recommend memory-aware instance types. By default Compute Optimizer analyzes 14 days of data; the paid enhanced infrastructure metrics feature extends this to 93 days, which is long enough to include a quarterly peak; the 32-day lookback preference would not reliably capture it. Acting on CPU alone is the classic trap that leads to undersized instances.
Determine a strategy to improve performance
Skerry Interactive hosts a multiplayer game server fleet behind Network Load Balancers in us-west-2, eu-west-1 and ap-northeast-1. Game traffic uses UDP. Players currently connect through Route 53 latency-based records, and when a Region has problems, players keep connecting to it for several minutes because of cached DNS answers. Several corporate customers also need a small, fixed set of IP addresses to add to their firewalls.
Which service should the solutions architect add in front of the NLBs?
- AAmazon CloudFront with the three NLBs as origins in an origin group.CloudFront serves HTTP and HTTPS traffic and does not proxy arbitrary UDP game traffic.
- BAWS Global Accelerator with an endpoint group per Region that contains each NLB.Global Accelerator provides two static anycast IP addresses, supports TCP and UDP, routes players over the AWS network to the closest healthy Region, and fails over without relying on DNS caching.
- CRoute 53 failover records with health checks and a 60-second TTL.Failover records still depend on resolvers honoring the TTL and do not provide fixed IP addresses for firewall allowlists.
- DAn Application Load Balancer in each Region in front of the NLBs.ALBs handle HTTP and HTTPS, not UDP, and do not provide global routing or static IP addresses.
Why: Global Accelerator and CloudFront both use the AWS edge network but solve different problems. CloudFront caches and accelerates HTTP content, while Global Accelerator provides static anycast IP addresses for TCP and UDP applications and shifts traffic between Regional endpoints based on health within seconds. Because clients connect to fixed IP addresses, failover does not depend on DNS caching, and firewall teams can allowlist two addresses. DNS-based routing remains useful, but it cannot meet the static IP and fast failover constraints here.
Determine a strategy to improve performance
Aldwick Aero runs a tightly coupled computational fluid dynamics simulation that uses MPI across 16 c7gn instances with Elastic Fabric Adapter. The instances were launched by an Auto Scaling group that spreads them across three Availability Zones, and profiling shows that most of the run time is spent waiting on node-to-node communication. The team wants the lowest possible network latency between nodes.
What should the solutions architect recommend?
- ALaunch the instances in a spread placement group.Spread placement groups put each instance on distinct hardware to reduce correlated failure and are limited to seven running instances per Availability Zone; they do not minimize latency.
- BLaunch the instances in a partition placement group across three Availability Zones.Partition placement groups isolate groups of instances for large distributed stores such as HDFS, and spanning zones adds latency.
- CLaunch all instances in a cluster placement group in a single Availability Zone.A cluster placement group packs instances close together in one zone for low-latency, high-throughput networking, which is what tightly coupled MPI jobs need.
- DReplace the instances with fewer, larger instances that stay spread across three Availability Zones.Cross-zone traffic still carries higher latency, so the communication bottleneck remains for the nodes that must talk to each other.
Why: Tightly coupled HPC workloads are limited by inter-node latency, so the placement of instances matters as much as their size. Cluster placement groups place instances in a low-latency group within one Availability Zone, and with EFA they give the best performance for MPI. Spread and partition placement groups address failure isolation rather than latency. The trade-off is reduced zone resilience, which is generally acceptable for restartable batch simulations.
Determine a strategy to improve performance
Glenmere Labs runs a nightly genomics batch job on a single r6i.4xlarge instance that reads and writes a 200 GiB gp2 EBS volume. The job runs at full speed for about 40 minutes and then slows sharply, although CPU utilization stays under 30%. CloudWatch shows the volume's BurstBalance metric falling to 0 at the same time that VolumeQueueLength rises. The team needs about 5,000 IOPS for the whole job at the lowest cost and without downtime.
What should the solutions architect recommend?
- AChange the instance type to r6i.8xlarge to provide more CPU and memory.CPU is not the constraint; the metrics show the volume running out of burst credits.
- BModify the volume to gp3 with 5,000 provisioned IOPS and adequate throughput by using Elastic Volumes.gp3 provides provisioned IOPS independent of size with no burst credits, and Elastic Volumes changes the type and performance while the volume stays in use.
- CModify the volume to io2 with 5,000 provisioned IOPS.io2 would meet the performance target but costs more than gp3 for this IOPS level, so it does not meet the lowest-cost requirement.
- DStripe four additional gp2 volumes with the existing one in a RAID 0 array.This adds complexity and requires data migration and downtime, while a single gp3 volume meets the requirement directly.
Why: Examining a bottleneck means following the metrics to the resource that is saturated. A small gp2 volume earns burst credits from a baseline of 3 IOPS per GiB, so a 200 GiB volume can burst to 3,000 IOPS only until BurstBalance is exhausted, after which it falls back to 600 IOPS and requests queue. gp3 decouples IOPS and throughput from size and has no credit model, and Elastic Volumes applies the change online. Scaling compute or choosing a premium volume type addresses the wrong constraint or overspends.