Understand the Amazon Bedrock model lifecycle

Amazon Bedrock regularly releases new Foundation Model (FM) versions with greater functionality, accuracy, and safety. Understanding the model lifecycle is essential to effectively planning and managing AI applications built on Amazon Bedrock. You can test these models through the Amazon Bedrock console or API to assess performance and compatibility before migrating your application.

This post explains how to manage FM migration with Amazon Bedrock. This ensures that your AI applications continue to work as your models evolve. Learn about the three lifecycle states, how to plan your migration using new enhanced access features, and practical strategies for migrating to the new model without disrupting your applications.

Amazon Bedrock model lifecycle overview

Models provided by Amazon Bedrock can exist in one of three states: active, legacy, or end of life (EOL). The current status is displayed both in the Amazon Bedrock console and in the API response. For example, when you make a GetFoundationModel or ListFoundationModels call, the model state changes to modelLifecycle Response fields.

The following diagram details the state of each model.

Details of the condition are as follows.

• active – Active models receive ongoing maintenance, updates, and bug fixes from the provider. While the model exists Activewhich can be used for inference via APIs such as: InvokeModel or Converse(if supported) and request quota increases through AWS Service Quotas.
• heritage – When a model provider migrates a model Legacy According to the state, Amazon Bedrock will notify customers at least six months in advance of the EOL date, providing critical time to plan and execute a transition to a new or replacement model version. meanwhile, Legacy During this period, existing customers may continue to use the model, but new customers may no longer have access to the model, and existing customers may lose access to inactive accounts if they do not call the model for more than 15 days. Organizations should be aware that they will no longer be able to create new provisioned throughput on a per-model basis and may face limitations in model customization capabilities. For models with an EOL date of February 1, 2026 or later, Amazon Bedrock Legacy state:
  • Extension of public access period – After spending at least 3 months Legacy Once in this state, the model enters this expanded access phase. Active users can continue using it for at least three more months until EOL. During expanded access, quota increase requests through AWS Service Quotas are not expected to be approved, so plan your capacity needs before your model enters this phase. During this period, prices may be adjusted (see Pricing during Expanded Access below). Customers will receive notification of the transition date and changes.
• End of production (EOL) – When a model reaches its EOL date, it becomes completely inaccessible in all AWS Regions unless otherwise noted in the EOL list. API requests to EOL models will fail, making EOL models unavailable to most customers unless there is a special arrangement between customer and provider for continued access. Transitioning to EOL requires active action by the customer. Migration does not occur automatically. Organizations must update their application code to use the alternative model before the EOL date arrives. Once EOL is reached, most customers will no longer have access to the model completely.

Once a model is launched on Amazon Bedrock, it remains available for at least 12 months after launch. Legacy It remains in that state for at least 6 months of EOL. This timeline helps customers plan their migration without panic.

Fees for extended access

Prices may be adjusted by the model provider during the extended access period. If a price change is planned, the first traditional announcement will notify you before any subsequent changes take effect, so there are no unexpected retroactive price increases. Customers with existing private pricing agreements with model providers or customers using provisioned throughput will continue to operate on their current pricing terms during the extended access period. This ensures that customers who have made specific arrangements with model providers or have invested in provisioned capacity are not unexpectedly impacted by price changes.

Model state change communication process

When a model provider moves a model to a legacy state, customers receive a notification six months before the model’s EOL date. This proactive communication approach allows customers sufficient time to plan and execute their migration strategy before the model reaches EOL.

The notification includes details about the model being deprecated, important dates, extended access availability, and when the model will be EOL. AWS uses multiple channels to ensure these important communications reach the right people.

• email notification
• AWS Health Dashboard
• Amazon Bedrock console alerts
• Programmatic access via API.

To ensure you receive these notifications, please verify and configure your account’s contact email address. By default, notifications are sent to the account’s root user email and alternate contacts (operations, security, billing). These contacts can be found on your AWS account page.[代替連絡先]You can check and update the section. To add additional recipients or delivery channels (such as Slack or email distribution lists), go to the AWS User Notifications console and select AWS Managed Notification Subscriptions to manage delivery channels and account contacts. If you don’t receive the notifications you expect, verify that your email address is configured correctly in these settings and that notification emails from health@aws.com are not being filtered by your email provider.

Migration strategies and best practices

If you migrate to the new model, update your application code and ensure that your service quotas can handle the expected volume. Planning ahead can help ensure a smooth transition with minimal disruption.

Planning your migration schedule

Start planning as soon as you have the model Legacy state:

