Обзор

Вопрос: Что такое Amazon EventBridge?

Amazon EventBridge – это сервис, предоставляющий в режиме реального времени доступ к изменениям данных в сервисах AWS, собственных приложениях и приложениях SaaS (модель «программное обеспечение как сервис») без написания кода. Для начала работы можно выбрать источник событий в консоли Amazon EventBridge и выбрать получателя среди множества сервисов AWS, в число которых входят AWS Lambda, Amazon Simple Notification Service (SNS) и Amazon Kinesis Data Firehose. Amazon EventBridge будет доставлять события автоматически в режиме, близком к реальному времени.

Вопрос: Как начать работу с Amazon EventBridge?

Войдите в аккаунт AWS, перейдите в консоль Amazon EventBridge и выберите источник событий из списка партнерских SaaS‑приложений и сервисов AWS. Если используется партнерское приложение, убедитесь в том, что аккаунт SaaS настроен на отправку событий, и одобрите его в предложенном разделе источников событий в консоли Amazon EventBridge. Amazon EventBridge автоматически создаст шину событий, в которую будут перенаправляться события. Кроме того, добавить в приложение возможность отправки событий в шину событий можно с помощью SDK AWS. Дополнительно можно настроить правило фильтрации и закрепить получателя – им может быть, к примеру, лямбда-функция. Amazon EventBridge будет автоматически принимать, фильтровать и отправлять события настроенному получателю безопасным способом с обеспечением высокой доступности.

Вопрос. Можно ли публиковать в Amazon EventBridge собственные события?

Да. Вы можете формировать специальные события на уровне приложения и публиковать их в Amazon EventBridge с помощью интерфейсов API сервиса. Можно также настроить запланированные события, формируемые периодически, и обрабатывать эти события в любом из поддерживаемых Amazon EventBridge получателей.

Вопрос: Какой формат должно иметь событие?

События используют определенную структуру JSON. В каждом событии используются одни и те же высокоуровневые конвертные поля, например источник события, временная метка и регион. Затем следует поле сведений, которое является телом события. Например, когда группа автоматического масштабирования Amazon Elastic Compute Cloud EC2 Auto Scaling создает новый инстанс Amazon EC2, она отправляет событие с источником «aws.autoscaling» и сведениями «EC2 instance created successfully» (Инстанс EC2 успешно создан).

Вопрос: Как установить фильтр, определяющий, какие события будут доставляться получателям?

События можно фильтровать с помощью правил. Правило соотносит входящие события с конкретной событийной шиной и перенаправляет их целевым адресатам для обработки. Простое правило может направить событие множеству адресатов, которые займутся его обработкой параллельно. Правила позволяют различным компонентам приложения находить и обрабатывать те события, которые представляют для них интерес. Правило может модифицировать событие перед отправкой получателю, передавая только некоторые его части или перезаписывая его константой. В случае примера, приведенного в предыдущем вопросе, можно создать правило для события, соответствующее источнику «aws.autoscaling» и сведениям «EC2 instance created successfully» (Инстанс EC2 успешно создан), чтобы получать оповещения при каждом успешном создании инстанса Amazon EC2 группой Auto Scaling.

Вопрос: Как защитить доступ к Amazon EventBridge?

Благодаря интеграции Amazon EventBridge с сервисом AWS Identity and Access Management (IAM) можно указывать, какие действия EventBridge пользователю разрешено выполнять в рамках аккаунта AWS. К примеру, можно создать политику IAM, которая позволит только определенным пользователям организации создавать шины событий и назначать получателей для событий.

Вопрос: Как сервис Amazon EventBridge связан с CloudWatch Events?

