Bedrock Model Lifecycle - AWS Guide to Deprecation & End of Life

Bedrock model lifecycle defines how foundation models move from active availability to legacy status and, eventually, End of Life.

It helps AWS teams understand when a model can be used, when migration planning should begin, and when model requests will stop working.

This process matters to companies running customer-facing AI assistants, document processing systems, generative AI agents, internal copilots, and other production workloads.

Without lifecycle planning, a model retirement can cause failed API requests, broken automations, unexpected pricing changes, or extended downtime.

Amazon Bedrock does not move an application to a newer model.

Every organization is responsible for identifying affected workloads, selecting a replacement, testing it, and updating the application before the End-of-Life date.

What Is the Bedrock Model Lifecycle?

Amazon Bedrock model lifecycle is a structured process for introducing, maintaining, retiring, and replacing foundation model versions.

Foundation model providers regularly release updated models with stronger reasoning, better accuracy, improved safety, or lower processing costs.

As newer versions become available, older versions eventually stop receiving active support.

AWS Bedrock model lifecycle places an available model into one of three states:

Active
Legacy
End-of-Life

A model remains available in Amazon Bedrock for at least 12 months after its initial launch.

It normally remains in the Legacy state for at least six months before reaching End of Life.

Lifecycle dates are specific to Amazon Bedrock.

A model provider may publish a separate retirement schedule, but Bedrock users should follow the dates listed in the official Amazon Bedrock documentation.

The Three Amazon Bedrock Model Lifecycle Stages

Each lifecycle stage changes what customers can do with a model and how urgently they need to prepare for migration.

Understanding these stages helps engineering, cloud operations, security, and product teams avoid last-minute replacement work.

1. Active

An Active model is available for normal development and production use.

The model provider is actively maintaining the version.

Depending on the model supported features, teams can use it for inference, request quota increases, create custom versions, or purchase Provisioned Throughput.

An Active model can be called through supported Amazon Bedrock API such as InvokeModel or Converse.

Active status does not mean the version will remain available indefinitely.

Teams should still keep model IDs outside application logic and maintain a current inventory of every application using the model.

2. Legacy

Legacy status is the formal signal that migration work should begin.

Existing customers can continue calling the model during the Legacy period.

However, new customers may be unable to access it.

Existing users may also lose access after 15 days of inactivity.

A Legacy model has additional restrictions.

Customers cannot create new Provisioned Throughput for it.

New fine-tuning jobs are also unavailable after the underlying foundation model enters Legacy status.

For models with EOL dates after February 1, 2026, a Legacy period may include public extended access.

This stage begins after at least three months in Legacy status and continues until the EOL date.

Pricing may increase during this period based on the model provider terms.

Legacy access should be treated as migration time, not as a permanent operating option.

3. End-of-Life

At End of Life, the model is no longer available to most Amazon Bedrock customers.

On or shortly after the published EOL date, calls to the retired model will fail across affected AWS Regions.

Migration does not happen automatically, and Bedrock does not silently redirect requests to a newer version.

Applications must be updated to reference a supported model ID before the deadline.

Private arrangements between a customer and model provider may permit continued access in limited cases, but this is not the standard path.

Why Bedrock Model Deprecation Matters

Bedrock model deprecation is an operational risk when model dependencies are not documented or tested.

A model change affects more than one API parameter.

Different versions may interpret instructions differently, return another response structure, use tokens at a different rate, or require changes to prompt design.

A migration may affect:

Prompt wording and system instructions
Model IDs and inference profiles
Context-window limits
Tool-use behavior
Output formatting and parsing
Token consumption
Response latency
Content filtering
Regional availability
Service quotas
Provisioned capacity
Model pricing

For example, a customer-support assistant may depend on a specific JSON response structure.

A replacement model could produce better answers but format the output differently.

Without regression testing, the application may fail even though the new model itself is working correctly.

Bedrock Sonnet 3.5 Deprecation

Bedrock Sonnet 3.5 deprecation shows why model status must be checked by model ID and AWS Region.

