Your managed store runs as one instance in a single zone — why might the headline availability commitment not apply to it at all?

## The commitment is conditioned on a configuration Engineers read a commitment as a property of the service — "this managed store is committed at a high figure". It is not. The clause almost always reads as a conditional: *if* the service is deployed in a stated configuration, *then* the provider commits to that figure for it. Change the configuration and you land on a different row, or off the table entirely. The stated configuration is usually some combination of: - **more than one instance or replica**, so a single machine failure is not a service failure; - **placement in separate availability zones**, so the instances are in different failure domains rather than merely being two processes in the same one; - **traffic arriving through the service's managed entry point**, so failover is something the platform can perform rather than something your client library has to notice; - **a supported tier**: previews, trial tiers and experimental features are commonly excluded outright. A single instance in one zone satisfies none of these. It sits in one failure domain by construction, so the provider has no mechanism to keep it serving through the loss of that domain — and, just as importantly, no way to patch the host underneath it without an interruption. ## Why the provider prices the shapes differently | Deployment shape | What the provider can absorb | Typical commitment | |---|---|---| | One instance, one zone | A restart, sometimes a host migration | Lower, or none at all | | Redundant instances across zones | Loss of one instance or one zone | The headline figure | | Redundant across regions, run by you | Loss of a region, if you orchestrate it | Usually not a single clause at all | The logic is the same one you would apply yourself: a commitment is only honest to the extent the provider controls the failure modes. With one instance, **scheduled maintenance is unavoidable downtime** — the provider must eventually patch or move the host, and there is nowhere for the workload to go. Rather than promise something it cannot deliver, the provider either lowers the figure for that shape or says the commitment does not cover it and publishes a maintenance-notice practice instead. This is also a quiet signal about the platform's own design. The configuration the provider is prepared to commit to is the configuration it has engineered around; deviating from it is a decision to be outside the supported path, whatever its cost advantage. ## Eligibility is continuous, not a checkbox The second half of this material catches people in production. The commitment covers periods in which you were in the committed configuration. That means: 1. **Deployments can drop you out of it.** A rolling replacement that briefly leaves one healthy instance, a scale-in that removes the second zone's capacity overnight, an incident response that intentionally shrinks to a single node — each leaves a window where the shape is not the committed one. 2. **Capacity policies can drop you out of it.** A cost-driven schedule that runs a single instance outside business hours is, contractually, an uncommitted period every night. 3. **You have to be able to prove the shape.** A claim later rests on showing you were in the committed configuration at the time, which means the record has to exist before you need it. None of this makes the cheaper shape wrong. A reporting service used during office hours may be perfectly well served by one instance, and paying for a second purely to become eligible for a small credit would be irrational. The point is that the decision should be made knowingly: *we are running outside the committed shape, we accept the downtime, and we are not counting on any contractual floor.* ## How to answer this in an interview Say three things. First, the commitment attaches to a deployment configuration, so the headline figure is not automatic. Second, name why — a single instance is one failure domain, and maintenance on it is unavoidable downtime the provider will not promise around. Third, note that eligibility is continuous, so deploys, scale-ins and cost schedules can move you outside it without anyone deciding to. That last point is the part that separates someone who has read the document from someone who has operated under it.