Сервис Amazon EventBridge использует в своей работе сервис CloudWatch Events и дополняет его возможности. Он использует тот же API и адрес сервиса, ту же базовую сервисную инфраструктуру. Если клиент уже работает с CloudWatch Events, ничего менять не требуется: можно продолжать использовать существующий API, шаблоны CloudFormation и консоль. По отзывам наших клиентов, CloudWatch Events является идеальным сервисом для построения событийных архитектур, поэтому мы создали новые возможности, позволяющие клиентам передавать данные из собственных приложений и SaaS‑приложений сторонних разработчиков. Мы решили не выпускать эти возможности под прежним названием CloudWatch и дали сервису новое имя, Amazon EventBridge, так как новые возможности вышли за пределы случая использования наблюдения, для которого изначально разрабатывался сервис CloudWatch Events.

Вопрос: Я уже использую Amazon CloudWatch Events и хочу опробовать новые возможности сервиса Amazon EventBridge. Нужно ли переносить правила и разрешения Amazon CloudWatch Events в Amazon EventBridge?

Нет. Пользователи Amazon CloudWatch Events могут получить доступ к существующей шине, правилам и событиям по умолчанию с помощью новой консоли и интерфейса API Amazon EventBridge или с помощью консоли и интерфейса API Amazon CloudWatch Events.

Вопрос: Я уже использую Amazon CloudWatch Events и не интересуюсь возможностями сервиса Amazon EventBridge. Какие изменения меня ждут?

Все остается без изменений. Amazon EventBridge использует интерфейс API сервиса Amazon CloudWatch Events, поэтому все существующие случаи использования интерфеса API CloudWatch Events останутся прежними.

Вопрос: Будет ли со временем прекращена поддержка Amazon CloudWatch Events?

Нет, мы не собираемся прекращать поддержку интерфейса API или самого сервиса. Сервис Amazon EventBridge использует тот же интерфейс API и предлагает дополнительные возможности. Со временем сервис Amazon CloudWatch Events будет переименован в Amazon EventBridge.

Вопрос: Какие сервисы AWS интегрированы в Amazon EventBridge в качестве источников событий?

В качестве источников событий EventBridge можно использовать более 90 сервисов AWS, в том числе AWS Lambda, Amazon Kinesis, AWS Fargate и Amazon Simple Storage Service (S3). Полный перечень интеграций с сервисами AWS приведён в документации EventBridge.

Вопрос: Какие сервисы AWS интегрированы в Amazon EventBridge в качестве получателей?

В качестве получателей для событий EventBridge можно использовать более 15 сервисов AWS, в том числе AWS Lambda, Amazon Simple Queue Service (SQS), Amazon SNS, Amazon Kinesis Streams и Amazon Kinesis Data Firehose. Полный перечень интеграций с сервисами AWS приведён в документации EventBridge.

Вопрос. Что такое архивирование и воспроизведение событий EventBridge?

Воспроизведение событий – это новая функция Amazon EventBridge, которая позволяет клиентам возвращать предыдущие события в шину событий или направлять их в определенное правило EventBridge. Эта функция позволяет разработчикам легко отлаживать свои приложения, расширять их, наполняя целевые объекты предыдущими событиями, а также восстанавливать после ошибок. Воспроизведение событий дает разработчикам уверенность в том, что они всегда имеют доступ к любому событию, опубликованному в EventBridge.

Вопрос: Что такое целевые объекты интерфейса API EventBridge?

Целевые объекты интсерфейса API позволяют разработчикам отправлять события любым локальным приложениям или приложениям SaaS с возможностью контроля пропускной способности и аутентификации. Клиенты могут настраивать правила преобразования ввода, которые будут приводить формат события в соответствие с форматом службы-получателя, а EventBridge будет заниматься безопасностью и доставкой. Когда включается правило, Amazon EventBridge преобразует событие на основании указанных условий и отправляет его указанному веб-сервису с информацией для аутентификации, предоставленной во время настройки правила. Безопасность предусмотрена заранее, поэтому разработчикам больше не требуется писать компоненты аутентификации для сервисов, которыми они хотят воспользоваться.

Вопрос: Что такое «подключение» для целевого объекта интерфейса API? Как настраивать целевые объекты интерфейса API?

