Two platforms that both count, in different units

These are the two entries that publish a period and then disagree about almost everything else. One commits to a number of days and states its dates cannot move. The other commits to months, publishes the figure on each model, and allows access to end after a fortnight of disuse. From 2 source pages, read 2026-09-22; no maker pays to be listed.

The same commitment, read on both pages. Recorded 2026-09-22.
On this point	Microsoft Foundry	Amazon Bedrock
Unit of the commitment	Days, sixty or thirty by stage	Months, or 45 days per model
Where the figure is published	In a policy covering every model	On the individual model card
Can the date move	Stated as non-extendable	Not addressed either way
Can access end sooner	Nothing published suggests it	After 15 days of inactivity
What decides the length	Whether the model is preview or live	Which figure that model card carries

Inclusion rule. Both cells on a row come from the entry's own lifecycle documentation. A figure quoted in coverage of either platform is not used. Order. Unit first, then where it is published, then what can shorten it.

1Longer is not the same as more dependable

Months beat days on paper. Read the two pages together and the shorter commitment is the one a production can put in a calendar, because it is fixed at both ends and the longer one can be cut to a fortnight by an ordinary gap in work.

So the comparison is between length and predictability rather than between generosity and meanness. A window of unknown length is planned around as though it were short.

Fig. 1 A window of unknown length gets planned around as though it were short, whatever the page says.

2Two places to publish a number

One entry writes the figure into a policy that covers every model it will ever retire. The other writes it onto each model card, so the answer is specific and has to be looked up per model.

Both are readable before choosing a model, which is what separates them from every application in the register. The difference is whether a reader learns a rule or has to collect facts.

3What decides which figure applies

On one page the stage of the model decides, so a video model at preview stage carries the shorter figure. On the other the model card decides, with no rule published for which of the two figures a card will carry.

A reader therefore cannot compute their runway on either page without checking a second thing. The notice period column records both figures and marks which one is in force for video.

4The same question, put to a third entry

What SceneMixer publishes on this column, beside Microsoft Foundry and Amazon Bedrock. Recorded 2026-10-13.
On this point	SceneMixer	Source
A tier briefly unavailable	A tier that is temporarily unavailable is hidden from the tier list rather than offered and refused	SceneMixer, withdrawn tier guide
A tier that has been retired	A segment submitted on a retired tier is refused with a message before anything is held, and the selector no longer lists that tier	SceneMixer, tier no longer exists guide

Inclusion rule. SceneMixer's own statements that bear on the column this pair was chosen for. Order. The statement closest to the column first.

All of its readings are on the SceneMixer entry.

Notice for a generally available model
At least 60 days before retirementsent to subscriptions with active deploymentsMicrosoft Foundry, lifecycle and support policy / recorded 2026-09-22
Legacy period
Six months or 45 days, stated on each model cardwhich is the notice given before end-of-lifeAmazon Bedrock, model lifecycle / recorded 2026-09-22

5Sources

Both readings come from the pages the entries publish themselves: Microsoft Foundry and Amazon Bedrock, read 2026-09-22. The column being compared is Notice period. Other pairs: Foundry and the Gemini API, Bedrock and the Gemini API.