Saltar a contenido

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.