Arquitectura Azure — Módulo 6: estado y datos del agente

Tercera y última traducción del reparto por forma de acceso: cada dato en el almacén cuya forma de consulta coincide con la suya, objetos con puntero, y el historial de sesiones como el honeypot que exige PII enmascarada, retención y acceso mínimo desde el día uno. Las casas de Azure, con dos rasgos propios que mueven decisiones.

Dato del agente	En AWS	En GCP	En Azure
Sesiones / estado	DynamoDB	Firestore	Cosmos DB (+ TTL)
Negocio relacional	Aurora	Cloud SQL	Azure Database for PostgreSQL
Vectores	pgvector / OpenSearch / S3 Vectors	pgvector / Vector Search	pgvector / Cosmos / AI Search
Objetos	S3	GCS	Blob Storage
Caché caliente	ElastiCache	Memorystore	Azure Managed Redis
Analítica fría	(secundario)	BigQuery	Fabric / Synapse (mención)

La tesis del módulo

Dos rasgos definen el mapa Azure: Cosmos DB es multi-modelo y trae búsqueda vectorial integrada — la sesión del agente y sus embeddings pueden vivir en la misma base —, y Azure AI Search no es “el OpenSearch de Azure” sino algo más ambicioso: el buscador híbrido (vector + texto + semántica) diseñado como pieza de RAG, que en el módulo 9 aparecerá como la fuente de conocimiento oficial de los agentes de Foundry. El reparto no cambia; cambia cuántos roles puede absorber cada casa — y la disciplina de no dejar que una absorba todos.

Cosmos DB: la sesión multi-modelo

Cosmos DB juega el rol de DynamoDB/Firestore — sesiones e historial serverless, latencia de milisegundos, TTL nativo (la política de retención del honeypot, incluida) — con dos particularidades:

• Multi-modelo: su API principal es de documentos (el pariente de Firestore, con consultas SQL-like sobre JSON), pero habla también otros protocolos (MongoDB, Cassandra, Gremlin). Para la plataforma: documentos y punto — la flexibilidad multi-API es para migraciones, no una invitación a la exotización.
• Vectores integrados: Cosmos indexa embeddings junto a los documentos — la sesión del cliente y el vector de su última consulta en el mismo registro, consultables juntos. Para el caso “buscar en el historial de conversaciones por similitud” (memoria de largo plazo del agente), es la opción de menor fricción: cero piezas nuevas, cero sincronización entre bases.

La decisión vectorial de Azure queda entonces en tres opciones con la lógica de la serie: pgvector en Azure Database for PostgreSQL (si el volumen es moderado y ya tienes Postgres — el punto de partida sano de siempre), Cosmos (si los vectores viven naturalmente junto a las sesiones/documentos que ya están ahí), y Azure AI Search cuando el retrieval es el producto — que merece su propia sección.

Azure AI Search: el buscador que es pieza de RAG

Azure AI Search es el índice de búsqueda administrado con la tríada completa: vectorial + texto completo (BM25) + híbrida con re-ranking semántico — el retrieval híbrido que el curso de RAG enseña a valorar, como servicio. Dos lecturas de arquitectura:

• Como vector store de producción, es el análogo de OpenSearch/Vertex Vector Search: se gradúa hacia él con métricas cuando pgvector queda corto — misma regla, tercera nube.
• Como pieza del ecosistema: AI Search es el camino oficial de grounding del stack de agentes de Microsoft (el módulo 9 lo mostrará como fuente de conocimiento de Foundry) y trae integración de ingesta con Blob Storage (indexar el data lake de documentos con pipeline administrado). Si tu plataforma va a usar los agentes administrados de Azure, elegir AI Search como índice alinea las piezas; si tu RAG es artesanal y fino, la evaluación es la de cualquier motor — contra tus evals, no contra el folleto.

