What is amazon api gateway?

Lambda requirements for container images

To deploy a container image to Lambda, note the following requirements:

1. The container image must implement the Lambda Runtime API. The AWS
   open-source implement the API. You can
   add a runtime interface client to your preferred base image to make it compatible
   with Lambda.

2. The container image must be able to run on a read-only file system. Your function
   code can access a
   writable directory with 512 MB of storage.

3. The default Lambda user must be able to read all the files required to run your function
   code. Lambda
   follows security best practices by defining a default Linux user with least-privileged
   permissions. Verify
   that your application code does not rely on files that other Linux users are restricted
   from running.

4. Lambda supports only Linux-based container images.

5. Lambda provides multi-architecture base images. However, the image you build for your
   function must target
   only one of the architectures. Lambda does not support functions that use multi-architecture
   container
   images.

Настройка сети для самостоятельно установленной Kafka

Инстансы Amazon EC2 с запущенной Kafka лучше всего разворачивать в приватных подсетях. Для того чтобы функция Lambda могла опрашивать инстансы Kafka, вам необходимо убедиться в том, что в публичной подсети каждой зоны доступности (AZ) запущен NAT Gateway.

В окружениях, предназначенных для тестирования и разработки, можно настроить маршрутизацию трафика через один NAT Gateway в одной AZ. Для производственных рабочих нагрузок в целях резервного дублирования рекомендуется, чтобы в каждой зоне доступности было развёрнуто по одному NAT Gateway. Шаги ниже помогут вам развернуть следующую архитектуру:

1. Создайте VPC с публичными и приватными подсетями и NAT Gateway, обеспечивающим доступ в Интернет. Чтобы развернуть такую инфраструктуру с помощью AWS CloudFormation, используйте данный шаблон.
2. Из консоли управления VPC отредактируйте группу безопасности по умолчанию, созданную этим шаблоном, чтобы разрешить входящий трафик на следующие порты:
   • Custom TCP: порты 2888-3888 со всех IP-адресов.
   • SSH (порт 22), только с вашего IP-адреса.
   • Custom TCP: порт 2181 со всех IP-адресов.
   • Custom TCP: порт 9092 со всех IP-адресов.
   • Весь трафик от ресурсов в той же самой группе безопасности.

(Optional) Step 4: Clean up

To prevent unnecessary costs, delete the resources that you created as part of this
getting started exercise.
The following steps delete your HTTP API, your Lambda function, and associated resources.

To delete an HTTP API

1. Sign in to the API Gateway console at https://console.aws.amazon.com/apigateway.

2. On the APIs page, select an API. Choose Actions, and then choose
   Delete.

3. Choose Delete.

To delete a Lambda function

1. Sign in to the Lambda console at https://console.aws.amazon.com/lambda.

2. On the Functions page, select a function. Choose Actions, and
   then choose Delete.

3. Choose Delete.

To delete a Lambda function’s log group

1. In the Amazon CloudWatch console, open the .

2. On the Log groups page, select the function’s log group
   (). Choose Actions, and then choose
   Delete log group.

3. Choose Delete.

To delete a Lambda function’s execution role

1. In the AWS Identity and Access Management console, open the .

2. Select the function’s role, for example,
   .

3. Choose Delete role.

4. Choose Yes, delete.

You can automate the creation and cleanup of AWS resources by using AWS CloudFormation
or AWS SAM. For example AWS CloudFormation
templates, see example
AWS CloudFormation templates.

Deploy and test the API

Deploy the API in the API Gateway console

1. Choose Deploy API from the Actions
   dropdown menu.

2. For Deployment stage, choose .

3. For Stage name, enter .

4. If desired, enter a Stage description.

5. If desired, enter a Deployment description.

6. Choose Deploy.

7. Note the API’s Invoke URL.

Use
browser and cURL to test an API with Lambda proxy integration

You can use a browser or cURL to test
your API.

To test requests using only query string parameters, you can type
the URL for the API’s resource into a browser address bar.
For example:
https://.execute-api..amazonaws.com/test/helloworld?name=John&city=Seattle

For other methods, you must use more advanced REST API testing utilities, such as
POSTMAN or cURL. This tutorial uses cURL. The cURL
command examples below assume that cURL is installed on your computer.

To test the deployed API using cURL:

1. Open a terminal window.

2. Copy the following cURL command and paste it into the terminal window,
   replacing with your API’s
   API ID and with the region
   where your API is deployed.

   Note

   If you’re running the command on Windows, use this syntax
   instead:

You should get a successful response with a payload similar to the
following:

If you change to in the preceding method
request, you should get the same response.

