Domain 4: Design Cost-Optimized Architectures

AWS Certified Solutions Architect – Associate (SAA-C03) — Domain 4: Design Cost-Optimized Architectures

Exam Code: SAA-C03  |  Level: Associate
Domain Weight: 20%  |  Total Domains: 4  |  Passing Score: 720/1000

---

Table of Contents

1. Cost-Optimized Storage
   • 1.1 S3 Cost Optimization
   • 1.2 EBS Cost Optimization
   • 1.3 EFS and FSx Cost Optimization
2. Cost-Optimized Compute
   • 2.1 EC2 Purchasing Decision Framework
   • 2.2 Serverless and Container Cost Models
   • 2.3 Right-Sizing and Auto Scaling for Cost
3. Cost-Optimized Databases
   • 3.1 RDS and Aurora Cost Optimization
   • 3.2 DynamoDB Cost Optimization
   • 3.3 Database Selection for Cost Efficiency
4. Cost-Optimized Network Architectures
   • 4.1 Understanding AWS Data Transfer Costs
   • 4.2 VPC Endpoints for Cost Reduction
   • 4.3 Content Delivery and Routing Cost Optimization
5. AWS Cost Management Tools
   • 5.1 AWS Cost Explorer and Budgets
   • 5.2 AWS Cost and Usage Report (CUR)
   • 5.3 Cost Allocation Tags
   • 5.4 AWS Trusted Advisor and Compute Optimizer
6. Cost Optimization Architecture Patterns
   • 6.1 Well-Architected Cost Optimization Pillar
   • 6.2 Cost Hierarchy Reference
7. Exam Tips & Quick Reference

---

1. Cost-Optimized Storage

1.1 S3 Cost Optimization

S3 Storage Class Cost Reference

Key Concept: S3 Intelligent-Tiering has no retrieval fees — it automatically moves objects between frequent, infrequent, and archive access tiers based on actual access patterns. The small per-object monitoring charge is offset by storage savings. Use it whenever the access pattern is unknown or changes over time.

S3 Lifecycle Policy — Typical Pattern

Example: Application log lifecycle

Day 0:    S3 Standard           (active analysis; frequent access)
Day 30:   → S3 Standard-IA     (analysis complete; infrequent access)
Day 90:   → S3 Glacier Flexible (archival; rare access)
Day 365:  → DELETE              (retention policy met)

Transition rules:
  Standard → Standard-IA:  must remain in Standard for ≥ 30 days
  Any → Glacier:            object must be ≥ 90 days old (IA) or per lifecycle config
  Note: minimum storage duration charges still apply even if deleted early

S3 Cost Reduction Strategies

Incomplete Multipart Upload cleanup — Incomplete uploads accumulate as charged storage with no usable object. Add a lifecycle rule: AbortIncompleteMultipartUpload after 7 days. Use S3 Storage Lens to monitor IncompleteMultipartUploadBytes.

Versioning cost management — With versioning enabled, all versions of every object are stored and charged. Add lifecycle rules to expire noncurrent versions after N days and delete expired delete markers.

S3 Requester Pays — By default the bucket owner pays for storage and data transfer. With Requester Pays enabled, the requester pays data transfer costs. Use when sharing large public or partner datasets.

---

1.2 EBS Cost Optimization

EBS Type Selection for Cost

Key Concept: Migrating from gp2 to gp3 for existing volumes typically reduces cost by ~20% while improving or matching performance. gp2 forces you to over-provision volume size to achieve target IOPS (3 IOPS/GB). gp3 lets you set IOPS independently at any size. This is always the correct answer when the question asks how to reduce EBS costs on a general-purpose workload.

EBS Snapshot Lifecycle Management

Use Amazon Data Lifecycle Manager (DLM) to automate snapshot creation schedules and deletion. Snapshots are incremental — only changed blocks are stored — but they accumulate over time and add cost without automation. Avoid enabling Fast Snapshot Restore (FSR) for every snapshot; it adds cost and is only needed for volumes that will be restored frequently.

---

1.3 EFS and FSx Cost Optimization

EFS Storage Tiers

Enable EFS lifecycle management to automatically move files to Infrequent Access storage after 30, 60, or 90 days of inactivity. There is no performance difference for file retrieval — only a small per-retrieval charge.

FSx Cost Considerations

For FSx for Lustre, choose Scratch deployment for temporary processing (lower cost, no replication) and Persistent deployment for long-term use. For FSx for Windows, HDD storage is cheaper than SSD for workloads where IOPS is not the bottleneck.

