🌐AWS en la era de la IA: cómo integrar Bedrock en arquitecturas enterprise sin romper lo que ya existe.

🧠 Introducción

En un engagement reciente con un cliente financiero en LATAM.

Datos en RDS Oracle. Lógica de negocio en microservicios sobre ECS. Integraciones legacy por MQ. Todo on-premise hasta hace dos años, hoy parcialmente migrado a AWS.

La pregunta del CTO fue directa:

"¿Podemos agregar IA generativa sin rehacer todo?"

Mi respuesta también fue directa:

"Depende de dónde están tus datos y qué nivel de control necesitas sobre ellos."

Esa conversación me hizo ordenar los patrones que he visto funcionar — y los que he visto explotar — al integrar Bedrock en arquitecturas enterprise existentes.

🚀 Preámbulo: el nuevo driver que nadie modeló en el Well-Architected

Cuando diseñamos arquitecturas enterprise en AWS, los cinco pilares del WAF cubren casi todo.

Pero hay un driver que emergió con la IA generativa que no estaba en el modelo original:

La proximidad del modelo al dato.

En arquitecturas tradicionales, mover datos era costoso pero tolerable. En inferencia con LLMs, el problema se invierte: no se pueden mover todos los datos al modelo en cada request. Se necesita que el modelo opere cerca de los datos — o que los datos lleguen al modelo de forma controlada, privada y auditable.

Eso tiene implicancias arquitectónicas concretas que se desarrollan a continuación.

Pero antes de hablar de Amazon Bedrock, vale la pena visualizar una arquitectura de referencia. La idea no es reemplazar los microservicios existentes, sino incorporar capacidades de IA como un servicio adicional dentro de una arquitectura desacoplada basada en eventos.

• Los usuarios consumen la aplicación mediante API Gateway.
• Los microservicios continúan siendo responsables de la lógica de negocio.
• EventBridge desacopla la comunicación con los componentes de IA.
• Amazon Bedrock procesa prompts y utiliza modelos fundacionales.
• Knowledge Base aporta contexto empresarial mediante embeddings.
• Amazon S3 almacena documentos, imágenes y otros datos utilizados por la IA.

⚙️ El mapa de servicios Bedrock que importa en enterprise

Antes de los patrones, es necesario tener claro qué hace cada pieza:

Servicio	Rol en la arquitectura
Bedrock Runtime	Invocación de modelos fundacionales (inference endpoint)
Bedrock Knowledge Bases	RAG gestionado — conecta nuestros datos a los modelos
Bedrock Agents	Orquestación de tareas multi-step con herramientas externas
Bedrock Guardrails	Control de contenido, PII redaction, topic filtering
Bedrock Flows	Pipelines visuales de orquestación (serverless)

El error más común que veo: tratar Bedrock como una API de chat. No lo es. Es una plataforma de inferencia enterprise con controles de red, identidad y gobierno propios.

🔒 Patrón 1 — Acceso privado: Bedrock sin tocar internet

Este es el patrón que más preguntas genera en clientes enterprise, especialmente en banca y salud.

El problema: por defecto, cuando una Lambda o un ECS task llama a Bedrock, el tráfico sale por internet (o por NAT Gateway si estamos en la VPC). Eso es inaceptable para workloads con datos sensibles.

La solución: VPC Interface Endpoints vía AWS PrivateLink.

VPC (subnet privada)
  └── ENI (Interface Endpoint)
        └── com.amazonaws.<region>.bedrock-runtime
              └── Bedrock Runtime API [sin salida a internet]

Con esto:

• El tráfico nunca sale de la red de AWS.
• No hay NAT Gateway charges por inferencia.
• Se puede aplicar VPC Endpoint Policies para restringir qué IAM principals puedan invocar qué modelos.

💸 Trade-off de costo (no es gratis): se elimina el data processing del NAT Gateway, pero el Interface Endpoint tiene su propio cargo por hora por AZ + data processing por GB. Con un volumen alto de inferencia sale a favor; a un volumen bajo y con pocos endpoints, se debe sacar cuentas antes de asumir que PrivateLink siempre es más barato.