To test the method, copy the following command and paste it
into the terminal window, replacing
with your API’s API ID and
with the region where your
API is deployed.

You should get a response similar to the result from the preceding
request, except that the request does not
have any payload. So the parameter will be .

Среда выполнения Lambda

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

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

До этого момента, только исполняемый процесс (runtime) мог влиять на жизненный цикл среды выполнения. Он взаимодействует с Runtime API посредством HTTP API endpoint, который находится внутри среды выполнения и взаимодействует с сервисом Lambda.

Lambda и Runtime API

Исполняемый процесс использует API для получения сообщений вызовов из Lambda и доставки их внутрь исполняемого кода функции. Затем он уведомляет сервис Lambda о результатах обработки переданного сообщения. После этого сервис Lambda снова «замораживает» среду выполнения.

До этого момента, исполняемый процесс Lambda проходил через две независимые фазы жизненного цикла в среде выполнения Lambda: Init и Invoke.

1. Init: в Init фазе, Lambda сервис инициирует исполняемый процесс (runtime), и затем запускает код инициализации функции (код за пределами обработчика main). Данная фаза происходит или в момент первичного запуска, или заранее – в случае включения Provisioned Concurrency режима.
2. Invoke: в Invoke фазе, исполняемый процесс (runtime) получает событие вызова от сервиса Lambda и запускает обработчик функции. Затем он возвращает результат вызова в Runtime API.

После окончания выполнения функции сервис Lambda «замораживает» среду выполнения и сохраняет её какое-то время на случай последущего вызова.

Если Lambda функция не получает вызовы в течение какого-то времени, сервис Lambda удаляет среду выполнения.

Предыдущий жизненный цикл Lambda

С появлением Extensions API расширения могут оказывать влияние, управлять и участвовать в жизненном цикле среды выполнения. Например, они могут использовать Extensions API для контроля «замораживания» среды выполнения сервиса Lambda.

Среда исполнения AWS Lambda с появлением Extensions API

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

Расширения позволяют интегрироваться с сервисом Lambda путём следующих изменений в его жизненном цикле:

1. Изменения фазы Init. Теперь существует три независимых Init задачи: Init расширения, Init исполняемого процесса, Init функции. Благодаря этому, у нас есть порядок запуска, где расширение и исполняемый процесс могут произвести операции по настройке перед запуском самой функции.
2. Больше контроля во время запуска. Во время фазы Invoke, как и раньше, исполняемый процесс (runtime) получает событие вызова от сервиса Lambda и запускает обработчик функции. В дополнение к этому, расширения могут получать и обрабатывать события об изменениях в жизненном цикле от сервиса Lambda. Они могут запускать логику обработки в ответ на полученные события и информировать сервис Lambda об окончании обработки. Сервис Lambda «замораживает» среду выполнения после получения подтверждения от всех расширений и исполняемого процесса. Таким образом, расширения могут теперь влиять на процесс «заморозки»-«разморозки» среды выполнения.
3. Фаза завершения работы: также расширения теперь имеют возможность выполнить действия при завершении работы среды выполнения за счёт появления фазы «завершения работы». Сервис Lambda посылает событие о завершении работы, которое даёт сигнал исполняемому процессу и расширению, что среда исполнения вот-вот закончит свою работу.

Новый жизненный цикл Lambda с появлением расширений

Каждая фаза жизненного цикла Lambda начинается с события от сервиса Lambda, отосланного исполняемому процессу и всем зарегистрированным расширениям. Исполняемый процесс и расширения уведомляют о завершении обработки запросом события Next от  и Extensions API. Lambda «замораживает» среду выполнения и все расширения, когда не остаётся событий для обработки.

Жизненный цикл Lambda для среды выполнения, исполняемого процесса, расширений и функции.

Дополнительную информацию о фазах жизненного цикла и Extensions API смотрите в документации.

Настройка функции Lambda и привязка источника событий

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

Создайте функцию Lambda, которая использует самостоятельно установленный кластер Kafka и топик в качестве источника событий:

