Bedrock Claude 3.x Shutdown Countdown: Migration Guide and Model Selection

Amazon Web Services (AWS) recently issued a formal notice regarding the end-of-life (EOL) of the Claude 3.x series models on Amazon Bedrock. According to the official announcement, several models—including Claude 3 Haiku, Claude 3 Sonnet, Claude 3.5 Sonnet, Claude 3.5 Sonnet v2, and Claude 3.7 Sonnet—will officially stop serving in seven specific regions on November 13, 2026. For developers and enterprises relying on these models to build generative AI applications, this means completing model migration, code modifications, and cost reassessment before the deadline.

Shutdown Scope and Key Milestones

This shutdown is not a global blanket cutoff but precisely targets seven AWS regions. Although the original text does not list the regions one by one, this scope typically covers the core regions where Bedrock was first launched and where usage density is highest. The affected model versions span a wide range—from the early Claude 3 Haiku to the more recent Claude 3.7 Sonnet—indicating that AWS is accelerating the push for users to migrate to the Claude 4 series and newer architectures.

Developers need to immediately check whether their accounts have invoked the above model IDs in these regions. Bedrock's on-demand billing model means that once a model is discontinued, the related Inference Profiles and Provisioned Throughput will no longer process requests, and existing workloads will directly return errors. With only a few months left before November 13, migration testing must be put on the agenda.

Inference Profile is a cross-region inference capability introduced by Amazon Bedrock in recent years. It allows developers to bind the same model ID to endpoints in multiple regions, and Bedrock automatically routes requests to available regions based on real-time capacity and latency, thereby improving throughput and reducing the probability of throttling caused by insufficient capacity in a single region. Inference Profiles are divided into two types: system-defined and application-defined. The former is maintained by AWS and covers common models, while the latter is composed of regions by the user. It is particularly important to note that the validity of an Inference Profile is tied to a specific model: when a model is discontinued in some regions, Profiles pointing to that model may lose the underlying capacity in those regions or even become entirely invalid. Therefore, during migration, you should not only replace the modelId but also verify whether the model and region set referenced by the Profile are still complete.

Provisioned Throughput, on the other hand, is a capacity reservation model billed by the hour. Users purchase fixed input/output token processing capacity (measured in Model Units) for a specific model to obtain stable latency and throughput guarantees, suitable for production-grade online inference. Unlike on-demand billing, Provisioned Throughput usually has a minimum commitment period (e.g., one month) and is strongly bound to a specific model version. Model discontinuation means that purchased provisioned capacity cannot be migrated to a new model and must be reordered; if there are still unexpired commitments before the shutdown date, resources may sit idle. Therefore, affected teams should inventory the expiration dates of their Provisioned Throughput as early as possible and incorporate them into the migration schedule.

Alternative Model Selection: Mapping Logic from 3.x to 4.x

Faced with the shutdown, the core question is "where to migrate to." AWS simultaneously provided new model IDs and pricing information in the announcement, which provides an official basis for selection. The overall strategy is: migrate lightweight tasks from Claude 3 Haiku to Claude 4 Haiku or a new model with equivalent positioning; migrate general tasks from Claude 3 Sonnet / 3.5 Sonnet to Claude 4 Sonnet; and for scenarios that originally used Claude 3.7 Sonnet for complex reasoning, it is recommended to evaluate Claude 4 Opus or higher-tier versions of Sonnet.

Note that the pricing structure of the new models may change. The original text mentions that the announcement includes pricing information, which means migration is not just changing a model ID but may also affect per-token costs and the overall budget. Before switching, developers are advised to use Bedrock's Cost Explorer to sample existing call volumes and recalculate monthly expenditure at the new prices to avoid bills exceeding expectations after launch.

Code Modification in Practice: Model ID and API Compatibility

The technical actions for migration center on replacing model identifiers. In Bedrock's Converse API or InvokeModel calls, the modelId parameter needs to be replaced from the old 3.x identifier (e.g., anthropic.claude-3-5-sonnet-20241022-v2:0) to the corresponding new model ID. If the application uses an Inference Profile (cross-region inference), you also need to confirm whether the new model supports the same Profile configuration.

Another easily overlooked point is request parameter compatibility. The Claude 4 series remains backward compatible with basic parameters such as max_tokens and temperature, but newly added capabilities such as extended thinking need to be explicitly enabled. If existing code hardcodes the context window size or output limit of the old model, it must be adjusted accordingly after migration; otherwise, parameter validation errors may be triggered. It is recommended to first use shadow traffic in a test environment to compare the output quality and latency of the old and new models, and then gradually switch production traffic.

Converse API is a unified conversation interface provided by Bedrock. It shields differences in underlying request body formats across models from different vendors (Anthropic, Meta, Mistral, etc.), allowing developers to call multiple models with the same message structure, and natively supports multi-turn conversations, tool use, and system prompts. In contrast, InvokeModel is a lower-level general inference interface; the request body must be constructed according to each model's proprietary schema, offering greater flexibility but poorer portability. Their impact on migration differs: for applications using the Converse API, model differences are mostly adapted internally by Bedrock, and the switching cost is mainly concentrated in modelId and a few capability switches; for applications using InvokeModel that directly assemble Anthropic's native request body, the field requirements of the new version need to be verified.

When choosing an interface, also note that the Converse API standardizes streaming output (ConverseStream) and tool use, making it easier to change models again in the future; if existing code has extensive request body customization to be compatible with old models, consider refactoring to the Converse API when migrating to new models to reduce future migration debt.

Migration Risks and Mitigation Recommendations

The limited time window is the biggest risk. The shutdown in seven regions takes effect simultaneously, meaning it cannot be circumvented through cross-region calls. Teams should freeze new feature development on 3.x models as early as possible and invest resources in migration validation. Second, prompt engineering may require fine-tuning—different model versions respond differently to the same prompt, especially when upgrading from 3.5 Sonnet to 4.x, where the stability of output formats requires regression testing.

For projects still in the prototype stage, they can be rebuilt directly on the new models to avoid migration debt. For production systems, it is recommended to develop a phased switching plan: first migrate batch processing tasks on non-critical paths, and after validating stability, migrate online inference services. At the same time, keep a rollback plan in case the new model encounters capacity or latency issues in specific regions.

Shadow traffic is a low-risk comparative validation method: a copy of real production requests is sent to the new model, but only its output, latency, and token consumption are recorded; the results are not returned to users. This allows quantifying differences between old and new models in accuracy, format stability, first-token latency, and total elapsed time without affecting the online experience. When implementing in the Bedrock scenario, note that shadow requests are also billed, so the sampling ratio should be controlled (e.g., 5%–10%); also avoid shadow requests triggering downstream side effects, such as duplicate database writes or external tool calls. A common practice is to disable tool execution on the shadow path and keep only text generation.

Extended thinking is a reasoning capability introduced in newer versions of Claude. Before giving the final answer, the model outputs an internal thinking process to improve correctness on complex math, code, and multi-step reasoning tasks. This capability needs to be explicitly enabled and a thinking budget set; it consumes additional output tokens, so both cost and latency are higher than ordinary calls. During migration, if the original system relied on 3.7 Sonnet for complex reasoning, after switching to the new model you should reassess whether to enable extended thinking and what budget to set, and use shadow traffic to compare quality and cost changes before and after enabling it, rather than enabling it fully by default.

Frequently Asked Questions

Q: What happens if I still call the old models after November 13? A: Requests will fail and return a model-unavailable error, and the relevant endpoints will no longer accept traffic.

Q: Are the new models necessarily more expensive than the old ones? A: Not necessarily; refer to the price list in the announcement. Some new models may offer better cost-effectiveness per unit of performance, but this needs to be measured against specific call volumes.

Q: Is it mandatory to modify application code for migration? A: If model IDs are managed through environment variables or a configuration center, you may only need to update the configuration; if hardcoded, code changes are required.

Q: Will all regions be discontinued simultaneously? A: The announcement specifies seven regions; support in other regions should be confirmed by consulting the Bedrock regional availability documentation.

One-line Summary

AWS announced that multiple Claude 3.x models will be discontinued in seven regions on November 13, 2026, and developers need to migrate to the Claude 4 series as soon as possible.

Paragraph Summary

Amazon Web Services issued a notice that Claude 3 Haiku, 3 Sonnet, 3.5 Sonnet, 3.5 Sonnet v2, and 3.7 Sonnet will stop serving in seven AWS regions on November 13, 2026. The article outlines the shutdown scope and timeline, noting that the discontinuation takes effect simultaneously and cannot be circumvented through cross-region calls. The core of migration lies in mapping old models to Claude 4 Haiku/Sonnet/Opus by task tier, updating modelId, checking Inference Profile and Provisioned Throughput configurations, and reassessing costs at new prices. Technically, attention should be paid to differences between the Converse API and InvokeModel, parameter compatibility, and context window adjustments. It is recommended to use shadow traffic to compare output quality and latency between old and new models, and to develop phased switching and rollback plans.