Before you commit to a design that leans on a published per-account ceiling, what do you need to establish about it?

## A ceiling is a number plus four properties Engineers copy a limit out of a documentation table and treat it as a fact about their design. The number alone decides almost nothing. Four properties around it decide everything, and all four are usually stated in the same table or answerable with one question to the provider. 1. **Can it be raised at all?** A raisable ceiling is a scheduling problem — file early, wait days. A fixed one is a design constraint that must be respected from the first diagram. 2. **What is it counted per?** Account, account-and-region, or something narrower. 3. **What does it count?** Objects that exist, things running at once, or actions inside a rolling window. 4. **If raisable, to what, and how fast?** Whether there is a stated maximum, and what the turnaround is in practice. ## Why *counted per* decides the architecture The scope is what tells you whether structure can buy you headroom. If a ceiling is counted per account and per region, then spreading the workload across a second region or a second account genuinely multiplies what you may have, and that is a legitimate — though not free — response to a fixed ceiling. If the ceiling is counted per something narrower, such as one private network or one grouping of resources, then the response is to create more of *that* construct rather than more accounts. And if a ceiling happens to be counted across the whole organisation, no amount of splitting below it helps at all. This is the question that most often gets skipped, and skipping it produces the worst kind of plan: a restructure that costs weeks and moves the same ceiling along with the workload. ## Why *what it counts* changes the failure Three ceilings that read identically in a table behave nothing alike: | What it counts | Symptom when met | What relieves it | |---|---|---| | Objects that exist | creation refused until you delete something | cleaning up orphans, or a raise | | Things running at once | creation refused while at peak, fine off-peak | reducing concurrency, or a raise | | Actions in a rolling window | refused in bursts, succeeds if you slow down | pacing the caller, batching | A ceiling on existence is relieved by deletion, so an estate full of forgotten resources is sitting on its own headroom. A ceiling on concurrency is relieved by finishing work. A ceiling counted per unit of time is not about how much you have at all, and treating it as such sends the team hunting for resources to delete when the real fix is to slow the caller down. ## Raisable, and to what A raisable ceiling is not an unbounded one. Ask two further things. First, whether the provider publishes a **maximum it will grant**, because a design that needs ten times the default is a different conversation from one that needs twice it. Second, whether the raise is an entitlement or a **judgement call**: many platforms review what you intend to run, grant partially, and invite you back once usage justifies more. That changes your plan from one request into a sequence of them, each with its own lead time. Providers genuinely differ here: on some platforms the raise is a self-service form resolved automatically, on others it is a reviewed case; some tie starting values to how long the account has existed or what it has already run. None of that is safe to assume from experience elsewhere, which is exactly why it belongs in the *establish* list rather than the *assume* list. ## Write it down as a constraint The output of this exercise is a short inventory — one row per ceiling the design leans on — carrying the scope, the granted value, whether it is raisable, what it counts, and when it was last checked. That document does three jobs at once: it feeds the headroom alerts, it gives the recovery plan something to evidence, and it stops the same lookup being redone from memory by whoever is blocked next. A design that leans on a ceiling without recording these properties has an undocumented dependency on a number someone else controls. The interviewer asking this question is checking whether you treat that as a dependency at all.