Reliability and Business Continuity
Scalability and Elasticity Across Compute, Cache, and Databases
CoreScale each measured tier with a demand-correlated signal and the policy, cache, or managed-database control that addresses its actual constraint.
Aligned to AWS Certified CloudOps Engineer - Associate (SOA-C03) Version 1.1, verified August 24, 2026.
Why this matters
A three-tier service remains constrained if only one layer scales. Operators must distinguish reactive, scheduled, predictive, cache, relational, and key-value capacity controls.
Must Know
- A scaling metric should represent demand per unit of capacity or another stable relationship to needed capacity; configure safe minimum, maximum, warmup, and cooldown boundaries.
- Target tracking maintains a target level; step scaling applies explicit adjustments by breach size; scheduled scaling prepares for known times; predictive scaling forecasts recurring patterns.
- Container workloads can require both task or pod scaling and underlying compute capacity so the scheduler can place new work.
- CloudFront reduces repeat origin requests for correctly cacheable HTTP content; ElastiCache reduces repeat application or database work with explicit key, TTL, invalidation, and failure behavior.
- For RDS, match instance, read, storage, or connection capacity to the measured dimension. Multi-AZ is an availability control, not general read scaling.
- For DynamoDB, choose on-demand or provisioned capacity with auto scaling as appropriate, and fix hot partition keys because table capacity alone cannot evenly redistribute a concentrated access pattern.
Compare and Distinguish
- Target tracking targets a level; step scaling maps alarm severity to increments.
- Scheduled scaling follows a known timetable; predictive scaling forecasts recurring demand; reactive scaling responds after current demand is measured.
- CloudFront caches content near viewers; ElastiCache caches application data close to the workload.
- RDS and DynamoDB expose different scaling controls; neither control substitutes for a sound access pattern.
Scenario examples
- Scenario: A known morning surge begins before slow instances can boot. Schedule capacity before the event and retain a reactive policy for variance.
- Scenario: ECS tasks scale but remain pending. Add capacity-provider or cluster-capacity scaling and verify placement constraints.
- Scenario: A DynamoDB table throttles one popular key while overall capacity remains available. Redesign or shard the hot access pattern before merely raising capacity.
Exam traps
- Do not scale on an unrelated total metric that rises when capacity rises.
- Do not assume workload scaling automatically supplies container host capacity.
- Do not use Multi-AZ as a read-scaling answer.
- Do not add a cache without defining staleness and invalidation.
Key takeaways
- Scale the constrained tier.
- Match policy behavior to the demand timeline.
- Treat cache correctness as part of elasticity.
- Separate capacity scaling from availability.
How it works
- Establish which tier saturates first and whether demand is current, scheduled, or predictably recurring.
- Apply the policy, cache, or managed-database setting that directly changes the constrained tier.
- Observe desired and in-service capacity, placement, cache behavior, throttling, and application latency after the adjustment.
When to use it
- Choose target tracking when capacity should maintain a metric near a target; choose step scaling when breach severity should determine the size of each adjustment.
- Schedule capacity for a known timetable, use predictive scaling for recurring forecastable demand, and retain reactive scaling for demand detected in current metrics.
- Place cacheable HTTP content near viewers with Amazon CloudFront; use Amazon ElastiCache when the application needs a data cache close to the workload.
- Apply Amazon RDS or DynamoDB scaling controls according to the database model and measured constraint, and repair the access pattern when concentrated demand remains the cause.
Security and governance implications
- Constrain scaling roles, alarm actions, and automation targets so demand changes cannot grant broader control of the workload.
- Apply the workload data-access and encryption requirements to cache nodes and database replicas as capacity changes.
Failure signals and diagnosis
- Compare desired, in-service, pending, and placement capacity across compute layers.
- For cache misses, inspect the key, TTL, invalidation, and representation variance.
- For database throttling, separate total capacity, local hot keys, connection pressure, read load, and storage growth.
More detail
- Choose target tracking, step, scheduled, or predictive scaling from how the demand signal behaves over time.
- For containers, reason separately about workload replicas and the compute capacity needed to place them.
- Distinguish CloudFront edge caching, ElastiCache application caching, RDS scaling controls, and DynamoDB capacity behavior.
Ready for the quiz?
- ECS tasks are pending after application auto scaling raises the desired count. Which evidence shows whether task scaling or underlying cluster capacity is the bottleneck?
- How do target tracking, step scaling, scheduled scaling, and predictive scaling respond to different demand patterns?
- If new container tasks remain pending after service scaling, what evidence shows whether underlying cluster capacity or placement is the remaining constraint?
Related objectives
- D2.1 — Task 2.1: Implement scalability and elasticity.
- 2.1.1 — Configure and manage scaling mechanisms in compute environments.
- 2.1.2 — Implement caching by using AWS services to enhance dynamic scalability (for example, Amazon CloudFront, Amazon ElastiCache).
- 2.1.3 — Configure and manage scaling in AWS managed databases (for example, Amazon RDS, DynamoDB).