Bedrock model IDs behind AppConfig flags: the swap gets cheaper, the approval gets thinner

The router is the easy part. The part worth arguing about is who ends up holding the switch. The walkthrough says it plainly: what each routing key means is decided by whoever controls the AppConfig deployment ^[4]. With the ID compiled into the function, changing the model that answers production traffic costs a code change and a review ^[2], and that review leaves names attached to the decision. Move the string into a hosted configuration version and the same decision becomes an API call by anyone holding deployment rights. AppConfig's numbered flag versions do tell you afterwards which model was live when ^[7], which settles forensics. It does not settle authorization.

The second thing the config cannot carry is compatibility. Each flag holds a single `model_id` string attribute and nothing else ^[9]. Bedrock's Converse API is what makes the swap mechanically possible at all ^[10], since it gives one call shape across the Anthropic, Amazon and Meta models, but a shared call shape is not shared behavior. Prompt structure and token budgets stay in the Lambda, written to whatever the least accommodating model behind a key can tolerate. Model access is a prerequisite too: the post requires Bedrock access enabled in advance for each model you plan to route to ^[15], which a config deployment cannot grant itself.

Rollback is where the honest gap sits. The author's pitch is instant rollback ^[5], and the mechanism is real: deployments go out through strategies, all-at-once in dev, gradual with automatic rollback in production, so a bad swap reverses the way it arrived ^[6]. But the trigger stated for wanting this is a model that misbehaves ^[2], and the flag document contains no per-key quality or latency field to detect that ^[16]. Whatever fires the rollback has to come from outside the configuration, and the walkthrough does not supply it. The revert path is fast; deciding to revert is still your problem.

One detail in the source argues the case better than the prose does. The exported Claude example is `us.anthropic.claude-haiku-4-5-20251001-v1:0` ^[11], an identifier with a calendar date inside it ^[17]. Any file that hardcodes strings like that is stale by construction, and new Claude, Nova and Llama versions land every few months while pricing moves underneath them ^[1]. That cadence is the test for the pattern. If you retarget a key several times a year, the second control plane pays for itself in avoided pipeline runs. If you have touched your model ID once since launch, you have added an AppConfig hierarchy, a flag document and a deployment step ^[13] to solve a problem that arrives annually, and you have moved a production decision out of the place where your team currently reads diffs.