1. В консоли управления Lambda нажмите Create function.
2. Введите название функции и выберите Node.js 12.x в качестве среды выполнения.
3. В разделе Permissions, подразделе Execution role выберите название роли, чтобы открыть консоль управления IAM.
4. Нажмите Add inline policy и создайте новую политику с названием SelfHostedKafkaPolicy и следующими правами доступа. Замените секцию Resource на ARN ваших инстансов:
5. Нажмите Create policy и убедитесь, что политика появилась в списке Permissions policies.
6. Вернитесь в свойства функции Lambda, выберите раздел Configuration. В подразделе Designer нажмите Add trigger.
7. В выпадающем списке выберите Apache Kafka
   • В разделе Bootstrap servers добавьте IP-адреса обоих ранее созданных инстансов, добавив порт 9092.
   • В поле Topic name введите ‘test’.
   • Введите наиболее подходящие вам размер партии сообщений (batch size) и стартовый индекс сообщения (см. документацию, чтобы узнать больше).
   • В поле VPC выберите VPC, созданную ранее шаблоном CloudFormation.
   • В поле VPC subnets выберите обе приватные подсети.
   • В поле VPC security groups выберите созданную группу безопасности.
   • Нажмите Add.

Через несколько секунд состояние триггера в консоли Lambda изменится на Enabled. Спустя несколько минут, триггер начнёт получать сообщения из кластера Kafka.

Как расширения доставляются в Lambda и запускаются?

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

Для добавления нового слоя используйте Консоль управления AWS, Интерфейс командной строки AWS (AWS CLI) или подходы «инфраструктура-как-код», с помощью AWS CloudFormation, AWS Serverless Application Model (AWS SAM) и Terraform.

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

Расширения могут запускаться в одном из двух режимов – внутренний и внешний.

• Внутренние расширения запускаются как часть исполняемого процесса, в том же процессе, что и код вашей функции. Расширения в таком режиме не используют отдельные процессы. Внутренние расширения позволяют изменять процесс запуска исполняемого процесса, используя специфичные для языка переменные окружения и скрипты-обёртки. Вы можете использовать переменные окружения для добавления утилит к исполняемым процессам Java Correto 8 и 11, Node.js 10 и 12 и .NET Core 3.1. Скрипты-обёртки (Wrapper scripts) позволяют передать управление запуском рантайма вашему скрипту с целью дополнительной конфигурации процесса запуска. Вы можете использовать скрипты-обёртки с js 10 и 12, Python 3.8, Ruby 2.7, Java 8 и 11 и .NET Core 3.1. Для дополнительной информации смотрите раздел документации «Modifying the runtime environment».
• Внешние расширения позволяют запускать отдельный процесс относительно исполняемого процесса, но в той же среде выполнения, что и Lambda-функция. Внешние расширения могут запускаться перед исполняемым процессом и могут продолжать работу после завершения исполняемого процесса. Внешние расширения работают с js 10 и 12, Python 3.7 и 3.8, Ruby 2.5 и 2.7, Java Corretto 8 и 11, .NET Core 3.1 и пользовательскими средами выполнения.

Внешние расширения могут быть написаны на языке программирования, отличающимся от языка Lambda-функции. Мы рекомендуем разрабатывать внешние расширения, используя компилируемый язык программирования, и распространять их в виде бинарных файлов (self-contained binary). Такой подход гарантирует совместимость со всеми поддерживаемыми средами выполнения. В случае использования некомпилируемых языков программирования, убедитесь, что вы включили необходимый исполняемый файл в ваше расширение.

Расширения запускаются в той же среде выполнения, что и функция, и делят с ней ресурсы: CPU, память и дисковое хранилище. Они также получают одинаковые переменные окружения и права доступа, используя ту же роль AWS Identity and Access Management (IAM), что и функция.

Чтобы узнать больше о ресурсах, безопасности и аспектах производительности расширений, читайте блог-пост «Introducing AWS Lambda extensions».

Примеры расширений и скриптов-обёрток для разработки ваших собственных расширений вы можете найти в GitHub репозитории.

Java: Using the Java inner exception to store the redirection URI

Because Java is a strongly typed language, the Lambda function return value contains the Java exception type which you cannot override (nor should you). Thus, you will be using a different property to retrieve the redirection URI:

API Gateway Settings	Value
Method Response: HTTP Status	302
Integration Response: Header Mappings	Location:

The parameter is accessible in the Lambda function Java runtime as an inner exception.

is a class that extends .

The full response from Lambda received by API Gateway is the following:

Because Lambda serializes the inner exception type to the outer . you can still use the same Lambda error regex in API Gateway to detect a redirect from .

API Gateway Settings	Value
Integration Response: Lambda Error Regex

URI Request Parameters

The request uses the following URI parameters.

Up to 3583 bytes of base64-encoded data about the invoking client to pass to the function
in the context
object.

The name of the Lambda function, version, or alias.

Name formats

• Function name — (name-only), (with alias).

• Function ARN — .

• Partial ARN — .

You can append a version number or alias to any of the formats. The length constraint
applies only to the full ARN.
If you specify only the function name, it is limited to 64 characters in length.

