Cloud architecture optimisation is not a one-time event — it is a continuous cycle of measurement, adjustment, and re-measurement. For the SAP-C02 exam, you must understand how to systematically improve both performance and cost over time, because real-world systems that never change become slow, expensive, and brittle.
Jump to a section
A simple way to picture Optimizing Performance and Cost Through Iteration
A house is never finished — it is always a work in progress shaped by changing needs, available budget, and new technologies.
Imagine you buy a fixer-upper home. Your first priority is to make it habitable: you patch the roof, replace the rotten window frames, and install a basic heating system. This initial build costs a lot because you are starting from scratch. But after living in the house for a year, you notice the kitchen is awkward — the sink is far from the stove, and the cabinets have no organisation. You decide to renovate the kitchen. You tear out the old cabinets, rearrange the layout, and add pull-out shelves. Cooking becomes faster, and you waste less time hunting for pots. The renovation cost less than the original build and delivered more daily convenience. A few years later, you install solar panels and better insulation. Your heating bills drop by half, and the house becomes more comfortable in winter. Each change — small or large — improves either performance (comfort, speed) or cost (lower bills, less wasted space). The process is iterative: you plan, execute, evaluate, and then plan again. You never stop tweaking because needs evolve, new products appear, and you discover better ways to do things. In cloud architecture, exactly this cycle of continuous change — measure, adjust, re-measure — optimises both speed and spending over the lifetime of a system.
Optimising performance and cost through iteration is the practice of continuously refining your AWS architecture based on data, not guesses. The core idea is simple: you build a system, measure how it behaves (speed, latency, resource usage, cost), identify a specific improvement, make a small change, measure again, and repeat. This loop never ends because workloads change, new AWS services launch, and your understanding of your own system deepens.
Let’s define the key terms. Performance means how fast and reliably your system responds to requests. It includes latency (the time between a user action and the system’s response), throughput (the number of requests handled per second), and error rate. Cost is the total money you pay to AWS for compute, storage, data transfer, and other services. The goal is to achieve the best performance for the lowest reasonable cost — not the absolute lowest cost regardless of performance, and not maximum performance at any price.
Why does iteration matter? Because a “one-and-done” design inevitably becomes suboptimal. When you first build an AWS workload, you make assumptions — about traffic patterns, user behaviour, data growth, and pricing. Those assumptions almost always turn out to be wrong. Traffic spikes that you did not predict cause slowdowns, or you are paying for capacity that sits idle. By iterating, you align your architecture with real-world conditions as they change.
The process has a clear structure:
Measure: Collect data using AWS tools like CloudWatch (for metrics such as CPU usage, memory usage, and request latency), Cost Explorer (for spend breakdowns), and Trusted Advisor (for cost-saving recommendations). You need a baseline — a snapshot of current performance and cost — before you change anything.
Analyse: Look at the data to find bottlenecks (the part of the system that limits overall performance) or cost waste (resources provisioned but not fully used). Common examples include over-provisioned EC2 instances (paying for more CPU/RAM than needed), idle load balancers, and unused Elastic IP addresses — each of which costs money with zero benefit.
Plan: Choose one specific change that addresses the largest bottleneck or the biggest waste. For performance, this might mean switching from a general-purpose EC2 instance type to a compute-optimised one for a CPU-bound task. For cost, it might mean using Reserved Instances (pay upfront for a 1- or 3-year commitment to get a discount) instead of On-Demand instances (pay per hour with no commitment) for a steady-state workload.
Implement: Make the change in a controlled way. Use AWS features such as blue/green deployments (running two identical environments side by side and switching traffic to the new one) or canary releases (directing a small percentage of users to the new version first) to minimise risk.
Re-measure: After the change, collect the same metrics you measured before. Compare the new numbers to the baseline. Did performance improve? Did cost go down? If yes, you move on to the next improvement. If no, you roll back and try a different approach.
This cycle replaces the old model of “fire and forget” architecture, where a system was built, signed off, and left untouched until it broke. In modern cloud operations, especially at the Solutions Architect Professional level, you are expected to design for continuous evolution. AWS calls this the Well-Architected Framework, and its “Cost Optimisation” and “Performance Efficiency” pillars both emphasise iteration.
A concrete example: Suppose you run a web application on EC2 instances behind an Application Load Balancer. Your baseline measurement shows average CPU utilisation at 15% — very low — but your monthly bill is high because you are running 10 large instances. Cost Explorer shows that 80% of your cost is compute. You plan to right-size: switch to smaller instances (from large to medium) and reduce the count to 5 based on actual peak traffic. You implement the change during a maintenance window. The following week, you measure again: CPU utilisation is now 40% (still comfortable), performance metrics like response time are unchanged, and your compute cost has dropped by 60%. That is iteration in action. Next, you might look at whether you can use Spot Instances (cheaper, interruptible compute) for non-critical batch jobs, further reducing cost.
The SAP-C02 exam expects you to know not just the iterative process, but also the specific AWS services and features that enable each step. For example, you must understand how to use AWS Compute Optimiser to get instance type recommendations, how to set up Cost Anomaly Detection to alert you to unexpected spend, and how to use Auto Scaling with dynamic scaling policies (automatically adjusting capacity based on demand) to match performance to actual load in real time.
Establish a Baseline
Collect current metrics on performance (response time, throughput, error rates) and cost (monthly spend per service, per resource) using CloudWatch, Cost Explorer, and Trusted Advisor. This gives you a point of reference to compare after changes.
Analyse the Data to Identify Bottlenecks and Waste
Look for resources with low utilisation (e.g., CPU below 20%), idle resources (EC2 instances running with zero traffic), or performance bottlenecks (database query latency, network congestion). Prioritise the biggest impact items first.
Plan One Specific Change
Choose exactly one improvement — for example, right-sizing an instance type or adding a cache layer. Define success criteria (e.g., reduce EC2 cost by 20% without increasing response time above 2 seconds). Avoid planning multiple changes at once.
Implement the Change in a Controlled Way
Use blue/green deployments or canary releases to minimise risk. For EC2 right-sizing, you might create a new instance type, test it in a staging environment, then switch production traffic. Automate where possible with AWS Systems Manager.
Re-measure and Compare to Baseline
After the change, run the same metrics you collected before. Compare the new numbers against the baseline. If performance and cost improved, move to the next iteration. If not, roll back and try a different change. This validates that the iteration was effective.
Schedule Regular Optimisation Reviews
Set a recurring calendar reminder (e.g., monthly) to repeat the cycle. Even if no immediate problems exist, new AWS features or changing usage patterns may offer new optimisation opportunities. This prevents cost drift and performance degradation over time.
An IT professional — let’s call her Priya — manages a customer-facing analytics platform running on AWS. The platform processes raw data uploaded by users and generates visual reports. Priya’s goal is to keep the platform fast (reports should load in under 2 seconds) while staying within a monthly budget of $50,000.
First, Priya establishes a baseline. She sets up CloudWatch dashboards showing average response time, CPU utilisation for each EC2 instance, and monthly spend per service (EC2, S3, Lambda, RDS). She also enables the AWS Cost Explorer for granular breakdown. The baseline reveals that the average response time is 3.5 seconds — unacceptable — and monthly spend is $62,000, driven mostly by a fleet of 20 general-purpose EC2 instances (m5.large) that run 24/7.
Priya analyses the data. She notices that CPU utilisation on the EC2 instances averages only 12% — the instances are far too powerful for the actual workload. She also sees that the database, an RDS instance, has a high number of read replicas (four) that are rarely queried. Both are drains on cost. The performance bottleneck is not compute but database queries that take long to run; the report generation queries are not indexed properly.
Priya plans her first iteration. She decides to tackle cost first:
Right-size EC2 instances: switch from m5.large to t3.medium, which provides sufficient CPU for the low-utilisation workload.
Reduce the number of read replicas from four to one, which is enough for the actual read load.
Implement a schedule: use AWS Instance Scheduler to turn off non-production EC2 instances overnight and at weekends.
Priya implements these changes during a scheduled maintenance window. She uses AWS Systems Manager to automate the instance type changes and modifies the RDS configuration to remove three read replicas.
After two weeks, she re-measures. Monthly spend has dropped to $38,000. Performance has not degraded — response time is still 3.5 seconds — but at least cost is now under control. Next, she focuses on performance. She adds appropriate indexes to the most commonly filtered columns in the RDS database and introduces an ElastiCache (in-memory cache) layer to store frequently requested report results. After another week, average response time drops to 1.8 seconds, and the database CPU load decreases.
Priya now iterates monthly. She reviews CloudWatch metrics and Cost Explorer data during a standing “optimisation hour” and picks one change per cycle. Over six months, she reduces spend to $32,000 (using Reserved Instances for the remaining steady-state EC2 instances) and further improves performance to 1.2 seconds by switching to Graviton-based instances (ARM processors that offer better price-performance for her workload). She also sets up Cost Anomaly Detection alerts so that if a new feature accidentally drives up costs, she is notified within 24 hours.
The key tools Priya uses:
AWS Compute Optimiser for instance type recommendations.
AWS Cost Explorer and Cost Anomaly Detection for cost analysis.
CloudWatch dashboards and alarms for performance monitoring.
AWS Trusted Advisor for cost optimisation checks (e.g., idle resources).
AWS Systems Manager for automated scheduling and instance management.
This iterative approach is practical, not theoretical. It works because Priya never tries to fix everything at once. She makes one change, measures the impact, and then decides the next move.
The SAP-C02 exam tests your ability to think through a multi-step optimisation process, not just memorise service names. You will see scenario questions where a company has a system with both cost and performance problems, and you must choose the best sequence of improvements.
Exam topics that appear frequently:
Right-sizing EC2 instances: choosing the correct instance family and size based on utilisation data from CloudWatch or Compute Optimiser. Traps include selecting “larger instances just to be safe” (wrong — you should match instances to actual usage) or confusing vertical scaling (making an instance bigger) with horizontal scaling (adding more instances).
Using Reserved Instances and Savings Plans for steady-state workloads: the exam expects you to know that these reduce cost by 30-70% compared to On-Demand, but only make sense for predictable, non-interruptible workloads. A trap is applying them to Spot instances (Spot has its own pricing mechanism) or recommending Reserved Instances for a short-lived project.
Auto Scaling policies: know the difference between simple scaling (manual step adjustments), target tracking (set a target metric like average CPU at 50%, and AWS adjusts automatically), and scheduled scaling (for predictable traffic patterns, e.g., more capacity during business hours). The exam loves to present a scenario where you must combine multiple policies.
Storage cost optimisation: using S3 lifecycle policies to move older data to colder storage tiers (e.g., from S3 Standard to S3 Glacier). Traps include forgetting data retrieval costs when using Glacier for frequently accessed data, or not considering that moving data costs money per GB.
Database read replicas and caching: the exam tests whether you offload repeated read queries to ElastiCache (or DAX for DynamoDB) instead of scaling up the main database. A common trap is adding more read replicas when a cache would be cheaper and more effective.
Measuring and monitoring: you must know which metrics to collect and which AWS services to use. CloudWatch is for metrics; CloudTrail is for API activity logs; VPC Flow Logs for network traffic analysis. A classic trap is using CloudTrail when you need real-time performance data — CloudTrail does not give you CPU utilisation.
Question patterns on SAP-C02:
Multi-part answer choices: “Which combination of steps should the Architect take to reduce costs while maintaining performance?” You will have to select two or three actions. Traps include actions that improve cost but degrade performance (e.g., moving all data to Glacier for storage cost savings, ignoring that the data needs sub-second access) or recommendations that ignore iteration (e.g., “immediately move to all Graviton instances without testing”, which is not iterative and risks breaking the application).
Ordering questions: “Put the steps of the optimisation process in the correct order.” The correct order is always: Measure, Analyse, Plan, Implement, Re-measure. Traps include placing “Implement” before “Analyse” or skipping “Re-measure”.
The cost-performance trade-off: questions where you must sacrifice a bit of cost to gain performance, or vice versa, and choose the option that aligns with the business priority — e.g., a customer-facing app needs speed, so cost optimisation cannot reduce performance below a threshold.
Key definitions to memorise:
Right-sizing: matching instance type and size to actual workload requirements, based on utilisation metrics.
Elasticity: the ability to automatically add or remove resources in response to demand. This is the foundation of both cost and performance optimisation.
Lifecycle policy: an S3 rule that transitions objects between storage classes (e.g., from Standard to Infrequent Access after 30 days) to reduce storage costs over time.
Idle resource: an AWS resource (EC2 instance, load balancer, EBS volume) that exists but is not processing any traffic. It still costs money — a common target for cost savings.
Exam traps to watch for:
Recommending Reserved Instances for a workload that is not yet stable — you should first let it run for a few weeks to collect data on usage patterns.
Suggesting to “downsize all instances immediately” without first checking if the application can handle lower capacity — iteration means changing one thing at a time.
Overlooking data transfer costs: moving data across regions or between services incurs charges. Optimising compute but ignoring data transfer can make your total cost worse.
Optimisation is a continuous cycle: Measure, Analyse, Plan, Implement, Re-measure — never a one-time fix.
Right-sizing EC2 instances based on actual CPU and memory utilisation is the single highest-impact cost optimisation for compute-heavy workloads.
Always establish a baseline of performance and cost before making any architectural change, so you can measure the impact accurately.
Reserved Instances and Savings Plans reduce cost by 30-70% for steady-state workloads but are unsuitable for short-lived or unpredictable workloads.
Auto Scaling with target tracking policies dynamically matches capacity to demand, optimising both cost and performance in real time.
Use lifecycle policies on S3 to automatically move infrequently accessed data to cheaper storage tiers, reducing per-GB storage costs.
Never sacrifice performance below a business-critical threshold in pursuit of cost savings — the exam rewards balanced decisions.
Implement changes one at a time to isolate their effect; changing multiple things simultaneously makes it impossible to know what worked.
These come up on the exam all the time. Here's how to tell them apart.
Right-sizing
Changes the size of an existing instance (e.g., from m5.large to m5.medium) to match workload needs
Usually a one-time change per instance, done infrequently
Goal: eliminate resource waste by matching capacity precisely to demand
Scaling
Adds or removes instances (horizontal scaling) or makes an instance larger (vertical scaling) in response to demand
Happens automatically or semi-automatically based on traffic changes
Goal: adjust capacity reactively to handle varying load
Reserved Instances
Requires a 1- or 3-year commitment upfront for a discount of 30-70% over On-Demand
Best for steady-state, predictable workloads that run 24/7
Cannot be stopped or changed easily without incurring fees
On-Demand Instances
Pay per hour with no commitment — maximum flexibility
Best for short-term, variable, or experimental workloads
Most expensive per hour, but allows zero-risk changes
Cost Optimisation
Focuses on reducing AWS spend through right-sizing, reserved pricing, and storage lifecycle policies
May involve moving to cheaper instance types or storage tiers
Must ensure performance requirements are still met — not just lowest cost
Performance Optimisation
Focuses on improving speed, throughput, and user experience
May involve upgrading instances, adding caching, or optimising database queries
May increase cost if resources are scaled up, but justified by business value
One-time architecture change
A single, large migration or redesign (e.g., lift-and-shift to cloud)
High risk — if wrong, the entire system may need rework
No built-in mechanism for future improvements
Iterative optimisation
Small, frequent, data-driven changes (e.g., adjusting instance size monthly)
Low risk — each change is reversible and tested independently
Continuous improvement loop that adapts to changing conditions
Mistake
Optimising cost and performance means making one big, perfect architecture change that will fix everything forever.
Correct
Optimisation is a continuous cycle of small, data-driven improvements. One big change is risky and rarely perfect because conditions change over time.
This mistake is common because beginners think of architecture like building a house — you design it once, build it, and then it is done. In the cloud, the environment changes constantly, so you must keep iterating.
Mistake
Cost optimisation always means choosing the cheapest AWS service or instance type available.
Correct
Cost optimisation means achieving the best value — the lowest cost that still meets your performance requirements. The cheapest option often has poor performance or high hidden costs (like data retrieval fees).
Beginners often confuse 'cost' with 'efficiency'. The cloud is about trade-offs; paying a bit more for a faster instance can reduce user wait times and prevent lost revenue, which is worth the extra spend.
Mistake
Performance optimisation is just about making things faster — it has nothing to do with cost.
Correct
Performance and cost are tightly linked. For example, adding more CPU capacity improves speed but increases cost. Conversely, a poorly performing system can cost more because users leave, or you run extra instances to compensate for slow code.
People tend to think of performance and cost as independent levers. In reality, a change to one almost always affects the other, and the exam tests your ability to balance them.
Mistake
Once you have measured and optimised a workload, you can stop — the job is done.
Correct
Optimisation is never complete. New AWS services are released, your workload grows, user behaviours change, and pricing updates occur. You should schedule regular optimisation reviews (e.g., monthly) to check if improvements are still valid.
This belief comes from the traditional IT mindset where you 'set and forget' infrastructure. Cloud is dynamic; without ongoing attention, cost drift and performance degradation happen silently.
Mistake
You should always use the most recent AWS instance type because it is the most cost-effective.
Correct
Newer instance types are often better for price-performance, but you must test them with your specific workload. Some applications are not compatible with newer hardware (e.g., Graviton ARM processors) or need specific features (like high network bandwidth) that only certain generations support.
The cloud industry markets 'newer is better', and beginners assume it always applies. Iterative optimisation requires validating that a change actually works for your particular use case before scaling it.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Start with monthly reviews after the initial launch. Once the architecture stabilises, quarterly reviews are often enough, unless you have high traffic volatility or frequent new feature releases.
Right-sizing means changing an existing instance to a different size (e.g., from m5.large to m5.medium). Scaling means adding or removing instances (horizontal scaling) or making an instance bigger (vertical scaling). Right-sizing is for when your instance is mismatched to the load; scaling handles changes in demand.
Use CloudWatch metrics and logs — they are passive and do not impact performance. For deeper diagnostics, use AWS X-Ray for tracing requests, which adds minimal overhead. Always test in a staging environment first if changes are risky.
No. Reserved Instances are best for workloads that run 24/7 for at least one year. For short-term projects, variable workloads, or development environments, On-Demand or Spot Instances are more cost-effective because they avoid upfront commitments.
The biggest trap is recommending a change that saves money but breaks performance requirements. For example, moving all data to Glacier storage without checking that the data needs sub-second access. Always verify that performance constraints are met before choosing a cost-savings measure.
There is no permanent state of 'optimised'. Even if performance targets are met and costs are low, new AWS services (like Graviton instances or S3 Intelligent-Tiering) could improve things further. Regularly review your baseline against the latest AWS pricing and features.
Roll back immediately to the previous configuration. The change was not successful. Then, re-analyse: maybe the workload needs a different instance type (e.g., compute-optimised instead of general-purpose) or a cache layer before you can downsize compute.
You've finished Optimizing Performance and Cost Through Iteration. Continue through the SAP-C02 study guide to build a complete picture of the exam.
Done with this chapter?