4 of the 7 questions we have for this objective, shown with the answer and the reasoning.
Design cost-optimized compute solutions
Delacroix Games runs a fleet of 12 m5.4xlarge EC2 instances that host an in-memory session cache written in Go. CloudWatch shows memory utilization steady at 85 percent while average CPU utilization is 6 percent, and the application is built from source for each deployment. The company wants to reduce the EC2 cost of the fleet without reducing the amount of memory available to the cache.
Which change should a solutions architect recommend?
- AMove the fleet to c6i.4xlarge instances, which have a lower hourly price than m5.4xlarge.Compute-optimized instances have half the memory per vCPU of the general-purpose family, so a c6i.4xlarge provides only 32 GiB compared with 64 GiB and would starve the cache.
- BMove the fleet to r6g.2xlarge instances built on AWS Graviton processors.A memory-optimized r6g.2xlarge provides the same 64 GiB of memory as an m5.4xlarge with fewer vCPUs that the workload does not use, and Graviton instances carry a lower price than comparable x86 instances; the Go application can simply be rebuilt for arm64.
- CMove the fleet to m5.8xlarge instances so that fewer instances are needed.Doubling the instance size doubles memory and CPU per instance but the price per GiB of memory stays the same, so the total cost for the same cache size does not fall and the unused CPU doubles.
- DMove the fleet to x2idn.4xlarge instances to maximize memory per instance.The x2idn family is designed for very large in-memory databases with high memory-to-vCPU ratios and local NVMe storage, and it carries a premium price that is unnecessary for a 64 GiB cache.
Why: Instance family selection should follow the bottleneck resource: a workload that is memory-bound with idle CPU is paying for vCPUs it never uses on a general-purpose instance. The memory-optimized R family delivers the same memory with half the vCPUs, and the Graviton (g suffix) variants are priced lower than equivalent x86 instances, so r6g.2xlarge keeps the 64 GiB while cutting cost on two axes. The deciding constraints are the memory requirement and the ability to rebuild the application, which makes the arm64 architecture change practical. The trap is picking a cheaper hourly price in the compute-optimized family without checking that memory per instance is halved.
Design cost-optimized compute solutions
Marbury Software runs its production API on an Auto Scaling group behind an Application Load Balancer across three Availability Zones. It also runs a development environment of 30 EC2 instances that developers use only during business hours, and a continuous integration farm of 20 c6i.xlarge On-Demand Instances that build stateless, retry-safe jobs from a queue around the clock. All environments are tagged with an Environment cost allocation tag. A cost review shows the non-production environments cost almost as much as production, and the company wants to cut non-production cost without changing production availability.
Which two actions should a solutions architect take? Each correct answer presents part of the solution.
- ADeploy Instance Scheduler on AWS or an EventBridge Scheduler rule to stop the development instances outside business hours and start them each morning.Development instances need to exist only when developers are working; stopping them for nights and weekends removes about two-thirds of their compute charges with no impact on production.
- BReduce the production Auto Scaling group to a single Availability Zone to cut the number of running instances.Removing Availability Zones lowers production availability, which the requirement explicitly forbids.
- CCreate an AWS Budgets alert for the Environment tag value of Development at 80 percent of last month's spend.A budget alert provides visibility and notification but does not itself reduce any cost.
- DRun the continuous integration build agents as Spot Instances in a mixed-instances Auto Scaling group with several instance types, keeping the queue as the source of work.Stateless, retry-safe, queue-driven build jobs are the ideal Spot workload; interruptions simply return the job to the queue, and Spot pricing is typically 60 to 90 percent below On-Demand.
- EConvert the development instances to Dedicated Hosts to receive a volume discount.Dedicated Hosts cost more than shared tenancy and are intended for licensing or compliance requirements, not for cost reduction.
Why: Different workload classes justify different availability and purchasing choices: production keeps multi-AZ On-Demand or committed capacity, development only needs to exist during working hours, and fault-tolerant batch work such as CI can run on interruptible Spot capacity. Scheduling stop and start for development environments and moving queue-driven stateless workers to Spot are the two highest-impact, lowest-risk non-production levers. The trap is applying any change to production, which the scenario rules out, or mistaking a monitoring tool like Budgets for a cost reduction. Cost allocation tags are what make this analysis possible, but they are an enabler rather than a saving on their own.
Design cost-optimized compute solutions
Saltmarsh Logistics has run a steady baseline of about 40 vCPU-equivalents of compute for three years, split between EC2 instances in an Auto Scaling group, Amazon ECS tasks on AWS Fargate, and several AWS Lambda functions. Traffic peaks at holiday periods add another 60 percent of capacity for a few weeks each year. The engineering team expects to migrate most EC2 workloads to Fargate over the next 18 months and may move some workloads from us-east-1 to eu-west-1. The company wants the largest discount on the baseline that still tolerates these changes, plus a cheap way to serve the peaks.
Which combination of purchasing options should a solutions architect recommend?
- AStandard Reserved Instances for the EC2 baseline, plus On-Demand Instances for the peaks.Standard Reserved Instances are tied to a specific instance family and Region and cover only EC2, so they would be stranded when workloads move to Fargate or to eu-west-1, and On-Demand is the most expensive way to serve peaks.
- BA 3-year Compute Savings Plan sized to the baseline, plus Spot capacity in the Auto Scaling group and Fargate Spot for the peaks.A Compute Savings Plan applies automatically to EC2 across any instance family, size, OS, tenancy, or Region, and also to Fargate and Lambda, so the commitment survives the planned migrations; Spot and Fargate Spot then serve the short interruptible peaks at the lowest possible rate.
- CAn EC2 Instance Savings Plan for us-east-1, plus On-Demand Capacity Reservations for the peaks.An EC2 Instance Savings Plan offers a deeper discount but is locked to an instance family in one Region and does not cover Fargate or Lambda, and Capacity Reservations guarantee availability at full On-Demand price rather than lowering cost.
- DConvertible Reserved Instances for the EC2 baseline, plus Dedicated Hosts for the peaks.Convertible Reserved Instances can change instance family but still cover only EC2 in one Region, and Dedicated Hosts are the most expensive EC2 option, suited to licensing constraints rather than seasonal peaks.
Why: The purchasing-option ladder trades discount depth for flexibility: Standard Reserved Instances and EC2 Instance Savings Plans give the deepest discounts but bind you to an instance family and Region, Convertible Reserved Instances add family flexibility but remain EC2-only, and Compute Savings Plans give a somewhat smaller discount that applies to EC2, Fargate, and Lambda in any Region. When the scenario forecasts a shift from EC2 to Fargate or across Regions, flexibility is worth more than a few extra percentage points, so the Compute Savings Plan is the right baseline commitment. Short, interruptible peaks belong on Spot or Fargate Spot, which cost far less than On-Demand. The trap is confusing Capacity Reservations with a discount; they reserve supply, not savings.
Design cost-optimized compute solutions
Hollins Freight runs about 300 EC2 instances across four AWS accounts that were sized by individual teams. Finance suspects that many instances are larger than their workloads need, but the operations team does not have time to analyze CloudWatch metrics for every instance by hand. The company wants a data-driven list of instances that can be downsized, with the recommended target size and the projected savings, using a native AWS service.
What should a solutions architect recommend?
- AEnable AWS Compute Optimizer across the organization and review its over-provisioned EC2 instance recommendations.Compute Optimizer analyzes CloudWatch utilization history for EC2 instances, Auto Scaling groups, EBS volumes, Lambda functions, and ECS on Fargate, classifies resources as over-provisioned or under-provisioned, and recommends specific instance sizes with estimated monthly savings.
- BEnable AWS Trusted Advisor and review its Security checks for each account.Trusted Advisor has a cost optimization category that flags low-utilization instances, but its Security checks are unrelated, and it does not recommend a specific target size the way Compute Optimizer does.
- CUse AWS Cost Explorer grouped by instance type to find the most expensive instance types.Cost Explorer shows what was spent by type but has no utilization data, so it cannot tell which instances are larger than they need to be.
- DInstall the CloudWatch agent on every instance and build a dashboard of CPU utilization.A dashboard still leaves the analysis and the choice of target size to humans across 300 instances, which the operations team has said it cannot do.
Why: AWS Compute Optimizer is the service that turns utilization metrics into right-sizing recommendations: it uses machine learning over CloudWatch data to label EC2 instances as optimized, over-provisioned, or under-provisioned and to propose instance types with projected cost and performance impact. Enabling it at the organization level covers all member accounts from one view. The deciding constraints are a native service, a concrete target size, and projected savings, which neither Cost Explorer nor a dashboard provides. The trap is Trusted Advisor, which flags low utilization but is coarser and does not produce size recommendations for most instance types.