Это скорее предложение, которое мне нужно.
Зачем нужен API Gateway, если мы можем напрямую выполнять функции Lambda из приложений?
Какие недостающие части предоставляет API Gateway, которые мы иначе пропустим при использовании голой лямбды?
Несколько причин, по которым я лично выбрал API Gateway вместо прямых вызовов Lambda:
Очевидные случаи - это устаревшие случаи, когда у вас есть какой-либо компонент, который потребует использования AWS SDK для выполнения вызова Lambda. Иногда добавить SDK достаточно просто, но иногда, например, в чистом коде C, это может быть обременительным. В любом случае проще перейти от использования существующей конечной точки REST к AWS API Gateway, поскольку в большинстве случаев это происходит одинаково, просто изменяя или вызывая URL.
В некотором смысле это вариант Legacy, но гораздо проще получить прямой доступ к конечной точке REST, чем к конечной точке Lambda. Примечательно, что вполне возможно создать функцию Lambda, которая возвращает HTML, предназначенный для просмотра человеком через браузер, и заставляет его «посещать» вашу Lambda, напрямую вызывая обслуживающий его шлюз API.
Шлюзы API могут не проходить аутентификацию или аутентифицироваться с помощью IAM или Cognito. Может быть полезно иметь полусекретные конечные точки, к которым любой компонент или пользователь может получить доступ без необходимости аутентификации, или даже полностью общедоступные конечные точки Lambda, к которым вы разрешаете пользователям доступ. Или вы можете использовать учетные записи пользователей с поддержкой AWS Cognito, чтобы ваши пользователи могли получить доступ к некоторым элементам вашей экосистемы, не нуждаясь в самих учетных записях IAM.
И по одной причине, почему я избегаю использования шлюзов API. Есть добавленная стоимость. В большинстве случаев это небольшие затраты, но когда вы начинаете запускать что-то в достаточно большом масштабе, стоимость API Gateway может быть фактором. И, конечно же, добавление API Gateway к вашему развертыванию может усложнить ситуацию.