Designing for the four domains
Domain 4: Designing cost-optimized architectures
Domain 4 (20%) asks for the cheapest design that still meets every requirement. Each task statement covers one layer; all share the cost-management tools from cost management.
4.1 Cost-optimized storage
| Situation | Cheapest fit |
|---|---|
| Frequently accessed objects | S3 Standard |
| Unknown or changing access | S3 Intelligent-Tiering |
| Infrequent, re-creatable data | S3 One Zone-IA |
| Archive, rare access | Glacier Flexible Retrieval / Deep Archive (by retrieval time allowed) |
| Lifecycle | S3 lifecycle rules; delete incomplete uploads and old versions |
| Block storage | gp3 over gp2; st1/sc1 for sequential/cold; delete unattached volumes; archive old snapshots |
| Shared files | EFS with lifecycle to IA/Archive; One Zone where acceptable |
| Moving data in | Network transfer (DataSync) if fast enough; Snow Family for very large volumes; Direct Connect for sustained large flows |
| Others download your data | Requester Pays |
| Backups | AWS Backup lifecycle to cold storage; retention matched to policy |
4.2 Cost-optimized compute
| Situation | Cheapest fit |
|---|---|
| Steady 24/7 | Savings Plans / Reserved Instances |
| Interruptible, flexible | Spot (mixed with On-Demand base in ASGs) |
| Spiky / low utilisation | Lambda or Fargate |
| Over-provisioned instances | Right-size with Compute Optimizer; Graviton |
| Non-production | Stop outside working hours; smaller instances; single AZ |
| Long-boot instances that stop/start | Hibernation |
| Choosing a load balancer | ALB for HTTP routing (one ALB can serve many services); NLB/GWLB when needed |
| Edge processing | CloudFront Functions for lightweight logic |
| Hybrid compute | Outposts / Snowball Edge only when on-premises processing is required |
4.3 Cost-optimized databases
| Situation | Cheapest fit |
|---|---|
| Variable or intermittent relational load | Aurora Serverless v2 |
| Steady relational load | Reserved DB instances |
| Key-value with unpredictable traffic | DynamoDB on-demand; predictable → provisioned + auto scaling |
| Repeated expensive reads | Cache (ElastiCache/DAX) |
| Old data rarely read | DynamoDB Standard-IA table class, TTL, export to S3 |
| Time-series or columnar analytics | Timestream; Redshift/Parquet on S3 + Athena |
| Commercial licence costs | Migrate to open-source engines / Aurora (DMS + schema conversion) |
| Backups | Snapshot frequency and retention matched to RPO and policy |
4.4 Cost-optimized networks
| Situation | Cheapest fit |
|---|---|
| Private subnets accessing S3/DynamoDB | Gateway endpoints (free) instead of NAT |
| NAT design | Shared NAT for dev/test; per-AZ for production |
| NAT instance vs gateway | NAT instance can be cheaper for tiny workloads but adds management; gateway preferred for production |
| Many VPCs | Transit Gateway vs many peerings (peering has no hourly charge — cheaper for a few VPCs) |
| Hybrid connectivity | VPN for low/moderate traffic; Direct Connect for high sustained volume (lower egress rates) |
| Global delivery | CloudFront reduces origin load and egress cost |
| Cross-AZ/Region chatter | Keep chatty components together; avoid needless replication |
| Bandwidth sizing | Right Direct Connect speed; multiple VPNs with ECMP on Transit Gateway only if needed |
| Protect backends cheaply | Throttling (API Gateway usage plans), caching |
Key idea
Cost answers are often about removing waste (idle, over-sized, wrong tier, unnecessary data transfer) rather than exotic services. And they must never break a stated requirement.
Exam patterns
- "Logs must be kept 5 years, rarely accessed, retrieval within 12 hours" → lifecycle to Glacier Deep Archive.
- "Private EC2 instances transfer terabytes to S3 through NAT; reduce cost" → S3 gateway endpoint.
- "Nightly batch processing, flexible timing" → Spot Instances / AWS Batch on Spot.
- "Database used only during business hours, unpredictable load" → Aurora Serverless v2.