Amazon Quick es un servicio de inteligencia unificada impulsado por IA que reúne los datos de una organización, los datos estructurados y el contenido empresarial no estructurado, como documentos, correos electrónicos y bases de conocimientos, en un único servicio donde cualquiera puede explorar, analizar y tomar medidas. Con más de 40 integraciones de aplicaciones, Quick cierra la brecha de última milla entre información y acción para que los usuarios puedan comprender sus datos y actuar en consecuencia directamente.
Amazon Quick Sight, la capacidad de inteligencia empresarial (BI) de Amazon Quick, es un servicio de BI unificado. Proporciona paneles interactivos modernos, consultas en lenguaje natural, informes con píxeles perfectos, información sobre aprendizaje automático (ML) y análisis integrados a escala. Amazon Quick reúne agentes de inteligencia artificial para obtener información, investigación y automatización de negocios en una experiencia integrada, lo que lo ayuda a trabajar de manera más inteligente y rápida mientras mantiene las políticas de seguridad y acceso.
Amazon Athena es un servicio de consulta interactivo sin servidor que se utiliza para analizar datos directamente en Amazon Simple Storage Service (Amazon S3) utilizando SQL estándar, sin infraestructura que administrar ni datos que cargar. Dirige a Athena a sus datos almacenados en Amazon S3, define el esquema utilizando el catálogo de datos de AWS Glue y comienza a realizar consultas.
Muchas empresas centralizan su implementación de Amazon Quick en una única cuenta de AWS mientras sus datos residen en varias cuentas de unidades de negocio. Una empresa de servicios financieros podría ejecutar Quick en una cuenta central de AWS, mientras que los datos de banca minorista residen en la cuenta A, la banca de inversión en la cuenta B y la gestión de riesgos en la cuenta C. Hasta ahora, consultar datos de Amazon Athena en estas cuentas significaba administrar múltiples suscripciones a Quick o absorber todos los costos de consulta en la cuenta central.
Hoy anunciamos el acceso entre cuentas de Athena para Amazon Quick. Con esta característica, los clientes pueden consultar datos de Athena en otras cuentas de AWS utilizando el encadenamiento de roles de AWS Identity and Access Management (IAM), y los costos de consulta se facturan a la cuenta donde residen los datos. En el contexto del acceso entre cuentas de Athena, el encadenamiento de roles permite que Amazon Quick en una cuenta de editor asuma un rol en la cuenta de consumidor del cliente, que a su vez tiene permisos para consultar datos en Athena y el catálogo de datos de AWS Glue sin compartir credenciales a largo plazo entre los límites de la cuenta. En esta publicación, analizamos la configuración de un extremo a otro: creación de roles de IAM, configuración de políticas de confianza, creación de la fuente de datos entre cuentas en Quick y creación de conjuntos de datos a partir de ella.
Definiciones de términos
Cuenta de Quick central (cuenta de origen): la cuenta de AWS donde se implementa Amazon Quick. Cuenta del consumidor: una cuenta de AWS donde residen los activos de datos de Athena (bases de datos, tablas, datos de S3), a la que se accede desde la cuenta de Quick central. RunAsRole (rol A): una función de IAM en la cuenta de Quick central que Quick asume primero; no tiene permisos de datos, solo permiso para encadenar funciones de cuenta de consumidor. Función de cuenta de consumidor (rol B): una función de IAM en cada cuenta de consumidor que otorga acceso a Athena, AWS Glue y S3; Trusts Role Un encadenamiento de roles: un proceso de credenciales de dos pasos en el que Quick asume RunAsRole y luego usa esas credenciales para asumir el rol de cuenta de consumidor. rastreado
Descripción general de la solución
La solución utiliza un mecanismo de encadenamiento de roles de dos pasos que involucra dos roles de IAM:
Rol A (RunAsRole): vive en la cuenta Quick central. Quick asume este papel primero. Rol B (rol de cuenta del consumidor): reside en la cuenta del consumidor donde residen los datos de Athena. El rol A se encadena con el rol B para ejecutar consultas.
Cuando un usuario rápido ejecuta una consulta, el servicio asume el rol A y luego usa esas credenciales para asumir el rol B en la cuenta del consumidor. Athena ejecuta la consulta utilizando las credenciales del rol B, por lo que los costos informáticos se facturan a la cuenta del consumidor.
Requisitos previos
Antes de comenzar, asegúrese de que esté implementado lo siguiente:
Amazon Quick Enterprise Edition activo en la cuenta central Acceso administrativo de IAM en ambas cuentas. Creará y configurará roles en cada interfaz de línea de comandos de AWS (AWS CLI) instalada y configurada con credenciales para ambas cuentas, o accederá a la consola de administración de AWS. Familiaridad con los conceptos de IAM, específicamente políticas de confianza, políticas de permisos y asunción de roles (sts:AssumeRole). Grupo de trabajo de Athena configurado en la cuenta del consumidor (el grupo de trabajo principal predeterminado funciona para comenzar). Bucket S3 en la cuenta del consumidor para los resultados de consultas de Athena (normalmente con prefijo). resultados-de-consulta-aws-athena-*)
Nota: Para conectar varias cuentas de consumidor, repita los pasos de configuración de funciones para cada cuenta. Planifique su convención de nomenclatura de funciones de IAM con antelación para optimizar la gestión a escala.
Arquitectura técnica
A medida que las organizaciones adoptan arquitecturas Lakehouse y distribuyen datos entre unidades de negocios, regiones de AWS y cuentas de AWS, necesitan una forma de consultar esos datos de manera centralizada sin moverlos. El acceso entre cuentas de Athena para Amazon Quick aborda este requisito. Al utilizar el encadenamiento de roles de IAM, una implementación central de Quick puede llegar a almacenes de datos distribuidos a través de los límites de las cuentas sin replicación de datos, credenciales compartidas de larga duración o múltiples suscripciones a Quick. La arquitectura escala desde una prueba de concepto de dos cuentas hasta una implementación en toda la empresa. En esta sección, describimos tres patrones, cada uno de los cuales se basa en el anterior.
Patrón 1: configuración básica de dos cuentas
La implementación más sencilla conecta una cuenta Quick central con una cuenta de consumidor. Esta es la configuración mínima viable y se relaciona directamente con el tutorial paso a paso de esta publicación. La cadena de roles descrita en la descripción general de la solución (Quick asume el rol A, el rol A se encadena al rol B usando sts:AssumeRole y Athena ejecuta la consulta con las credenciales del rol B) se aplica directamente aquí. Este patrón es muy adecuado para la validación inicial o para conectar los datos de una única unidad de negocio a una cuenta de BI AWS compartida (central).
Patrón 2: cubo y radio
La mayoría de las empresas centralizan su implementación rápida en una sola cuenta (el centro), mientras que los datos se distribuyen entre varias cuentas de unidades de negocio (los radios). El modelo hub-and-spoke amplía la configuración básica: la política de permisos de la función A enumera varios ARN de funciones de consumidor, que pueden residir en la misma cuenta o en diferentes cuentas, y se crea una fuente de datos independiente en Quick para cada una. La ventaja clave de este patrón es la independencia entre los radios. Agregar una nueva unidad de negocios requiere crear un nuevo rol B en la cuenta de esa unidad y registrar una nueva fuente de datos en Quick, sin cambios en los radios existentes. Cada radio controla sus propios permisos del rol B, determinando qué tablas y prefijos de S3 están expuestos a la cuenta central de BI AWS. La atribución de costes se produce de forma natural: las consultas de Athena de cada radio se facturan en su propia cuenta. Debido a que un único panel de Quick puede hacer referencia a fuentes de datos de múltiples cuentas de consumidores, los autores de BI pueden crear análisis entre unidades de negocios sin abandonar la experiencia unificada de Quick. Este es el patrón recomendado para la mayoría de las empresas.
A medida que vaya más allá de un puñado de radios, considere crear una plantilla para la configuración del lado del consumidor. Una plantilla de AWS CloudFormation o CDK para el rol B, el grupo de trabajo de Athena y las políticas de confianza y permisos requeridas permiten a los equipos de las unidades de negocios realizar su incorporación por sí mismos, o al equipo central de BI aprovisionar nuevos radios con una implementación de pila única.
Patrón 3: malla de datos
En una malla de datos, los productores y los consumidores son cuentas distintas. Una cuenta de productor posee y administra sus datos sin procesar, aprovisionándolos en una cuenta de consumidor. Por ejemplo, utilizar AWS Lake Formation con AWS Resource Access Manager (AWS RAM) para compartir tablas entre los límites de las cuentas. El mecanismo de aprovisionamiento específico es elección del equipo del dominio y está fuera del alcance. La cuenta del consumidor, que contiene el rol B, el catálogo de datos de AWS Glue y el grupo de trabajo de Athena, es a lo que se conecta Amazon Quick a través de la cadena de roles. La cuenta publica productos de datos gobernados en otras cuentas de consumidores mediante políticas de recursos de AWS Glue Data Catalog, lo que hace que sus datos estén disponibles para análisis entre dominios. Este intercambio de igual a igual entre Cuentas de Consumidor, cada una de las cuales actúa como productor y consumidor de productos de datos, es lo que define la malla. Un autor de BI en Quick puede realizar consultas en múltiples Cuentas de Consumidor en un solo panel, con costos de consulta atribuidos por Cuenta de Consumidor. A escala empresarial, una única implementación de Amazon Quick puede conectarse a cientos de cuentas de consumidores. La forma en que las cuentas de dominio suministran datos sin procesar a las cuentas de consumidores está fuera de alcance.
Elegir un patrón
El patrón correcto depende de su estrategia de datos. La configuración básica de dos cuentas valida la cadena de roles de extremo a extremo. La mayoría de las empresas adoptarán el sistema hub-and-spoke a medida que incorporan unidades de negocios adicionales porque mantiene la independencia de los radios, la atribución de costos limpia y las políticas de confianza sencillas. Las organizaciones con fuertes límites de propiedad de datos o equipos de dominio dedicados evolucionarán naturalmente hacia el patrón de malla de datos, donde las cuentas de consumidores son distintas de las cuentas de productores que suministran los datos, y Amazon Quick sirve como capa de análisis unificada en todas ellas. Recomendamos comenzar con algo pequeño y expandirlo a medida que crezcan los requisitos.
Mirando hacia adelante
A medida que las capacidades de la IA agente maduran y los agentes de IA comienzan a consultar, transformar y actuar de forma autónoma sobre los datos a través de los límites organizacionales, la capacidad de acceder a los datos donde residen, están gobernados, tienen costos atribuidos y son auditables, se vuelve fundamental. El acceso a Athena entre cuentas es un componente básico para ese futuro. Hoy en día, conecta paneles Quick con lagos de datos distribuidos. A medida que evolucionan los patrones de agencia, el mismo mecanismo de encadenamiento de roles de IAM puede extenderse a los agentes de IA que consultan a Athena en nombre de los usuarios comerciales, aplican reglas de gobernanza en tiempo real y dirigen los costos informáticos al propietario de los datos sin centralizar los datos en una sola cuenta.
Solución
El acceso entre cuentas de Athena para Amazon Quick utiliza el encadenamiento de roles de IAM para conectar su cuenta central de Quick con una o más cuentas de consumidores donde residen sus datos. En lugar de consolidar datos en una sola cuenta o administrar suscripciones Quick separadas por unidad de negocio, puede configurar dos roles de IAM que funcionan en conjunto (uno en cada cuenta) para enrutar consultas y atribuir costos correctamente.
Cree el rol A (RunAsRole) en la cuenta Central Quick
El rol A reside en la cuenta Quick central. Amazon Quick asume esta función cuando un usuario inicia una consulta. El rol A no tiene permisos de datos propios; su único propósito es encadenarse a la cuenta del consumidor. Necesita dos cosas:
Una política de confianza que permite que el servicio Quick la asuma. Una política de permiso que le permite asumir el rol B en la cuenta del consumidor.
Cree la política de confianza y asígnele el nombre role-a-trust-policy.json. Esto permite que la entidad de servicio Quick asuma el rol A, en el ámbito de las operaciones de origen de datos en su cuenta. Política de muestra:
Cree el rol mediante la AWS CLI
Cree la política de permisos y asígnele el nombre role-a-permission-policy.json.
Adjunte la política de permisos como una política en línea mediante AWS CLI. Esto permite que el rol A asuma el rol B en la cuenta del consumidor. La condición ExternalId garantiza que solo las fuentes de datos Quick puedan desencadenar la cadena de roles:
Además, la entidad principal de IAM que crea la fuente de datos Quick necesita el permiso iam:PassRole en la función A.
Crear rol B en la cuenta del consumidor
El rol B reside en la cuenta del consumidor donde residen sus tablas de Athena, el catálogo de datos de AWS Glue y los datos de S3. El rol A asume el rol B para ejecutar la consulta.
Cree la política de confianza y asígnele el nombre role-b-trust-policy.json. Esto permite que la cuenta Quick asuma el rol B, con una condición ExternalId vinculada al ARN de la fuente de datos. Política de muestra:
Cree el rol mediante la AWS CLI:
Cree la política de permisos de Athena, AWS Glue y S3 y asígnele el nombre role-b-permission-policy.json. Ámbite a las bases de datos, tablas y ubicaciones de S3 específicas relevantes para tus datos.
Adjunte la política de permisos como una política en línea mediante AWS CLI
Cree la fuente de datos de Athena entre cuentas en Quick (cuenta central o de origen)
Usando la AWS CLI, ingrese lo siguiente:
O usando Python (Boto3):
Verifique que la fuente de datos se haya creado correctamente:
Resultado esperado:
Comparta la fuente de datos y cree conjuntos de datos
Una vez que la fuente de datos esté activa, compártala con los autores de Quick utilizando el siguiente código de muestra:
Los autores ahora pueden abrir Quick, navegar a Conjuntos de datos, crear un nuevo conjunto de datos, seleccionar la fuente de datos de la cuenta cruzada de Athena y explorar las bases de datos y tablas de AWS Glue desde la cuenta del consumidor. Pueden crear conjuntos de datos, aplicar transformaciones y crear paneles, todo desde la cuenta Quick central, con los costos de consulta facturados a la cuenta del consumidor.
Conexión de múltiples cuentas de consumidores
Para conectar cuentas de consumidores adicionales, repita la solución anterior para cada función/cuenta
Actualice la política de permisos del rol A para incluir el ARN del nuevo rol de cuenta de consumidor (o use un patrón comodín si sus roles de consumidor siguen una convención de nomenclatura). Cree el rol B en la nueva cuenta de consumidor con las políticas de confianza y acceso a datos adecuadas. Cree una nueva fuente de datos en Quick con el nuevo ConsumerAccountRoleArn. Comparte la fuente de datos. Cada fuente de datos se asigna a una cuenta de consumidor. Los autores seleccionan la fuente de datos adecuada en función de los datos de la unidad de negocio que necesitan.
Consideraciones de seguridad
El modelo de seguridad para el acceso entre cuentas de Athena está diseñado para permitir el acceso a datos distribuidos a escala y, al mismo tiempo, garantizar que cada consulta esté autorizada, tenga alcance y sea auditable. Como se describe en el tutorial, la condición ExternalId en la política de confianza del rol B evita ataques adjuntos confusos. Solo las fuentes de datos rápidos de la cuenta autorizada (central) pueden completar la cadena de funciones. Además, Quick aplica una política de alcance reducido en línea cada vez que asume el rol A, restringiendo cada sesión a un único rol de consumidor incluso cuando los permisos permanentes del rol A cubren varias cuentas. Juntos, estos mecanismos garantizan que cada cadena de consulta esté autenticada y tenga un alcance limitado. La cuenta del consumidor mantiene su propio límite de privilegios mínimos a través de los permisos del rol B. Cada unidad de negocio determina de forma independiente qué tablas, bases de datos y prefijos de S3 son visibles para la cuenta central de BI AWS. Recomendamos limitar el alcance de los permisos de AWS Glue y S3 a recursos específicos en lugar de utilizar comodines, restringir el rol B a un grupo de trabajo designado de Athena con el cifrado de resultados de consultas y límites de costos habilitados, y usar instancias de rol B separadas cuando la cuenta del consumidor contiene datos en diferentes niveles de clasificación.
La cadena de roles completa se captura en AWS CloudTrail en ambas cuentas desde el AssumeRole inicial en la cuenta central hasta la cadena hasta la cuenta del consumidor y las consultas de Athena que siguen. Esto proporciona un seguimiento de auditoría completo desde el inicio de la consulta hasta el acceso a los datos y admite alertas sobre patrones anómalos, como cuentas de origen inesperadas o picos en los datos escaneados.
Como se indicó en el paso 1 del tutorial, la entidad principal de IAM que crea la fuente de datos requiere iam:PassRole en la función A, lo que evita que los administradores asocien funciones arbitrarias con fuentes de datos. Estos mecanismos (ExternalId, alcance reducido, privilegio mínimo, CloudTrail y PassRole) forman un modelo de defensa en profundidad totalmente programático y basado en políticas, lo que lo hace muy adecuado para la gobernanza automatizada a medida que maduran las herramientas en este espacio.
Atribución de costos
Debido a que las consultas de Athena se ejecutan con las credenciales del rol B en la cuenta del consumidor, todas las llamadas a la API de AWS asociadas se producen en esa cuenta. La facturación estándar de AWS maneja la separación de costos automáticamente. La cuenta del consumidor incluye los cargos por consultas de Athena, los costos de acceso a S3 y las llamadas al catálogo de AWS Glue en su propia factura. La cuenta Quick central solo genera costos de sesión Quick y almacenamiento SPICE. Antes de esta característica, las organizaciones absorbían todos los costos de consulta de forma centralizada (perdiendo visibilidad por unidad de negocio) u operaban suscripciones Quick separadas por unidad de negocio, fragmentando la experiencia de BI. El acceso entre cuentas de Athena elimina esa compensación: una implementación rápida unificada con visibilidad de costos por unidad de negocio que no requiere lógica de devolución de cargo personalizada.
Limpiar
Para evitar incurrir en cargos continuos, elimine los recursos de AWS (roles de IAM, fuentes de datos de Quick Sight, políticas) que creó como parte de la experimentación. Para obtener instrucciones, consulte la documentación de servicio.
Conclusión
El acceso entre cuentas de Athena para Amazon Quick permite a las empresas mantener una cuenta de BI AWS centralizada respetando al mismo tiempo la gobernanza de datos de múltiples cuentas y los límites de costos. El enfoque de encadenamiento de roles proporciona una atribución de costos adecuada, mantiene la soberanía de los datos por unidad de negocio y se integra con los controles de seguridad de IAM existentes.
Para comenzar, cree los roles de IAM en sus cuentas Quick y de consumidor como se describe en esta publicación, luego cree la fuente de datos usando el parámetro ConsumerAccountRoleArn. Para obtener más detalles, consulte la Guía rápida del usuario de Amazon.
Sobre los autores
Vignessh Baskaran
Vignessh Baskaran es gerente técnico de productos sénior en Amazon Quick, donde posee productos de datos basados en inteligencia artificial para conectividad, catálogos y semántica, y preparación de datos. Tiene más de una década de experiencia en el desarrollo de soluciones de análisis y datos a gran escala. Fuera del trabajo, le gusta ver Cricket, jugar Racquetball y explorar diferentes cocinas en Seattle.
Ramón López
Ramón López es arquitecto principal de soluciones de Amazon Quick. Con muchos años de experiencia en la creación de soluciones de BI y experiencia en contabilidad, le encanta trabajar con clientes, crear soluciones y ofrecer servicios de clase mundial. Cuando no está trabajando, prefiere estar al aire libre en el océano o en la montaña.
Salim Khan
Salim Khan es arquitecto senior de soluciones de IA generativa a nivel mundial para Amazon Quick en AWS. Tiene más de 16 años de experiencia implementando soluciones de inteligencia empresarial empresarial. En AWS, Salim trabaja con clientes de todo el mundo para diseñar e implementar capacidades de BI impulsadas por IA y de IA generativa en Amazon Quick. Antes de AWS, trabajó como consultor de BI en sectores verticales como el de automoción, atención sanitaria, entretenimiento, consumo, publicaciones y servicios financieros, ofreciendo soluciones de inteligencia empresarial, almacenamiento de datos, integración de datos y gestión de datos maestros.