Skip to main content

Design Cost-Optimized Architectures for SAA-C03

This guide covers Domain 4: Design Cost-Optimized Architectures of the AWS Certified Solutions Architect – Associate (SAA-C03) exam. Cost optimization in AWS is not about choosing the cheapest service in every category. It is about aligning the architecture’s spending with the actual value required by the business, while still meeting security, resilience, and performance objectives. As a solutions architect, you must design systems that deliver the right level of capability for the lowest appropriate cost, and then continuously refine that balance as requirements evolve.

In this domain, you will learn to evaluate AWS pricing and purchasing models, right‑size compute and storage resources, apply elastic scaling, eliminate waste, and use AWS cost management tools to keep architectures financially sustainable.

Learning Objectives​

After completing this domain, you should be able to:

  • Select cost‑effective AWS services and configurations without sacrificing functional requirements.
  • Understand and apply AWS purchasing options: On‑Demand, Reserved Instances, Savings Plans, and Spot Instances.
  • Optimize compute, storage, database, and networking expenditures through right‑sizing and architectural patterns.
  • Implement lifecycle policies and tiered storage to align data cost with access frequency.
  • Design elastic architectures that scale down during low demand.
  • Use cost monitoring tools to detect anomalies and track spending trends.
  • Evaluate cost trade‑offs against security, resilience, and performance.

Core Cost Optimization Principles​

AWS cost optimization rests on a set of design principles that guide your decisions:

  • Right‑sizing – Match resource capacity to actual workload needs. Continuously monitor usage and adjust instance types, storage tiers, and database classes.
  • Eliminate unused resources – Identify and decommission idle EC2 instances, unattached EBS volumes, obsolete snapshots, and underutilized databases.
  • Choose the appropriate pricing model – For steady‑state workloads, reserved capacity offers significant discounts; for variable or stateless workloads, use On‑Demand or Spot.
  • Increase elasticity – Design systems that scale out during peaks and scale in during troughs. Avoid provisioning for theoretical maximum load all the time.
  • Automate operations – Automate instance scheduling, resource tagging, and infrastructure cleanup to reduce manual effort and prevent orphaned resources.
  • Design for efficiency – Use managed services (Lambda, DynamoDB, S3, Fargate) that charge per usage rather than per provisioned capacity. Offload operational overhead to AWS where feasible.
  • Continuously review – Cost optimization is not a one‑time project. Use AWS Cost Explorer, Budgets, and Trusted Advisor to monitor spending and identify new optimization opportunities.

These principles translate directly into service‑level choices and architectural patterns, which we examine next.

AWS Pricing Models​

Understanding how you pay for AWS services is fundamental to cost optimization.

On‑Demand Pricing​

On‑Demand pricing charges per hour or per second (with a minimum of 60 seconds for EC2) and requires no upfront commitment. It is ideal for:

  • Workloads with unpredictable, spiky, or short‑term usage.
  • Development and test environments that are run intermittently.
  • Applications where you cannot predict capacity needs.

On‑Demand provides maximum flexibility but is the most expensive per‑unit option for steady usage.

Reserved Instances and Savings Plans​

Reserved Instances (RIs) provide a significant discount (up to 72%) in exchange for a one‑ or three‑year commitment. RIs are specific to an instance family, size, and region. Convertible RIs allow changes to instance attributes with a slightly lower discount.

Savings Plans are a more flexible commitment model. Compute Savings Plans apply to any EC2 instance, regardless of family, size, region, OS, or tenancy, as well as Lambda and Fargate usage. EC2 Instance Savings Plans are similar to RIs but cover a single instance family within a region. Savings Plans discounts reach up to 72% and are simpler to manage than RIs.

Choose RIs or Savings Plans for workloads that run continuously (e.g., production web servers, database instances) and where you can make a long‑term commitment.

Spot Instances​

Spot Instances allow you to bid on spare EC2 capacity and can be terminated with a two‑minute warning when AWS needs the capacity back. They offer up to 90% discount compared to On‑Demand, making them suitable for:

  • Stateless, fault‑tolerant applications (web servers, containerized workloads).
  • Batch processing, data analytics, image rendering, and CI/CD pipelines.
  • Workloads that can handle interruption gracefully, such as those using Spot Fleet with diversification across instance types and pools.

