Automatically adding or removing resources to match real-time demand.
Elasticity is the ability of a cloud system to automatically provision and release resources in response to real-time demand, so compute capacity tracks actual workload rather than a fixed estimate. On AWS this is delivered primarily through Auto Scaling groups, which add EC2 instances when CPU or request metrics spike and terminate them when demand subsides, with billing adjusting accordingly. The exam often contrasts elasticity with scalability: scalability means a system can handle more load (it has the headroom), while elasticity means it automatically does so, expanding and contracting without manual intervention. Scalability is a design property; elasticity is the dynamic, automated behavior built on top of it.
The ability to add or remove resources to handle a changing workload.
Scalability is the capacity of a system to handle increased demand by adding resources, or to reduce costs by removing them when demand drops. AWS enables two forms: vertical scaling (scaling up) increases the compute power of a single instance — for example, moving from a t3.small to an m5.xlarge — while horizontal scaling (scaling out) adds more instances behind a load balancer. The CLF-C02 exam often pairs scalability with elasticity; the key distinction is that scalability describes the architectural ability to grow, whereas elasticity refers to doing so automatically and dynamically in real time.
Designing systems to stay operational with minimal downtime even when components fail.
High availability (HA) is an architectural goal that keeps systems running by eliminating single points of failure through redundancy and automatic failover. On AWS, distributing resources across multiple Availability Zones within a Region is the standard approach: if one data center fails, traffic shifts to healthy zones automatically via services like Elastic Load Balancing. The critical CLF-C02 distinction is between high availability and fault tolerance. Fault tolerance means zero downtime and zero data loss through fully redundant parallel systems, while high availability accepts a brief recovery window. Questions hinting at “minimal downtime” or “automatic recovery” describe HA; questions requiring absolutely no disruption describe fault tolerance.
A workload's ability to perform its function correctly and recover from failures.
Reliability is one of the six pillars of the AWS Well-Architected Framework and describes a system’s ability to perform its intended function correctly and consistently, including the capacity to automatically recover from infrastructure or service failures. AWS supports reliability through services such as Amazon Route 53 for DNS failover, Elastic Load Balancing to distribute traffic across healthy targets, and Auto Scaling to replace failed instances without manual intervention. The key exam distinction is between reliability and high availability: high availability minimizes downtime, while reliability is broader — not just staying up, but recovering correctly when something goes wrong. A highly available system that returns corrupted data is not reliable.
Capital expenditure (upfront purchases) versus operational expenditure (ongoing pay-as-you-go costs).
Capital expenditure (CapEx) means paying upfront for physical assets — servers, networking gear, data-center space — that depreciate over time and require forecasting demand years in advance. Operational expenditure (OpEx) covers recurring costs billed as the business consumes resources, the model behind AWS pay-as-you-go pricing. The exam frames this as a cloud value proposition: migrating to AWS converts large, fixed CapEx into variable OpEx, eliminating the risk of over- or under-provisioning. A common trap is treating Reserved Instances as CapEx — they remain OpEx because AWS owns and operates the hardware; the customer is committing to usage, not purchasing an asset.
Lower per-unit costs that AWS achieves by aggregating usage across many customers and passing savings on.
Economies of scale arise when a provider’s per-unit costs fall as total volume grows. AWS operates at a scale no individual business can match, purchasing compute, networking, and storage hardware in enormous quantities and spreading fixed costs — data center construction, power infrastructure, staffing — across millions of customers worldwide. Those lower operating costs are periodically passed back to customers as price reductions, which AWS has done more than a hundred times since launching.
The exam-day distinction to watch is between economies of scale and pay-as-you-go pricing. Pay-as-you-go means customers pay only for what they consume; economies of scale explain why those consumption-based prices can be set so low. Both appear in AWS’s six advantages of cloud computing, so understanding the separation between the two concepts prevents confusing them on a scenario question.
The practice of running systems to deliver business value at the lowest price point.
Cost Optimization is one of the six pillars of the AWS Well-Architected Framework, focused on delivering business value at the lowest price point without overprovisioning. On CLF-C02 it appears both standalone and within Well-Architected questions, so know its pillar relationship. The pillar covers right-sizing resources, choosing the appropriate pricing model (On-Demand, Spot, Reserved, or Savings Plans), using managed services to reduce operational overhead, and monitoring spend. A common trap is confusing the pillar with cost monitoring — tools like AWS Cost Explorer and AWS Budgets support it but are not the pillar itself.