• Evaluation phase – Assess the current usage of legacy models, including which applications depend on them, typical request patterns, and specific behaviors and outputs that applications depend on.
• research stage – Research recommended alternative models and understand their capabilities, how they differ from legacy models, new features that can enhance your application, and local availability of new models. Review API changes and documentation.
• testing stage – Perform thorough testing on new models and compare performance metrics between them. This helps identify adjustments needed in application code or prompt engineering.
• transition phase – Implement changes using a phased-in approach. Monitor system performance during migration and maintain rollback capabilities.
• Operation stage – After migration, continuously monitor your application and user feedback to ensure it is working as expected in the new model.

Technical migration steps

Test your migration thoroughly.

• Update API reference – Modify your application code to reference the new model ID. For example, change from anthropic.claude-3-5-sonnet-20240620-v1:0 to anthropic.claude-sonnet-4-5-20250929-v1:0 or global cross-region inference global.anthropic.claude-sonnet-4-5-20250929-v1:0. Update the prompt structure according to new model best practices. For detailed guidance, see Anthropic’s Migration from Claude Sonnet 3.x to Claude Sonnet 4.x on Amazon Bedrock.
• Request a quota increase – Before fully migrating, request an increase through the AWS Service Quotas console if necessary to ensure that you have sufficient quota for your new model.
• Adjust prompts – Newer models may have different responses to the same prompt. Review and adjust the prompts according to your new model specifications. You can also use tools such as Amazon Bedrock’s Prompt Optimizer to rewrite prompts for your target model.
• Handling update responses – If the new model returns responses in a different format or with different characteristics, update the parsing and processing logic accordingly.
• Optimize token usage – Take advantage of the efficiency gains of the new model by reviewing and optimizing token usage patterns. For example, models that support prompt caching can reduce the cost and latency of calls.

testing strategy

Thorough testing is critical to a successful migration.

• Compare side by side – Run the same request against both the legacy and new models and compare the output to identify differences that may impact your application. For production environments, consider shadow testing. Send duplicate requests to new models along with existing models without impacting end users. Using this approach, you can evaluate model performance, latency and error rates, and other operational factors before complete migration. Run A/B tests to assess user impact by routing a controlled percentage of live traffic to your new model while monitoring key metrics such as user engagement, task completion rates, satisfaction scores, and business KPIs.
• performance test – Measure response times, token usage, and other performance metrics to understand how new models perform compared to legacy versions. Validate business-specific success metrics.
• Regression testing and edge case testing – Verify that existing functionality continues to work as expected on new models. Pay particular attention to unusual or complex inputs that can reveal differences in how the model handles difficult scenarios.

conclusion

Amazon Bedrock’s model lifecycle policy provides clear stages for managing FM evolution. The transition period will provide expanded access options and fine-tuned model provisions to balance innovation and stability.

Get up-to-date information about your model’s state through the AWS Health Dashboard and plan your migrations as your model transitions to that state. Legacy Test new versions thoroughly. These guidelines will help you maintain continuity in your AI applications while using improved functionality in new models.

If you have further questions or concerns, please contact the AWS team. We want to help you make a smooth transition so you can continue to take advantage of the latest advancements in FM technology.

For continued learning and implementation support, visit the official AWS Bedrock documentation for comprehensive guides and API references. Additionally, visit the AWS Machine Learning Blog and AWS Architecture Center for real-world case studies, migration best practices, and reference architectures to help you optimize your model lifecycle management strategy.

---

About the author

Saurabh Trikhande He is a senior product manager for Amazon Bedrock and Amazon SageMaker Inference. He is passionate about working with customers and partners, motivated by the goal of democratizing AI. He focuses on key challenges related to deploying complex AI applications, inference with multi-tenant models, optimizing costs, and making the deployment of generative AI models more accessible. In my free time, I enjoy hiking, learning about innovative technology, following TechCrunch, and spending time with my family.

Melanie LeeWith a PhD, she is a Senior Generative AI Specialist Solutions Architect at AWS based in Sydney, Australia, where she focuses on collaborating with customers to build solutions using cutting-edge AI/ML tools. Leveraging the power of her LLM, she has been actively involved in multiple generative AI initiatives across APJ. Prior to joining AWS, Dr. Lee held data science roles in the financial and retail industries.

Derrick Chu He is a Senior Solutions Architect at AWS, accelerating the digital transformation of enterprises through cloud adoption, AI/ML, and generative AI solutions. He specializes in full-stack development and ML, designing end-to-end solutions across front-end interfaces, IoT applications, data integration, and ML models, with a particular focus on computer vision and multimodal systems.

Jared Dean Principal AI/ML Solutions Architect at AWS. Jared works with customers in a variety of industries to develop machine learning applications that improve efficiency. Interested in AI, technology, and BBQ in general.

Julia Bodia I am a Principal Product Manager at Amazon Bedrock.

pooja rao He is a senior program manager at AWS, leading quota and capacity management and supporting business development for the Bedrock Go-To-Market team. Outside of work, I enjoy reading, traveling, and spending time with my family.