Para un agente de IA en AWS que necesita consultar datos repartidos entre servicios cloud y sistemas locales, el ejemplo de Denodo combina las fuentes en tiempo de consulta; el de AtScale resuelve cada consulta en un solo motor de almacén de datos y replica los datos operativos antes. AWS publicó los dos tutoriales el 20 de octubre de 2026. La topología que ya tenga tu equipo es la pista principal para elegir entre estos patrones.
La frontera de consulta marca la diferencia
En el tutorial de Denodo, Virtual DataPort planifica consultas federadas sobre Amazon Aurora, Amazon Redshift y una base de datos PostgreSQL local, y combina los resultados. Así, el agente puede consultar esas fuentes distribuidas sin que el ejemplo requiera una tabla consolidada mediante ETL.
El tutorial de AtScale plantea otro recorrido: los datos analíticos de Customer 360 están en Amazon Redshift Serverless y cada consulta se resuelve en un solo motor de almacén. Los datos operativos de Aurora se replican previamente al almacén. Para un equipo que necesita combinar fuentes en vivo, los límites del ejemplo de Denodo encajan mejor; el patrón de AtScale se ajusta a una arquitectura que ya consolida los datos analíticos y mantiene esa réplica.
| Dimensión | Ejemplo de Denodo | Ejemplo de AtScale |
| Ejecución de consultas | Virtual DataPort federa Amazon Aurora, Amazon Redshift y PostgreSQL local en tiempo de consulta. | Cada consulta se resuelve en un motor; el ejemplo usa Amazon Redshift Serverless y replica previamente datos operativos desde Aurora. |
| Modelo semántico | Vistas base, derivadas y de métricas en Virtual DataPort; consultas con VQL. | Objetos YAML de SML para dimensiones, hechos, medidas, cálculos, perspectivas y seguridad por filas; el modelo se versiona en Git. |
| Acceso en el ejemplo | Una política enmascara los campos etiquetados ssn y card_num para marketing_user; hr_user los ve sin enmascarar. | El ejemplo combina control de acceso por roles, seguridad por filas y perspectivas; la perspectiva de marketing omite esos campos. |
| Conexión del agente | El servidor MCP de Denodo conecta el agente con Virtual DataPort; AgentCore Gateway e Identity transmiten la identidad mediante un intercambio de token On-Behalf-Of. | El servidor MCP de AtScale conecta el agente con el modelo; AgentCore Gateway e Identity gestionan la credencial y el motor de AtScale resuelve el rol del usuario. |
| Interfaces del modelo | La misma vista puede exponerse mediante JDBC, ODBC, ADBC, GraphQL, OData y MCP. | El modelo desplegado se expone mediante SQL, XMLA y MCP. |
Cómo se representan las reglas de negocio
Denodo organiza el modelo en vistas base que corresponden a los orígenes, vistas derivadas para relacionar los datos y una vista de métricas reutilizable. El ejemplo crea seis vistas base y usa VQL, el lenguaje de consulta de Virtual DataPort. La métrica queda definida en una capa que puede reutilizarse en consultas, en lugar de depender únicamente de cómo el agente formule una pregunta.
AtScale usa SML, o Semantic Modeling Language, para describir conjuntos de datos y objetos dimensionales como jerarquías, hechos, medidas y cálculos. Esos objetos se expresan en YAML y se versionan en Git. En este patrón, los cambios del modelo semántico quedan representados como cambios en esos archivos versionados.
Identidad, permisos y auditoría
En ambos tutoriales, un agente creado con Strands Agents se aloja en Amazon Bedrock AgentCore y accede a la capa semántica mediante MCP y AgentCore Gateway. El recorrido de identidad no es idéntico: Denodo muestra un intercambio de token On-Behalf-Of para transmitir la identidad del usuario a Virtual DataPort; AtScale describe la gestión de la credencial de conexión y la resolución del rol de quien llama en su motor.
Los ejemplos también aplican los permisos de forma distinta. Denodo enmascara valores de los campos sensibles para el rol marketing_user, mientras que el rol hr_user los ve sin enmascarar. AtScale combina control de acceso por roles y seguridad por filas con perspectivas que determinan qué elementos del modelo ve cada perfil. En su ejemplo, la perspectiva de marketing excluye los campos ssn y card_num.
La información de auditoría sigue ese énfasis. El ejemplo de AtScale registra tanto el SQL dimensional generado por el modelo de lenguaje como el SQL traducido que se envía a Amazon Redshift; también incluye identidad, políticas aplicadas, uso de agregados y número de filas devueltas. La descripción de Denodo destaca la solicitud VQL, el rol asignado, el plan federado y los resultados de las políticas.
Qué patrón encaja con tus datos
Si el agente debe combinar datos que permanecen en Amazon Aurora, Amazon Redshift y PostgreSQL local durante la consulta, la arquitectura federada del ejemplo de Denodo corresponde a esa distribución. Si el equipo ya concentra sus datos analíticos en un almacén y puede mantener la replicación desde los sistemas operativos, el patrón de AtScale ofrece una capa dimensional que resuelve cada consulta en un solo motor.