Каждый целевой объект интерфейса API использует подключение, которое определяет способ авторизации и данные для доступа к подключению к конечной точке HTTP. Когда вы настраиваете параметры авторизации и создаете подключение, в AWS Secrets Manager создаются конфиденциальные данные для безопасного хранения информации для авторизации. Также можно добавить в подключение дополнительные параметры в соответствии с требованиями приложения.

Чтобы настроить целевой объект интерфейса API, необходимо указать конечную точку целевого объекта интерфейса API, то есть целевой объект конечной точки вызова по HTTP для событий. Для авторизации в этой конечной точке потребуется создать подключение. Можно дополнительно определить лимит частоты вызовов – максимальное количество вызовов в секунду, которые направляются в конечную точку целевого объекта API. Подробнее о подключениях и целевых объектах API.

Лимиты и производительность

Вопрос: Какие лимиты установлены для сервиса?

См. страницу «Лимиты сервисов» по ссылке.

Вопрос: Какой обычно бывает задержка между отправкой и получением события?

Обычная задержка составляет примерно полсекунды. Однако это значение может меняться.

Вопрос: Поддерживает ли Amazon EventBridge теги ресурсов?

Да, теги можно присваивать правилам. Для шин событий или источников событий теги не предусмотрены.

Вопрос: Какой пропускной способностью обладает Amazon EventBridge?

Ограничения, действующие для пропускной способности шины событий, указаны на странице «Лимиты сервиса» по ссылке. Если требуется большая пропускная способность, отправьте запрос на повышение ограничений через AWS Support Center. Для этого нужно выбрать «Create Case» (Создать заявку), затем «Service Limit Increase» (Повышение лимитов сервиса).

Вопрос: Действует ли для Amazon EventBridge соглашение об уровне обслуживания?

Да. AWS будет предпринимать коммерчески целесообразные усилия для обеспечения доступности сервиса EventBridge на уровне бесперебойной работы не менее 99,99 % за любой оплачиваемый месяц в каждом из регионов AWS. За подробностями обратитесь к полному тексту Соглашения об уровне обслуживания EventBridge.

Реестр схем

Вопрос. Что такое схема?

Схема отражает структуру события и обычно включает такие сведения, как заголовок и формат каждого элемента данных в событии. Например, схема может содержать поля для имени и номера телефона с указанием формата: текстовая строка для имени и целое число для номера телефона. Также схема может включать сведения о шаблонах и форматах, например требовать 10-значное число в качестве номера телефона. Схема события очень важна, поскольку демонстрирует передаваемую в этом событии информацию и позволяет создавать код для обработки этой информации.

Вопрос. Что такое реестр схем?

Реестр схем сохраняет коллекцию схем с поддержкой поиска по ним, что позволяет всем разработчикам в организации легко обращаться к любой схеме, созданной приложением, без изучения документации или поиска автора схемы для получения ее описания. Вы можете добавлять схемы в реестр вручную или автоматически, включив функцию обнаружения схем EventBridge.

Вопрос. Что такое функция обнаружения схем?

Обнаружение схем автоматизирует процесс поиска схем и их добавления в реестр. Если для шины событий EventBridge включено обнаружение схем, в реестр автоматически сохраняется схема каждого события, отправленного в эту шину событий. При любых изменениях схемы события функция обнаружения схем автоматически создаст в реестре новую версию этой схемы. После добавления схемы в реестр вы сможете создать привязку к этой схеме в коде (через консоль EventBridge или напрямую в среде IDE), что позволяет представлять каждое событие в формате строго типизированного объекта и использовать для него любые функции среды IDE, такие как проверка и автоматическое заполнение.

Вопрос. Можно ли обнаруживать схемы для событий, отправленных из других аккаунтов?

Функция обнаружения схем поддерживается только для событий, созданных в стандартных, пользовательских или партнерских шинах событий в том же аккаунте, где размещается средство обнаружения.

