What infrastructure actually costs and how to bring it down.
5 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.
Reserved Instances, Savings Plans, Spot, and On-Demand: how do you decide what mix to run for a given EC2 workload?
The decision runs on one axis: how predictable is the usage, not how important the workload is. Steady, known baseline load goes on Savings Plans, spiky or unknown load stays On-Demand, and anything interruption- tolerant goes on Spot. Reserved Instances are mostly the older, less flexible version of a Savings Plan today.
Your RDS bill keeps climbing every month. What levers do you actually have to bring it down?
RDS cost breaks into three independent knobs: compute (instance type and purchase option), storage (type and provisioned amount), and everything that scales with those two but isn't obviously tied to them, like snapshot retention and cross-AZ data transfer. Most real savings come from right-sizing and switching purchase options, not from a single trick.
Your CI pipeline runs twice for every pull request. How do you investigate?
Almost always two triggers firing on one action, usually push and pull_request both matching the same branch. Read the event that started each run, then make the trigger config deliberate instead of deleting jobs until the noise stops.