El resto del mapa se traduce sin ceremonia: Blob Storage es el S3 de esta casa (objetos, punteros, la regla eterna), Azure Managed Redis — el sucesor de Azure Cache for Redis, cuyos niveles se retiran entre marzo de 2027 y septiembre de 2028, así que los diseños nuevos no nacen en el servicio saliente — el caché caliente y las claves de idempotencia, y la analítica fría vive en el mundo Fabric/Synapse — que existe y es serio, pero no tiene el rol protagónico-integrado que BigQuery jugaba en GCP: el JOIN de costo-por-tarea del módulo 8 se armará con las exportaciones de Cost Management, con una pieza más de plomería que en la nube vecina.

     EL MAPA DE DATOS DE LA PLATAFORMA (AZURE)

            ┌─────────────┐
            │   agente    │
            └──────┬──────┘
                   │ cada dato a su almacén
     ┌──────────┬──┴───────┬──────────┐
     ▼          ▼          ▼          ▼
 ┌────────┐ ┌────────┐ ┌────────┐ ┌────────┐
 │ Cosmos │ │Postgres│ │ Redis  │ │  Blob  │
 │sesiones│ │negocio+│ │ caché  │ │objetos │
 │+vector │ │pgvector│ │caliente│ │baratos │
 │ (+TTL) │ └────────┘ └────────┘ └───┬────┘
 └────────┘                           │ indexa
                                      ▼
                              ┌────────────┐
                              │ AI Search  │ híbrido
                              │ (RAG/      │ vector+
                              │ grounding) │ BM25
                              └────────────┘

Ojo — el honeypot habla todos los idiomas: que Cosmos guarde sesiones y vectores y documentos multiplica lo que concentra — el historial con embeddings de todo lo conversado es más honeypot, no menos. Las tres decisiones del día uno (PII enmascarada antes de persistir, TTL como política escrita, acceso por managed identity mínimo) más el cifrado con llaves propias del módulo 10 no se relajan porque la base sea cómoda. La comodidad de guardar es exactamente lo que la política de retención existe para contrapesar.

Errores comunes

• Cosmos para todo porque puede. Multi-modelo y con vectores no significa cola, ni analítica, ni relacional de reportes. El reparto por forma de acceso sobrevive a la base más versátil de la serie.
• AI Search por defecto para vectores. El mismo salto reflejo de OpenSearch/Vector Search: pgvector primero si hay Postgres y el volumen es moderado; la graduación pide métricas.
• Ignorar la alineación con Foundry. Si el módulo 9 está en tu horizonte, el índice de grounding oficial es AI Search — elegir otra pieza para el mismo rol es comprar una integración artesanal evitable. La decisión vectorial mira el ecosistema, no solo el benchmark.
• Objetos en la base, tercera nube. El PDF va a Blob; Cosmos y Postgres guardan punteros. La regla no envejece.
• Buscar “el BigQuery de Azure” y frustrarse. Fabric/Synapse cubren la analítica con otra forma e integración. El diseño FinOps del módulo 8 lo asume: exportaciones + su almacén, una pieza más que en GCP.
• Relajar el honeypot por comodidad. TTL, PII y acceso mínimo se deciden al crear el contenedor de sesiones — la versatilidad de Cosmos no es una excepción a la política sino su mejor argumento.

La frase para llevarse

“Cosmos te deja guardar la sesión con sus vectores y AI Search te da el retrieval híbrido como servicio — pero el reparto por forma de acceso no se negocia con ninguna base versátil, y el historial con embeddings es más honeypot que nunca: TTL, PII enmascarada y acceso mínimo, escritos el día uno.”

Qué viene

Módulo 7: el LLM gateway y Microsoft Foundry. La carta fuerte de Azure: OpenAI como inquilino de primera parte — GPT servido con contratos, red privada y compliance de Azure — junto al catálogo de Foundry Models, y el gateway con un protagonista inesperado: API Management con políticas GenAI (límites de tokens, balanceo entre despliegues) como el proxy semi-administrado que las otras nubes no traen.

Material relacionado

• Módulo 5: integración — Service Bus y eventos
• Módulo 7: el LLM gateway y Foundry
• Curso de AWS — Módulo 6: estado y datos
• Curso de GCP — Módulo 6: estado y datos
• RAG a fondo — Módulo 1: por qué RAG
• Glosario de Arquitectura Azure para Agentes de IA