SRE Capacity Planning Interview Template: Amazon‑Specific Framework with Downloadable Checklist
TL;DR
Amazon rejects candidates who treat capacity planning as a spreadsheet exercise; the interview rewards a judgment that balances risk, cost, and product velocity. In a Q2 debrief the hiring manager asked the interviewee to justify a 30 % over‑provision decision, and the candidate lost because the answer lacked a trade‑off narrative. The verdict: focus on “impact‑driven sizing” and be ready to articulate the economic signal behind every metric you quote.
Who This Is For
The piece is for senior SREs who have already shipped production‑grade services, are currently earning $165 k–$190 k base, and are targeting Amazon’s SRE ladder II or III. These readers have been through at least one full‑stack interview cycle, understand basic reliability concepts, and need a concrete template to survive Amazon’s capacity‑planning deep‑dive.
What does Amazon expect in a capacity‑planning interview?
Amazon expects a judgment that ties capacity numbers to business outcomes, not a list of formulas. In a recent interview, the candidate started by reciting the “M/M/1 queue” model; the senior bar raiser interrupted, “Your answer isn’t about the model — it’s about the decision you would make with it.” The correct approach is to frame the answer as a three‑part story: (1) define the service‑level goal (e.g., 99.9 % availability), (2) quantify the traffic forecast using a concrete growth curve (e.g., 12 % month‑over‑month), and (3) translate that forecast into a cost‑aware provisioned capacity that respects Amazon’s “two‑pizza team” budget constraints.
The first counter‑intuitive truth is that “more data is less useful than a single, well‑chosen KPI.” Amazon interviewers often ask you to pick one metric—typically “peak QPS under load” or “95th‑percentile latency.” The judgment is to defend that choice with a business rationale: “I track peak QPS because it directly caps our ability to meet the 99.9 % availability target, and any over‑provision beyond the 30 % safety margin would erode the cost budget.”
A second insight is that “risk tolerance is a product decision, not an engineering one.” In a hiring committee discussion, the PM argued that a 5 % SLA breach was acceptable for a new feature rollout. The SRE interviewee who aligned with the product’s risk appetite earned the bar raiser’s nod, while the one who insisted on “zero‑tolerance” was labeled inflexible. The judgment is to treat risk as a variable you can negotiate, not a constant you must enforce.
How do you demonstrate SRE judgment during the Amazon debrief?
The debrief is where the hiring manager, senior bar raiser, and the interview panel translate your interview performance into a hiring signal. In a Q3 debrief, the hiring manager pushed back because the candidate described a capacity‑planning process that required “weekly manual spreadsheet updates.” The senior bar raiser countered, “The problem isn’t the spreadsheet — it’s the lack of automation signal.” The verdict was that the candidate failed to show an automated pipeline for capacity forecasting, which Amazon treats as a core SRE competency.
The second judgment layer is to surface “decision velocity.” Amazon values the ability to make sizing decisions in under 48 hours to keep product releases on schedule. When you discuss a past incident where you revised capacity after a traffic spike, embed the timeline: “I detected the spike at 02:15 UTC, triggered an auto‑scale policy within 5 minutes, and completed a post‑mortem recommendation in 36 hours, saving $12 k in over‑provisioned EC2 spend.” The hiring committee will cite that timeline as evidence of your impact‑driven mindset.
A third insight is that “communication style beats raw numbers.” In the debrief, the hiring manager asked the candidate to summarize the capacity plan in a single sentence for a non‑technical stakeholder. The candidate replied, “We need to add 2 × t2‑medium instances to keep latency below 120 ms during peak load.” The bar raiser marked that as a failure because the answer omitted cost and risk context. The correct judgment is to embed cost and risk: “We need 2 × t2‑medium instances, costing $3 800/month, to keep latency under 120 ms and maintain our SLA, with a 30 % safety margin for traffic spikes.”
Which Amazon‑specific metrics matter in capacity planning?
Amazon’s internal metrics differ from generic industry dashboards; the interview expects you to reference “service‑level indicators (SLIs) that map to Amazon’s internal cost model.” In a recent interview, the candidate listed “CPU utilization, memory usage, and network I/O” and was told, “Your answer isn’t about the raw metrics — it’s about the Amazon‑specific cost‑weighting you apply.” The judgment is to mention the “Amazon Compute Unit (ACU) cost factor” and how it drives your capacity sizing.
The first labeled insight: “The ACU cost factor is the decisive metric for any capacity discussion.” When you calculate required instances, translate the raw CPU requirement into ACUs, then multiply by the current ACU rate (e.g., $0.023 per ACU‑hour). For a service needing 250 ACU‑hours per day, the cost is $5.5 k per day, which you can present as a concrete budget impact.
The second insight: “Latency cost is expressed as a dollar value per millisecond of SLA breach.” Amazon historically assigns $10 k per 0.1 % SLA breach for high‑value services. When you argue for a 30 % safety margin, you can quantify the avoided breach cost: “A 0.1 % breach would cost $10 k, so the 30 % safety margin saves $3 k per month on average.”
The third insight: “Capacity‑planning decisions are evaluated against a 12‑month cost‑budget horizon.” In the interview, you should state the projected 12‑month spend based on the capacity plan (e.g., “Projected annual cost $440 k, within the team’s $500 k budget”). This demonstrates that you can align engineering decisions with Amazon’s fiscal cadence.
What signals do hiring committees look for in your answers?
Hiring committees score answers on three signals: (1) Business impact, (2) Automation mindset, (3) Risk communication. In a recent hiring committee, the senior bar raiser noted, “The candidate’s answer showed impact but lacked automation — that’s a red flag.” The judgment is that a strong answer must hit all three signals; missing any one drops the candidate below the bar.
The first “not X, but Y” contrast: not “a perfect model,” but “a pragmatic model that can be automated.” Candidates who recite textbook queuing theory without showing how they would embed it in a CI/CD pipeline are penalized.
The second contrast: not “a static safety margin,” but “a dynamic margin that adjusts with traffic trends.” Candidates who propose a fixed 30 % buffer are outperformed by those who describe a feedback loop that trims the buffer as demand stabilizes, thereby saving $15 k annually.
The third contrast: not “a vague risk statement,” but “a quantified risk trade‑off.” When you say, “We accept a 0.05 % SLA risk,” accompany it with the dollar impact and the mitigation plan. The hiring committee will cite that quantified risk as evidence of mature judgment.
A senior bar raiser often asks, “If the product roadmap changes in six months, how does your capacity plan adapt?” The answer should outline a revision cadence (e.g., “Quarterly capacity review with automated forecast updates”) and a clear communication path to product managers. This demonstrates that you can keep capacity aligned with Amazon’s rapid iteration cycles.
Preparation Checklist
- Review Amazon’s SRE handbook and extract the sections on “capacity planning” and “cost modeling.”
- Build a one‑page capacity‑planning slide that includes: SLO, forecasted peak QPS, ACU cost, safety margin, and 12‑month budget impact.
- Practice narrating the slide in under two minutes, ending with a single sentence that ties cost, risk, and product velocity.
- Conduct a mock interview with a senior SRE peer who will play the bar raiser role and force you to justify every number.
- Work through a structured preparation system (the PM Interview Playbook covers “impact‑driven sizing” with real debrief examples).
- Prepare three scripts for the “non‑technical stakeholder” question:
- “We need X instances, costing $Y per month, to keep latency under Z ms and stay within our SLA budget.”
- “If traffic grows 12 % month‑over‑month, our automated scaling will add capacity within five minutes, avoiding a $10 k SLA breach.”
- “We’ll review the forecast quarterly and adjust the safety margin, which historically saves $15 k annually.”
Mistakes to Avoid
BAD: “I always provision 50 % extra capacity to be safe.” GOOD: “I provision a 30 % safety margin, which our cost model shows balances SLA risk with a $12 k annual spend.” The mistake is treating safety as a static percentage without cost justification.
BAD: “I rely on manual spreadsheets for weekly updates.” GOOD: “I built an automated pipeline that pulls CloudWatch metrics, runs a forecast model, and updates capacity tags nightly.” The mistake is ignoring automation, which Amazon treats as a core SRE skill.
BAD: “I explain risk in vague terms like ‘low chance of failure.’” GOOD: “We accept a 0.05 % SLA breach risk, quantified as a $5 k potential cost, and mitigate it with a dynamic scaling policy.” The mistake is failing to quantify risk, which deprives the hiring committee of a clear judgment signal.
FAQ
What is the most important metric to mention in an Amazon capacity‑planning interview?
The hiring committee’s judgment centers on the Amazon Compute Unit (ACU) cost coupled with a single SLA‑related KPI (e.g., 99.9 % availability). Mention ACU cost first, then tie it to the SLA breach dollar value to show you understand both performance and budget impact.
How many interview rounds should I expect for an Amazon SRE role?
The standard process includes five interview rounds over a 30‑day period: a recruiter screen, a technical phone, a system‑design interview, a capacity‑planning deep dive, and a final hiring‑committee debrief. The judgment is to treat the capacity‑planning interview as the decisive round, because it is the only one that evaluates the cost‑risk trade‑off skill set.
What compensation range should I negotiate after receiving an offer?
For an SRE II at Amazon, a typical package is $165 000–$180 000 base, $25 000–$35 000 sign‑on, and 0.03 %–0.04 % equity that vests over four years. The judgment is to negotiate for the higher end of the base range by emphasizing your capacity‑planning impact, and to request a sign‑on that reflects the market premium for automation expertise.
The 0→1 PM Interview Playbook (2026 Edition) — view on Amazon →