---

2. Cost-Optimized Compute

2.1 EC2 Purchasing Decision Framework

Choose the right purchasing option before deploying — this is the single largest lever for reducing EC2 costs.

Decision by Workload Type

Reserved Instance Types — Decision Matrix

RI Scope Comparison:

Exam Tip: Standard RIs can be sold on the RI Marketplace. Convertible RIs cannot be sold. If a question mentions flexibility to change instance types, Convertible RI or Compute Savings Plan is more appropriate than Standard RI.

Savings Plans — When to Choose Over RIs

EC2 Instance Savings Plan — commit to a specific instance family in a specific Region. Can change size (m5.large → m5.xlarge), OS, and tenancy within that family.

Compute Savings Plan — applies to any EC2 instance (any Region, family, size, OS, tenancy), Lambda function charges, and Fargate tasks. Lower discount than Instance Savings Plan but maximum flexibility.

Choose Compute Savings Plans when: migrating workloads across Regions, using a mix of EC2 + Lambda + Fargate, or uncertain about future instance type requirements.

---

2.2 Serverless and Container Cost Models

Lambda vs. EC2 Cost Comparison

Lambda cost optimization:

• Right-size memory — use AWS Lambda Power Tuning to find the optimal memory setting. More memory = faster execution, which can reduce total GB-seconds cost.
• Reduce execution time — move initialization outside the handler; reuse connections; minimize package size.
• Use Savings Plans for Lambda — Compute Savings Plans apply to Lambda provisioned concurrency charges.

AWS Fargate Cost Model

Fargate charges per vCPU and memory per second. No charge for idle capacity (unlike EC2). More expensive per vCPU-second than EC2 for steady-state workloads, but cost-effective for variable and intermittent workloads where EC2 instances would sit idle.

---

2.3 Right-Sizing and Auto Scaling for Cost

Right-Sizing Tools

Auto Scaling for Cost Efficiency

• Set appropriate minimum capacity — do not over-provision the floor.
• Use scheduled scaling to pre-scale for known demand windows and scale in during off-hours.
• Use scale-in cooldown periods to prevent premature scale-out after scale-in events.

Example: Business hours scheduled scaling
08:00 Mon–Fri: Scale OUT to desired=10 (pre-warm before business starts)
20:00 Mon–Fri: Scale IN to desired=2  (keep minimum overnight)
Weekend:       Keep at desired=1       (dev/test traffic only)

Spot Instance Strategy for Cost Reduction

• Use Mixed Instances Policy — specify multiple instance types across multiple AZs; more Spot capacity pools means lower interruption probability.
• Use capacity-optimized allocation strategy — AWS selects pools with most spare capacity; minimizes interruptions over lowest-price strategy.
• Checkpointing — save progress regularly so that an interrupted Spot Instance can be restarted without losing all work.

---

3. Cost-Optimized Databases

3.1 RDS and Aurora Cost Optimization

RDS Cost Levers

Right-size instances — use Performance Insights and CloudWatch to identify CPU and memory headroom before scaling up. Multi-AZ adds a standby instance (double the instance cost) — use Multi-AZ only for production.

Read replicas instead of vertical scaling — for read-heavy workloads, adding a read replica and routing reads to the replica endpoint is cheaper than upgrading to a larger primary instance.

RDS storage choice — use gp3 storage for RDS (configurable IOPS independent of size). Non-Aurora RDS storage can only be increased, not decreased. Aurora storage auto-grows and is charged per GB-month; delete old snapshots to reduce cost.

Stopping RDS instances (dev/test) — RDS can be stopped for up to 7 days with no compute charges (storage charges continue). AWS automatically restarts the instance after 7 days. Use AWS Instance Scheduler to automate stop/start based on tags.

Aurora Serverless v2 for Variable Workloads

Aurora Serverless v2 scales from 0.5 ACU to 128 ACU in fine-grained increments with per-second billing. It eliminates over-provisioning for variable or bursty workloads and is ideal for dev/test environments, multi-tenant SaaS, and applications with seasonal traffic.

---

3.2 DynamoDB Cost Optimization

On-Demand vs. Provisioned Capacity — Cost Decision

DynamoDB TTL (Time to Live)

TTL automatically deletes items after a specified timestamp attribute expires. No RCU or WCU is consumed for TTL deletions. Use TTL for: session data, temporary tokens, cache-like data, or any item with a natural expiration. Deleted items appear in DynamoDB Streams for up to 24 hours.