Вопрос: Сколько стоит реестр схем?

Плата за использование реестра схем не взимается, но после включения обнаружения схем вы будете оплачивать входящие события. Для обнаружения схем предусмотрен уровень бесплатного пользования с объемом до 5 млн событий в месяц, и этого обычно достаточно для целей разработки. За дополнительные сообщения сверх уровня бесплатного пользования взимается плата в размере 0,10 USD за каждый миллион принятых сообщений. Дополнительные сведения приведены на странице с ценами на EventBridge.

Вопрос: Как реестр схем поможет сократить объем создаваемого кода?

Во-первых, обнаружение схем будет автоматически отслеживать схемы всех событий, которые вы отправляете в шину событий EventBridge, и сохранять их в реестре, избавляя от управления схемами событий вручную. Во-вторых, при создании приложений, которые обрабатывают события в этой шине событий, вы сможете генерировать и загружать привязки кода к нужной схеме, используя события в формате строго типизированных объектов. Это снижает затраты на десериализацию, проверку данных и эксперименты с событиями.

Вопрос. Почему нужно использовать реестр схем?

С помощью реестра схем EventBridge поможет вам быстрее разрабатывать приложения, управляемые событиями, и сосредоточиться на основном коде приложения. Раньше вам приходилось самостоятельно искать доступные события и выяснять их структуру, а затем создавать код для расшифровки и преобразования событий в понятный приложению формат. Теперь благодаря реестру схем вы можете автоматически обнаруживать события, доступные из любых поддерживаемых источников, включая сервисы AWS, приложения организации и сторонних разработчиков, а также сразу узнавать их схемы.

Вопрос. Какие среды IDE поддерживает реестр схем?

К реестру схем можно обращаться через набор средств AWS для JetBrains (IntelliJ, PyCharm, WebStorm, Rider) и VS Code, а также через консоль EventBridge и интерфейсы API. Дополнительные сведения о реестре схем EventBridge в разных IDE вы найдете здесь.

Вопрос. Можно ли использовать схему с моделью бессерверных приложений Serverless Application Model (AWS SAM)?

Да, последняя версия интерфейса командной строки для модели бессерверных приложений AWS SAM поддерживает интерактивный режим для создания в EventBridge новых бессерверных приложений в формате типа события для любой схемы. Просто выберите шаблон «Приложение EventBridge для быстрого старта» и нужную схему события. Модель бессерверных приложений AWS SAM автоматически создаст приложение с функцией Lambda, которая вызывается из EventBridge и содержит код обработки выбранного события. Это позволит вам использовать триггер события в коде как обычный объект и применять любые функции среды IDE, например проверку значений и автозаполнение.

Подключаемый модуль набора средств AWS для Jetbrains (Intellij, PyCharm, Webstorm, Rider) и AWS Toolkit for Visual Studio Code также поддерживает возможность создавать на основе этого шаблона бессерверные приложения с триггером, основанным на выбранной схеме, непосредственно в любой удобной среде IDE.

На каких языках можно создать код на основе схем?

Создавать код можно на языках Java (8 и более поздних версий), Python (3.6 и более поздних версий) и TypeScript (3.0 и более поздних версий).

Вопрос. В каких регионах AWS доступен реестр схем?

Реестр схем EventBridge доступен в таких регионах: восток США (Огайо и Северная Виргиния), запад США (Орегон и Северная Калифорния), Канада (центр), ЕС (Стокгольм, Париж, Ирландия, Франкфурт и Лондон), Азия и Тихий океан (Мумбаи, Токио, Сеул, Сингапур, Гонконг и Сидней) и Южная Америка (Сан-Паулу).

Глобальные адреса

Вопрос: Что такое глобальные адреса?