Punto técnico importante: Bedrock tiene dos endpoints separados que necesitamos configurar:

• bedrock → para operaciones del control plane (listar modelos, configurar Knowledge Bases).
• bedrock-runtime → para inferencia.

Y desde febrero de 2026, también está disponible PrivateLink para el endpoint bedrock-mantle (el nuevo motor de inferencia distribuida de AWS, compatible con OpenAI API spec). Esto es relevante si estamos migrando workloads que usan el SDK de OpenAI.

VPC Endpoint Policy mínima recomendada:

{
  "Statement": [{
    "Effect": "Allow",
    "Principal": {
      "AWS": "arn:aws:iam::123456789012:role/bedrock-inference-role"
    },
    "Action": "bedrock:InvokeModel",
    "Resource": "arn:aws:bedrock:us-east-1::foundation-model/anthropic.claude-*"
  }]
}

👉 Con esta política, solo el rol específico puede invocar modelos Claude. Cualquier otro principal — incluso con permisos IAM — es rechazado a nivel de endpoint.

⚠️ Caveat que rompe en producción: esta policy cubre invocación directa al foundation-model. Pero en producción casi todo invoca vía cross-region inference profiles (us.anthropic.claude-*, eu.anthropic.claude-*) para throughput y resiliencia. El profile necesita permiso sobre dos tipos de recurso: el ARN del profile y el del foundation model en la región de origen y en cada región destino del profile. Si solo permitimos foundation-model/*, la llamada vía profile nos devuelve un AccessDenied.

{
  "Effect": "Allow",
  "Action": "bedrock:InvokeModel",
  "Resource": [
    "arn:aws:bedrock:us-east-1:123456789012:inference-profile/us.anthropic.claude-*",
    "arn:aws:bedrock:us-east-1::foundation-model/anthropic.claude-*",
    "arn:aws:bedrock:us-east-2::foundation-model/anthropic.claude-*",
    "arn:aws:bedrock:us-west-2::foundation-model/anthropic.claude-*"
  ]
}

Son 4 ARNs = 1 inference profile + 3 foundation-models, uno por cada región a la que rutea el profile us (N. Virginia, Ohio, Oregon). Para global CRIS, además se suma el FM sin región: arn:aws:bedrock:::foundation-model/....

🧩 Patrón 2 — RAG privado: Knowledge Bases sin exponer nuestro datos

El patrón RAG (Retrieval-Augmented Generation) es el más usado para integrar IA con datos enterprise existentes. La pregunta arquitectónica clave es:

¿Dónde viven los embeddings y quién controla el acceso?

Con Bedrock Knowledge Bases:

S3 (datos source) 
  → Bedrock Knowledge Bases (embedding + vector store)
    → OpenSearch Serverless (índice vectorial, en tu cuenta)
      → Bedrock Runtime (retrieval + inferencia)
        → Tu aplicación

Lo que importa para enterprise:

• Los datos nunca salen de la cuenta AWS.
• El modelo fundacional no se re-entrena con los datos propios (Bedrock lo garantiza contractualmente).
• El vector store (OpenSearch Serverless) es accesible de forma privada vía VPC endpoint, con acceso controlado por data access policies + IAM.
• Se puede aplicar metadata filtering para segmentar qué datos ve cada usuario o rol.

Antipatrón frecuente: indexar todo el lake en el vector store sin segmentación.
Resultado: el modelo responde con información de un tenant usando contexto de otro. Necesitamos filtros por tenant_id, classification_level o lo que corresponda a nuestro modelo de datos.

🛡️ Patrón 3 — Guardrails como capa de control transversal

Bedrock Guardrails no es solo un filtro de contenido. En enterprise, es el mecanismo de gobierno de IA.

Lo que hace:

• Content filtering: bloquea hasta el 88% de contenido dañino según AWS.
• PII redaction: enmascara datos sensibles en prompts y respuestas.
• Topic denial: define temas que el modelo no puede responder (ej: asesoría legal o médica).
• Prompt attack detection: protección contra jailbreaks e inyecciones.
• Grounding checks: detecta alucinaciones comparando contra contexto conocido.

Lo que cambió en 2025 y es crítico para enterprise:

Desde marzo de 2025, Guardrails soporta IAM policy-based enforcement. Esto significa que se puede configurar una condición IAM (bedrock:GuardrailIdentifier) que rechaza cualquier llamada a InvokeModel que no incluya un guardrail. Ojo con el matiz: IAM solo bloquea la ausencia del guardrail — la app igual tiene que pasarlo en cada llamada; lo que se gana es que ningún equipo pueda invocar el modelo "pelado".

{
  "Condition": {
    "StringEquals": {
      "bedrock:GuardrailIdentifier": "arn:aws:bedrock:us-east-1:123456789012:guardrail/abc123"
    }
  }
}

En la práctica, se puede forzar a nivel IAM que toda invocación pase por un guardrail vía SCP + condición. Para un ambiente multi-cuenta (que es el estándar enterprise), esto es el equivalente al aws:PrincipalOrgID condition pero para gobierno de IA.

🔄 Actualización (abril 2026): enforcement nativo cross-account

El enfoque anterior funciona, pero tiene un techo: depende de que la app pase el guardrail en cada llamada. Desde abril de 2026, con la disponibilidad general de los cross-account safeguards, se puede especificar un guardrail en una nueva Amazon Bedrock policy dentro de la cuenta de management de la organización, que enforcea automáticamente los safeguards configurados en todas las entidades miembro para cada invocación de modelo en Bedrock.

La diferencia arquitectónica es la clave: cualquier llamada de inferencia en esas cuentas pasa por los filtros centralizados sin tocar la configuración de cada cuenta, y sin que la app pase nada — las cuentas miembro no pueden sobreescribirlo. El guardrail deja de ser una responsabilidad de la aplicación y pasa a ser un baseline de seguridad inmutable, como un SCP (técnicamente es un tipo de política declarativa nuevo en Organizations, no un SCP, pero hereda igual).

{
  "bedrock": {
    "guardrail_inference": {
      "us-east-1": {
        "config_1": {
          "identifier": {
            "@@assign": "arn:aws:bedrock:us-east-1:111122223333:guardrail/abc123:1"
          },
          "selective_content_guarding": {
            "messages": { "@@assign": "comprehensive" }
          },
          "model_enforcement": {
            "included_models": { "@@assign": ["ALL"] },
            "excluded_models": { "@@assign": ["amazon.titan-embed-text-v2:0"] }
          }
        }
      }
    }
  }
}

Dos cosas que no podemos ignorar antes de llevarlo a producción:

ARN inválido = outage. Un ARN incorrecto o inválido en la policy no falla de forma elegante: causa violaciones de política y bloquea el uso de los modelos para inferencia en las cuentas afectadas. Tratamos el ARN del guardrail como infra config: versionado, peer-reviewed, probado en una OU de no-prod antes de tocar producción.

comprehensive es el único default sensato en regulado. El modo comprehensive evalúa todo el contenido sin importar cómo lo taggee la app; selective confía en el tagging del caller. En banca o salud, selective es una optimización de performance, no un punto de partida.

💸 Patrón 4 — Control de costos de inferencia

Este es el antipatrón que más explota en producción y menos se habla en los blogs de arquitectura.

El costo de Bedrock es por token (input + output). En arquitecturas enterprise sin control, el consumo puede crecer exponencialmente por tres razones:

1. Contextos sin límite: prompts que incluyen todo el historial de conversación sin truncar.
2. RAG sin relevance threshold: recuperar chunks irrelevantes que agrandan el prompt sin aportar calidad.
3. Modelos sobredimensionados: usar Claude Opus para tasks que Claude Haiku resuelve igual.

Decisión de modelo por tipo de tarea:

Task	Modelo recomendado	Justificación
Clasificación, routing, extracción simple	Claude Haiku / Nova Micro	Latencia baja, costo mínimo
RAG, Q&A sobre documentos	Claude Sonnet / Nova Lite	Balance calidad/costo
Razonamiento complejo, análisis legal/financiero	Claude Opus / Nova Pro	Justifica el costo por la complejidad

Modelos vigentes a junio 2026.

Control arquitectónico: no debemos exponer el modelo directamente a la aplicación. Se debe interponer una capa de abstracción (un servicio interno o una Step Function) que:

• Seleccione el modelo según el tipo de request.
• Aplique límites de tokens por usuario/tenant.
• Registre consumo en CloudWatch para chargebacks internos.

🔁 Patrón 5 — Desacoplamiento: la AI Layer como servicio interno

El error de acoplamiento es el más difícil de corregir después.

El AI Gateway centraliza las responsabilidades transversales. La línea punteada roja muestra el antipatrón: aplicación llamando Bedrock directamente, sin gobernanza.

❌ Antipatrón:
App → Bedrock (directo, hardcodeado)

✅ Patrón correcto:
App → AI Gateway (interno) → Bedrock
                ↑
         [routing, auth, logging, cost control, fallback]

El AI Gateway interno puede ser tan simple como una Lambda con API Gateway, o tan complejo como un servicio ECS dedicado. Lo importante es que centraliza:

• Autenticación: quién puede invocar IA y con qué modelo.
• Logging: cada request/response auditado en S3 (requerimiento regulatorio en banca).
• Fallback: si Bedrock throttlea, ¿qué pasa? ¿error 500 o respuesta degradada?
• Observabilidad: latencia de inferencia, tokens consumidos, tasa de rechazo por guardrails.

AI Gateway sigue aportando valor aunque contemos con este enforcement nativo — el gateway nos da routing, cost control, fallback y logging que el org policy no cubre.

Sin esta capa, cuando el CTO pregunte "¿cuánto nos costó la IA este mes por área de negocio?" — no vamos a tener respuesta.

🧠 Insight clave (nivel arquitecto)

La integración de Bedrock en enterprise no es un problema de IA. Es un problema de arquitectura de red, identidad y gobierno — los mismos que ya se resolvieron para otros servicios AWS.

La diferencia es que los errores en IA tienen dos dimensiones nuevas:

• Costos que escalan con el uso (no con la infraestructura).
• Riesgos de compliance si los datos sensibles tocan el modelo sin control.

Tratar Bedrock como otro servicio managed de AWS — con los mismos patrones de VPC, IAM, logging y abstracción de capas — es exactamente el enfoque correcto.

🌎 Antipatrones consolidados

❌ AI washing: integrar Bedrock sin caso de uso medible. Si no podemos definir una métrica de éxito antes de construir, no construyamos.

❌ Inferencia acoplada: llamar Bedrock directamente desde la app sin abstracción. Imposible de gobernar, imposible de migrar de modelo.

❌ RAG sin segmentación: todos los datos en el mismo índice vectorial. Riesgo de privacidad entre tenants o clasificaciones.

❌ Sin observabilidad de modelos: métricas de aplicación sin métricas de inferencia. No sabemos si el modelo está respondiendo bien, solo si el endpoint está up.

❌ Modelo único para todo: el mismo modelo para clasificación simple y análisis complejo. El costo de inferencia explota sin ganancia de calidad.

🔧 Conclusión

La pregunta que más escucho es: "¿Podemos agregar IA a nuestra arquitectura existente?"

La respuesta correcta no es técnica. Es arquitectónica:

✔️ ¿Dónde estan tus datos y quién controla el acceso?
✔️ ¿Existe una capa de abstracción que centralice gobierno y costos?
✔️ ¿La red permite inferencia privada sin exponer datos sensibles a internet?

Las empresas que integren IA correctamente no serán las que usen los modelos más potentes. Serán las que resuelvan primero el problema de datos, red y gobierno — y construyan la capa de inferencia encima de eso.

Happy learning on AWS 🚀