Amazon Bedrock: el modelo en tu cuenta AWS
Por defecto, la llamada al modelo es lo único que Chronos no gobierna: Claude Code habla con api.anthropic.com con su propio login. Para una empresa con cuenta AWS eso deja cuatro huecos: el gasto queda fuera de tu acuerdo con AWS, el tráfico sale de tu región, nada llega a tu CloudTrail y tus Guardrails no aplican.
La organización puede publicar Amazon Bedrock como proveedor del modelo. El modelo del agente pasa a ejecutarse en tu propia cuenta:
- Tu factura. El gasto de modelo cae en tu acuerdo AWS, no en una factura aparte de Anthropic.
- Tu región. La inferencia va a
bedrock-runtime.<tu-región>.amazonaws.com, o a tu propio endpoint de PrivateLink. - Tu auditoría. Cada invocación lleva etiquetas con la organización, la identidad y la sesión de Chronos, así que CloudTrail cruza con el registro de auditoría de Chronos por sesión.
- Tus controles. Aplican tus Bedrock Guardrails, tu service tier y tus inference profiles.
El agente sigue sin tener jamás una credencial de AWS. Se le apunta a una dirección de loopback con una credencial de relleno; el broker descarta esa firma y re-firma con una credencial de corta duración emitida por sesión. De esa forma se siguen dos cosas: la sesión funciona incluso en un repositorio con egress = "loopback" (la salida la hace el daemon, no el agente sandboxeado) y la credencial se refresca a mitad de turno sin que el agente se entere.
Es Bedrock Runtime (inferencia). No es el producto "Bedrock Agents" de AWS: el agente lo pone Chronos. Y como Bedrock sirve modelos Claude, aplica solo a Claude Code: los otros cinco agentes conservan sus proveedores.
Configurarlo (administradores)
Se hace una vez, desde el panel de la empresa.
1. Despliega el rol en tu cuenta AWS:
aws cloudformation deploy \
--template-file docs/chronos-bedrock-role.yaml \
--stack-name chronos-bedrock-role \
--capabilities CAPABILITY_NAMED_IAM \
--parameter-overrides PanelPrincipalArn=arn:aws:iam::<cuenta-panel>:user/chronos-panel \
ExternalId=<tu-external-id>
Necesita su propio rol. Si ya desplegaste chronos-agents para el conector de AWS, aquel lleva ReadOnlyAccess, y bedrock:InvokeModel no es una acción de lectura: reutilizarlo no concede nada.
Si creas el rol a mano (Terraform, la consola), necesita exactamente cuatro acciones: bedrock:InvokeModel, bedrock:InvokeModelWithResponseStream, bedrock:ListInferenceProfiles y bedrock:GetInferenceProfile, con una política de confianza que permita sts:AssumeRole y sts:TagSession desde el principal del panel, condicionada a tu ExternalId. TagSession es lo que hace funcionar la atribución en CloudTrail: sin él, la emisión falla. Acota la lista de recursos a inference profiles concretos si quieres restringir qué modelos puede invocar una sesión.
Lo crees como lo crees, el panel aplica encima una session policy de solo-inferencia al emitir la credencial: el techo se impone dos veces.
2. Dale identidad AWS al panel (AWS_ACCESS_KEY_ID / AWS_SECRET_ACCESS_KEY en el entorno del proceso del panel). Sin ella, la emisión falla en cerrado y queda auditada.
3. Configura la entrada sembrada. En el panel, abre la entrada Amazon Bedrock (viene de serie, inerte) y usa set token. Pega:
{
"role_arn": "arn:aws:iam::123456789012:role/chronos-bedrock",
"external_id": "<tu-external-id>",
"region": "eu-west-1",
"model_opus": "eu.anthropic.claude-opus-5",
"model_sonnet": "eu.anthropic.claude-sonnet-4-6"
}
El ExternalId se guarda en modo solo-escritura; el resto es política no secreta. Fija al menos un modelo. Chronos rechaza un proveedor sin ningún pin: los alias sin fijar resuelven a valores por defecto que tu cuenta puede no tener habilitados y, como Opus se factura por encima de Sonnet, a un precio que la organización no eligió.
No hay paso 4. El siguiente turno de cualquier sesión de la organización corre sobre Bedrock.
Referencia de configuración
| Clave | Significado |
|---|---|
role_arn |
El rol que asume el panel. Obligatorio. |
external_id |
Guarda anti confused-deputy, solo-escritura. |
region |
La región AWS que sirve Bedrock. Obligatoria. |
model_opus, model_sonnet, model_haiku |
A qué resuelve cada alias. Al menos uno. |
region_prefix |
Prefijo del inference profile cross-region: us, eu, apac, jp, au, global. |
service_tier |
default, flex o priority. |
guardrail_id, guardrail_version |
Bedrock Guardrails aplicados a cada llamada. |
endpoint |
Un endpoint PrivateLink delante de Bedrock Runtime. Origen https sin ruta. |
Los ids de modelo son específicos de tu cuenta: un inference profile cross-region como eu.anthropic.claude-opus-5, o el ARN de un application inference profile si enrutas por el tuyo.
Qué ve el desarrollador
Nada que configurar y nada que elegir. El selector de modelo mantiene su forma, con dos diferencias: los modelos listados bajo Claude Code son los que tu cuenta tiene de verdad y el grupo lleva una insignia con la cuenta y la región donde corre el turno.
Qué cuenta sirve el modelo es una decisión de organización, así que a propósito no es una opción por turno. Un desarrollador no puede apuntar una sesión a un proveedor que la organización no ha publicado: el mismo principio que gobierna qué MCP alcanza una sesión. Un .env del proyecto tampoco lo puede pisar: tu ANTHROPIC_API_KEY sigue llegando a tu servidor de desarrollo como siempre, pero el agente la ignora porque corre sobre Bedrock.
Si algo no está configurado
Todos los caminos de fallo hacen lo mismo: descartar el proveedor, dejarlo en el registro de auditoría y dejar que la sesión corra con el proveedor propio del agente. Un rol que falta, un panel sin identidad AWS, una denegación de STS, un pin de modelo ausente o una región mal escrita se comportan igual: nunca te queda una sesión a medio configurar que falla en cada turno.
Límites
- Solo Claude Code. Los demás agentes tienen sus propios proveedores.
- Un proveedor por organización. Ejecutar Anthropic y Bedrock a la vez y elegir por sesión no está soportado hoy.
- El panel es obligatorio. Sin él no hay credencial que emitir, y el sandbox impide al agente leer
~/.aws, así que un perfil AWS local no puede sustituirlo.