Блог

Это не так.

Документация для Boto3 не очень хорошо описывает цепочку учетных данных, но в документации CLI показаны различные источники учетных данных (и, поскольку CLI написан на Python, он предоставляет авторитетную документацию).

В отличие от EC2 и ECS, которые извлекают учетные данные на основе ролей из метаданных экземпляра, Lambda предоставляет учетные данные в переменных среды. Среда выполнения Lambda устанавливает эти переменные среды при запуске, и каждый вызов этой среды выполнения Lambda использует одни и те же значения.

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

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

Обновить:

Вот Лямбда Питона, которая демонстрирует то, что я сказал выше. Как часть своего кода инициализации (вне обработчика) он записывает, когда он был впервые инициализирован, а затем сообщает об этой отметке времени всякий раз, когда он вызывается. Он также регистрирует текущее содержимое переменных среды «AWS», чтобы вы могли видеть, изменяется ли какая-либо из них.

 import json
import os
from datetime import datetime

print("initializing environment")
init_timestamp = datetime.utcnow()

def lambda_handler(event, context):
    print(f"environment was initialized at {init_timestamp.isoformat()}")
    print("")
    print("**** env ****")
    keys = list(os.environ.keys())
    keys.sort()
    for k in keys:
        if k.startswith("AWS_"):
            print(f"{k}: {os.environ[k]}")
 

Настройте его для обеспечения параллелизма, а затем используйте эту команду командной оболочки, чтобы вызывать его каждые 45 секунд:

 while true ; do date ; aws lambda invoke --function-name InvocationExplorer:2 --invocation-type Event --payload '{"foo": "irrelevant"}' /tmp/$ ; sleep 45 ; done
 

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

 2021-10-19T16:19:32.699-04:00   initializing environment
2021-10-19T16:30:57.240-04:00   START RequestId: a27f6802-c7e6-4f70-b890-2e0172d46780 Version: 2
2021-10-19T16:30:57.243-04:00   environment was initialized at 2021-10-19T16:19:32.699455 
...
2021-10-19T17:07:24.853-04:00   END RequestId: dd9a356f-7928-4bf9-be56-86f4c5e1bb64
2021-10-19T17:07:24.853-04:00   REPORT RequestId: dd9a356f-7928-4bf9-be56-86f4c5e1bb64 Duration: 1.00 ms Billed Duration: 2 ms Memory Size: 128 MB Max Memory Used: 39 MB 
 

Как вы можете видеть, Лямбда-код был инициализирован в 16:19:32, когда я включил параллелизм подготовки. Первый запрос был обработан в 16:30:57.

Но то, что я хочу вызвать, — это последний запрос в этом потоке журналов, в 17:07:24, или примерно через 48 минут после инициализации Лямбды.

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

 2021-10-19T17:04:08.739-04:00   initializing environment
2021-10-19T17:08:10.276-04:00   START RequestId: 6b15ba7c-91e2-4f91-bb6c-99b9877f1ebf Version: 2
2021-10-19T17:08:10.279-04:00   environment was initialized at 2021-10-19T17:04:08.739398 
 

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

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