High-Performance and Cost-Optimised Scenarios

Scenario: A news website's RDS MySQL database serves 90% read traffic for article content that changes at most once an hour. Database CPU averages 80%, costs are rising, and latency is 200ms per query. Solution: Add an ElastiCache Redis cluster in front of RDS using the lazy loading (cache-aside) pattern. Application checks cache first — on a cache hit, return the cached article in <1ms. On a miss, query RDS, return the result, and write it to the cache with a 1-hour TTL. Expected result: 90% cache hit rate, RDS CPU drops to under 20%, latency drops to under 5ms for cached responses.

Scenario: Users in Asia Pacific experience 2-4 second load times for a web application hosted on EC2 in us-east-1. The application serves large static assets (images, JS, CSS). Solution: Place a CloudFront distribution in front of the ALB. Configure a cache behaviour for the /static/* path with a long TTL (e.g., 1 week) so static files are cached at CloudFront edge locations near users in Asia. Dynamic API requests bypass caching with TTL=0. Asian users load static assets from a Singapore or Tokyo edge location in under 100ms instead of waiting for round trips to us-east-1.

Scenario: A company has 500 EC2 instances, many provisioned 3 years ago with large instance types. Their AWS bill is high but they do not know which instances are over-provisioned. Solution: Enable AWS Compute Optimizer (free, uses 14 days of CloudWatch metrics). Compute Optimizer analyses each instance's actual CPU, memory, network, and disk utilisation and provides recommendations to right-size. A t3.xlarge running at 8% CPU average would be recommended to downsize to t3.small. Applying recommendations across 500 instances typically reduces EC2 costs by 20–40%.

Scenario: A genomics company runs nightly batch jobs that take 8 hours and can be retried if interrupted. EC2 On-Demand costs $10,000 per month for these jobs. Solution: Use EC2 Spot Instances for the batch processing fleet. Spot Instances are unused EC2 capacity available at up to 90% discount. For interruption-tolerant batch jobs, use AWS Batch which automatically re-queues failed Spot jobs and uses a mixed fleet (Spot + minimal On-Demand fallback). Expected savings: 70–90% reduction in compute costs — from $10,000 to $1,000–3,000 per month.

Scenario: A gaming leaderboard uses DynamoDB with provisioned throughput. During game launches, traffic spikes 50x and the table throttles requests. Outside launches, throughput is near zero — provisioned capacity is wasted. Solution: Switch DynamoDB to On-Demand capacity mode. On-Demand scales instantly to any throughput without manual capacity planning, and charges per request rather than per provisioned unit. You pay only for the requests you make — no idle capacity cost between launches. On-Demand trades slightly higher per-request cost for guaranteed no-throttle and zero capacity management.

Scenario: A company stores millions of user-generated images in S3 Standard. Access patterns vary unpredictably — some images are accessed daily, others not for months. They want to reduce storage costs without managing lifecycle policies manually. Solution: Use S3 Intelligent-Tiering. It automatically moves objects between tiers based on access patterns: Frequent Access (Standard), Infrequent Access (30+ days not accessed), Archive Instant Access (90+ days), and Archive Access (90+ days, opt-in). There are no retrieval fees within Intelligent-Tiering. The monitoring charge is $0.0025 per 1,000 objects per month — negligible for large datasets.

Scenario: A startup wants to query S3 data lake tables. They run about 10 ad hoc queries per week. A vendor proposes Amazon Redshift with a dc2.large cluster. Solution for a startup: Start with Amazon Athena — zero infrastructure cost, pay only for data scanned (~$5/TB). 10 queries per week on well-partitioned Parquet data might cost under $5/month. Redshift dc2.large costs ~$180/month continuously. Redshift becomes cost-effective only when query concurrency is high (50+ queries/day) or sub-second response is required. The keyword 'ad hoc, infrequent' firmly points to Athena.

Scenario: A relational database server requires 64,000 IOPS with consistent low latency. The current gp3 EBS volume is hitting its IOPS ceiling. Solution: Upgrade to io2 Block Express (EBS volume type designed for I/O-intensive databases). io2 Block Express supports up to 256,000 IOPS per volume and sub-millisecond latency. It is more expensive than gp3 ($0.125/GB + $0.065/provisioned IOPS/month) but the only EBS option that meets 64,000+ IOPS requirements. For latency-critical database workloads where gp3's 16,000 IOPS ceiling is insufficient, io2 is the only viable EBS choice.

Scenario: A company runs 20 r6i.4xlarge EC2 instances continuously for a production application and expects no change in requirements for 3 years. Their current On-Demand spend is $80,000/year for these instances. Solution: Purchase 3-year Standard Reserved Instances (or Compute Savings Plans) with All Upfront payment for the maximum discount. Standard Reserved Instances offer up to 72% discount versus On-Demand. The instances run 24/7 with predictable workload — the classic profile for Reserved Instances. Expected cost reduction: $80,000 × 0.72 = $22,400/year vs. $80,000/year On-Demand — saving $57,600/year.

Scenario: A company runs a REST API on a t3.micro EC2 instance costing $8/month. The API receives 1 million requests/month, each taking 100ms to process. The team asks if Lambda would be cheaper. Analysis: Lambda pricing: 1,000,000 requests × $0.0000002 = $0.20 (request cost) + 1,000,000 × 0.1s × 128MB memory × rate = ~$1.67 (compute cost) = ~$1.87/month. Lambda is cheaper than EC2 for this low-traffic API. As traffic grows above ~40 million requests/month, EC2 becomes cheaper. Use the Lambda Cost Calculator to find the break-even for each workload.

Scenario: A global API serving users in Europe, US, and Asia experiences inconsistent latency because traffic traverses unpredictable internet paths. CloudFront was considered but the API responses are dynamic (non-cacheable). Solution: Use AWS Global Accelerator. It provides two static anycast IP addresses globally. User traffic enters the AWS global backbone at the nearest AWS edge location and travels over AWS's private network to the origin in the target Region — avoiding the congested public internet middle-mile. Global Accelerator improves dynamic API response time by 20-60% and provides instant failover when a Region endpoint becomes unhealthy.

Test your understanding of AWS Solutions Architect (SAA-C03) concepts from this lesson.

In this lesson you worked through scenarios covering: ElastiCache lazy loading to reduce RDS CPU from 80% to 20%, Spot Instances and AWS Batch for 70-90% batch job cost savings, Athena for infrequent ad hoc queries versus Redshift for high-concurrency analytics, and S3 Intelligent-Tiering for unpredictable access patterns without retrieval fees. Next up is the final capstone: a timed mixed-domain mini exam to measure your readiness.