Where an architecture is allowed to run, and what that costs
where_can_this_runApply requirements FIRST, then price only the regions that survive.
Use this for "the data has to stay in India", "we cannot use US-owned
jurisdictions", "our users are in Europe", "it has to survive a zone failure".
The order is the whole point. A cheaper region that cannot legally hold the
data is not a cheaper option, it is not an option, and a tool that priced
first and filtered second would already have told the user a number they
cannot have.
`items` is the same shape `estimate_cost` takes. `constraints` is
`[{"constraint": "<id>", "value": "<value>"}]`, with the ids and the value each
one expects coming from `list_cost_building_blocks`.
The reply separates three things that must never be confused:
* `options` are regions that satisfy every requirement AND can price the whole
architecture, cheapest first.
* `cannot_run_this` are regions that satisfy the requirements but do not sell
part of what was asked for. They are kept out of the ranking on purpose: a
region that prices three lines of five prices LOW, so it would sort to the
top and win by being incomplete.
* `excluded` are regions that failed a requirement, each with the reason.
`cost_of_requirements` says what the requirements cost against running anywhere,
and splits that into the part caused by the location and the part caused by the
architecture changes the requirements forced (a standby copy for zone failure,
for instance). Those are different decisions and a single premium figure hides
which one is expensive.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| term | No | OnDemand | |
| items | Yes | ||
| regions | No | ||
| constraints | Yes |