Глобальные адреса – это новая функция Amazon EventBridge, которая упрощает создание высокодоступных приложений, управляемых событиями, с помощью AWS. Вы можете реплицировать события в основном и вторичном регионах, чтобы обеспечить обработку отказа с минимальной потерей данных, а также возможность автоматического перехода на резервный регион в случае каких-либо сбоев в обслуживании. Это упрощает внедрение многорегиональных архитектур и позволяет включить отказоустойчивость в приложения, управляемые событиями.

Вопрос. Что дает использование глобальных адресов?

Глобальные адреса помогут вам обеспечить лучшую работу для ваших конечных клиентов, минимизируя объем данных, подверженных риску во время перебоев в обслуживании. Вы можете сделать свои приложения, управляемые событиями, более надежными и устойчивыми к внешним воздействиям, имея возможность автоматически и без необходимости ручного вмешательства переключать ввод событий на вторичный регион. Вы можете гибко настраивать критерии обработки отказа с помощью предупреждений CloudWatch (через проверки работоспособности Route53) для определения момента обработки отказа и момента маршрутизации событий обратно в основной регион.

Вопрос. Как глобальный адрес повышает доступность моих приложений?

После публикации событий в глобальном адресе они направляются на шину событий в вашем основном регионе. Если в основном регионе обнаружены ошибки, событие помечается как неработоспособное, а входящие события направляются во вторичный регион. Ошибки можно легко обнаружить с помощью предупреждений CloudWatch (через проверки работоспособности Route53), которые вы задаете. Как только проблема будет устранена, мы направляем новые события обратно в основной регион и продолжаем обработку событий.

Вопрос. Какие типы приложений хорошо подходят для глобальных адресов?

Глобальные адреса хорошо подходят для приложений, которые не требуют идемпотентности или могут работать с идемпотентностью в разных регионах. Они также хорошо подходят для приложений, которые терпимы к тому, что до 420 секунд события не реплицируются и, таким образом, застревают в основном регионе до тех пор, пока сервис или регион не восстановятся (так называемая цель точки восстановления).

Вопрос. Какие метрики следует использовать для обработки отказа глобального адреса?

Мы добавили новый показатель, который сообщает о сквозной задержке Amazon EventBridge, что позволит вам легко определить, есть ли ошибки в EventBridge, которые потребуют обработку отказа ввода событий на вторичный регион. Мы облегчили клиентам работу с консолью, предоставив предварительно заполненный стек CloudFormation (который вы можете изменить по своему усмотрению) для создания предупреждения CloudWatch и проверки работоспособности Route53. Более подробную информацию о настройке сигналов тревоги и проверке работоспособности можно найти в нашем блоге о запуске и документации.

Вопрос. Нужно ли мне использовать метрики моего подписчика для обработки отказа моего глобального адреса?

Мы не рекомендуем включать показатели подписчиков в проверку работоспособности, поскольку это может привести к тому, что при возникновении проблемы у одного подписчика ваш издатель переключится на резервный регион, несмотря на то, что все остальные подписчики в основном регионе работоспособны. Если один из ваших подписчиков не может обрабатывать события в основном регионе, вам следует включить репликацию, чтобы убедиться, что ваш подписчик во вторичном регионе может успешно обрабатывать события.

Вопрос. Что такое ожидаемое целевое время восстановления (RTO) и целевая точка восстановления (RPO)?

Целевое время восстановления (RTO) – это время, в течение которого резервный регион или цель начнет получать новые события после сбоя. Целевая точка восстановления (RPO) – это мера данных, которые останутся необработанными во время сбоя. Для глобальных адресов, если вы следуете нашим предписаниям по настройке предупреждений, RTO и RPO будут составлять 360 секунд (максимум 420). Для RTO время включает период срабатывания предупреждений CloudWatch и обновления статусов для проверок работоспособности Route53. Для RPO время включает события, которые не реплицируются во вторичный регион и застревают в основном регионе до тех пор, пока служба или регион не восстановятся.

Вопрос. Нужно ли мне включать репликацию?

