Cost

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.

How do you cut EC2 costs for workloads that sit idle nights and weekends, without relying on someone remembering to turn things off?

Automate the stop and start instead of asking anyone to remember it. Scheduled Auto Scaling actions or AWS Instance Scheduler both work; the choice mostly comes down to whether the fleet is already behind an Auto Scaling group. Either way, tag-based scoping is what keeps it from ever touching something that shouldn't be stopped.

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.

When would you scale vertically instead of horizontally?

Go vertical when the bottleneck doesn't split: database buffer cache, cache memory, network bandwidth on one node, a single-threaded lock. Go horizontal when the work partitions cleanly. The real question isn't which is better, it's whether the thing that's saturated can be divided across machines at all.

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.

Your 5 GB monorepo has code, binaries, Terraform and Helm charts, and clones are slow. What do you do?

Measure what the 5 GB actually is: big blobs, deep history, and a wide tree are three different problems with three different fixes. Work through them in order of cost, artifacts out of Git, binaries into LFS, partial clone and sparse checkout for developers, and treat splitting the repo as the last resort rather than the first idea.

Your LLM feature costs $40k/month and is growing 30% monthly. Leadership wants it cut by 70% without hurting quality. What do you do?

Most LLM spend goes on tokens that never needed generating, requests that never needed a frontier model, and identical prefixes reprocessed on every call. Measure where the money actually goes first, then attack caching, routing and prompt size before anything as drastic as self-hosting.