The AWS post's scope note matters: SchedulingConfig governs the placement plan for each individual scale operation [14]. Balance is therefore an outcome of each API call, not a property the endpoint holds. After enough scale-in and scale-out cycles, the per-operation plans can drift, and AWS's answer is a second setting in a second object: the endpoint's ScaleInPolicy with the CONSOLIDATION strategy, which runs a background sweeper that consolidates copies and releases idle instances while honoring AZ balance constraints [14][15]. Two-AZ placement is one parameter on the component and one policy on the endpoint.
AWS also leans on the phrase "best-effort," and it is worth sitting with. AWS describes availability-aware distribution as even placement across AZs on a best-effort basis, while stating separately that endpoint and inference component update operations persist multi-AZ placement, so HA survives model updates [16]. Persisting placement through updates is real engineering and the harder half of the problem. Best-effort spreading, though, is a behaviour to test on your own endpoint rather than a control to cite in an audit, particularly if the requirement is a hard internal rule like Salesforce's 2-AZ mandate for every production model [5].
Here is the arithmetic the post sets up but does not finish. The documented scenario is four instances, two per AZ, with four copies deployed under SPREAD, landing two in AZ-1 and two in AZ-2 [9]. Lose an AZ and two copies remain, which is half the serving capacity [1]. Two-AZ HA at unchanged throughput therefore costs double the copies you need in steady state, and the copies are the thing you were consolidating onto shared GPUs to save money on. Set MaxImbalance to 0 and the constraint tightens further: strict balance across two AZs admits only even copy counts [2].
The 8x number is Salesforce's, for Agentforce, and it comes specifically from co-hosting multiple models on shared GPUs [2]. For it to transfer you would need a fleet of models that each leave a GPU substantially idle, compatible enough accelerator and instance requirements to share, and traffic peaks that do not arrive together. One large model per endpoint gets none of it, and neither does a portfolio whose components all spike at the same hour. What transfers unconditionally is the failure mode: without SchedulingConfig, the default algorithm optimizes each deployment operation on its own and distributes copies evenly across instances without considering AZs, so copies of one model can pile into one zone even on a multi-AZ endpoint [3].
The post also tells you never to set CopyCount to 1 for an HA-critical model, because a single copy lives in a single AZ [13]. In plain terms, a single copy means your high-availability plan runs in one Availability Zone.