Да. Вы должны включить репликацию, чтобы минимизировать риск для данных во время перебоев в обслуживании. После настройки пользовательских шин в обоих регионах и создания глобального адреса вы можете обновить свои приложения для публикации событий в глобальном адресе. Таким образом, ваши входящие события будут реплицироваться обратно в основной регион после устранения проблемы. Вы можете архивировать события во вторичном регионе, чтобы ни одно из них не было потеряно во время сбоя. Чтобы быстро восстановиться после сбоев, вы можете реплицировать свою архитектуру во вторичном регионе для продолжения обработки событий. Также необходимо включить репликацию, чтобы обеспечить автоматическое восстановление после устранения проблемы.

Вопрос. Каковы рекомендации по управлению квотами в обоих моих регионах?

Вы должны убедиться, что в основном и вторичном регионах установлены одинаковые квоты. Рекомендуем включить репликацию и обрабатывать события во вторичном регионе, поскольку это гарантирует не только наличие нужных квот, но и правильную настройку приложения во вторичном регионе.

Вопрос. Есть ли простой способ воспроизвести мою архитектуру в моем вторичном регионе?

Вы можете использовать наборы AWS CloudFormation StackSets, которые позволяют легко реплицировать вашу архитектуру в регионах AWS. Примеры приведены в документации.

Вопрос. Могу ли я использовать любой счет, любой регион и любую шину для вторичной архитектуры?

В первой итерации запуска не поддерживаются переходные регионы, Китай и GovCloud. Список регионов, поддерживаемых на момент запуска, см. в вопросе 16 ниже. Мы также поддерживаем обработку отказа и восстановление между одним и тем же аккаунтом и шинами с одинаковым именем в разных регионах.

Вопрос. Работают ли глобальные адреса с событиями AWS из CloudTrail, S3 и других служб AWS?

Глобальные адреса доступны только для специальных событий. В будущем мы добавим поддержку событий от сервисов AWS, подтвержденных событий от S3 (оповещение о событиях Amazon S3) и событий третьих сторон.

Вопрос. Поддерживается ли маршрутизация на базе задержки?

Нет, мы не поддерживаем маршрутизацию на базе задержки в первой итерации запуска.
Сколько стоят глобальные адреса?

Глобальные адреса доступны без дополнительной платы. Сегодня глобальные адреса доступны только для специальных событий, а специальные события, опубликованные на глобальном адресе, тарифицируются в соответствии с ценами на такие события. Подробные сведения о ценах приведены на странице цен EventBridge.

Вопрос. Взимается ли плата за репликацию?

Да, вы будете платить 1 USD за миллион событий за репликацию, который EventBridge взимает за межрегиональные события.

Вопрос. В каких регионах доступны глобальные адреса?

Глобальные адреса доступны в таких регионах: восток США (Огайо и Северная Виргиния), запад США (Орегон и Северная Калифорния), Канада (центр), ЕС (Стокгольм, Париж, Ирландия, Франкфурт и Лондон), Азия и Тихий океан (Мумбаи, Токио, Сеул, Сингапур, Осака и Сидней) и Южная Америка (Сан-Паулу).

Стоимость и оплата

Вопрос: Сколько стоит использование сервиса EventBridge?

Цены приведены по ссылке.

 

Вопрос: Будет ли начисляться плата за события, отправленные партнером на источник событий, за которым не закреплена шина событий?

Нет.

Архитектура и проектирование

Вопрос: Можно ли настроить получателя на отправку событий в другой аккаунт?

Да. Такие события называются событиями других аккаунтов. Можно настроить получателя, который является шиной событий по умолчанию или любой другой шиной событий в другом аккаунте.

Вопрос. Можно ли использовать сервис AWS CloudFormation вместе с Amazon EventBridge?

Да. Поддержка CloudFormation доступна во всех регионах доступности Amazon EventBridge. Подробности о предоставлении ресурсов Amazon EventBridge и управлении ими с помощью CloudFormation см. в нашей документации.