Archiving Historical DynamoDB Data

For historical data that is rarely accessed, export to S3 and query with Athena. S3 + Athena is dramatically cheaper than keeping old data in DynamoDB. Use the Export to S3 feature (no RCU consumed during export) on a point-in-time snapshot.

---

3.3 Database Selection for Cost Efficiency

Note: Managed services (RDS, Aurora, DynamoDB) have a higher AWS service fee than running a database on EC2, but the total cost of ownership is usually lower when you include the labor cost of patching, backup management, failover configuration, and monitoring. For production workloads, managed services are almost always more cost-effective.

---

4. Cost-Optimized Network Architectures

4.1 Understanding AWS Data Transfer Costs

Understanding what is free and what is charged prevents expensive surprises.

FREE data transfers:
  ✓ Inbound from internet to AWS (any service)
  ✓ Within the same AZ using private IP addresses
  ✓ Between EC2 and S3/DynamoDB via Gateway VPC Endpoints
  ✓ CloudFront to S3 origin in the same Region

CHARGED data transfers:
  ✗ Outbound from AWS to the internet (per GB)
  ✗ Between Regions (cross-region replication, cross-region VPC peering)
  ✗ Between AZs in the same Region (using public IPs or private IPs)
  ✗ NAT Gateway data processing ($0.045/GB)
  ✗ Interface VPC Endpoints (PrivateLink): $0.01/hr + $0.01/GB

Exam Tip: The single most common cost optimization question involves private EC2 instances accessing S3 or DynamoDB. The answer is always Gateway VPC Endpoint (free) — it eliminates NAT Gateway data processing charges ($0.045/GB) and keeps traffic private. This is a real-world optimization that saves significant money at scale.

---

4.2 VPC Endpoints for Cost Reduction

Endpoint Type Cost Comparison

NAT Gateway vs. NAT Instance

Reducing Cross-AZ Data Transfer Costs

Each data transfer between AZs (even within the same VPC) is charged. To minimize:

• Place resources that communicate frequently in the same AZ when possible.
• Configure ElastiCache read replicas in the same AZ as the consuming application.
• Use the private IP address for all EC2-to-EC2 communication within the same AZ (cross-AZ private IP traffic is charged; same-AZ private IP is free).

---

4.3 Content Delivery and Routing Cost Optimization

CloudFront for Data Transfer Cost Reduction

CloudFront data transfer rates are significantly lower than direct EC2-to-internet transfer rates. Caching at the edge reduces the number of requests hitting your origin (EC2 or S3), which reduces both compute cost and data transfer cost.

• Cache-Control headers from your origin control how long CloudFront holds objects before re-fetching.
• WAF deployed on CloudFront is cheaper than deploying WAF on every regional ALB.
• S3 requests from CloudFront in the same Region are free (no inter-service transfer charge).

AWS Direct Connect for High-Volume Transfer

Direct Connect data transfer rates are substantially lower than public internet transfer rates. The break-even point is roughly 1–2 TB/month of outbound transfer, depending on the Direct Connect commitment tier. Requires a 1–3 year contract and physical provisioning time.

AWS Transit Gateway — Multi-VPC Cost Considerations

For large numbers of VPCs, Transit Gateway is cheaper than managing a mesh of VPC peering connections because it eliminates the routing complexity — even though it adds a per-attachment and per-GB charge.

---

5. AWS Cost Management Tools

5.1 AWS Cost Explorer and Budgets

AWS Cost Explorer

Cost Explorer provides visualization and analysis of historical and forecasted AWS costs with 12 months of history and 12-month forecasting.

AWS Budgets

AWS Budgets alerts when spending, usage, RI coverage, or Savings Plans coverage exceed thresholds.

Budget Actions — the most powerful feature. When a threshold is breached, automatically apply an IAM policy or SCP to prevent launching new resources. This is the only AWS native way to programmatically stop overspending.

Exam Tip: The question "how to automatically prevent spending beyond a budget" has one answer: AWS Budgets with Budget Actions that applies an SCP or IAM policy. CloudWatch alarms + SNS only sends notifications; they don't take action on spending.

---

5.2 AWS Cost and Usage Report (CUR)

The most granular cost data available from AWS. CUR includes hourly or daily line items for every resource, usage type, tag, and pricing dimension. Delivered to an S3 bucket; query with Athena or load into Redshift for custom dashboards.

Use CUR for: engineering-level cost analysis, chargeback/showback to internal teams, building custom cost dashboards, and detailed per-resource attribution.

---

