TL;DR: RACR (Requirements, Assumptions, Constraints, Risks) captures what a design must deliver and what it is standing on. AMPRS (Availability, Manageability, Performance, Recoverability, Security) evaluates how each decision affects the five infrastructure qualities. Use RACR to frame the problem, AMPRS to judge the answer, and trace every decision back to both.
While preparing for my VCF Architect certification, I ran into a topic that goes well beyond the exam. RACR and AMPRS are things I already apply every day, often without naming them, whenever I evaluate a design or a proposal. Studying them in a structured way made me stop and reflect, and this post is the result of that reflection.
Most infrastructure designs don’t fail because someone picked the wrong product. They fail because nobody wrote down why a choice was made, what was assumed to be true, and what it would cost elsewhere. Six months later, someone asks “why is this cluster stretched?” and the only answer is “it seemed like a good idea.”
RACR and AMPRS are the two lenses I use to avoid that. They come from the VMware/VCDX design methodology world, but they work for anything: a vSphere cluster, a Kubernetes platform, a backup strategy, or evaluating whether a vendor proposal actually makes sense.
What is RACR?#
RACR is a design-framing method that classifies every piece of input into Requirements, Assumptions, Constraints and Risks before any solution is chosen.
Each category has a precise meaning, and mixing them is the most common mistake:
| Item | Definition | Example |
|---|---|---|
| Requirement | Something the design must deliver. Functional (what it does) or non-functional (how well). | “Tier-1 VMs must tolerate the loss of one host with no service impact.” |
| Assumption | Something believed to be true but not verified. Every assumption needs an owner and a validation step. | “The customer’s WAN link has at least 1 Gbps available for replication.” |
| Constraint | Something that limits the design choices and cannot be changed by the architect. | “Must reuse the existing Fibre Channel array until 2028.” |
| Risk | Something that may happen and harm the design goals, with a mitigation. | “Single storage array is a single point of failure for all clusters.” |
A useful rule of thumb: if you can negotiate it, it’s a requirement; if you can’t, it’s a constraint; if you haven’t checked it, it’s an assumption; if it could go wrong, it’s a risk.
What is AMPRS?#
AMPRS is an evaluation model that scores every design decision against five infrastructure qualities: Availability, Manageability, Performance, Recoverability and Security.
- Availability — Can the service stay up when components fail? (HA, redundancy, fault domains)
- Manageability — Can the team operate it day-2? (automation, monitoring, lifecycle, skills)
- Performance — Does it meet throughput, latency and capacity targets under real load?
- Recoverability — When something breaks badly, how fast and how completely do we get back? (RPO/RTO, backups, DR)
- Security — Does it protect confidentiality and integrity? (segmentation, identity, hardening, compliance)
The key idea: no decision is neutral. Almost every choice improves one quality and costs another. AMPRS forces you to say that out loud.
Why these frameworks matter#
Without structure, design reviews turn into debates between preferences. With RACR and AMPRS:
- Decisions become traceable. Each decision cites the requirement it satisfies and the constraint it respects.
- Hidden assumptions surface early. An unvalidated assumption is a risk waiting to happen, and RACR puts it on the table.
- Trade-offs are explicit. “We gained Performance, lost Manageability, and here’s how we compensate” is a defensible statement. “It’s faster” is not.
- Reviews get faster. A reviewer (or a VCDX panel) can follow the logic instead of reverse-engineering it.
How RACR and AMPRS work together#
Think of it as a pipeline: RACR defines the problem space, design decisions live inside it, and AMPRS evaluates each decision’s impact.
Step 1: RACR frames the problem#
Before drawing any diagram, collect inputs from stakeholders and classify them. Number each item (R01, A01, C01, RK01) so it can be referenced later.
Step 2: Decisions are made against RACR#
Every design decision should answer: which requirement does this satisfy, and which constraint shapes it? If a decision doesn’t trace to any requirement, question why it exists.
Step 3: AMPRS scores the impact#
For each decision, mark the effect on each quality: positive (+), negative (−) or neutral (0). Negative impacts must either be accepted with justification or mitigated.
Step 4: The loop closes#
Negative AMPRS impacts often create new risks. Those go back into the RACR register. The design is “done” when every risk has a mitigation or an explicit acceptance.
A practical example: stretched cluster or not?#
Say the input is: “the business wants zero data loss if a datacenter fails.” Classified with RACR:
- R01: RPO = 0 for Tier-1 workloads.
- R02: RTO ≤ 15 minutes.
- C01: Two sites, 40 km apart, existing dark fiber.
- A01: Round-trip latency between sites is below 5 ms (to be validated with a network test).
- RK01: A split-brain scenario if the witness is unreachable.
Two options, evaluated with AMPRS:
| Quality | Option A: vSAN stretched cluster | Option B: async replication + SRM |
|---|---|---|
| Availability | + Automatic restart on surviving site | 0 Requires failover orchestration |
| Manageability | − Witness host, site affinity rules, more complex upgrades | + Simpler clusters, runbooks in SRM |
| Performance | − Synchronous writes add inter-site latency | + Local write latency only |
| Recoverability | + RPO = 0, RTO in minutes | − RPO > 0 (fails R01) |
| Security | 0 Same trust domain across sites | 0 Same |
Option B fails R01, so it’s out regardless of its manageability advantage. Option A is chosen, but its negative impacts become new entries: a risk for write latency (mitigated by validating A01) and a manageability risk (mitigated by documenting witness operations). That is the whole method in one table.
Common mistakes#
- Writing solutions as requirements. “Must use vSAN” is not a requirement. It’s either a constraint (if truly imposed) or a decision you haven’t justified yet.
- Leaving assumptions unvalidated. An assumption with no owner and no validation date is just a risk you hid.
- Treating constraints as optional. If budget or hardware is fixed, it’s a constraint. Designing around it as if it weren’t wastes everyone’s time.
- Scoring only the positives in AMPRS. A decision with only “+” marks usually means the analysis wasn’t honest.
- Risks without mitigations. Listing a risk is half the job. State the mitigation or the explicit acceptance, and who accepted it.
- Skipping Manageability. It’s the quality that hurts most on day 2 and the one most often ignored on day 0.
FAQ#
What does RACR stand for in infrastructure design? Requirements, Assumptions, Constraints and Risks. It’s a method for classifying design inputs before choosing a solution, so every later decision can be traced back to what the business needs and what limits the design.
What does AMPRS stand for? Availability, Manageability, Performance, Recoverability and Security. These are the five infrastructure design qualities used to evaluate the positive and negative impact of each design decision, popularized by the VMware VCDX methodology.
What is the difference between a constraint and an assumption? A constraint is a known, fixed limitation the architect cannot change, like existing hardware. An assumption is something believed true but not yet verified, like available bandwidth. Assumptions need validation; constraints need to be respected.
Is RACR and AMPRS only for VMware designs? No. They originated in VMware design methodology, but they apply to any infrastructure: Kubernetes platforms, cloud landing zones, networks, backup strategies or evaluating a vendor proposal. They are vendor-neutral thinking tools.
How do I document design decisions using AMPRS? For each decision, record the justification, the requirements and constraints it relates to, and the impact on each quality as positive, negative or neutral. Every negative impact should reference a mitigation or a risk entry.
Conclusion#
RACR tells you what you are solving and what you are standing on. AMPRS tells you what each answer costs. Neither is complicated, and that’s the point: the value isn’t in the acronyms, it’s in the discipline of writing things down before arguing about them. Next time you review a design, including your own, ask two questions for every decision: which requirement drove this? and what did it cost in AMPRS? If there’s no answer, you’ve found your next piece of work.
