Claude 5.5 on Amazon Bedrock: The Real Lifecycle Checklist

Choosing to call Claude 5.5 through Amazon Bedrock rather than Anthropic’s first-party API is as much a lifecycle decision as a model-selection decision, and most teams treat it as the latter only. Bedrock runs its own retirement calendar, independent of Anthropic’s, and it is typically longer. The policy governing that calendar also just changed for models launched on or after September 7, 2026, which includes Claude Opus 5.5 itself. If your team picked Bedrock purely for billing convenience and AWS-native IAM, you got a real operational benefit you probably didn’t price in: more migration runway than Anthropic’s own API gives you, on a lifecycle contract that’s different from the one governing older Claude models already in your stack.

Why the Platform You Buy Through Changes Your Real Runway

Anthropic commits to at least 60 days’ notice before retiring a publicly released model on its own platforms. Amazon Bedrock sets its own schedule entirely, and the gap between the two is measured in months, not days. Claude Sonnet 4 was retired on Anthropic’s own API on June 15, 2026, but the same model’s end-of-life date on Amazon Bedrock is October 14, 2026, four months later. Claude Opus 4.1 shows the same pattern: retired on Anthropic’s API on August 5, 2026, with a Bedrock end-of-life date of January 8, 2027, five months out. The practical takeaway is blunt: the model ID you’re running matters less than the platform you’re calling it through, because that platform decides how long you actually have to migrate.

Opus 5.5 Runs on a Different Bedrock Lifecycle Contract Than Older Claude Models

What changed in the September 2026 policy

Claude Opus 5.5 launched on Bedrock on September 22, 2026, with an EOL date listed as no sooner than September 22, 2027, and a Legacy period of six months. That phrasing matters because it reflects a new policy structure Bedrock introduced for any model launched on or after September 7, 2026. The older policy, which still governs Claude models launched before that date, guaranteed a minimum 12 months on the platform before EOL, plus a separate “public extended access” phase after at least three months in Legacy state, during which pricing could rise. The newer policy collapses that into a single model-card commitment: an “EOL no sooner than” date and a Legacy period of either six months or 45 days. This means your Opus 5.5 deployment and, say, an older Opus 4.5 deployment sitting in the same account are governed by two different lifecycle contracts, not variations on the same one. A team that reads one model card and assumes the terms apply uniformly across its Claude footprint on Bedrock is working from an incomplete picture.

What Legacy status actually blocks immediately

The Legacy state is more restrictive than it sounds on first read. Once a model enters Legacy, you can no longer create new Provisioned Throughput endpoints or start new fine-tuning jobs against it, even though existing on-demand deployments and existing Provisioned Throughput endpoints keep working. New customers can’t start using a Legacy model at all, and existing customers can lose access after just fifteen days of inactivity. That inactivity clause is the detail worth building a monitor for specifically, because a low-traffic internal tool built on a model that later goes Legacy can silently lose access well before the model’s actual EOL date, with no code change on your end to explain the outage.

The Migration Behavior Gap

The theory of model lifecycle management assumes teams migrate proactively once a deprecation notice lands. The data says otherwise. An empirical study tracking 22,555 migration commits across 17,703 public GitHub repositories found that 82% of migrations away from retired models were committed after the shutdown date had already passed, not before it. That’s not a planning failure in the sense of teams not knowing a model would retire. It’s an observability failure: the information existed in a changelog or a model card, but nothing in the team’s actual monitoring stack surfaced it as an action item before production calls started failing.

The Lifecycle Checklist Worth Building Now

Track the modelLifecycle field programmatically, through the ListFoundationModels or GetFoundationModel API calls, rather than relying on someone periodically rereading documentation. That field tells you a model’s current state in the region you’re actually calling, and model lifecycle state can differ by region, which is easy to miss if your monitoring only checks one. Treat the Legacy transition, not the EOL date, as your real trigger point, since that’s when new Provisioned Throughput and fine-tuning paths close and when low-traffic workloads become vulnerable to the inactivity clause. If your workload’s EOL date falls after a model enters public extended access under the older policy, budget for a pricing increase during that window, since the provider sets that rate and it isn’t disclosed upfront on the model card. And decide, per workload, which platform actually governs your retirement runway, Anthropic’s first-party API, Bedrock, Microsoft Foundry, or Google Cloud, because picking the platform with the longest runway for a given model is a legitimate architecture decision, not just a procurement preference.

At SIRAYA, the standing recommendation for any team running Claude models at scale is to build lifecycle-state monitoring into the same observability stack that tracks latency and error rate, not into a separate compliance spreadsheet somebody checks quarterly. Given that most real-world migrations happen after the shutdown, not before it, the teams avoiding that outcome are the ones who made the lifecycle field a monitored signal instead of a document someone has to remember to read.