How the placement optimiser prices a multi-region design

The single-region ranking answers "where is this one workload cheapest?". Real estates have several workloads that talk to each other, and the cheapest region for each one in isolation is often not the cheapest layout once the traffic between them is priced. The placement optimiser takes several workloads, the traffic between them and to the internet, where each one runs today and what it would cost to move, and finds the layout with the lowest total over your horizon.

What is counted

• Compute: the reference instance for the workload shape (general, compute, memory, general plus 100 GB SSD, or a custom vCPU and RAM shape priced from the per-unit rates), times instances, times hours per month.
• Block storage: GB times the region's general-purpose SSD rate per GB-month, where the data has one.
• Egress: every traffic flow is priced at the source region's rate to its destination. Between two regions of the same provider that is the published inter-region rate for the pair; to the internet it is the first paid tier; inside one region it is zero (inter-AZ transfer is outside the model); across providers it is the source's internet rate.
• Migration: a one-off you declare per workload, charged only if the workload moves. The total over the horizon is months times recurring plus migration; the break-even month is migration divided by the monthly saving.

What is a hard limit

Residency (the regions a workload may live in), a maximum latency to a hub city or to another region, compliance certificates a region must hold, and capacity declared per region and shape. These are not weighed against cost; they remove regions from a workload's options before anything is priced. The result lists them under hard constraints so you can see what shaped the answer.

What it refuses to guess

A rate that is not in the data is unknown, never zero. If every layout that satisfies the constraints would need an unknown rate, the status is "blocked by unknown rates" and the rates are listed by name with a field to supply each one. With "allow unknown rates" the result is labelled a lower bound and names the rates missing from it. The current layout is compared with the proposed one only when both are fully priced; otherwise no saving is shown.

What the statuses mean

• Proven optimal: the solver proved no cheaper layout exists under these prices and constraints. Small problems are enumerated exhaustively in plain JavaScript; larger ones go to the HiGHS mixed-integer solver running as WebAssembly in a worker, which proves optimality by closing the gap between its best layout and a lower bound.
• Feasible, not proven optimal: the time limit ran out. The layout satisfies every constraint; the gap shown is how much cheaper a better layout could be at most. Raise the time limit or remove a workload to get a proof.
• Blocked by unknown rates: supply the rate or allow unknown rates.
• No placement satisfies the constraints: at least one workload has no region left after residency, latency, compliance and capacity. Loosen one.

The worked example

The page opens with six made-up AWS workloads: two web APIs that must stay within 40 ms of their users in Europe and the US East coast, a batch job and a cache that must stay in the EU, an analytics job, and an archive processor that receives 500 GB a month from analytics. Each has a current region and a migration cost. The optimiser keeps both APIs where they are (the latency bound leaves no cheaper option), moves the EU batch and cache to the cheapest EU region that satisfies residency, and moves the archive processor next to analytics so their traffic becomes free same-region transfer instead of inter-region egress. The migration costs are paid back within months and the status is proven optimal.

Sharing and reproducing a result

Share link puts the whole scenario in the URL, compressed, so a colleague opens the same editor. Export JSON writes the request and response in the contract format (version 1.0.0, the same schema as the reference implementation); Import JSON solves any request in that format. Nothing is sent to a server: the solve happens in your browser.