Amazon Pulls Nova Premier, Canvas and Reel From Bedrock

If you've got a Bedrock inference profile pointed at amazon.nova-premier-v1:0, today is the day it stops being a someday problem. Amazon Nova Premier reaches end of life on Amazon Bedrock on September 14, 2026, and Nova Canvas plus two versions of Nova Reel follow on September 30.

What happened

Amazon is retiring three corners of its Nova model family from Bedrock: Nova Premier (the largest text and reasoning model in the lineup), Nova Canvas (image generation), and two Nova Reel versions (video generation). AWS marked all three as Legacy status months ago, and now the end-of-life dates have arrived.

This isn't an isolated model refresh. Reuters reported in late July, citing Business Insider, that Amazon is winding down Nova Premier alongside Nova Omni, Reel and Canvas as part of a broader reset, redirecting engineering talent and compute toward a frontier-model research effort reportedly led by AI researcher Pieter Abbeel, aimed at a release around AWS re:Invent 2026. The smaller, cheaper Nova models that most production workloads actually use, Micro, Lite and Pro, aren't on the retirement list.

Under Bedrock's model lifecycle policy, a model moves through Active, then Legacy, then End-of-Life. Once a model is Legacy, new customers can't start using it, existing accounts lose access after 15 days of inactivity, and you can't provision new Provisioned Throughput against it. Models with an EOL date after February 1, 2026 also get a public extended access window in their final months, where the model stays reachable past what you'd expect but at pricing the model provider sets, and AWS is explicit that this pricing tends to go up, not down. Once EOL hits, the model ID simply stops resolving.

AWS does not migrate your application for you. If a Bedrock agent, batch job or app is still calling one of these model IDs after its EOL date, the call fails.

Why it matters for an FDE

If you shipped a pilot or a production workload against Nova Premier for its longer context or heavier reasoning, or against Canvas or Reel for generative media, you now own a migration, not a maintenance task. And because Bedrock's Legacy period quietly changes pricing before the hard cutoff, a workload can get more expensive weeks before it stops working at all, which is the kind of thing that shows up as a mystery line item in a cost review rather than an outage.

This is also a case study worth keeping for the next planning cycle: any FDE team building on a named foundation model, not just an open-weight one, is inheriting the provider's model lifecycle as a dependency. That belongs in the backlog next to your actual feature work, not as a surprise ticket when a customer's integration breaks.

What to do Monday morning

First, find every model ID you're actually calling. Don't trust memory or old runbooks.

aws bedrock list-foundation-models \
  --region us-east-1 \
  --query "modelSummaries[?contains(modelId, 'nova')].{id:modelId,status:modelLifecycle.status}" \
  --output table

This surfaces every Nova model ID in the region along with its lifecycle status, so you can spot LEGACY and EOL entries at a glance. Run it against every region your workloads touch, since lifecycle status is regional.

Second, grep your codebase and infrastructure-as-code for the retiring model IDs directly: amazon.nova-premier-v1:0, the Nova Canvas model ID, and the two affected Nova Reel versions. Check Bedrock agents, Provisioned Throughput allocations, and any inference profile ARNs, not just direct InvokeModel calls.

Third, pick replacements deliberately instead of defaulting to whatever's newest. For text and reasoning, that likely means Nova Pro or a Claude model on Bedrock, depending on what you were actually using Premier's extra headroom for. For image and video generation, check Bedrock's current model catalog for what replaces Canvas and Reel's specific capabilities before you commit, since generative media models don't swap in like-for-like the way text models often do.

Put this on the sprint board as a tracked item with the EOL date as the deadline, not a someday-maybe. A model retirement with three months of public notice shouldn't turn into an incident.

A foundation model's lifecycle is now part of your production dependency graph, and treating it like any other deprecated API you'd track in a sprint is what keeps a scheduled retirement from becoming an outage.