Length Constraints: Minimum length of 1. Maximum length of 170.

Pattern:

Required: Yes

Choose from the following options.

• (default) — Invoke the function synchronously. Keep the connection open until
  the function returns a response or times out. The API response includes the function
  response and additional
  data.

  

  

  

  

  

  

  

  

  

  

• — Invoke the function asynchronously. Send events that fail multiple times to the
  function’s dead-letter queue (if it’s configured). The API response only includes
  a status code.

• — Validate parameter values and verify that the user or role has permission to invoke
  the function.

Valid Values:

Set to to include the execution log in the response. Applies to synchronously invoked functions
only.

Valid Values:

Specify a version or alias to invoke a published version of the function.

Length Constraints: Minimum length of 1. Maximum length of 128.

Pattern:

Публикации в блоге

Announcing HTTP APIs for Amazon API Gateway

 

Джордж Мао

4 ДЕКАБРЯ 2019 Г.

Building a Multi‑region Serverless Application with Amazon API Gateway and AWS Lambda

Стефано Булиани (Stefano Buliani) и Магнус Бьоркман (Magnus Bjorkman)

13 НОЯБРЯ 2017 Г.

Announcing WebSocket APIs in Amazon API Gateway

Диего Магальяйнс

18 ДЕКАБРЯ 2018 Г.

Как предоставлять сложные инфраструктуры по запросу с помощью Amazon API Gateway и AWS Lambda

Бен Эйкхорст (Ben Eichorst) и Вероника Меглер (Veronika Megler)

12 СЕНТЯБРЯ 2017 Г.

Using Enhanced Request Authrorizers in Amazon API Gateway

Стефано Булиани

27 СЕНТЯБРЯ 2017 Г.

 

Удаление шаблонной логики подтверждения в своих API REST с помощью технологии подтверждения запросов Amazon API Gateway

Брайан Листон

11 АПРЕЛЯ 2017 Г.

Monetize your APIs in AWS Marketplace using Amazon API Gateway

Брайан Листон

01 ДЕКАБРЯ 2016 Г.

Защищенный доступ по API с использованием объединенных удостоверений Amazon Cognito, пулов пользователей Amazon Cognito и Amazon API Gateway

Эд Лима

19 ИЮНЯ 2017 Г.

Санкционирование доступа к Amazon API Gateway и AWS Lambda через прокси-ресурс с использованием пулов пользователей Amazon Cognito

Брайан Листон

03 ФЕВРАЛЯ 2017 Г.

Generate Your Own API Gateway Developer Portal

Брайан Листон

01 ДЕКАБРЯ 2016 Г.

Дополнительные советы AWS, рекомендации и руководства см. в следующих блогах.

Reporting batch item failures

When your Lambda function encounters an error while processing a batch, all messages
in that batch become
visible in the queue again by default, including messages that Lambda processed successfully.
As a result, your
function can end up processing the same message several times.

To avoid reprocessing all messages in a failed batch, you can configure your event
source mapping to make only
the failed messages visible again. To do this, when configuring your event source
mapping, include the value
in the list. This lets your function
return a partial success, which can help reduce the number of unnecessary retries
on records.

Report syntax

After you include in your event source mapping configuration, you can
return a list of the failed message IDs in your function response. For example, suppose
you have a batch of five
messages, with message IDs , , , , and
. Your function successfully processes , , and
. To make messages and visible again in your queue, your
response syntax should look like the following:

To return the list of failed message IDs in the batch, you can use a class
object or create your own custom class. Here is an example of a response that uses
the
object.

To use this feature, your function must gracefully handle errors. Have your function
logic catch all
exceptions and report the messages that result in failure in in your function
response. If your function throws an exception, the entire batch is considered a complete
failure.

Note

If you’re using this feature with a FIFO queue, your function should stop processing
messages after the
first failure and return all failed and unprocessed messages in . This helps
preserve the ordering of messages in your queue.

Success and failure conditions

Lambda treats a batch as a complete success if your function returns any of the following:

• An empty list

• A null list

• An empty

• A null

Lambda treats a batch as a complete failure if your function returns any of the following:

• An invalid JSON response

• An empty string

• A null

• An with a bad key name

• An value with a message ID that doesn’t exist

CloudWatch metrics

To determine whether your function is correctly reporting batch item failures, you
can monitor the
and Amazon SQS metrics in
Amazon CloudWatch.

• tracks the number of messages removed from your queue. If this
  drops to 0, this is a sign that your function response is not correctly returning
  failed messages.

• tracks how long the oldest message has stayed in your queue.
  A sharp increase in this metric can indicate that your function is not correctly returning
  failed
  messages.

Next steps

For this example, you used the AWS Management Console to create a simple HTTP API.
The HTTP API invokes a Lambda
function and returns a response to clients.

The following are next steps as you continue to work with API Gateway.

• Configure additional types of API integrations,
  including:

To get help with Amazon API Gateway from the community, see the API Gateway
Discussion Forum. When you enter this forum, AWS might require you to sign in.

To get help with API Gateway directly from AWS, see the support options on the AWS Support page.

See also our frequently asked questions (FAQs), or
contact us directly.

Securing environment variables

For securing your environment variables, you can use server-side encryption to protect
your data at rest and
client-side encryption to protect your data in transit.

Note

To increase database security, we recommend that you use AWS Secrets Manager instead
of environment variables
to store database credentials. For more information, see Configuring database access for a Lambda
function.

Security at rest

Lambda always provides server-side encryption at rest with an AWS KMS key. By default,
Lambda uses an
AWS managed key. If this default behavior suits your workflow, you don’t need to set
anything else up. Lambda
creates the AWS managed key in your account and manages permissions to it for you.
AWS doesn’t charge you to
use this key.

If you prefer, you can provide an AWS KMS customer managed key instead. You might
do this to have control over rotation of
the KMS key or to meet the requirements of your organization for managing KMS keys.
When you use a customer managed key,
only users in your account with access to the KMS key can view or manage environment
variables on the
function.

Customer managed keys incur standard AWS KMS charges. For more information, see AWS Key Management Service pricing, in the AWS KMS product
pages.

Security in transit

For additional security, you can enable helpers for encryption in transit, which ensures
that your
environment variables are encrypted client-side for protection in transit.

To configure encryption for your environment variables

1. Use the AWS Key Management Service (AWS KMS) to create any customer managed keys for
   Lambda to use for server-side and client-side
   encryption. For more information, see Creating keys in the AWS Key Management Service Developer Guide.

2. Using the Lambda console, navigate to the Edit environment variables page.

   1. Open the of the Lambda console.

   2. Choose a function.

   3. Choose Configuration, then choose Environment variables from
      the left navigation bar.

   4. In the Environment variables section, choose Edit.

   5. Expand Encryption configuration.

3. Optionally, enable console encryption helpers to use client-side encryption to protect
   your data in
   transit.

   1. Under Encryption in transit, choose Enable helpers for encryption in
      transit.

   2. For each environment variable that you want to enable console encryption helpers for,
      choose
      Encrypt next to the environment variable.

   3. Under AWS KMS key to encrypt in transit, choose a customer managed key that you created
      at the beginning of
      this procedure.

   4. Choose Execution role policy and copy the policy. This policy grants permission
      to your function’s execution role to decrypt the environment variables.

      

      

      

      

      

      

      

      

      

      Save this policy to use in the last step of this procedure.

   5. Add code to your function that decrypts the environment variables. Choose Decrypt secrets
      snippet to see an example.

4. Optionally, specify your customer managed key for encryption at rest.

   1. Choose
      Use
      a customer master key.

   2. Choose a customer managed key that you created at the beginning of this procedure.

5. Choose Save.

6. Set up permissions.

   If you’re using a customer managed key with server-side encryption, grant permissions
   to any AWS Identity and Access Management (IAM) users
   or roles that you want to be able to view or manange environment variables on the
   function. For more
   information, see .

   If you’re enabling client-side encryption for security in transit, your function needs
   permission to call
   the API operation. Add the policy that you saved previously in this procedure to the
   function’s execution role.

Managing permissions to your server-side
encryption KMS key

No AWS KMS permissions are required for your user or the function’s execution role
to use the default
encryption key. To use a customer managed key, you need permission to use the key.
Lambda uses your permissions
to create a grant on the key. This allows Lambda to use it for encryption.

• – To view keys in the Lambda console.

• , – To configure a customer managed key on a
  function.

• – To view and manage environment variables that are encrypted with a
  customer managed key.

You can get these permissions from your user account or from a key’s resource-based
permissions policy.
is provided by the managed policies for
Lambda. Key policies grant the remaining permissions to users in the Key users
group.

Users without permissions can still manage functions, but they can’t view environment
variables or manage them in the Lambda console. To prevent a user from viewing environment
variables, add a
statement to the user’s permissions that denies access to the default key, a customer
managed key, or all
keys.

Example IAM policy – Deny access by key ARN

For details on managing key permissions, see Using key policies
in AWS KMS in the AWS Key Management Service Developer Guide.