Always design Spot‑based solutions with automated replacement and checkpointing where possible.

Dedicated Capacity Options​

Dedicated Hosts and Dedicated Instances are designed for regulatory or licensing requirements that demand physical server isolation. They come at a premium and should be used only when necessary. Evaluate whether license mobility (BYOL) offsets the additional cost.

Compute Cost Optimization​

Compute is often the largest component of an AWS bill. Effective optimization starts with selecting the right service and then applying scaling and purchasing strategies.

  • EC2 right‑sizing – Use AWS Compute Optimizer to identify over‑provisioned or under‑provisioned instances. Migrate to a smaller instance family if CPU/memory usage is low, or switch to a burstable instance type (T3/T4g) for workloads with variable load.
  • Auto Scaling – Configure Auto Scaling groups to dynamically add and remove instances based on demand. Set minimum and maximum capacities that reflect realistic usage. Use scheduled scaling for predictable patterns (e.g., scale down at night).
  • Serverless compute – Lambda charges per request and per compute duration. For intermittent or event‑driven workloads, Lambda eliminates idle capacity costs. Compare the cost of Lambda with running a dedicated instance for always‑warm scenarios—if request volumes are high and continuous, EC2 might be cheaper.
  • Container services – ECS with Fargate charges per vCPU and memory per second, removing instance management. For large, consistently running container clusters, ECS on EC2 with Savings Plans may be more cost‑effective. Analyze both models.
  • Instance scheduling – Automate start/stop of non‑production instances outside business hours using AWS Instance Scheduler or Lambda scripts. This can reduce costs by 50–70% for dev/test environments.

Storage Cost Optimization​

Storage costs depend on volume, performance tier, and access frequency. The key is to align the storage class with data lifecycle.

  • Amazon S3 storage classes – Choose the appropriate class based on access patterns:
    • S3 Standard for frequently accessed data.
    • S3 Intelligent‑Tiering for unknown or changing access patterns; it automatically moves objects between frequent and infrequent access tiers.
    • S3 Standard‑IA and One Zone‑IA for infrequently accessed data that requires rapid access when needed.
    • S3 Glacier and Glacier Deep Archive for archival data with retrieval times of minutes to hours. Use S3 Lifecycle policies to transition objects automatically after a set number of days and expire obsolete data.
  • Amazon EBS – Delete unattached volumes and old snapshots. Use gp3 volumes instead of gp2 where possible, as gp3 provides better price/performance independent of size. Snapshot only volumes that need backup; incremental snapshots reduce storage cost over full copies.
  • Amazon EFS – Use EFS Lifecycle Management to move files not accessed for a defined period to the Infrequent Access (IA) storage class, which costs less per GB but incurs a retrieval fee. Choose EFS One Zone for dev/test workloads that don’t need regional redundancy.
  • Amazon FSx – Select the right storage type (HDD vs SSD) and provisioned throughput carefully. Delete backups no longer needed and consider using data deduplication where applicable (FSx for Windows).

The table below summarizes key storage cost strategies.

StrategyBenefitLimitationSuitable For
S3 Intelligent‑TieringAutomatic cost optimization for unpredictable accessSmall monthly monitoring fee per objectUnknown or variable access patterns
S3 Lifecycle policiesAutomated transitions and expirationMust define rules correctly; transitions to Glacier may have minimum storage duration chargesLogs, backups, media archives
EBS snapshotsIncremental backups reduce capacity costsOld snapshots accumulate; need manual cleanup or lifecycleProduction databases and volumes
EFS IA lifecycleLower storage cost for infrequently accessed filesRetrieval charge appliesShared file systems with mixed access patterns

Database Cost Optimization​

