Что будет, если отключить лямбда-зонд в автомобиле?

Avtopub2 февраля 20187 февраля 20180

Автомобили в наше время оснащаются большим количеством электронных устройств и датчиков, без которых уже невозможно обойтись. Сегодня будет идти речь о датчике кислорода или лямбда-зонде. Вы узнаете, как он работает и что будет, если отключить его в случае выхода из строя.

Уже само название этого датчика многим непонятно. Рассмотрим детальнее назначение датчика кислорода, что поможет понять, можно ли эксплуатировать автомобиль без него.

Принцип работы

Лямбда-зонд помогает оптимизировать состав топливовоздушной смеси, необходимой для работы двигателя. В идеале эта смесь должна состоять из 1 части бензина и 14,6-14,8 части воздуха. Для этого электронный блок управления анализирует показатели разных датчиков, среди которых и наш лямбда-зонд.

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

Проверка лямбда-зонда

Если компьютер получает неправильные данные с кислородного датчика, на панели приборов загорается индикатор Check Engine. При считывании ошибок диагностика может показать неисправность лямбда-зонда. Но не всегда всё настолько однозначно. Иногда датчик показывает неверные значения, так как в двигатель попадает слишком много воздуха или бензина. Виновником может быть банальный подсос воздуха (кстати, мы писали о том, как его искать и устранять – http://avtopub.com/kak-najti-podsos-vozduxa-v-dvigatele-i-ustranit-ego/).

Один из простейших способов проверки – отключение лямбда-зонда и проверка поведения автомобиля во время движения. Если датчик работает нормально, его отключение приведет к ухудшению динамики и значительному росту расхода топлива. Если же датчик неисправен, всё будет, как и раньше.

Подробная статья о том, как проверить датчик кислорода (лямбда-зонд) мультиметром — http://avtopub.com/proverka-lyambda-zonda-datchika-kisloroda-multimetrom/

Можно ли отключить лямбда-зонд и ездить без него?

Отметим, что этот вопрос зачастую возникает потому, что датчик кислорода – запчасть недешевая. Необходимо просто всё взвесить и проанализировать целесообразность такой «экономии». Вы уже знаете, что эксплуатация автомобиля без датчика кислорода обязательно приводит к существенному увеличению расхода бензина. Причина состоит в том, что электронный блок управления в такой ситуации переходит в аварийный режим, регулируя состав смеси по средним показателям. Также автомобиль будет «тупить», поэтому вы будете сильнее давить на газ.

В результате всего этого сэкономить явно не удастся. Очень быстро вы потратите на топливо деньги, которые лучше использовать для покупки нового лямбда-зонда. Конечно, иногда приобрести новый датчик просто нет возможности. В таких случаях некоторое время можно ездить и без него.

Причины выхода из строя датчика и обманки

Лямбда-зонд, как и все детали автомобиля, имеет определенный срок службы. Но ускорить его износ может использование некачественного топлива. Кроме этого, его расположение внизу автомобиля делает датчик кислорода уязвимым к механическим повреждениям. Нередки случаи повреждения проводки или разъема датчика.

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

Предыдущая запись

Следующая запись

Отключение кислородных датчиков лямбда-зонд

С 1 марта 2006 г в РФ был введен обязательный стандарт Евро-2. Согласно этому стандарту, на всех новых продаваемых бензиновых автомобилях содержание CO в выхлопных газах не должно превышать 0,5% на холостых оборотах и 0,3% — на повышенных. К слову, в Европе этот стандарт был введен десятью годами ранее, но речь не об этом. Речь о том, что с того момента все новые машины, продаваемые на территории РФ, в обязательном порядке стали комплектоваться лямбда-зондами, устанавливаемыми до катализатора.

Установленный до катализатора лямбда-зонд (его еще называют «лямбда-зонд 1» или «верхний датчик кислорода»), оценивает содержание кислорода в выхлопных газах. И по его показаниям «мозги» двигателя видят – богатая топливная смесь сейчас в двигателе или бедная, тем самым подстраивая ее до стехиометрических условий (когда соотношение воздуха и топлива идеальное). Именно при этих условиях происходит наилучшее (для экологии) сгорание топливной смеси, а содержание CO в выхлопных газах не превышает норму. Более того, при этих условиях достигается оптимальное соотношение мощности двигателя и расхода топлива.

Чуть позже был введен обязательный стандарт Евро-3. И для его выполнения машины стали комплектоваться дополнительным лямбда-зондом, установленным после катализатора (его еще называют «лямбда-зонд 2» или «нижний кислородный датчик»). Задача этого датчика — оценивать состояние катализатора. Фактически он сообщает «мозгам» двигателя – справляется ли катализатор со своей основной задачей (дожигом несгоревшего в двигателе бензина). И если катализатор уже не справляется, то «мозги» двигателя зажигают индикатор Check Engine и записывают в память ошибку (код ошибки P0420 или P0430).

Теперь, когда мы разобрались, что такое лямбда-зонды и зачем их начали ставить на автомобили, представим, что произойдет если какой-то из лямбда-зондов перестанет нормально работать. Во-первых, загорится индикатор Check Engine на приборной панели, а в память ЭБУ запишется одна (или несколько) из следующих ошибок: P0130, P0131, P0132, P0133, P0134, P0135, P0136, P0137, P0138, P0139, P0140, P0141 (хотя возможны и другие коды ошибок). Если проблема возникла по «верхнему кислородному датчику», то возможна также неравномерная работа двигателя, плохая тяга, дерганья при движении, перерасход топлива. Если проблема возникла по «нижнему кислородному датчику», то ничего серьезного не произойдет. Разве что ЭБУ не сможет диагностировать состояние катализатора и может повыситься расход топлива.

Напрашивается резонный вопрос – зачем же отключать лямбда-зонды? На самом деле, отключать первый лямбда-зонд (который стоит до катализатора и по которому регулируется топливная смесь) большого смысла нет. Если он вышел из строя, гораздо разумнее (в финансовых соображениях) просто поменять его на новый. Единственная разумная причина, по которой есть смысл отключить первую «лямбду» — подготовка автомобиля для поездок в лес или дальние рейсы, где нет возможности чинить машину и покупать запчасти, где от отказоустойчивости автомобиля зависит прибыль или даже жизнь, где расход топлива не так важен, как надежность машины. Отключение первого лямбда-зонда (то есть перевод автомобиля на нормы Евро-0), как правило, делают на рейсовых Газелях, а также УАЗиках, предназначенных для поездок на охоту или рыбалку.

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

Остается последний и самый интересный вопрос – как правильно отключать лямбда-зонды? Парадокс заключается в том, что снятие штекера с разъема датчика не исключит его из работы двигателя. Станет только хуже – на приборной панели загорится Check Engine, а «мозги» двигателя начнут функционировать по аварийному режиму. Чтобы полностью исключить определенный лямбда-зонд из работы двигателя, необходимо менять прошивку ЭБУ. То есть загружать такую прошивку, в алгоритме которой лямбда-зонд не принимает никакого участия. Впрочем, для нашей лаборатории чип-тюнинга это не представляет сложности. У нас имеются все необходимое оборудование (программаторы, программы редактирования прошивок и т.д.), для того чтобы быстро и качественно отключить определенный лямбда-зонд на вашем автомобиле.

Итак, допустим, что вы хотите отключить лямбда-зонд на вашем автомобиле, и вы задаетесь вопросом – с чего начать. Начать можно со звонка в нашу фирму или даже личного визита к нам, для получения развернутой консультации. Наш телефон: (8212) 42-55-00, наш адрес: г. Сыктывкар, ул. Дырнос, д. 3/15 (возле ГИБДД). Мы ответим на любой ваш вопрос, запишем вас на удобное вам время, выполним работы качественно и в оговоренные сроки.

Мы заставим ваш автомобиль ехать лучше!

Чипануть!

Можете ли вы остановить выполнение AWS Lambda?

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

Можно ли остановить функцию AWS Lambda? Невозможно остановить выполняемую в данный момент функцию AWS Lambda. Но вы можете остановить будущие вызовы, установив параллелизм на ноль или отключив интеграцию.

Итак, есть несколько различных аспектов темы остановки Lambda. Позвольте мне рассказать вам о нескольких различных вариантах остановки вашей функции AWS Lambda, чтобы вы могли решить, какой из них наиболее подходит для вашей ситуации.

Установить параллелизм на ноль

Один из основных способов остановить Lambda — установить нулевой предел параллелизма. Обратите внимание, что установка параллелизма на ноль не остановит какие-либо текущие лямбда-функции, но предотвратит запуск любых новых лямбда-функций.

Вы можете установить параллелизм лямбда на ноль из интерфейса консоли лямбда, нажав кнопку дроссельной заслонки на странице функции лямбда. Или вы можете установить свойство параллелизма через интерфейс командной строки. Вот так…

Отключить интеграции (например, Kinesis)

Еще один вариант остановки выполнения Lamba — отключить интеграции. Например, если вы используете что-то вроде Kinesis, отключив интеграцию, вы предотвратите запуск Kinesis в будущем.

Вы можете «отключить» интеграцию kinesis в AWS Lambda, щелкнув интеграцию и нажав «отключить». Примечание. Отключение интеграции с Kinesis не приведет к удалению сообщений из вашего потока Kinesis, пока они не достигнут установленного вами срока хранения Kinesis, который по умолчанию составляет 24 часа.

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

Установите более низкое время ожидания

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

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

Вы можете установить свойство тайм-аута в основных настройках вашего Lambda или с помощью метода конфигурации функции обновления в интерфейсе командной строки AWS.

Удалить разрешения IAM

Другой вариант остановки функции Lambda — удалить все соответствующие разрешения на выполнение. Прежде чем какой-либо ресурс сможет активировать вашу функцию Lambda, ваша Lambda должна иметь соответствующее разрешение для своей роли IAM.

Если вы хотите остановить будущие вызовы, простой способ сделать это — удалить соответствующее разрешение из роли IAM, связанной с вашей Lambda. Вы можете найти ссылку на роль IAM на вкладке разрешений Lambda.

Удалить повторные попытки

Окончательное решение, которое поможет остановить вашу лямбда-функцию, — убедиться, что у вас есть правильные настройки повторных попыток для вашего сценария. По умолчанию AWS Lambda повторяет асинхронные события несколько раз.

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

Параметры повтора можно найти в разделе «асинхронный вызов» консоли AWS Lambda или обновить свойство с помощью команды AWS CLI update-function-configuration.

Stop That Lambda

Надеемся, что этот обзор вариантов остановки функции AWS Lambda помог указать вам правильное направление.

Чтобы быстро резюмировать то, что мы рассмотрели: выполнение функций Lambda нельзя остановить, но вы можете отключить такие интеграции, как kinesis, или, при необходимости, отключить вызовы, установив параллелизм на ноль или удалив разрешения IAM.

Для полного ознакомления с различными настройками AWS Lambda обязательно ознакомьтесь со статьей «Освойте консоль AWS Lambda: подробное пошаговое руководство». или узнать больше о Serverless: Serverless: полное руководство.

• Автор
• Последние сообщения

Лу Бичард

Привет, я Лу! Я облачный инженер-программист из Лондона. Я создал Open Up The Cloud, чтобы помочь людям начать и развивать свою карьеру в облаке. Я редактирую ежемесячный информационный бюллетень Open Up The Cloud, который, я думаю, вам очень понравится. Вы можете найти меня в Twitter или LinkedIn, я всегда рад общению. Когда я не пишу, вы обычно можете увидеть, как я поднимаю тяжелые вещи и опускаю их или еду на двух колесах (иногда с двигателем, иногда без него).

Последние сообщения Лу Бичарда (посмотреть все)

Опубликовано Пятница, 23 октября 2020 г.

Категории: AWS, Serverless

Как включить/отключить лямбда-триггер по расписанию | Зак Чарльз

Эта тема заставляет меня задуматься: « зачем нам это делать? » и «можем ли мы вместо этого сделать что-то еще?» . Тем не менее, эта тема время от времени поднимается, и вы достаточно заинтересованы, чтобы читать этот пост, поэтому давайте обсудим и рассмотрим несколько решений.

Я использую «триггер» в качестве сокращения для сопоставлений источников событий , которые интегрируют Lambda с SQS, DynamoDB Streams, Kinesis, Kafka и т. д. по некоторым причинам, по которым я обычно стараюсь не включать и не отключать сопоставления источников событий Lambda по расписанию.

• Нативного способа сделать это не существует, поэтому любое решение усложняет и повышает риск, требуя дополнительной инфраструктуры и, возможно, кода.
• Отключение и включение триггеров, скорее всего, повлияет на такие атрибуты качества, как задержка и доступность, неинтуитивным образом.
• Пауза в обработке может привести к непреодолимому отставанию, если не учитывать ее должным образом.
• Запланированные изменения в инфраструктуре и поведении обработки сделают работу системы более сложной.
• Любые всплески активности при повторном включении триггера могут вызвать больше проблем с нисходящим потоком, чем те, которые были предотвращены.
• Желание сделать что-то подобное часто указывает на то, что вместо этого можно улучшить что-то другое.

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

Предотвратить перегрузку нижестоящего компонента

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

Что-то можно делать только в определенное время или в определенные дни

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

Действие должно происходить только в определенное время

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

Пакетная работа

Возможно, намного эффективнее и дешевле обрабатывать элементы большими партиями, чем по отдельности, поэтому вы позволяете им стоять в очереди с течением времени (дольше, чем 5 минут, которые уже поддерживаются для таких источников, как SQS).

Требования третьих сторон

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

Ваша уникальная причина

Вы нашли этот пост в блоге, потому что у вас была причина? Что это? Я хотел бы знать. Прокомментируйте, пожалуйста!

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

Общие ресурсы

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

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

Общие ограничения

Это особенно применимо в облачных средах, таких как AWS. Хорошим примером является параллелизм Lambda, где каждая учетная запись по умолчанию получает 1000 одновременных вызовов. Это ограничение распределяется между всеми функциями в учетной записи, и при его превышении вызовы регулируются, поэтому функции, принадлежащие разным службам, могут мешать друг другу.

Регулируемые вызовы могут подойти для некоторых фоновых рабочих нагрузок, но вы, вероятно, не хотите, чтобы Lambda ограничивала функции, отвечающие на HTTP-запросы через шлюз API, например.

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

Синхронный обмен сообщениями

Службы, взаимодействующие с другой службой с помощью синхронного обмена сообщениями типа запрос/ответ, например HTTP, связаны во времени, поскольку другая служба должна быть доступна для первой, чтобы выполнить свою работу. Более того, другая служба должна иметь мощность для вашей рабочей нагрузки, как и любая другая. Увеличение активности одного сервиса может легко помешать другому.

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

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

Конфликт при асинхронном обмене сообщениями

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

В этом примере реализация очереди с приоритетом может позволить обрабатывать более важные сообщения в первую очередь. У AWS есть интересная запись в блоге на эту тему под названием «Реализация приоритетной очереди с помощью Amazon DynamoDB». Другой вариант — использовать разные очереди для разных уровней приоритета. Это можно сделать с помощью фильтрации сообщений SNS или шаблонов событий EventBridge для различной маршрутизации сообщений, или вы можете просто попросить клиентов отправлять сообщения в нужную очередь. Другой вариант — сортировать сообщения в одной очереди, перемещая их в другие очереди, предполагая, что операция сортировки дешевле, чем фактическое выполнение работы. В любом случае идея состоит в том, что ресурсы, предназначенные для обработки сообщений с высоким приоритетом, не потребляются сообщениями с более низким приоритетом.

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

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

Давайте рассмотрим сценарий «Работать только ночью», в котором мы хотим, чтобы наше сопоставление источников событий включалось каждую ночь между 01:00 и 06:00 .

Действие UpdateEventSourceMapping API Lambda используется для включения/отключения. Это действие принимает UUID сопоставления источника события, а все остальное не является обязательным. Нас интересует только обновление свойства Enabled.

В 01:00 мы хотим вызвать это действие и установить для Enabled значение true .
В 06:00 мы хотим вызвать его снова и установить для Enabled значение false .

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

Правила EventBridge поддерживают выражения cron с точностью до минуты. Такие веб-сайты, как crontab.guru, помогают создавать эти загадочные выражения. Вы также можете использовать консоль EventBridge для предварительного просмотра следующих 10 случаев срабатывания правила. Обратите внимание, что выражения расписания EventBridge указаны в формате UTC.

Мы хотим запланировать включение для 0 1 * * ? * (01:00 UTC каждый день).
Мы хотим запланировать отключение для 0 6 * * ? * (06:00 UTC каждый день).

EventBridge не может напрямую вызвать действие UpdateEventSourceMapping, поэтому нам нужен какой-то связующий элемент между ними. Автоматизация инфраструктуры — одно из преимуществ Lambda, и EventBridge может ориентироваться на Lambda, так что это очевидный выбор. Сначала посмотрим на это, а потом на интересную альтернативу.

Этот вариант включает в себя написание небольшой функции, которая вызывает Lambda API для включения или отключения сопоставления источников событий.

В качестве доказательства концепции я создал базовую функцию Node.js, которая принимает UUID отображения источника события и новое значение для Enabled, а затем просто вызывает updateEventSourceMapping. Этот код достаточно простой, чтобы его можно было включить в шаблон CloudFormation, что упрощает развертывание.

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

Целевые объекты правила EventBridge можно настроить с помощью постоянного значения JSON text , которое будет передано функции. В приведенном ниже примере я нашел UUID, запустив list-event-source-mappings (попробуйте использовать AWS CloudShell).

Плюсы и минусы

Этот подход прост, дешев и использует Lambda для одной из своих целей. Если вы привыкли работать с лямбда-функциями, то здесь у вас не возникнет проблем.

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

Я думаю, что плюсы перевешивают минусы, и это вполне разумная реализация. Сказав это, давайте посмотрим на другое решение.

На момент написания API Gateway может действовать как прокси для 104 других сервисов AWS. Эти интеграции служб очень гибкие, позволяя вам вызывать действия в других службах без написания кода, включая UpdateEventSourceMapping.

Чтобы понять, как настроить интеграцию службы, просмотрите раздел «Синтаксис запроса» в документации по действию. В частности, нас интересуют:

• HTTP-метод: PUT,
• Путь: /2015-03-31/event-source-mappings/UUID ,
• Заголовки: Тип содержимого: application/json и
• Тело: { "Enabled": boolean }

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

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

В EventBridge нам нужно внести некоторые изменения:

• Установить целью правила API Gateway.
• Настройте правильный API, этап развертывания и цель интеграции.
• Добавьте заголовок с ключом Content-Type и значением application/json .
• Изменить константный текст JSON . Теперь он будет использоваться для тела HTTP и проксироваться в UpdateEventSourceMapping, поэтому он должен соответствовать Lambda API:

Безопасность

Шлюз API поддерживает три разных типа конечных точек; периферийно-оптимизированные, региональные и частные. Нет смысла использовать конечную точку, оптимизированную для периферии, поскольку и EventBridge, и Lambda являются региональными. Поскольку EventBridge не поддерживает частные конечные точки API, мы должны использовать региональную конечную точку .

Региональные конечные точки общедоступны по умолчанию , и, очевидно, мы не хотим, чтобы кто-либо в Интернете мог что-либо включать или отключать. К счастью, это легко решить, включив авторизацию IAM в API Gateway.

При авторизации, установленной на AWS_IAM , вызовы API теперь должны быть подписаны учетными данными AWS. Если вы дополнительно не настроите политику ресурсов, учетные данные должны быть от той же учетной записи и разрешать execute-api:Invoke в API.

После настройки роли IAM, подобной приведенной ниже, EventBridge будет обрабатывать запросы на подпись и сможет снова вызывать ваш API.

В этой конфигурации ваш API защищен IAM в основном так же, как базовый Lambda API.

Плюсы и минусы

Использование интеграции службы API Gateway вместо Lambda означает, что вы не развертываете дополнительный код. Он по-прежнему бессерверен, поэтому вы ничего не платите между вызовами. Как только вы разберетесь в интеграции сервисов, это решение станет таким же простым, если не проще, чем вариант Lambda.

API-интерфейсы REST шлюза API стоят дороже, чем функции Lambda, но здесь речь идет о долях цента в месяц.