Original Anthropic Claude 3.5 Sonnet model with the ID anthropic.claude-3-5-sonnet-20240620-v1:0 entered Legacy status on January 30, 2026, in listed Asia Pacific and AWS GovCloud Regions.

Its public extended access period began on April 30, 2026, with an EOL date of July 30, 2026.

Claude 3.5 Sonnet v2 also has a July 30, 2026, EOL date in the specific Asia Pacific Regions listed in the Amazon Bedrock lifecycle documentation.

This does not mean every Claude 3.5 Sonnet endpoint in every Region follows the same schedule. Teams should verify the exact model ID, source Region, inference profile, and destination Regions used by each application.

Organizations still using an affected version should complete migration immediately.

Testing should include prompts, response parsers, tools, guardrails, quotas, cost, latency, and output quality.

Bedrock Model Lifecycle Examples

Migration replaces a Legacy model without changing production traffic all at once.

Consider a company using Claude 3.5 Sonnet to summarize contracts.

Application sends documents to Amazon Bedrock, requests structured findings, and saves the results in a contract management platform.

A practical migration could follow this sequence:

Identify the dependency

Team searches source code, Lambda functions, environment variables, infrastructure templates, prompt libraries, and monitoring logs for the retiring model ID.

Select an Active replacement

Team compares supported Active models based on document understanding, context length, Regional availability, latency, cost, and output quality.

Build an evaluation set

Team creates a fixed group of representative contracts, including long documents, unusual clauses, scanned content, and known edge cases.

Run side-by-side tests

Same inputs are sent to both models.

Results are compared for accuracy, omissions, unsupported claims, response time, token use, and output structure.

Update prompts and application logic

Prompts are adjusted for the new model.

Parsing rules, token limits, retry logic, and response validation are updated where required.

Release in phases

Small percentage of traffic is routed to the new model.

Team monitors errors and business metrics before increasing traffic.

Remove the old dependency

After the new version meets acceptance criteria, the old model ID is removed from production configuration and deployment templates.

Bedrock model lifecycle example reduces the risk of changing model behavior without visibility.

How to Manage AWS Model Lifecycle

Lifecycle management requires ownership, automated visibility, and a repeatable migration process.

Following practices help companies manage the broader AWS model lifecycle across multiple Bedrock applications.

Maintain a model inventory

Record every model ID, AWS account, Region, workload owner, business purpose, invocation method, and deployment environment.

Inventory should also show whether the application uses direct inference, cross-Region inference, custom models, Provisioned Throughput, Knowledge Bases, or Agents.

Check lifecycle Status

Amazon Bedrock returns model status through the modelLifecycle field when teams call GetFoundationModel or ListFoundationModels.

This data can be included in a scheduled governance check.

A Legacy status can then create an alert, ticket, or migration task for the responsible team.

Monitor AWS notifications

Lifecycle announcements may appear through email, the AWS Health Dashboard, the Amazon Bedrock console, and API responses.

Account contact details should remain current.

Operations and engineering teams should not depend only on messages sent to the AWS root account.

Separate model IDs from business logic

Store model identifiers in controlled configuration, such as AWS Systems Manager Parameter Store or environment variables.

This makes the technical replacement easier, although testing is still required before changing production settings.

Create a reusable evaluation process

Maintain test prompts and expected outcomes for every important AI workload.

Evaluate accuracy, safety, latency, cost, formatting, and task completion.

A model that performs well for general conversation may not be suitable for extraction, coding, classification, or agent-based workflows.

Start during Legacy status

Do not wait for the final weeks before AWS Bedrock model End of Life.

Quota approvals, compliance reviews, prompt changes, and application testing can take longer than expected.

AWS recommends assessing usage, researching replacements, testing model behavior, completing a phased migration, and monitoring performance after deployment.

How Qualix Solutions Supports Bedrock Lifecycle Management

Qualix Solutions helps companies move from reactive model replacement to an organized lifecycle process.

AWS consultants can assess current Bedrock dependencies, identify Legacy models, compare replacement options, and prepare a migration plan based on business and technical requirements.

Support can include: