Why Amazon Bedrock model end of life forces migrations on your schedule
A platform team opens a notice saying a Bedrock model is moving toward retirement, and the migration clock has already started. Amazon Bedrock model end of life follows three stages: Active, Legacy and End-of-Life. During Legacy, the model is still reachable but scheduled for retirement, and that window can be as short as 45 days. Accounts that have gone inactive can also lose access before the published date. The calendar you plan against is the shortest one that applies to your account, which may be earlier than the date in the announcement.
The short answer: pinning an open-weight model on your own infrastructure removes forced migrations, because the weights you serve do not change until your team changes them. You then own the upgrades. vLLM, an Apache-2.0 serving engine, exposes OpenAI-compatible endpoints such as /v1/chat/completions, so application code written against the OpenAI API can keep its request shape while your team chooses the model behind it. The project ships new minor releases about every two weeks, with v0.31.0 dated October 5, 2026, so a pinned deployment needs a deliberate schedule for moving versions and applying security fixes (vLLM GitHub releases).
Before you decide, list the Bedrock model IDs your workloads call and check each one's lifecycle status and dates in the AWS console and current documentation. Confirm which accounts and regions are inactive enough to be at risk. Name the owner of each model decision and agree whether a retirement is handled as a scheduled change or an incident. For workloads where a fixed model version matters, such as regulated output or prompts with an existing evaluation baseline, estimate the effort of hosting the weights, securing GPU capacity and rerunning evaluations on your own prompts before a notice arrives. Pinning fits when your team can staff upgrades. If it cannot, the managed model may still be the lower-risk choice for now.
What a model lifecycle policy requires from your platform
A lifecycle policy only holds if the platform can pin a model, meet a migration window, prove which version answered a request and keep serving when a vendor account changes state. The four requirements below connect those constraints to the components you would own on your own infrastructure.
A stable model identifier you control
Bedrock model IDs and version suffixes are set by AWS and retired on AWS's schedule. A self-hosted vLLM server is started with a model path that you choose, so the name your applications call stays fixed while the weights behind it change only when you decide. Keep that alias in one place, such as the gateway configuration, so a swap touches one file. Confirm with AWS which model IDs your workloads use today and their current lifecycle state, because that list sets your first migration candidates.
A migration window you can meet
The Legacy period is the window in which you still have a working model but must move. Bedrock Legacy periods can be as short as 45 days, so the planning clock starts when AWS announces Legacy status, not when your team gets to it. Pinning an open-weight model on your own servers means you choose when to move, and a candidate can be evaluated in parallel on your own prompts. Confirm the notice AWS gives for each model and the account inactivity rules that can end access early.
Evidence of which model served each request
Auditors and incident responders will ask which model version produced a given output. Log the model name and version, the gateway route, the request time and the token counts for every call. The LiteLLM gateway can send logs to Langfuse, Datadog, OpenTelemetry and Prometheus, and vLLM exposes request counts and token throughput at /metrics. Keep the model revision and quantization settings in version control so a log entry can be traced back to a configuration. Confirm what your retention rules require before you choose a log store.
Access that does not depend on vendor account status
Inactive AWS accounts can lose Bedrock access early, which would stop production traffic with no change on your side. A self-hosted endpoint runs on your cloud account or data center, so its availability depends on your own identity and network controls. Protect the vLLM server behind a reverse proxy that allowlists only user-facing paths, because --api-key does not cover every endpoint, including /metrics and /health. Confirm with AWS the account conditions that trigger access loss so your monitoring alerts before that point.
How the Bedrock lifecycle stages affect your workloads
An application that calls Bedrock with a fixed model ID moves through three lifecycle stages whether or not its team is ready. A model is Active while it accepts new and existing traffic, enters Legacy when AWS announces its retirement, and reaches End-of-Life when calls to that model ID stop succeeding. The model ID in your code, configuration or infrastructure definitions is the only thing that changes meaning at each stage. Nothing in your application code signals the transition, so the inventory of pinned model IDs is the first control to build.
The Legacy window is the period that decides how much time your team has to act. Your planning should treat the 45-day minimum Legacy period as the shortest window you could receive, not a typical one, and assume that some models will be given less notice than your regression testing and change approvals require. Inactive accounts can lose access to a model before its published End-of-Life date, so a non-production account, a sandbox or a dormant project may fail first. Check which accounts and regions call each model ID, and which of them send traffic only occasionally.
Confirm current lifecycle dates, notice periods and inactivity rules in the Bedrock console and in the AWS documentation for each model provider before you commit to a migration date. Those sources change, and the figures in this section may not match what applies to your account or region on the day you read them. Record the dates you confirm, the owner of each model ID and the replacement you plan to test, so that a Legacy notice becomes a scheduled change rather than an incident.
Which open-source options pin a model version under your control
This table compares the open-source pieces that let a team fix a model version and record which version answered each request. Read each row as a separate job: serving the weights, routing requests through stable names, and proving the version in the logs. The main takeaway is that pinning is only as strong as the upgrade process your team runs, because no open-source component performs upgrades for you.
| Component | How it meets the pinning requirement | Trade-offs and what to confirm |
|---|---|---|
| vLLM (model serving) | Loads the exact open-weight checkpoint you choose and keeps it running until you replace it, so the model changes only when your team deploys a new version. | Apache-2.0 with no paid edition, so cost comes from GPU capacity, networking, storage and the staff who operate it. Confirm the GPUs your target model needs and plan upgrades against the vLLM release cadence. |
| LiteLLM (gateway) | Presents one OpenAI-compatible endpoint, so applications call a stable alias while the backend model name is set in gateway configuration and changed under change control. | MIT licensed, except the enterprise directory, which has its own license. Virtual keys, budgets and fallbacks are available, but fallbacks to a different model version must be disabled if you need strict pinning. Confirm which features your license covers. |
| Langfuse (tracing) | Records the model identifier and parameters on every trace, giving an audit trail of which version answered each request during any period. | Open core: code outside the ee directories is MIT licensed. Self-hosting needs PostgreSQL, ClickHouse, Redis or Valkey and S3-compatible storage, which you run and back up. Some advanced features need an enterprise license key. |
| Opik (tracing) | Stores traces with model and version metadata, so you can show which version produced a given output without relying on the provider's logs. | Apache-2.0, and the README states the full platform can be self-hosted without a commercial license. Storage, backups and upgrades of the platform sit with your team. Confirm the metadata fields you need are captured by your SDK version. |
| Upgrade process | Model changes are deliberate events: you test the new version against your own prompts, update the alias and keep the old version available for rollback. | Recurring effort falls on your team, including evaluation, retesting and sign-off. Ask any implementation partner to write the change procedure and test set into the scope before work starts. |
When pinning a model on your infrastructure is the right move
Regulated teams often validate a model version once, document its behavior, and then need it to stay fixed for as long as the control evidence depends on it. A Bedrock model moves through Active, Legacy and End-of-Life stages on AWS's schedule, so a validated version can be retired before a re-validation cycle finishes. Running an open-weight model on your own infrastructure lets you choose when a version changes, which removes the forced move in the sense that the version stays until you decide otherwise.
- Version control stays with you: the weights, the vLLM release and the container image are pinned in your registry, and nothing changes unless your change process approves it.
- Evidence stays stable: test results, prompt baselines and risk assessments refer to a version that does not disappear mid-review.
- Upgrades still happen: you must schedule security patches and vLLM releases yourself, so plan a recurring review rather than treating pinning as a one-time decision.
- Bedrock may still fit: if your regulator accepts AWS's lifecycle notices and your validation cycle is shorter than the Legacy period, staying on Bedrock avoids operating the stack.
- Confirm with your assessor: ask how the control owner, auditor or regulator treats a self-selected open-weight model compared with a provider-managed one before you commit.
Before relying on pinning, check the current Bedrock lifecycle dates for each model you use in the AWS documentation and map them against your validation calendar.
Some teams do not have a compliance mandate but still spend engineering time each time a Bedrock model reaches its end of life. The cost is mostly re-testing prompts, adjusting output handling and coordinating releases across applications. Self-hosting helps most when several applications depend on the same model and the migration cost repeats across them. It helps least when the team already has an automated evaluation suite that makes a model swap routine.
- Fewer migrations driven by AWS: a model served on your cluster keeps its version until you change the deployment, so the lifecycle date stops setting your release calendar.
- Shared evaluation harness: a fixed model lets you build regression tests against stable outputs, which makes deliberate upgrades cheaper.
- Operating load moves to you: GPU capacity, scaling, monitoring through the Prometheus metrics that vLLM exposes, and incident response become your responsibility.
- Account inactivity matters: if a project or account goes quiet, Bedrock access can end earlier than the model date, so check account activity rules as part of the plan.
- Quantify before deciding: count how many migrations occurred in the last two years and estimate the team hours each took, then compare that with the staffing needed to run inference.
Ask your AWS account team to confirm the notice period and access rules that apply to the models you use today.
Some organizations want AWS to own model rotation. They value managed capacity, IAM integration, regional availability and a single billing and audit boundary, and they accept that AWS sets the lifecycle. For these teams, a forced migration is an expected event that is handled through the normal change process, not a reason to change platforms. Staying on Bedrock is usually the better fit when the workload is not regulated in a way that requires a fixed model version and when the team has little appetite for GPU operations.
- Managed lifecycle notices: AWS announces model changes, and the migration path is documented for each model family.
- No GPU fleet to run: capacity planning, driver updates, node failures and autoscaling stay with AWS rather than your platform team.
- Built-in IAM and audit integration: access control and logs follow the patterns your AWS organization already uses.
- Self-hosting still adds work: pinning removes forced moves, but you inherit model selection, quantization choices and version management.
- Hybrid options exist: you can keep Bedrock for most workloads and self-host only the workloads with a fixed-version requirement.
Before choosing this path, confirm which Bedrock models your applications call and whether their lifecycle dates fall within your release cycle.
How to deploy a pinned model on vLLM without losing continuity
This sequence moves a Bedrock workload onto an open-weight model that you choose, validate and version yourself, so a provider's retirement date no longer dictates when you change models.
Inventory every Bedrock model ID in use
Platform engineering pulls the model IDs from application configuration, Bedrock invocation logs and any CloudWatch or CloudTrail records that show InvokeModel calls, then lists the owning team, the use case and the data classification for each. Include batch jobs, evaluation pipelines and scripts that run outside the main application, because those are the ones teams forget. The step is done when every active ID has an owner and a use case, and when you have checked each one against the Bedrock lifecycle status shown in your own console or account for that region.
Select and validate a replacement model
The ML or platform team shortlists open-weight models that fit each use case, considering licence terms, context length, hardware needs and the quality your own prompts require. They run a fixed set of representative prompts from production traffic, with expected outputs or grading rules, against the candidate and the current Bedrock model, and review differences with the business owner. Confirm the licence of each weight file in writing before it enters your environment. The step closes with a signed-off model card that records the exact weights, revision and test results.
Serve the pinned model with the OpenAI-compatible server
Platform engineers deploy the chosen weights with vllm serve on GPU nodes in your own cloud account or data center, pinning the vLLM release and the model revision in the deployment manifest rather than pulling latest. The server exposes /v1/chat/completions and related endpoints, so applications that call an OpenAI-style API can point at it with a base URL change. The step is complete when a test request returns a completion from the pinned model and the image tag and model revision are recorded in version control.
Place the server behind an allowlisting reverse proxy
Security engineers put a reverse proxy in front of vLLM and allow only the endpoints that users and applications need, such as the /v1 chat, completions, responses and embeddings paths. vLLM's --api-key option does not protect every route, including /metrics, /health and /pause, and the vLLM security documentation advises against relying on it alone. Configure the proxy to deny everything else, and test that a request to an unlisted path is refused. Authentication and rate limits belong at this layer, with the keys stored in your secrets manager.
Wire vLLM metrics into monitoring
Observability engineers scrape the Prometheus-format metrics exposed at /metrics on the API server into your existing stack, and build dashboards for request counts, token throughput, latency histograms and KV cache use. Keep the metrics endpoint on the internal network only, since the proxy does not expose it to users. Set alerts on latency and error rates against the baselines you recorded during validation. The step is done when the dashboard shows live traffic and an alert fires in a controlled test.
Isolate multi-node traffic on a private network
If the model spans more than one node using pipeline parallelism, the traffic between nodes needs its own protection. The vLLM security documentation states that node-to-node communication is insecure by default, with no authorization or encryption, so place the nodes on an isolated network segment that only cluster members can reach. Verify with a network scan from outside the segment that no inter-node port is reachable, and record the result. Skip this work for single-node deployments, but document that the choice was made.
Set an internal version policy
Governance owners write a short policy that names who may approve a model change, how long a pinned version stays in service, how new weights are tested against the validation set, and how the old version is retired. Because you control the schedule, the policy replaces a provider's lifecycle dates with your own review cycle. vLLM ships minor releases on a regular cadence, so the policy should also state when a server upgrade is tested and whether it is allowed to change model output. The step closes when the policy is approved and linked from the model card.
Questions buyers ask before pinning models in-house
What drives the cost of self-hosting an open-weight model on vLLM?
The cost comes from four components: accelerator capacity, the surrounding infrastructure, implementation and the people who operate the service. vLLM itself has no paid edition, so there is no license fee to pay for the inference engine. The largest recurring line is usually GPU or other accelerator capacity, whether you buy hardware or rent instances, and it runs whether or not requests arrive. Surrounding infrastructure adds storage, networking, a gateway, monitoring and backups. Implementation is typically a one-time cost covering sizing, deployment, endpoint protection and testing. Operating staff is the recurring cost that is easiest to underestimate, since someone must patch, upgrade, watch capacity and respond to incidents. When you request a quote, ask for each component to be priced separately, state the model size and expected concurrency that drive the GPU sizing, and ask which costs are one-time and which recur each month.
How long does a self-hosted vLLM deployment take to put into production?
No timeline is given here without a written scope, because the duration depends on the model, the hardware lead time, the network design, the controls you require and how many systems the gateway and guardrails must connect to. Deployment work usually covers sizing the accelerators, standing up the vLLM server with OpenAI-compatible endpoints, placing an authenticated reverse proxy in front of it, wiring metrics into your monitoring, and running acceptance tests on your own prompts. Hardware procurement can dominate the schedule if you do not already own accelerators. DeployOpen plans and delivers most engagements as fixed-scope work, with scope, deliverables and timelines agreed in writing before work starts. Ask for a written plan that lists each milestone, the dependencies you must provide, and the acceptance criteria that close the work.
What does the work need from our own staff?
Your staff needs to provide decisions, access and knowledge of the workload, even when an implementation partner builds the system. Platform or infrastructure engineers should own the cloud accounts or data center capacity, network segmentation and identity integration. Security staff should approve the endpoint exposure model, key handling and logging retention. Application owners must supply representative prompts and the acceptance criteria that define a good answer for their use case. vLLM's security documentation states that node-to-node traffic in a multi-node deployment is insecure by default and must be isolated on a protected network, which is a decision your network team must confirm. Your staff will also own the operating runbook after handover, so plan for named owners on call for the inference service.
Can our own team run a self-hosted vLLM service without an implementation partner?
Yes, a capable platform team can deploy vLLM, since it is Apache-2.0 licensed open source and documented for running on NVIDIA CUDA, AMD ROCm and Intel XPU GPUs, as well as on CPUs. The harder parts are operational: securing endpoints, because the --api-key option does not cover every route, so you need a reverse proxy that allowlists only user-facing endpoints; scaling across GPUs and nodes with tensor and pipeline parallelism; and monitoring the Prometheus metrics at /metrics. Self-building also shifts the work of tracking releases to your team. Decide honestly whether you have engineers with GPU and Kubernetes experience who can carry this load for years. If not, a fixed-scope implementation followed by a support retainer may cost less than hiring for the gap.
How often does vLLM release new versions?
vLLM ships new minor releases about every two weeks. The project's GitHub releases show v0.28.0 on August 26, v0.29.0 on September 9, v0.30.0 on September 22 and v0.31.0 on October 5, 2026. That cadence matters for model pinning: a regular release train means you will need a repeatable process to test, stage and roll out upgrades, rather than treating the server as a fixed installation. Plan a staging environment that runs your acceptance prompts against each candidate version, and record which vLLM version and model weights were approved for production. You choose when to adopt a release, which is the control that managed services do not give you, but you also carry the work of keeping up with it. Confirm your upgrade window and security patch policy in writing before go-live.
Does self-hosting guarantee the model will give the same quality of answers?
No. Self-hosting gives you control over which model weights and serving software version run, but it does not by itself guarantee output quality, safety or consistency over time. Quality depends on the model you choose, the quantization and serving settings, the prompts and the data your application sends. An open-weight replacement for a Bedrock model may behave differently, so you need to measure it on your own prompts before cutting over. Pinning also means you keep a model version that you choose to retain, which can fall behind newer models, and that trade-off belongs in your risk register. Ask any provider to show the evaluation method they will use, the acceptance thresholds and the results on your workload before you accept the replacement.
Evidence that shows which model version served each request
A pinned open-weight model only removes forced migrations if you can also prove which version answered which request, and when. The cards below describe the records that connect a model version, a gateway alias, an upgrade decision and the traces that show the result. Auditors and certification bodies decide whether this evidence is sufficient; DeployOpen prepares the evidence but does not issue attestations.
Model and version manifest
A manifest lists each served model by its exact weights identifier, revision or checksum, quantization, tokenizer, serving image tag and vLLM version. Keep it in version control so every change is a reviewed commit. Check that the manifest matches what the running vLLM server reports, since a manifest that drifts from production proves nothing. Ask your team who may edit it and how edits are approved.
Gateway logs with alias-to-model mapping
Applications should call a stable alias, such as a team-facing model name, that the gateway resolves to a concrete model. Log the alias, the resolved model, the fallback path taken and the timestamp for every request. Without this mapping, a log line that says the application used a model name tells an auditor nothing about which weights produced the output. Confirm that the LiteLLM logging configuration writes these fields to the destination you retain.
Change records for each upgrade
Each model or serving change needs a record that names the requester, the reason, the test evidence, the approver and the rollout window. Link the record to the manifest commit so the before and after states are visible. Record rollbacks as separate events. Retaining this history is what lets you show that a version change was controlled rather than silent, and it matters most when a provider deprecation forced the change.
Validation results on your prompts
Store the results of running your own prompt set against each candidate and each pinned version, with the scoring method and the reviewer's sign-off. Keep the prompt set itself under version control, because results are meaningful only for the prompts they were run on. Record which failures were accepted and why. Ask your evaluation owner to confirm that the scoring rules were fixed before the results were seen.
Trace retention in Langfuse or Opik
Traces that include the model name, token counts, latency and evaluation scores can be stored in self-hosted Langfuse or Opik, both of which run on your own infrastructure. Set a retention period that matches your policy and confirm that deleting traces also removes the linked scores. Langfuse depends on PostgreSQL, ClickHouse, Redis or Valkey and S3-compatible storage, so the backup and restore of those stores belongs in the same evidence plan. Opik is Apache-2.0 licensed and can be self-hosted without a commercial license.
What changes for your team after you pin a model
Pinning an open-weight model moves version control from AWS to your team, and the work that Bedrock hides becomes yours on a recurring basis. Upgrades are the first item: vLLM ships new minor releases roughly every two weeks, so someone must decide which release to run, when to take it, and how to roll back a vllm serve deployment that misbehaves under production traffic. Model upgrades are a separate decision from engine upgrades, and each needs its own change record, owner and rollback plan.
Validation comes before every swap. Keep a regression set built from your own prompts, expected outputs and the guardrail checks your applications depend on, and run it against any candidate model or vLLM release before traffic moves. Capacity planning is the second recurring duty: someone must watch KV cache use, latency histograms and request counts exposed on the /metrics endpoint, and size GPU capacity for peak load and for a replacement node during maintenance. On-call covers the cluster itself, including GPU failures, node-to-node communication that vLLM's security docs describe as insecure by default without an isolated network, and the authentication gap around endpoints such as /metrics and /health.
These responsibilities carry recurring costs in staff time, monitoring and GPU capacity, and they continue after the first deployment. Your internal team can own them, or you can retain DeployOpen for ongoing support, upgrades and continuous testing. Retainers are scoped and agreed in writing, so ask for the upgrade cadence, validation coverage, on-call hours and response expectations to appear in that scope before work starts.
How DeployOpen deploys pinned open-weight models
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For Bedrock model end of life, that means scoping which models you must keep stable, building a pinned vLLM serving stack behind your own gateway, and handing over the runbooks your team needs to control every model version.
How we scope
- Inventory every Bedrock model ID in use and record its lifecycle status and access dates
- Agree in writing which workloads need a pinned version and which can move
- Confirm the target cloud accounts, data centers or air-gapped networks before work starts
- Define the outputs to test before any model is pinned or replaced
- Most engagements are fixed-scope, with deliverables and timelines agreed in advance
How we build
- Deploy vLLM with the model weights and versions you have approved and recorded
- Place the serving endpoints behind a reverse proxy that allowlists only user-facing routes
- Connect an OpenAI-compatible gateway so applications change configuration, not code
- Wire vLLM metrics at /metrics into your existing monitoring and alert on latency and KV cache use
- Test replacement outputs against your own prompts and document the results for review
How we hand over
- Document the pinned model identifiers, weight checksums and the procedure for changing them
- Provide runbooks for node-to-node isolation, key rotation and endpoint access control
- Record the version upgrade process, including a regression test set your team can rerun
- Walk your operators through the deployment so the team can run it without DeployOpen
How we support
- Ongoing support, upgrades and continuous testing are available as retainers
- Retainers can cover reviewing vLLM releases against your pinned configuration
- Ask any provider to confirm how model versions, backups and patches are handled in writing
- Compliance readiness work prepares systems and evidence, but independent auditors issue the assessment
