Skip to lesson

AWSAWS Certified Generative AI Developer - Professional2026-101.2 Select and configure FMs

Replace retiring models before access disappears

Completed by the knowledge check

Learning objective

Plan model retirement and replacement when versions or providers become unavailable. Treat continued model access as a dependency with a migration plan, not as an indefinite property of a working deployment.

Core idea

Retirement is a planned dependency change. An outage fallback handles an immediate execution failure; a replacement program establishes that another model can serve the task before the old one disappears. Waiting for failed invocations leaves no time to validate behavior, permissions, capacity, or recovery.

Maintain an inventory of exact model dependencies and a tested replacement path for each important task. Include inactive recovery accounts and fallback routes. A production model can still work while a newly created environment is no longer eligible to adopt it.

How it works

Track the applicable lifecycle policy

Amazon Bedrock exposes modelLifecycle through GetFoundationModel and ListFoundationModels. The states are Active, Legacy, and End-of-Life (EOL). Poll the relevant regional inventory through a controlled dependency-review process, and compare it with the model cards and retirement documentation rather than relying only on a remembered announcement.

AWS changed the policy boundary for models launched on or after September 7, 2026. Those models use model-card-specific minimum-availability and Legacy terms, including documented provider exceptions. Models launched before that date use the separate Model lifecycle (Legacy) policy. Do not apply the earlier general minimum-availability period to every later release.

Legacy limits matter before EOL: new customers cannot adopt the model, existing customers can lose access after 15 days of inactivity, and new Provisioned Throughput is unavailable. Under the earlier policy, lifecycle state can differ by Region. Record the policy applicable to the exact model and its regional status. EOL does not trigger an automatic migration.

Under the policy for models launched before September 7, 2026, models with EOL dates after February 1, 2026 enter public extended access after at least 3 months in Legacy. Expect higher provider-set pricing during that phase. Include the extended-access date and cost change in the migration deadline rather than budgeting only against final loss of access.

Inventory direct and indirect dependencies

For every task, record the exact model ID, source Region, inference profile or deployment resource, application adapter, prompt version, and required output capabilities. Include primary routes, fallback routes, experiments, and seldom-used recovery paths. A search through primary application code alone can miss a target stored in configuration.

Use the routing configuration boundary from 1.2.3 to make these dependencies discoverable. Review each AppConfig task mapping and record the configuration version. For hosted custom models, review the release package and base-model or adapter dependencies from 1.2.7. An artifact you control has a different lifecycle from a managed API you only invoke.

Bedrock customized models also inherit restrictions when their foundation model becomes Legacy: no new fine-tuning jobs or Provisioned Throughput endpoints, although existing on-demand deployments and Provisioned Throughput endpoints created before Legacy can continue. Include these constraints when planning another customization release.

CloudWatch’s LegacyModelInvocations provides a concrete Bedrock runtime signal for use of Legacy models. Pair it with the inventory: no recent invocations does not prove that a model is irrelevant, because a fallback or disaster-recovery route might intentionally be quiet. Usage measurement identifies traffic; configuration review identifies latent dependencies.

Assign an owner and a replacement deadline for each affected task. Work backward from the loss-of-access date through evaluation, approval, staged rollout, and a contingency margin. The deadline is your release policy, not a new AWS lifecycle guarantee.

Validate the replacement as a task configuration

Build a replacement shortlist with the same hard gates as 1.2.1. Check modality, context fit, regional eligibility, permitted processing locations, and capacity. A later version in the same family is still a different candidate. Another provider can also require a different adapter or interpretation of inference settings.

Benchmark the complete replacement configuration using the held-out dataset and operating envelope from 1.2.2. Include failure handling, abstention, tool behavior where relevant, and response validation. A replacement that answers ordinary prompts more elegantly can still fail the application’s consequential slice.

Retest prompts and validators deliberately. Do not update only the model ID and assume compatibility because the Converse request still parses. A stable API provides interface consistency; it does not guarantee unchanged outputs, costs, tokenization, or semantic behavior.

Embedding-model retirement requires an additional compatibility decision. The query and indexed vectors must remain in a compatible representation. Plan regeneration and validation of the affected index when changing embedding space rather than routing queries from the replacement to an unrelated old index. Detailed embedding and vector-store remediation belongs to 5.2.5.

Cut over with a realistic return path

Promote the approved replacement gradually through the mechanism from 1.2.8. Record the model and routing versions on both sides of the change. Keep the former configuration only for the period in which its target remains eligible and available; a rollback plan has an expiration date when it depends on a retiring API.

Prepare a contingency that does not require the retired model. That might be another evaluated target or a reduced task with an explicit unavailable or handoff result. A fallback chain containing two IDs that share the same retirement event is not an independent replacement plan.

After cutover, use runtime metrics and configuration inspection to find residual dependencies. Remove the old target from scheduled work, experiments, fallback plans, and recovery instructions. Keep the evaluation and decision evidence even after live routes have moved away from the version.

Test the recovery environment with the replacement before calling migration complete. Its identity, Region, quotas, and processing boundaries can differ from production. An existing-account invocation is not evidence that a fresh recovery account can use the same Legacy model.

Key distinctions and trade-offs

Retirement versus transient outage: Retirement removes a planned dependency. An outage interrupts an otherwise eligible one. The former needs migration; the latter uses bounded recovery.

API compatibility versus behavioral compatibility: A replacement can accept the same request schema while changing answer quality, stop behavior, or token use.

Production access versus recovery eligibility: Continued access in a busy account does not establish adoption rights or availability elsewhere.

Migrating early creates evaluation and release work while the old path still functions. Migrating late reduces that overlap but consumes the margin needed to discover regressions. Keep a validated replacement ready before loss of access makes the change compulsory.

Architecture / decision scenario

A policy assistant uses a Legacy model in production and lists that same model as its disaster-recovery target. The team sees successful daily invocations and assumes the dependency is safe until the final EOL date.

The inventory review identifies a newly provisioned recovery account and an inactive test route. You evaluate an Active replacement across the full task dataset, verify its permitted inference path, and stage the AppConfig routing change. Production traffic moves before the retirement deadline.

LegacyModelInvocations and configuration review then reveal a forgotten batch route still using the former target. You migrate that route and exercise recovery using the replacement. The old model remains historical evidence rather than the last remaining recovery mechanism.

Common exam traps

  • Applying one historical lifecycle period to every model launch.
  • Assuming Bedrock migrates application routes automatically at EOL.
  • Treating successful production traffic as proof of new-account eligibility.
  • Keeping a retiring version as the only fallback.
  • Changing an embedding model without reviewing index compatibility.
  • Calling migration complete while latent configuration routes remain unchanged.

What to remember

  • Track exact model versions, regional status, and their applicable policy.
  • Distinguish pre-September 7, 2026 policy from later model-card terms.
  • Combine modelLifecycle inventory with LegacyModelInvocations usage evidence.
  • Validate replacements as complete task configurations.
  • Remove hidden routes and test recovery before retirement forces the cutover.

Knowledge check

References