Databases are often difficult to rightsize because performance depends on complex interactions. However, significant savings are possible with careful planning.

  • Amazon RDS – Choose the smallest instance class that meets your baseline performance. Use Multi‑AZ only for production workloads that require high availability and automatic failover; for dev/test, single‑AZ is sufficient. Use Reserved Instances for RDS instances that run 24/7. Stop non‑production databases when not in use (they can remain stopped for up to seven days).
  • Amazon Aurora – Aurora Serverless v2 automatically scales capacity based on demand, eliminating idle capacity costs. It is well‑suited for variable or unpredictable workloads and development databases. For steady high‑load production, provisioned Aurora with reserved capacity may be cheaper.
  • Amazon DynamoDB – Use on‑demand capacity for new or variable workloads to avoid over‑provisioning. Switch to provisioned capacity with auto‑scaling for predictable workloads to lower costs. Use DynamoDB Standard‑IA table class for infrequently accessed tables (e.g., archive data) to reduce storage cost. Review unused tables and indexes; delete them.
  • Amazon ElastiCache – Cache only the hot data. Right‑size the node type and use the smallest node that meets your cache hit rate requirement. Reserve nodes for steady workloads.

Networking Cost Optimization​

Data transfer costs can be surprising if not designed from the beginning. Optimizing network architecture minimizes unnecessary charges.

  • Data transfer – Transfers within the same Availability Zone using private IPs are often free or low‑cost, but cross‑AZ and cross‑region transfers incur charges. Minimize cross‑AZ traffic by placing tightly coupled application tiers in the same AZ (at the expense of resilience, a trade‑off to evaluate). Use AWS PrivateLink or VPC Endpoints to reduce internet traffic costs when accessing AWS services.
  • CloudFront – Use CloudFront to serve content from edge locations, reducing data transfer out of S3 or EC2. CloudFront’s regional edge caching can lower origin fetch costs. However, CloudFront itself has per‑request and data transfer charges; for low‑traffic sites, the cost may outweigh the benefit.
  • NAT Gateway – NAT Gateways are priced per hour and per GB processed. To reduce costs, avoid placing all private subnet instances behind a NAT Gateway if they only occasionally need internet access. Use a single NAT Gateway per region (tolerating a potential single point of failure) rather than one per AZ, or use VPC Endpoints for S3 and DynamoDB so that those services are accessed privately without a NAT.
  • Inter‑Region connectivity – Evaluate whether AWS Global Accelerator or direct Connect is justified. Global Accelerator charges per hour and per amount of data transferred but improves global latency; use it only when latency‑sensitive workloads require it.

Monitoring and Cost Management Tools​

Continuous visibility into spending is critical. AWS provides a suite of tools for financial management.

  • AWS Cost Explorer – Visualize spending trends, create custom reports, and forecast future costs. Use it to identify top cost drivers by service, region, or tag.
  • AWS Budgets – Set dollar or usage thresholds and receive alerts when spending exceeds (or is forecasted to exceed) the budget. Budgets can also trigger automated actions, like stopping EC2 instances.
  • AWS Cost and Usage Report (CUR) – Provides the most detailed billing data, delivered to S3. Use it with Amazon Athena or QuickSight for advanced analysis.
  • AWS Trusted Advisor – Checks for idle resources, under‑utilized instances, and unattached EBS volumes. It also recommends Reserved Instance purchases based on historical usage.
  • AWS Compute Optimizer – Analyzes instance and Auto Scaling group configurations and recommends more cost‑efficient sizes.
  • S3 Storage Lens – Provides organization‑wide visibility into storage usage and cost optimization opportunities, including recommendations for lifecycle policies.

The following workflow diagram shows a typical cost optimization decision cycle.

This cycle of monitor, analyze, optimize, and validate is central to FinOps and ensures that architecture cost continuously aligns with business value.

Common Architecture Scenarios​

Scenario 1: Development Environment Left Running​

A software company runs a development environment 24/7, but developers use it only during business hours and on‑call rarely uses it at night.

Optimization decisions:

  • Implement AWS Instance Scheduler to stop EC2 and RDS instances automatically at 7 PM and start them at 7 AM on weekdays, and keep them off on weekends.
  • For resources that must run continuously (CI/CD servers), evaluate Reserved Instances or Savings Plans.
  • Monitor with Cost Explorer to verify that spending drops after hours.

Scenario 2: Historical Log Archive​

A media company retains terabytes of server logs for compliance, but only accesses logs older than 90 days once or twice a year.

