Private inference boundaries
Move inference without overlooking the embedding store
Changing the answer model's endpoint leaves ingestion, retrieval and diagnostics untouched unless the migration explicitly includes them. Review the entire dependency set.
In this article
Separate the services being moved
List the answer model, embedding model, vector store, source storage, preprocessing and evaluation services. Identify which are changing and which remain in place. A new inference region does not automatically relocate previously stored embeddings or source passages.
Record the reason for the move and the requirements each component must satisfy. Performance, cost and data-handling goals can lead to different migration work. Keep the goal concrete enough to verify.
Do not assume embeddings are outside the data review because they are numeric. Their treatment should follow the organisation's data classification and the service's actual access and retention controls.
Check compatibility before rebuilding
If the embedding model changes, verify the vector dimensions and retrieval compatibility. Existing vectors generally cannot be treated as interchangeable with vectors produced by a different embedding configuration without evidence.
Plan a new index or controlled rebuild where needed, retaining source identity and versions. Account for updates and deletions that occur during the migration. A copied snapshot can already be stale before activation.
Keep the answer-model migration separate from retrieval changes where practical. This makes quality differences easier to diagnose and allows a more focused rollback.
Verify every new route
Test network routing and identities from the deployed runtime. Include ingestion workers and background evaluators, which may run in different environments from the main application.
Review logging and fallback settings on the new services. A destination change can reset defaults or introduce diagnostic copies that did not exist in the old path.
Use synthetic marker requests and source documents to confirm where payloads and derived records appear. Compare the result with the migration inventory before moving ordinary traffic.
Retire old copies deliberately
After activation and validation, identify old indexes, stored files, cached answers and diagnostic exports that remain. Apply the documented retention and removal process rather than assuming unused infrastructure contains no data.
Keep the old route available only for the agreed recovery window and required tasks. Confirm that rollback would still meet current access and source-freshness requirements before relying on it.
Record the final dependency set and verified configuration. The migration is complete when the system's actual data path matches the intended boundary, including the supporting stores that do not appear in the final model call.
Primary sources
AWS: Bedrock private endpointsMicrosoft Learn: index updates and rebuildsAWS: model invocation loggingReferences checked 11 September 2026.