Esta es la Parte 2 de nuestra serie sobre cómo construir un flujo de trabajo de desarrollo con IA de nivel productivo. Lee la Parte 1: Por qué tu configuración de programación con IA acabará perjudicándote
La semana pasada hablamos de por qué la mayoría de las configuraciones de programación con IA se desmoronan sin hacer ruido: límites de contexto, herramientas dispersas, ausencia de memoria entre sesiones. Esta semana vamos a construir los cimientos que resuelven todo eso.
Empezamos con AWS Bedrock y Claude Code. No porque estén de moda, sino porque esta combinación concreta resuelve problemas con los que te toparás en cuanto intentes usar IA en algo que vaya más allá de un script de un solo archivo.
Por qué Bedrock en concreto
Puedes usar Claude directamente a través de la API de Anthropic. Funciona bien. Pero Bedrock te da tres cosas que importan enormemente en cuanto haces trabajo de verdad:
Almacenamiento en caché de prompts. Este es el gran punto. El almacenamiento en caché de prompts de Bedrock puede reducir los costes hasta en un 90 % y la latencia hasta en un 85 %. Si alguna vez has esperado 15 segundos a que Claude vuelva a leer todo el contexto de tu base de código en cada mensaje, entiendes por qué esto importa. Con la caché, ese contexto se almacena y se reutiliza. Tu segundo, tercer y quincuagésimo mensaje de una sesión hacen referencia al mismo contexto en caché en lugar de reprocesarlo desde cero.
En términos prácticos: una sesión en la que iteras sobre una funcionalidad compleja —enviando de 30 a 40 mensajes contra el mismo contexto de la base de código— pasa de costar varios dólares a costar céntimos. La mejora de latencia significa que obtienes respuestas en 2-3 segundos en lugar de 10-15. Esa es la diferencia entre un estado de flujo y uno de frustración.
Infraestructura que ya gestionas. Si tu equipo está en AWS (y estadísticamente, probablemente lo esté), Bedrock encaja en tus roles de IAM, configuraciones de VPC, logging de CloudWatch y facturación ya existentes. Sin relación con un proveedor aparte. Sin claves de API sueltas por ahí. Sin conciliación de facturación separada. Es simplemente otro servicio de AWS.
Flexibilidad de modelos sin recablear nada. Bedrock te da acceso a Claude Sonnet, Claude Haiku y otros modelos a través de la misma interfaz. Cuando necesitas un modelo más barato para tareas simples (linting, formateo, código repetitivo) y un modelo potente para decisiones de arquitectura, estás cambiando un parámetro, no cambiando de proveedor.
Las concesiones de coste y contexto que de verdad importan
Antes de configurar nada, seamos honestos sobre los números.
Sin caché: Claude Sonnet en Bedrock cuesta aproximadamente 3 $ por millón de tokens de entrada y 15 $ por millón de tokens de salida. Una sesión intensa de desarrollo en la que alimentas el contexto del proyecto repetidamente puede llegar a costar entre 5 y 15 $/día por desarrollador. Eso se acumula rápido en un equipo.
Con caché: esas mismas sesiones bajan a aproximadamente 0,50-2,00 $/día. Las lecturas de caché cuestan una fracción del procesamiento de entrada nueva. A lo largo de un mes, para un equipo de cinco ingenieros, estás ante la diferencia entre una factura de 1.500 $ y una de 200 $. Eso no es optimización: es la diferencia entre "podemos permitirnos usar esto" y "no podemos".
La concesión de la ventana de contexto es igual de importante. La ventana de contexto de 200K tokens de Claude es enorme, pero no es infinita. Necesitas una estrategia sobre qué entra en esa ventana y qué no. Lo cubriremos en profundidad en los artículos sobre CLAUDE.md y la capa de memoria (Semanas 3 y 4), pero la decisión de infraestructura importa ahora: el almacenamiento en caché de Bedrock hace económicamente viable usar ventanas de contexto grandes de forma agresiva, lo que significa que tu IA realmente entiende lo suficiente de tu base de código como para dar respuestas útiles.
Cómo configurarlo: pasos técnicos
Aquí está la configuración real. Esto asume que tienes una cuenta de AWS y familiaridad básica con la CLI.
Paso 1: habilitar el acceso a modelos de Bedrock
Bedrock no te da acceso a los modelos por defecto. Tienes que solicitarlo.
- Abre la consola de AWS y navega a Amazon Bedrock
- En la barra lateral izquierda, haz clic en Model access
- Haz clic en Manage model access
- Encuentra y habilita los modelos de Anthropic que necesites:
- Claude Sonnet 4 (tu caballo de batalla principal: buen razonamiento, buena velocidad)
- Claude Haiku 4 (rápido y barato: úsalo para tareas simples, mensajes de commit, consultas rápidas)
- Envía la solicitud. La aprobación suele ser instantánea en la mayoría de regiones, pero puede tardar hasta unos minutos.
La región importa. No todas las regiones admiten todos los modelos ni el almacenamiento en caché de prompts. A fecha de escribir esto, us-east-1 (Norte de Virginia) y us-west-2 (Oregón) tienen el soporte más amplio. Elige una de estas a menos que tengas una razón de cumplimiento normativo específica para no hacerlo.
Paso 2: configurar IAM Identity Center (SSO)
No crees claves de acceso de IAM de larga duración. No uses tus credenciales de root. Usa IAM Identity Center con SSO: es lo que AWS recomienda, y por buenas razones.
Las claves de acceso de larga duración son un riesgo. Quedan en archivos de configuración, se suben a repos por accidente y nunca caducan a menos que alguien recuerde rotarlas. El SSO te da credenciales temporales que caducan automáticamente, gestión centralizada de accesos y un registro de auditoría de quién usa qué.
Habilita IAM Identity Center (si aún no lo has hecho):
- Abre la consola de AWS y navega a IAM Identity Center
- Haz clic en Enable (esto debe hacerse en tu cuenta de gestión si usas AWS Organizations)
- Elige tu fuente de identidad: si ya usas Google Workspace, Okta, Azure AD o similar, conéctalo aquí. Si no, el directorio integrado funciona bien para equipos más pequeños.
Crea un conjunto de permisos para el acceso a Bedrock:
# Create a permission set with scoped Bedrock access # You can do this in the console under IAM Identity Center → Permission sets → Create # The inline policy should look like this: cat > bedrock-permission-set-policy.json << 'EOF' { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "bedrock:InvokeModel", "bedrock:InvokeModelWithResponseStream" ], "Resource": [ "arn:aws:bedrock:*::foundation-model/anthropic.claude-*" ] } ] } EOF
- En IAM Identity Center, ve a Permission sets → Create permission set
- Elige Custom permission set
- Añade la política en línea de arriba
- Ponle un nombre claro como
BedrockClaudeCodeAccess - Asígnalo a los usuarios o grupos relevantes para la cuenta de AWS donde Bedrock está habilitado
Configura la CLI de AWS para SSO:
# Configure your SSO profile aws configure sso # Follow the prompts: # SSO session name: baur-sso (or whatever makes sense) # SSO start URL: https://your-org.awsapps.com/start # SSO region: us-east-1 # SSO registration scopes: sso:account:access # This creates a named profile. Log in: aws sso login --profile your-profile-name
Esto te da credenciales temporales que se refrescan automáticamente. Sin claves que filtrar, sin rotaciones que olvidar, y si alguien deja el equipo, revocas el acceso en un solo lugar.
Por qué esto importa más allá de la seguridad: cuando incorporas nuevos desarrolladores (o nuevos ingenieros de cliente, en nuestro caso), el SSO significa "inicia sesión con tu cuenta de empresa" en lugar de "aquí tienes un CSV con claves de acceso, ponlas en tu perfil de shell y no las pierdas". Lo primero escala. Lo segundo se convierte en una pesadilla de gestión de credenciales para cuando llegas al quinto desarrollador.
Paso 3: instalar y configurar Claude Code
# Install Claude Code npm install -g @anthropic-ai/claude-code # Configure it to use Bedrock with your SSO profile export CLAUDE_CODE_USE_BEDROCK=1 export AWS_PROFILE=your-profile-name export AWS_REGION=us-east-1
Para que persista, añade esto a tu perfil de shell (~/.zshrc, ~/.bashrc, etc.) o usa direnv para acotarlo por proyecto:
# In your project root, create .envrc echo 'export CLAUDE_CODE_USE_BEDROCK=1' >> .envrc echo 'export AWS_PROFILE=your-profile-name' >> .envrc echo 'export AWS_REGION=us-east-1' >> .envrc direnv allow
Cuando tu sesión de SSO caduque, simplemente ejecuta de nuevo aws sso login --profile your-profile-name. Sin claves que gestionar.
Paso 4: verificar la conexión
# Start Claude Code claude # In the Claude Code session, ask something simple: > What model are you running on and through what provider?
Claude debería confirmar que se ejecuta a través de Bedrock. Si obtienes errores de autenticación, asegúrate de que tu sesión de SSO está activa (aws sso login --profile your-profile-name) y vuelve a comprobar la configuración de tu conjunto de permisos y de la región.
Paso 5: habilitar el almacenamiento en caché de prompts
Aquí es donde la cosa se pone buena. El almacenamiento en caché de prompts en Bedrock funciona automáticamente para las solicitudes que califican: no necesitas activar ningún interruptor. Pero sí necesitas estructurar tu uso para beneficiarte de él.
La caché entra en acción cuando:
- Envías contexto repetido (prompts de sistema, archivos del proyecto, documentación) a lo largo de los mensajes de una sesión
- El contenido en caché alcanza el umbral mínimo de tokens (normalmente ~1.024 tokens para Sonnet, ~2.048 para contextos más grandes)
- Usas el mismo modelo en la misma región
Qué significa esto en la práctica con Claude Code: cuando inicias una sesión y Claude Code carga el contexto de tu proyecto (tu archivo CLAUDE.md, los archivos fuente relevantes, la documentación), ese contexto se guarda en caché en el primer mensaje. Cada mensaje posterior de esa sesión reutiliza la caché. Por eso las sesiones más largas y enfocadas son drásticamente más baratas que muchas cortas.
Para monitorizar tus tasas de aciertos de caché:
# Enable CloudWatch metrics for Bedrock # In the AWS Console: Bedrock → Settings → Enable model invocation logging # Or via CLI: aws bedrock put-model-invocation-logging-configuration \ --logging-config '{ "cloudWatchConfig": { "logGroupName": "/aws/bedrock/claude-code", "roleArn": "arn:aws:iam::<account-id>:role/BedrockLoggingRole", "largeDataDeliveryS3Config": { "bucketName": "your-bedrock-logs-bucket", "keyPrefix": "claude-code/" } } }'
Esto te da visibilidad sobre qué solicitudes están dando con la caché y cuáles no, algo crítico para entender tus costes reales.
Paso 6: configurar alertas de coste
Esto no es negociable. Los costes de IA pueden dispararse de forma inesperada, especialmente durante sprints intensos de desarrollo.
# Create a Bedrock-specific cost budget aws budgets create-budget \ --account-id <your-account-id> \ --budget '{ "BudgetName": "bedrock-claude-monthly", "BudgetLimit": {"Amount": "500", "Unit": "USD"}, "TimeUnit": "MONTHLY", "BudgetType": "COST", "CostFilters": { "Service": ["Amazon Bedrock"] } }' \ --notifications-with-subscribers '[ { "Notification": { "NotificationType": "ACTUAL", "ComparisonOperator": "GREATER_THAN", "Threshold": 80, "ThresholdType": "PERCENTAGE" }, "Subscribers": [ {"SubscriptionType": "EMAIL", "Address": "your-email@company.com"} ] } ]'
Fija el umbral en lo que tenga sentido para tu equipo. La idea es que te enteres de los sobrecostes por una alerta de presupuesto, no por tu factura mensual de AWS.
Qué consigues con esto
Al final de estos pasos, tienes:
- Claude Code ejecutándose a través de Bedrock con SSO y permisos correctamente acotados
- Almacenamiento en caché de prompts reduciendo automáticamente tus costes y tu latencia
- Logging de CloudWatch para que puedas ver qué está pasando
- Alertas de coste para que no te lleves sorpresas
Esta es la capa de infraestructura. Por sí sola no es emocionante. Pero absolutamente todo lo que construyamos en las próximas semanas —la configuración de CLAUDE.md, los sistemas de memoria, los flujos de trabajo multiagente— todo eso se ejecuta sobre estos cimientos.
Si los cimientos son lentos, caros o están mal protegidos, todo lo que hay encima hereda esos problemas. Hazlo bien ahora y el resto de la serie tratará de construir capacidades. Hazlo mal y el resto de la serie tratará de pelearte con tu propia infraestructura.
La próxima semana
Semana 3: CLAUDE.md — Enseñar a la IA cómo trabaja realmente tu equipo. El archivo de configuración que convierte a un asistente de IA genérico en uno que entiende tus decisiones de arquitectura, tus estándares de código y el contexto de tu proyecto. Aquí es donde las cosas empiezan a volverse genuinamente potentes.
En Baur Software, combinamos herramientas de IA como esta con ingenieros experimentados para ayudar a los equipos a entregar más rápido sin sacrificar la calidad. Si estás montando tu flujo de trabajo de desarrollo con IA y quieres saltarte la fase de prueba y error, hablemos.