Capacity, availability and staying up under load.
3 items at intermediate level · all topics
Your traffic is spiky and unpredictable during business hours. Design an EC2 Auto Scaling policy that reacts fast without overspending overnight.
Target tracking should be the default scaling policy, since it only needs one metric and handles the math itself. Layer scheduled actions on top for the predictable part of the day, and treat step scaling as the exception for spikes that need a bigger, immediate jump than target tracking gives you.
When would you use EC2 Spot Instances in production, and how do you design a workload to survive interruptions?
Spot is unused EC2 capacity sold at a steep discount, usually 60 to 90 percent off On-Demand, with the trade that AWS can reclaim it with two minutes of warning. It's a good fit for anything stateless, retryable, or checkpointed, and a bad fit for anything that can't tolerate an interruption.
Multi-AZ deployments, read replicas, and Aurora all get mentioned as RDS availability features. What's actually different between them, and when do you use each?
Multi-AZ is a synchronous standby that exists purely for failover, not for serving traffic. A read replica is asynchronous and exists to serve read traffic, with failover as a secondary, slower use. Aurora replaces both mechanisms with a shared, distributed storage layer, which is why an Aurora Replica can do double duty that a standard RDS replica can't.