AWS Exam Review
Performance And Cost Mixed Drills
Practice SAA-C03 mixed scenarios where scalability, latency, throughput, compute sizing, caching, storage tiers, database capacity, edge delivery, and cost optimization interact.
After this, you will understand
Performance and cost drills teach the core AWS habit of buying elasticity only where it changes the bottleneck.
Scale the hot path, cache repeated reads, pick the right storage tier, and avoid paying for unused steady capacity.
Learners choose the fastest-looking option even when the question asks for cost-effective performance under a specific access pattern.
Find the bottleneck, classify the demand pattern, then choose the cheapest AWS mechanism that satisfies latency, throughput, and availability.
Think before readingWhat question should you ask before choosing a performance service?
Reading in progress
This page is saved in your local study history so you can continue later.
Study path
Read these in order
Start with the mechanics, then move into the patterns that explain why the system is shaped this way.
Concepts Covered
- Mixed performance and cost scenario reading
- Auto Scaling versus overprovisioning
- Read replicas and caching
- CloudFront and edge caching
- S3 storage tier decisions
- DynamoDB capacity mode choices
- Lambda memory and duration tradeoffs
- NAT Gateway versus VPC endpoint cost
- Savings Plans and Spot Instance boundaries
- Cost-aware scaling traps
1. Domain Mental Model
Performance questions tempt learners to choose the biggest resource. Cost questions tempt learners to choose the cheapest resource. SAA-C03 often tests the harder middle: meet the performance requirement at the lowest appropriate cost.
The exam wording usually gives enough clues to classify demand:
steady -> commit or right-size
bursty -> elastic or serverless
read-heavy -> cache or replica
global repeated content -> edge cache
unknown object access -> intelligent tiering
private service traffic -> endpoint before NAT when supported
Do not optimize blindly. A cheaper option that misses latency is wrong. A faster option that ignores the requested cost constraint is also wrong.
2. Official Task Map
This drill set sits across SAA-C03 Domain 3 and Domain 4.
Domain 3 asks for high-performing storage, compute, database, network, and data ingestion designs. Domain 4 asks for cost-optimized storage, compute, database, and network architectures.
When these domains combine, the question usually sounds like:
meet the latency or throughput target, but do not overpay for capacity the workload does not need
That is why Auto Scaling, caching, replicas, edge delivery, S3 storage classes, DynamoDB capacity modes, NAT costs, serverless scaling, Spot, and Savings Plans often show up together.
3. What AWS Is Testing
Start by naming the hot path. Is the slow part the web tier, database, object storage, file system, analytics query, network transfer, or external dependency?
Then classify the workload. Is traffic predictable, spiky, seasonal, read-heavy, write-heavy, latency-sensitive, batch-oriented, interruptible, or globally distributed?
Finally, match the pricing shape. AWS charges differently for provisioned capacity, requests, data transfer, storage duration, monitoring, state transitions, and managed service features.
The best answer is usually the smallest architecture move that satisfies the stated performance target.
4. Service And Concept Clusters
Use these clusters while drilling:
- Compute elasticity: Amazon EC2 Auto Scaling, AWS Auto Scaling, Lambda vs ECS/Fargate vs EC2
- Database performance: RDS Multi-AZ vs Read Replicas, Amazon ElastiCache, ElastiCache vs DynamoDB DAX
- Storage cost and performance: Amazon S3, S3 Lifecycle And Storage Classes, S3 vs EBS vs EFS vs Instance Store
- Edge and network: Amazon CloudFront, CloudFront vs Global Accelerator, NAT Gateway vs VPC Endpoints
- Cost tooling: AWS Cost Explorer, AWS Budgets, AWS Compute Optimizer, AWS Savings Plans
5. Architecture Reasoning Patterns
Use the drills below to practice this cost-aware performance trace:
bottleneck -> demand pattern -> freshness requirement -> scaling mechanism -> pricing shape
Drill 1: Global Static And Dynamic Web Traffic
Scenario: A public website serves static assets globally and has API traffic to an origin in one Region. Users complain about latency. The business wants lower origin load and better global response time.
Best answer: use CloudFront for cacheable static content and appropriate cache behavior for dynamic paths. Keep the origin protected and tune TTLs, cache keys, compression, and origin settings.
Why: repeated global content should move closer to users. CloudFront can reduce latency and origin requests. For dynamic APIs, cache only when correctness allows it.
Distractors:
- Scaling the origin only adds capacity in one Region.
- Moving everything to Multi-Region active-active may exceed the requirement and cost.
- A larger load balancer does not reduce global distance.
- ElastiCache helps application/database reads but does not deliver static assets at the edge.
Drill 2: Read-Heavy Relational Database
Scenario: An RDS-backed application has slow read queries during peak hours. Writes are healthy. The team wants better read performance without changing the database engine.
Best answer: add read replicas for read scaling when the application can route read traffic appropriately. Consider ElastiCache when repeated reads can tolerate cached data and the access pattern fits.
Why: read replicas increase read capacity. Caching reduces repeated database reads. Multi-AZ is not the performance answer here because it is for high availability and failover.
Distractors:
- Multi-AZ improves resilience, not normal read throughput.
- A larger primary may work but can be less cost-effective than read scaling or caching.
- DynamoDB migration is not the least disruptive answer if the requirement says keep the relational engine.
- Backups do not improve query latency.
Drill 3: Unpredictable S3 Access Patterns
Scenario: A team stores millions of objects in S3. Some are accessed frequently for a few weeks, then rarely. Others become popular unpredictably. The team wants cost savings without operational guessing.
Best answer: use S3 Intelligent-Tiering for objects with unknown or changing access patterns, and use lifecycle policies when the transition schedule is predictable.
Why: lifecycle rules are excellent when access age is known. Intelligent-Tiering is better when access is uncertain and the monitoring charge is worth the automation.
Distractors:
- S3 Glacier classes are wrong when immediate or unpredictable access is required.
- Keeping everything in Standard is simple but may waste money.
- Manually moving objects by script can create operational risk.
- EBS volume types are unrelated to object storage lifecycle.
Drill 4: Bursty Compute With Some Interruptible Work
Scenario: A service has baseline web traffic, unpredictable bursts, and nightly batch jobs that can retry if interrupted. The company wants lower compute cost while maintaining availability for the web tier.
Best answer: use Auto Scaling for the web tier with appropriate On-Demand or Savings Plan coverage for steady baseline, and use Spot Instances or Spot-capable managed compute for interruptible batch work.
Why: not all compute has the same interruption tolerance. The steady web tier needs reliable capacity. Batch can often trade interruption risk for lower cost.
Distractors:
- Running every workload on Spot risks user-facing availability.
- Buying large reserved capacity for bursts wastes money.
- Vertical scaling alone ignores elasticity.
- Lambda is not automatically best if the workload duration, runtime, networking, or execution shape does not fit.
Drill 5: Private S3 Traffic From Many Subnets
Scenario: Private subnet workloads transfer large amounts of data to S3 through NAT Gateways. The team wants lower cost and no public internet path for supported traffic.
Best answer: use an S3 gateway endpoint and route private subnet traffic to S3 through it. Add endpoint and bucket policy controls when the scenario requires scoped access.
Why: gateway endpoints for S3 avoid NAT device dependency for supported VPC-to-S3 traffic and have no additional endpoint charge. This is both a security and cost clue, but here the cost of NAT data processing is the pressure.
Distractors:
- More NAT Gateways may improve AZ-local resilience but can increase cost.
- Interface endpoints are useful in specific endpoint scenarios but are not the default lowest-cost S3 VPC answer.
- Public S3 access ignores the private-path requirement.
- Direct Connect is not required for traffic already inside a VPC.
6. High-Yield Comparisons
CloudFront versus larger origin: CloudFront reduces distance and repeated origin load; larger origin capacity only helps the Region hosting the origin.
Read replica versus Multi-AZ: read replicas help scale reads; Multi-AZ is for high availability and failover.
ElastiCache versus read replica: cache repeated access when freshness tolerance fits; replicas help query offload while keeping relational query behavior.
S3 Intelligent-Tiering versus lifecycle rules: Intelligent-Tiering fits unknown access; lifecycle rules fit predictable age-based transitions.
Spot versus Savings Plans: Spot fits interruptible work; Savings Plans fit steady eligible usage.
Gateway endpoint versus NAT Gateway: gateway endpoints fit supported private S3 and DynamoDB traffic; NAT handles broader outbound paths but can be more expensive for heavy service traffic.
7. Scenario Triggers
Use this checklist when performance and cost appear together:
- Read-heavy relational database: read replica or cache, depending on freshness and query pattern.
- Repeated global content: CloudFront.
- Unknown S3 access pattern: Intelligent-Tiering.
- Predictable archive schedule: lifecycle transition.
- Steady compute: right-size and commit where appropriate.
- Interruptible batch: Spot.
- Bursty event-driven work: serverless or queue-backed elasticity.
- Private S3/DynamoDB traffic: gateway endpoint before NAT when requirements fit.
8. Common Traps
Do not choose Multi-AZ when the requirement is read throughput.
Do not choose the largest instance before considering horizontal scaling, caching, or right-sizing.
Do not archive objects to a retrieval-delayed class when the scenario needs immediate access.
Do not run user-facing baseline workloads entirely on Spot if interruption is unacceptable.
Do not assume serverless is always cheapest; duration, concurrency, request volume, networking, and logs matter.
Do not pay NAT processing costs for heavy private S3 traffic when a gateway endpoint satisfies the design.
Do not use cost tools as architecture fixes. Cost Explorer and Budgets reveal or alert; they do not automatically change workload design.
9. Study Path
Study in this order:
- Design High-Performing Architectures
- Design Cost-Optimized Architectures
- High-Performing Architecture Trap Drills
- Cost-Optimized Architecture Trap Drills
- CloudFront vs Global Accelerator
- S3 Lifecycle And Storage Classes
- Multi-Account Cost Governance
10. Related Topics
Review High-Performing Architecture Trap Drills, Cost-Optimized Architecture Trap Drills, CloudFront vs Global Accelerator, and S3 Lifecycle And Storage Classes.
Official AWS references:
What to study next
These links keep the session moving: read prerequisites first, then open the systems, concepts, and patterns that deepen this page.
Prerequisites
Read these first if the mechanics feel unfamiliar.
More Links
Additional references connected to this page.