A fire-grant office must keep constituent letters in an approved AWS Region. Another Region has a newer foundation model. Which hosting choice is correct?

Data residency for constituent letters is a hard placement rule, not a soft preference that yields to model novelty. Keeping the letters in the approved AWS Region preserves the residency boundary the fire-grant office already committed to, even when that means forgoing a newer foundation model that is only available elsewhere. The residency obligation attaches to where the letters live and are processed; a hosting choice that relocates them for capability reasons still breaks that obligation.

Moving the letters to the newer-model Region fails because novelty of a foundation model does not outrank residency. Regional model coverage and data-residency constraints are separate GenAI hosting tradeoffs, and when they conflict the residency rule wins for regulated or policy-bound constituent content. Copying the letters to every Region fails because replication expands the processing footprint instead of preserving a single approved location; residency is not satisfied by making the data ubiquitous. Storing the letters on an intern laptop fails because a local device is not an approved Region control plane and removes the residency lock the office relies on for audit and policy evidence.

Exam caveat: foundation-model availability differs by Region, so teams routinely face a capability-versus-residency tension; the practitioner answer is to honor residency first, then select the best model that is available inside the allowed boundary. Operational check: confirm the Bedrock (or equivalent) model list for the approved Region, document which models are in scope there, and refuse any workflow that would move constituent letter content across that boundary for a newer SKU.