Optimization decisions:

  • Store current logs in S3 Standard for 30 days, then transition to S3 Standard‑IA for 90 days, then to S3 Glacier Deep Archive after 90 days.
  • Set up S3 Lifecycle policies to automate transitions.
  • Use S3 Glacier Deep Archive for the lowest cost, accepting retrieval times of 12–48 hours. Ensure the retrieval process is documented for compliance audits.

Scenario 3: Unpredictable Web Traffic​

A marketing website has highly variable traffic: peaks during campaigns and near‑zero at night.

Optimization decisions:

  • Use Auto Scaling with a small base of Reserved Instances for the minimum steady load, and On‑Demand or Spot Instances for the variable portion.
  • Alternatively, if the application can be containerized, deploy to ECS Fargate or Lambda behind API Gateway to pay only for actual usage.
  • Front the site with CloudFront to reduce origin load and data transfer costs, especially for static content.
  • Continuously review actual traffic patterns and adjust the minimum Reserved capacity annually.

Common Cost Optimization Mistakes​

  • Choosing the cheapest option without evaluating requirements – A low‑cost storage class that requires hours of retrieval may violate business RTO. Always map cost decisions to performance and availability SLAs.
  • Over‑provisioning resources – Provisioning for peak load 24/7 wastes money. Use Auto Scaling, and for databases, consider Aurora Serverless or on‑demand DynamoDB until patterns are understood.
  • Ignoring unused resources – Orphaned elastic IPs, unattached EBS volumes, old snapshots, and idle load balancers accumulate charges. Regularly audit your account with Trusted Advisor.
  • Storing all data in expensive tiers – Not all data needs sub‑millisecond access. Use lifecycle policies to move older data to lower‑cost tiers.
  • Failing to monitor spending – Without Cost Explorer budgets and alerts, cost spikes may go unnoticed until the monthly bill arrives. Set budgets for each environment and tag resources for cost allocation.
  • Optimizing cost at the expense of reliability – Eliminating Multi‑AZ or backups to save money can lead to extended outages and data loss. Evaluate risk and cost together; the cheapest architecture is not always the most cost‑effective in the long run.
ServiceRole in Cost Optimization
AWS Cost ExplorerVisualize and analyze spending patterns
AWS BudgetsSet cost thresholds and receive alerts
AWS Trusted AdvisorIdentify idle resources and RI recommendations
AWS Compute OptimizerRight‑sizing recommendations for EC2, Auto Scaling, EBS
Amazon EC2 Auto ScalingDynamically adjust compute capacity to match demand
AWS LambdaPay‑per‑request compute, eliminating idle cost
Amazon S3 Lifecycle PoliciesAutomate data tiering and expiration
Amazon EC2 Spot InstancesDeeply discounted compute for fault‑tolerant workloads
AWS Savings PlansFlexible reserved pricing for compute
Amazon CloudFrontReduce data transfer costs by caching at the edge

Relationship with Other SAA‑C03 Domains​

Cost optimization does not happen in isolation; every cost decision interacts with the other pillars:

  • Design Secure Architectures – Security services (WAF, KMS, GuardDuty) add cost. You must budget for security while avoiding waste, for example by consolidating AWS WAF rules across multiple CloudFront distributions.
  • Design Resilient Architectures – Multi‑AZ and multi‑region designs increase cost. The trade‑off is clear: higher availability costs more. The business must define the required SLA, and the architect selects the minimum resilience needed to meet it.
  • Design High‑Performing Architectures – Scaling for performance often means adding resources. Caching services (ElastiCache, CloudFront) reduce load on databases and compute, potentially lowering overall cost while improving performance.

The SAA‑C03 exam frequently presents scenarios that force you to rank these pillars. A question might ask: “Which solution meets the high‑availability requirement while minimizing cost?” That is exactly the integrated thinking you develop by studying all four domains together.

What to Explore Next​

Cost optimization is the final domain in the SAA‑C03 framework, but it is not an endpoint. As you design architectures, treat cost as an ongoing concern—just like security and reliability. Use the cost management tools discussed here to observe the financial impact of your design choices, and iterate.

Now that you have studied all four domains, your next step is to integrate them through the Architecture Scenarios and Hands‑on Labs. These practical exercises will require you to balance cost, security, resilience, and performance simultaneously, exactly as the exam—and real‑world architecture—demands.