Blog de Amazon Web Services (AWS)
Presentación de los destinos multicuenta para los buses de eventos de Amazon EventBridge
Esta publicación fue escrita por Anton Aleksandrov, arquitecto principal de soluciones de Serverless, y Alexander Vladimirov, arquitecto sénior de soluciones de Serverless
Hoy, Amazon EventBridge anuncia la compatibilidad con los destinos entre cuentas para buses de eventos. Esta nueva capacidad le permite enviar eventos directamente a los destinatarios, como Amazon Simple Queue Service (Amazon SQS), AWS Lambda y Amazon Simple Notification Service (Amazon SNS), ubicados en otras cuentas.
Anteriormente, EventBridge permitía la transmisión de eventos entre cuentas desde un bus de eventos de una cuenta a un bus de eventos de otra cuenta. Este lanzamiento amplía esa capacidad y permite configurar el bus de eventos de origen para enviar los eventos directamente a todos los destinos compatibles con EventBridge en otras cuentas, no solo a los buses de eventos. Esto elimina la necesidad de un bus de eventos adicional en la cuenta de destino.
Descripción general
Las arquitecturas basadas en eventos creadas con EventBridge permiten crear soluciones que abarquen muchos departamentos de la empresa y dominios empresariales, sin dejar de ser asíncronas y estar acopladas de forma flexible. A medida que las soluciones crezcan, es posible que tenga que enviar los eventos más allá de los límites de las cuentas.
Por ejemplo, puede tener un conjunto de buses de eventos alojados en varias cuentas que envían los eventos relacionados con la seguridad a una cola de Amazon SQS alojada en una cuenta centralizada para su posterior procesamiento y análisis asíncronos.
Anteriormente, las reglas de EventBridge permitían definir los objetivos en la misma cuenta. El único tipo de destino que permitía la entrega de eventos entre cuentas era otro bus de eventos. Si quería enviar eventos más allá de los límites de las cuentas, tenía que crear buses de eventos tanto en la cuenta de origen como en la de destino. Después, configuraría una regla en el bus de eventos de origen para enviar los eventos al bus de destino y otra regla en el bus de eventos de destino para enviar el evento al destino deseado de la cuenta de destino. Como alternativa, se puede utilizar una función de Lambda o un tema de SNS como mecanismo de enlace para enviar eventos entre cuentas.
El siguiente diagrama ilustra el aspecto que tenía una arquitectura de entrega de eventos entre cuentas antes de la nueva funcionalidad. Se necesitaba un componente “puente”, como otro bus de eventos, un tema de SNS o una función de Lambda, para enviar los eventos de una cuenta a otra.
Figura 1: Entrega de eventos entre cuentas desde el bus de origen al bus de destino
Con esta nueva función de EventBridge, puede enviar los eventos directamente desde el bus de eventos de origen a los destinos deseados en diferentes cuentas. Esto simplifica la arquitectura y el modelo de permisos. También reduce la latencia en las soluciones basadas en eventos al disponer de menos componentes que procesen los eventos a lo largo del trayecto desde el origen hasta el destino.
Figura 2: Entrega de eventos multicuenta a destino directamente
Configuración de los destinos de las reglas de entrega de EventBridge para la entrega de eventos entre cuentas
La activación de la entrega de eventos entre cuentas debe hacerse teniendo en cuenta la seguridad. Debe establecer una confianza mutua entre el origen y el destino. Las reglas del bus de eventos de origen deben tener un rol de AWS Identity and Access Management (IAM) que les permita enviar eventos a destinos específicos. Esto se consigue asignando un rol de ejecución a los destinos de las reglas de entrega.
Los destinos de entrega de eventos alojados en diferentes cuentas deben tener una política de acceso a los recursos adjunta que permita explícitamente recibir eventos del rol de ejecución utilizado en la cuenta de origen. Debido a este requisito, puede habilitar la entrega de eventos entre cuentas solo para destinos que soporten las políticas de acceso a los recursos, como las colas de Amazon SQS, los temas de Amazon SNS y las funciones de AWS Lambda.
Tener una función de IAM en la cuenta de origen y una política de recursos en la cuenta de destino le permite tener un control granular sobre qué principales pueden utilizar la acción PutEvents y en qué condiciones. Puede definir políticas de control de servicios (SCP) para establecer los límites organizacionales que determinen quién puede enviar y recibir eventos en su organización.
Como se ilustra en el siguiente diagrama, considere que el equipo A es propietario de la cuenta de origen (Account A). El equipo A es responsable de configurar el bus de eventos de origen, su función de ejecución, sus reglas y sus destinos. Los equipos B y C son propietarios de las cuentas objetivo (Account B y Account C, según corresponda). Ambos equipos gestionan sus respectivas cuentas destino. Por ejemplo, crear destinos de entrega, como colas de SQS, y conceder permisos para aceptar eventos del bus de eventos de la cuenta de origen. Este enfoque permite al equipo A administrar el bus de eventos de origen centralizado para otros equipos, y a los equipos B y C controlar quién puede enviar los eventos a sus destinos. Proporciona un alto grado de control y gobernanza generales.
Figura 3: Una colaboración entre equipos que envía eventos desde la cuenta de origen a los objetivos de la cuenta de destino
El siguiente ejemplo describe la configuración de la entrega de eventos entre cuentas a una cola de SQS. También puede aplicar la misma técnica a otros tipos de objetivos, como las funciones de Lambda o los temas de SNS.
Consulte el siguiente diagrama para ver el diseño arquitectónico conceptual y el orden de creación de los recursos.
Figura 4: Permisos necesarios para la entrega de eventos entre cuentas
Suponiendo que el bus de eventos de origen ya existe, hay tres pasos generales para configurar la entrega de eventos entre cuentas:
- Cuenta de destino: cree el destino de entrega, como una cola de SQS.
- Cuenta de origen: configure una regla para la entrega de eventos entre cuentas. Establezca el ARN de la cola de SQS de destino como destino de la regla y asigne un rol de ejecución con permisos para enviar mensajes a la cola de SQS de destino.
- Cuenta de destino: aplique una política de recursos a la cola SQS de destino que permita que la función de ejecución del bus de eventos de origen envíe eventos.
Mostrando la entrega de eventos entre cuentas en acción
Siga las instrucciones de este repositorio de GitHub para aprovisionar el ejemplo en su cuentas de AWS mediante AWS Serverless Application Model (AWS SAM). Una regla de bus de eventos de la cuenta de origen envía los eventos directamente a una cola de SQS, a una función de Lambda y a un tema de SNS de una cuenta de destino. Debe tener dos cuentas para que el ejemplo funcione.
Figura 5: Ejemplo de arquitectura del proyecto, que ofrece eventos entre cuentas para Lambda, SQS y SNS.
Asegúrese de introducir una dirección de correo electrónico válida como valor de SNSSubscriptionEmail y confirme su suscripción de correo electrónico una vez desplegada la pila de destino.
Tras la implementación, abra la consola de EventBridge en la cuenta de origen. Navegue hasta el bus de eventos recién creado, cuyo nombre incluye “SourceEventBus”. Utilice la función Enviar eventos para publicar eventos de muestra, como se muestra en la siguiente captura de pantalla. Asegúrese de que la fuente de sus eventos esté configurada como “prueba” (test).
Figura 6: Envío del evento de prueba
Valide que los eventos se entreguen correctamente a los tres destinos multicuentas. Abre la cuenta de destino en otro navegador o en una ventana de incógnito:
- Navegue hasta la consola SQS. Abra la cola recién creada, cuyo nombre incluye “TargetSQSqueue”.
- Elija Enviar y recibir mensajes y, a continuación, seleccione Sondeo de mensajes. Puede ver los eventos enviados en el paso anterior.
Figura 7: Recepción del evento de prueba con SQS
3. Navegue hasta Amazon CloudWatch Logs. Abra el grupo de registros de la función Lambda recién creada, cuyo nombre incluye “TargetLambdaFunction”. Muestra los eventos enviados en el paso anterior.
Figura 8:Recibir un evento de prueba con Lambda
4. Revise su correo electrónico. Si ha confirmado la suscripción al tema de SNS durante la implementación del código de ejemplo, se muestran los eventos enviados en el paso anterior.
Figura 9: Recibir un evento de prueba con SNS
Conclusión
La nueva capacidad de EventBridge le permite enviar eventos directamente a los destinatarios más allá de los límites de las cuentas. Esta capacidad ayuda a simplificar las arquitecturas basadas en eventos, así como a mejorar la latencia al reducir la cantidad de componentes que procesan los eventos cuando viajan desde los buses de eventos hasta sus destinos.
Consulte la página de precios de EventBridge para obtener más información sobre los costes de entrega de eventos entre cuentas.
Para obtener documentación adicional, consulte la documentación de Amazon EventBridge. Obtenga el código de muestra utilizado en este blog de este repositorio de GitHub.
Para obtener más recursos de aprendizaje sin servidor, visite Serverless Land.
Este contenido es una traducción del Blog Original en inglés traducido por Christian Bolaños y revisado por Diego Casas.