5.3 Cost Allocation Tags

Tags applied to AWS resources appear in Cost Explorer and CUR after they are activated in the Billing Console of the management (payer) account.

Exam Tip: Tags must be activated in the management account's billing settings before they appear in cost reports. This is a frequently tested detail — applying tags to resources is not sufficient; they must also be activated in billing.

---

5.4 AWS Trusted Advisor and Compute Optimizer

AWS Trusted Advisor — Cost Optimization Checks

Full Trusted Advisor access (including cost checks above the basic level) requires Business or Enterprise Support.

AWS Compute Optimizer

ML-based service that analyzes CloudWatch metrics and recommends right-sized resources for EC2 instances, EC2 Auto Scaling groups, ECS services on Fargate, Lambda functions, and EBS volumes.

---

6. Cost Optimization Architecture Patterns

6.1 Well-Architected Cost Optimization Pillar

AWS Well-Architected defines five design principles for cost optimization:

1. Implement cloud financial management — assign ownership; designate a cost optimization team; track cost KPIs.
2. Adopt a consumption model — pay only for what you use; automate shutdown of non-production resources after hours.
3. Measure overall efficiency — track cost per business output (cost per transaction, cost per user); not just total spend.
4. Stop spending on undifferentiated heavy lifting — use managed services (RDS, Lambda, ECS) instead of self-managed infrastructure.
5. Analyze and attribute expenditure — tag every resource; use CUR; ensure teams see their own costs.

Common Cost Optimization Patterns

Auto-stop non-production resources:

EventBridge Scheduler → Lambda → stop RDS and EC2 instances after 6 PM weekdays
EventBridge Scheduler → Lambda → start them at 8 AM weekdays
Weekend: keep stopped entirely (dev traffic goes to smaller test environment)

Right-size before reserving:

1. Deploy on On-Demand → run for 2–4 weeks
2. Analyze CloudWatch metrics (CPU, memory, network, disk)
3. Right-size to correct instance family and size
4. Purchase RI or Savings Plan for the right-sized instance

Key Concept: Never buy Reserved Instances for a workload that has not been right-sized first. Reserving an over-provisioned instance wastes the discount on unused capacity.

---

6.2 Cost Hierarchy Reference

Compute Cost Hierarchy (Cheapest to Most Expensive per Unit of Work)

1. Spot Instances         — Up to 90% off; interruption-tolerant workloads only
2. Reserved Instances /
   Savings Plans          — Up to 72% off; 1–3 year commitment required
3. Fargate / Lambda       — Variable; competitive for appropriate workloads
4. On-Demand Instances    — Full price; maximum flexibility; no savings
5. Dedicated Hosts        — Compliance; licensing; highest cost

Storage Cost Hierarchy (Approximate, Cheapest to Most Expensive per GB)

---

Exam Tips & Quick Reference

Scenario-to-Answer Mapping

---

Common Traps

• RI before right-sizing: Purchasing Reserved Instances before right-sizing locks in a discount on the wrong instance size. Always right-size first, then reserve.
• Standard vs. Convertible RI selling: Standard RIs can be sold on the RI Marketplace. Convertible RIs cannot. This distinction appears on the exam.
• Budget Actions vs. Alarms: CloudWatch Alarms send notifications; they do not take cost-limiting actions. Only AWS Budgets with Budget Actions can automatically restrict new resource launches.
• Tag activation: Applying tags to resources is not enough — tags must be activated in the billing console of the payer account before they appear in Cost Explorer or CUR.
• NAT Gateway for S3: A very common expensive mistake: sending S3 traffic through a NAT Gateway at $0.045/GB when a free Gateway VPC Endpoint would eliminate the charge entirely.
• Intelligent-Tiering monitoring fee: S3 Intelligent-Tiering has a small per-object monitoring charge. For objects < 128 KB, the monitoring fee may exceed the storage savings — consider using Standard or Standard-IA directly for small objects.
• Compute Optimizer memory metrics: Compute Optimizer cannot provide memory-based recommendations unless the CloudWatch agent is installed on EC2 instances to publish memory metrics.
• Spot for stateful workloads: Spot Instances are inappropriate for stateful workloads that cannot be interrupted. They are only suitable for fault-tolerant, stateless, or checkpointing-capable workloads.

---

Key Terms — Domain 4

---

End of Domain 4. You have completed all four SAA-C03 study domains.

Domain weight summary: Domain 1 (30%) · Domain 2 (26%) · Domain 3 (24%) · Domain 4 (20%)