Вопрос: Когда следует использовать Amazon EventBridge, а когда Amazon SNS?

Для разработки приложений, управляемых событиями, можно использовать как Amazon EventBridge, так и Amazon SNS. Выбор зависит от конкретных задач. Amazon EventBridge рекомендуется использовать для разработки приложений, реагирующих на события SaaS‑приложений и (или) сервисов AWS. Amazon EventBridge – единственный событийный сервис, непосредственно интегрированный со сторонними партнерами SaaS. Amazon EventBridge также способен автоматически принимать события более чем из 90 сервисов AWS без создания каких‑либо ресурсов в аккаунте разработчика. Кроме того, Amazon EventBridge использует для событий определенную структуру на базе JSON и позволяет создавать правила, действующие во всем теле события и позволяющие выбирать события для перенаправления получателю. В настоящее время Amazon EventBridge поддерживает в качестве получателей более 15 сервисов AWS, в том числе AWS Lambda, Amazon SQS, Amazon SNS, а также Amazon Kinesis Streams и Kinesis Data Firehose. На момент запуска сервис Amazon EventBridge имеет ограниченную пропускную способность (см. «Лимиты сервисов»), которую можно увеличить по требованию, и типовую задержку полсекунды.

Сервис Amazon SNS рекомендуется использовать для создания приложения, реагирующего на сообщения с высокой пропускной способностью или низкими задержками, публикуемые другими приложениями или микросервисами (так как Amazon SNS предлагает практически неограниченную пропускную способность), или для приложений, которым необходим очень высокий уровень распределения данных (тысячи или миллионы адресов). Этот сервис не структурирует сообщения, они могут иметь любой формат. Amazon SNS поддерживает перенаправление сообщений получателям шести различных типов, в том числе в AWS Lambda, Amazon SQS, конечные точки HTTP(S), SMS‑сообщения, мобильные push‑уведомления и электронную почту. Типовая задержка сервиса Amazon SNS – менее 30 мс. Многие сервисы AWS (более 30, в том числе Amazon EC2, Amazon S3 и Amazon RDS) могут отправлять сообщения SNS после соответствующей настройки.

Возможности интеграции

Вопрос: Зачем интегрировать SaaS‑приложение с Amazon EventBridge?

Сервис Amazon EventBridge позволяет поставщикам SaaS‑решений просто интегрировать свой сервис в событийные архитектуры клиентов, построенные в AWS. Благодаря Amazon EventBridge продукт будет непосредственно доступен миллионам разработчиков AWS, что позволит найти новые примеры использования. Сервис предлагает полностью контролируемый, безопасный и масштабируемый способ отправки событий, не требуя от поставщика SaaS‑решений управления событийной инфраструктурой.

Вопрос: Наша SaaS‑компания может стать отличным источником событий. Как реализовать интеграцию?

Чтобы начать публикацию событий в Amazon EventBridge, поставщики решений SaaS, желающие стать партнерами по Amazon EventBridge, должны выполнить требования инструкций по самообслуживанию, указанные на странице о начале интеграции с Amazon EventBridge.

Вопрос: Насколько сложна интеграция с Amazon EventBridge для поставщиков SaaS?

Если поставщик SaaS поддерживает веб-перехватчик или иной режим интеграции на основе push‑уведомлений, интеграция с Amazon EventBridge обычно занимает не более 5 дней разработки.

Вопрос: Какие интеграции SaaS поддерживаются?

Полный перечень поддерживаемых интеграций приведен по ссылке.

Интеграции с Amazon EventBridge
Подробнее об интеграциях с Amazon EventBridge

Ознакомьтесь со страницей интеграции с Amazon EventBridge.

Подробнее 
Начать разработку в консоли
Начните разработку в консоли

Начните разработку с помощью Amazon EventBridge в Консоли управления AWS.

Вход 
Ознакомиться с документацией
Подробности в документации

Более подробные сведения об EventBridge см. в руководстве для разработчиков.

Подробнее