Amazon SAA-C03: Бессерверные и событийно-ориентированные архитектуры / Интеграция API — Руководство по подготовке

By Laurynas Brazys · 19 July 2026 · #amazon #saa-c03 #certification #exam-prep #study-guide

Часть AWS SAA-C03 — Полное руководство по подготовке. Практикуйтесь с проверенными ответами в центре экзаменов Amazon, или пройдите тесты на время на ExamRoll.io.

AWS Lambda: модель выполнения, жизненный цикл среды выполнения и холодные старты

Lambda выполняет код в изолированных микро-ВМ Firecracker, которые следуют двухфазному жизненному циклу. Фаза INIT подготавливает контейнер, запускает среду выполнения, загружает и распаковывает пакет развертывания и выполняет любую инициализацию на уровне модуля — создание клиента SDK, загрузку секретов, расшифрованных с помощью KMS, настройку пула подключений к базе данных, загрузку классов JVM и прогрев JIT. Фаза INVOKE запускает обработчик (handler). Холодный старт влечет за собой полные затраты фазы INIT; теплый вызов повторно использует окружение, поэтому все, что кэшируется вне обработчика (пулы HTTP keep-alive, расшифрованные секреты, клиенты БД), сохраняется между вызовами в этом контейнере. Именно поэтому каноническим шаблоном является создание «дорогих» объектов в области видимости модуля и их повторное использование:

import boto3, os
ddb = boto3.client('dynamodb')          # reused across warm invokes
_secret = None
def _load_secret():
    global _secret
    if _secret is None:
        _secret = kms.decrypt(...)      # KMS call once per container, not per invoke
    return _secret

def handler(event, ctx):
    ...

Величина холодного старта зависит от среды выполнения. Для Node.js и Python это от десятков до нескольких сотен миллисекунд; для JVM и .NET время может превышать секунду. Для функций, подключенных к VPC, Hyperplane ENI в значительной степени амортизировали исторические задержки, связанные с подключением ENI, но размер пакета и «тяжелый» код в фазе INIT по-прежнему являются доминирующими факторами.

Три инструмента по-разному решают проблему холодных стартов:

SnapStart — это экономически выгодное решение для нагрузок на Java без жестких требований к задержкам: холодные старты сокращаются примерно на порядок без дополнительной платы за вызов. Provisioned concurrency — правильный выбор, когда синхронный API должен поддерживать p99 ниже, скажем, 100 мс во время всплесков; его настройка на уровень всплеска p95 сокращает разрыв в «хвостовых» задержках (tail-latency). Недостаточный размер — классическая ошибка: on-demand запускает новые контейнеры только при поступлении запроса, поэтому всплеск нагрузки приводит к многосекундным ожиданиям для реальных пользователей.

# SAM: SnapStart on a Java 17 function
MyJavaFn:
  Type: AWS::Serverless::Function
  Properties:
    Runtime: java17
    SnapStart: { ApplyOn: PublishedVersions }
    AutoPublishAlias: live

Саму Provisioned concurrency можно масштабировать с помощью Application Auto Scaling — запланированное действие, увеличивающее количество с 10 до 200 в 07:45 и обратно в 10:00, позволяет не платить за «прогретые» мощности ночью, устраняя при этом утренние холодные старты.

Выделение памяти одновременно является регулятором CPU: количество vCPU линейно масштабируется с объемом памяти до ~1769 МБ на vCPU. Функция с фиксированными 128 МБ может в итоге стоить дороже, чем функция с 1024 МБ, потому что удвоенное время выполнения часто превышает удвоенную цену за миллисекунду. Не гадайте — используйте AWS Lambda Power Tuning для перебора конфигураций на репрезентативных нагрузках.

Управление параллелизмом Lambda и защита нижестоящих систем

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

• Reserved concurrency ограничивает и резервирует количество одновременных выполнений, которое может использовать функция. Это выделяет емкость из пула аккаунта и защищает нижестоящие системы (небольшой инстанс RDS, API партнера с ограничениями скорости) от перегрузки.
• Provisioned concurrency предварительно инициализирует окружения — это рычаг управления задержкой, а не масштабированием.
• Unreserved account concurrency — это общий пул, по умолчанию 1000 на регион.

Предположение, что Lambda «масштабируется бесконечно», упускает из виду два ограничения. Во-первых, лимит одновременных выполнений на уровне аккаунта реален, а лимиты всплесков (начальные 500–3000 в зависимости от региона, затем +500/мин) определяют скорость наращивания мощности. При его превышении синхронные вызывающие стороны получают 429 TooManyRequestsException, что API Gateway отображает как ошибку 5xx. Во-вторых, нижестоящие системы имеют свои собственные лимиты: db.t3.micro с max_connections=85 не выдержит тысячи одновременных Lambda-функций, каждая из которых открывает соединение. PostgreSQL создает дочерний процесс (fork) для каждого соединения, потребляя ~10 МБ ОЗУ; даже при наличии свободных ресурсов CPU, одно только установление и разрыв соединений может полностью загрузить инстанс.

Два способа смягчения последствий: (1) RDS Proxy, который объединяет в пул и мультиплексирует множество клиентских соединений в небольшой набор постоянных соединений с бэкендом, и (2) добавление очереди, чтобы скорость обработки была отделена от скорости поступления запросов:

import psycopg2, os
conn = psycopg2.connect(
    host=os.environ['PROXY_ENDPOINT'],   # RDS Proxy, not the DB directly
    dbname='orders', user='app', password=get_secret())

RDS Proxy — это решение с минимальными изменениями (драйвер и строка подключения почти не меняются), что делает его правильным ответом, когда требуется «минимальное изменение приложения» плюс решение проблемы исчерпания подключений. У DynamoDB нет этой проблемы: ее HTTPS API не имеет состояния (stateless), поэтому DynamoDB естественным образом сочетается с Lambda-нагрузками с высоким коэффициентом ветвления (high-fanout).

Lambda: IAM, переменные окружения и сеть

Каждая функция при вызове принимает на себя роль выполнения (execution role). Политика доверия этой роли предоставляет разрешение sts:AssumeRole сервису lambda.amazonaws.com; её политика разрешений определяет, что функция может делать. Среда выполнения автоматически внедряет кратковременные учётные данные STS в переменные AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY и AWS_SESSION_TOKEN. Никогда не встраивайте ключи доступа IAM-пользователей в переменные окружения или код — они статичны, их можно обнаружить в утёкшем исходном коде или экспортах CloudTrail, их нужно ротировать вручную, и они обходят всю модель временных учётных данных.

FnRole:
  Type: AWS::IAM::Role
  Properties:
    AssumeRolePolicyDocument:
      Statement:
      - Effect: Allow
        Principal: { Service: lambda.amazonaws.com }
        Action: sts:AssumeRole
    Policies:
      - PolicyName: ReadOrders
        PolicyDocument:
          Statement:
          - Effect: Allow
            Action: ["dynamodb:GetItem", "dynamodb:Query"]
            Resource: !GetAtt OrdersTable.Arn

Переменные окружения, содержащие конфиденциальные данные, следует шифровать с помощью управляемого клиентом ключа KMS, используя «помощники для шифрования при передаче» (helpers for encryption in transit), чтобы консоль шифровала данные на стороне клиента. Расшифровывать их следует один раз на этапе INIT и кэшировать в переменной на уровне модуля — иначе каждый вызов будет оплачивать API-вызов к KMS.

По умолчанию функция запускается в управляемом AWS VPC с неограниченным доступом в интернет. Подключайте её к вашему собственному VPC только тогда, когда ей нужен доступ к ресурсам внутри VPC (RDS в приватных подсетях, ElastiCache, локальная сеть через Direct Connect). В этом случае Lambda подключает сетевые интерфейсы Hyperplane ENI в указанные вами подсети и наследует их маршрутизацию.

Классическая ловушка — поместить Lambda в приватную подсеть без маршрута для трафика к сервисам AWS, кроме как через NAT-шлюз, или, что ещё хуже, через самоуправляемый NAT-инстанс. NAT-инстансы упираются в производительность одного сетевого интерфейса, являются единой точкой отказа (SPOF) и тарифицируются за гигабайт. Даже NAT-шлюзы взимают плату за гигабайт и не являются необходимыми для трафика к сервисам AWS. Правильный подход:

• Шлюзовые VPC-эндпоинты (Gateway VPC endpoints) для S3 и DynamoDB (бесплатно)
• Интерфейсные эндпоинты (Interface endpoints, PrivateLink) для KMS, Secrets Manager, SQS, SNS, STS и подобных сервисов

Это позволяет сохранить трафик в магистральной сети AWS, устраняет ограничения пропускной способности NAT и предотвращает неожиданные счета за исходящий трафик. Важно отметить, что ENI для Lambda никогда не получают публичный IP-адрес; размещение функции в «публичной» подсети не даёт ей доступа в интернет — вам всё равно понадобится NAT-шлюз в отдельной публичной подсети с соответствующим маршрутом.

Amazon API Gateway: типы эндпоинтов, авторизация и доставка

API Gateway предлагает три вида API:

Выбирайте REST, когда вам нужны API-ключи и планы использования, валидация запросов по JSON Schema, шаблоны преобразования VTL, авторизаторы Cognito с областями видимости для каждого метода или WAF; выбирайте HTTP для легковесных прокси-сценариев с JWT-аутентификацией, где стоимость и задержка важнее.

Типы эндпоинтов определяют, где размещается фронтенд API:

• Edge-optimized (оптимизированный для границы сети): использует управляемую API Gateway дистрибуцию CloudFront; TLS-соединение терминируется в ближайшей точке присутствия (POP). Лучше всего подходит для глобально распределённых клиентов.
• Regional (региональный): доступен из одного региона без CloudFront. Лучше всего подходит, когда клиенты находятся в том же регионе, когда вы хотите использовать собственную дистрибуцию CloudFront или когда используется маршрутизация на основе задержки в Route 53 между несколькими регионами.
• Private (приватный): доступен только через интерфейсный VPC-эндпоинт. Лучше всего подходит для внутренних микросервисов, которые не должны проходить через публичный интернет.

Выбор edge-optimized для внутреннего API в одном регионе добавляет ненужный хоп через CloudFront и замедляет распространение развертываний. Выбор regional для глобально используемого публичного API заставляет каждый запрос проходить через публичный интернет до одного региона.

Пользовательские домены (Custom domains) требуют сертификатов ACM, расположение которых зависит от типа эндпоинта: us-east-1 для edge-optimized (CloudFront — глобальный сервис и терминирует TLS там); регион самого API для региональных эндпоинтов. Путаница в этом вопросе — типичная ошибка конфигурации. Сопоставления путей (Base path mappings) позволяют одному домену мультиплексировать несколько API (/orders → API заказов, /users → API пользователей).

Существует четыре модели авторизации, и использование чего-то кроме встроенных механизмов — классический антипаттерн:

Пользовательский Lambda-авторизатор добавляет дополнительный вызов на каждый запрос (или на время жизни кэша), ещё одну функцию для обновлений и мониторинга, а также путь в коде, где ошибки в проверке подписи могут незаметно разрешить доступ. Используйте его только тогда, когда встроенные механизмы действительно не могут удовлетворить требования.

Интеграция типа ‘Lambda proxy’ — это стандартный паттерн: весь запрос передаётся как событие, и функция должна вернуть ответ в определённой структуре:

{
  "statusCode": 200,
  "headers": {"Content-Type": "application/json"},
  "body": "{\"orderId\":\"abc123\"}",
  "isBase64Encoded": false
}

Для асинхронного приёма данных по принципу «отправил и забыл» при очень высоком TPS используйте прямую интеграцию API Gateway с сервисами AWS, чтобы отправлять данные напрямую в SQS или Kinesis, минуя Lambda. Это устраняет холодные старты на пути записи и разделяет скорость приёма данных от пропускной способности их обработки.

Для безопасного развертывания используйте канареечные развертывания (canary deployments) на стейдже: процент трафика направляется на новое развертывание, в то время как большинство остаётся на стабильной версии. Метрики CloudWatch для каждой «канарейки» помогают принять решение о полном переключении или откате.

aws apigateway update-stage --rest-api-id abc123 --stage-name prod \
  --patch-operations \
    op=replace,path=/canarySettings/percentTraffic,value=10 \
    op=replace,path=/canarySettings/deploymentId,value=xyz789

Для простого веб-хука, где громоздкая настройка API Gateway избыточна (например, колбэк от Slack для одного клиента, обработчик push-событий GitHub), URL-адреса функций Lambda (Lambda function URLs) предоставляют выделенный HTTPS-эндпоинт прямо на функции. Защищайте их с помощью AuthType: AWS_IAM, когда вызывающие стороны являются принципалами AWS; если NONE, вы обязаны проверять подпись запроса внутри функции. URL-адрес функции с AuthType: NONE и без проверки внутри самой функции — это анонимная вычислительная точка в публичном интернете.

Типы вызовов, повторные попытки и идемпотентность

Источники событий делятся на две категории с очень разным поведением. Push-источники (API Gateway, ALB, S3, SNS, EventBridge, Cognito) вызывают Lambda напрямую и требуют ресурсной политики AWS::Lambda::Permission, предоставляющей право lambda:InvokeFunction с правильным Principal (например, events.amazonaws.com) и SourceArn. Без нее правило будет соответствовать событиям, но каждый вызов будет молча отклонен — функция никогда не запустится, а сбои появятся только в CloudTrail. Это отличается от роли выполнения, которая определяет, что функция может делать, а не кто может ее вызывать.

Poll-источники (SQS, Kinesis, DynamoDB Streams, MSK) считываются сервисом Lambda через сопоставление источника событий — ресурсная политика не нужна, но роль выполнения должна предоставлять права на чтение.

Типы вызовов дополнительно влияют на поведение повторных попыток:

• Синхронный (API Gateway, ALB, SDK с RequestResponse): ошибки возвращаются немедленно; за повторные попытки отвечает вызывающая сторона.
• Асинхронный (S3, SNS, EventBridge): Lambda буферизует события во внутренней очереди и при сбое повторяет попытку дважды с задержками, затем отправляет в DLQ (очередь недоставленных сообщений) или в место назначения при сбое.
• Сопоставление источника событий SQS: SQS продолжает повторно доставлять сообщение, пока maxReceiveCount не инициирует его перемещение в DLQ исходной очереди.
• Kinesis / DynamoDB Streams: повторяет обработку одного пакета из шарда до успеха или истечения срока его хранения, блокируя шард на это время — застрявший пакет останавливает всю последующую обработку для этого раздела.

Поскольку повторные попытки встроены в каждый уровень, идемпотентность является обязательной, а не опциональной. Истечение тайм-аута видимости SQS во время медленной записи или асинхронный повтор после ошибки 5xx на стороне получателя приведут к появлению дубликатов. Канонический паттерн использует детерминированный ключ и условную запись в DynamoDB:

def handler(event, context):
    msg_id = event['Records'][0]['messageId']
    try:
        ddb.put_item(
            TableName='processed',
            Item={'id': {'S': msg_id}, 'ttl': {'N': str(ttl)}},
            ConditionExpression='attribute_not_exists(id)')
    except ddb.exceptions.ConditionalCheckFailedException:
        return  # already processed
    process(event)

Декоратор @idempotent из AWS Lambda Powertools реализует именно этот паттерн с использованием DynamoDB.

Разделение с помощью SQS и SNS

Прямое подключение push-источников с веерной рассылкой к Lambda является хрупким. Уведомления о событиях S3, например, синхронны для каждого события и подвержены влиянию лимита одновременных выполнений Lambda; если количество вызовов превысит доступный параллелизм во время всплеска загрузок (например, маркетинговая кампания загружает тысячи документов за секунды), окно повторных попыток S3 будет коротким, и события могут быть фактически потеряны. Решение — использовать буфер:

SNS — это сервис для реализации паттерна pub/sub (издатель-подписчик): одна публикация, множество подписчиков (SQS, Lambda, HTTPS, email). Фильтрация сообщений основана на атрибутах. SQS — это надёжная двухточечная очередь, хранящая сообщения до 14 дней. Рабочей комбинацией является веерная рассылка SNS → SQS, которая предоставляет каждому потребителю собственную буферизованную очередь для независимого масштабирования и повторной обработки.

Для строгого порядка (например, последовательная обработка заказов для каждого клиента) используйте очередь SQS FIFO с MessageGroupId, установленным в ключ упорядочивания. Сообщения в одной группе доставляются по порядку; разные группы обрабатываются параллельно. Стандартные очереди SQS обеспечивают доставку с негарантированным порядком.

Канонический паттерн разделенного приема данных использует прямую интеграцию API Gateway с SQS для поглощения всплесков и обработчик с ограниченной скоростью:

Resources:
  OrdersQueue:
    Type: AWS::SQS::Queue
    Properties:
      FifoQueue: true
      ContentBasedDeduplication: true
      RedrivePolicy:
        deadLetterTargetArn: !GetAtt OrdersDLQ.Arn
        maxReceiveCount: 5

  ProcessorFunction:
    Type: AWS::Lambda::Function
    Properties:
      ReservedConcurrentExecutions: 20   # cap the DB write rate

  Mapping:
    Type: AWS::Lambda::EventSourceMapping
    Properties:
      EventSourceArn: !GetAtt OrdersQueue.Arn
      FunctionName: !Ref ProcessorFunction
      BatchSize: 10

Зарезервированный параллелизм используется намеренно — он ограничивает скорость записи в базу данных, так что очередь (а не RDS) поглощает всплеск. Неудачные сообщения направляются в DLQ после maxReceiveCount для офлайн-анализа.

EventBridge: правила, трансформация входных данных и API Destinations

EventBridge — это шина событий с поддержкой схем, обладающая богатыми возможностями сопоставления по JSON-шаблону, источниками от SaaS-партнеров, реестром схем, а также функциями архивации и воспроизведения. Правила сопоставляют события по шаблонам и рассылают их более чем 30 типам целей (Lambda, Step Functions, SQS, Kinesis, ECS, Firehose), с фильтрацией на основе содержимого тела сообщения, а не только атрибутов, как в SNS:

{
  "source": ["tenant.energy"],
  "detail-type": ["UsageReported"],
  "detail": { "kWh": [{ "numeric": [">", 100] }] }
}

Правило может иметь до пяти целей, каждая из которых получает либо необработанное событие, либо его преобразованную часть. Трансформаторы входных данных обеспечивают слабую связанность: InputPathsMap извлекает JSON-пути из события, а InputTemplate преобразует их в тот формат, который ожидает цель:

EventPattern:
  source: ["com.acme.orders"]
  detail-type: ["OrderPlaced"]
Targets:
  - Arn: !GetAtt PaymentValidator.Arn
    InputTransformer:
      InputPathsMap:
        orderId: "$.detail.orderId"
        amount: "$.detail.total"
        card: "$.detail.payment.cardToken"
      InputTemplate: |
        {"orderId": <orderId>, "amount": <amount>, "cardToken": <card>}

Каждая Lambda-функция валидации получает только то, что ей нужно; валидатор адреса никогда не видит токен карты. Это решение значительно превосходит монолитную Lambda-функцию, которая получает полное событие и ветвится внутри — монолит концентрирует IAM-разрешения (одна роль должна иметь все разрешения для последующих сервисов), увеличивает радиус поражения при ошибке, связывает ритм развертывания, мешает настраивать память/тайм-аут для каждой отдельной задачи и заставляет всю функцию масштабироваться до уровня самой «шумной» ветви.

API destinations меняют направление: EventBridge вызывает внешний HTTPS-эндпоинт. В паре с соединением, которое хранит учетные данные Basic, API-key или OAuth в Secrets Manager, это бессерверный способ уведомить сторонний SaaS, когда, скажем, задание AWS Batch успешно завершилось — Lambda для этого не требуется. EventBridge перехватывает событие изменения состояния, правило соответствует JobSucceeded, и цель типа API destination отправляет POST-запрос поставщику с учетными данными, внедренными из соединения.

Правила по расписанию (выражения cron/rate) или более новый EventBridge Scheduler заменяют EC2-инстансы для проверки работоспособности (heartbeat) при выполнении периодических задач — ночных отчетов, ежечасного обновления кэша.

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

Step Functions: Оркестрация и распределённое отображение

Когда рабочий процесс состоит более чем из пары шагов, содержит ветвление, повторные попытки, требует одобрения человека или длительного ожидания, встраивание этой логики в цепочку Lambda-функций становится невозможным для поддержки. Step Functions выносит конечный автомат вовне, используя Amazon States Language.

• Стандартные рабочие процессы: выполняются до одного года, семантика «ровно один раз» (exactly-once), полная история выполнения, .waitForTaskToken для шлюзов, требующих участия человека или внешних систем. Примеры: выполнение заказов, ETL, процессы утверждения.
• Экспресс-рабочие процессы: выполняются до пяти минут, семантика «не менее одного раза» (at-least-once), большой объём, низкая стоимость за выполнение. Примеры: короткие синхронные оркестрации за API Gateway; преобразования для IoT и потоковых данных.

Каждая задача должна явно объявлять Retry и Catch:

"ValidatePayment": {
  "Type": "Task",
  "Resource": "arn:aws:states:::lambda:invoke",
  "Parameters": {"FunctionName": "PaymentValidator", "Payload.$": "$"},
  "Retry": [{
    "ErrorEquals": ["Lambda.ServiceException", "Lambda.TooManyRequestsException"],
    "IntervalSeconds": 2, "MaxAttempts": 4, "BackoffRate": 2.0
  }],
  "Catch": [{"ErrorEquals": ["PaymentDeclined"], "Next": "RefundStep"}],
  "Next": "ShipOrder"
}

Состояния Parallel и Map выполняют ветви параллельно и агрегируют результаты — это идеально подходит для систем обработки заказов с независимыми валидаторами (адрес, наличие товара, оплата). Состояние между шагами передаётся через JSON-документ выполнения, что избавляет от необходимости в общей базе данных, используемой исключительно для координации рабочего процесса.

Паттерн .waitForTaskToken приостанавливает выполнение до тех пор, пока внешний участник не вызовет SendTaskSuccess с токеном — это канонический ответ, когда рабочий процесс охватывает Lambda, EC2, контейнеры, локальные системы и требует ручного утверждения с минимальными операционными издержками:

"ManagerApproval": {
  "Type": "Task",
  "Resource": "arn:aws:states:::sns:publish.waitForTaskToken",
  "Parameters": {
    "TopicArn": "arn:aws:sns:us-east-1:111:approvals",
    "Message": { "TaskToken.$": "$$.Task.Token", "OrderId.$": "$.orderId" }
  },
  "Next": "Fulfill"
}

Распределённое отображение (Distributed Map) расширяет стандартное состояние Map для обработки до 10 000 параллельных дочерних выполнений и может напрямую итерировать по объектам в бакете S3 или по строкам в файле CSV/JSONL, с автоматической пакетной обработкой, созданием контрольных точек и отказоустойчивостью. Для тысяч полуструктурированных объектов S3 это наиболее эффективный с точки зрения эксплуатации вариант — укажите префикс, определите задачу для каждого элемента, и Step Functions возьмёт на себя веерное распределение (fan-out), MaxConcurrency, повторные попытки и агрегацию результатов:

{
  "Type": "Map",
  "ItemReader": {
    "Resource": "arn:aws:states:::s3:listObjectsV2",
    "Parameters": { "Bucket": "raw-events", "Prefix": "2024/" }
  },
  "MaxConcurrency": 1000,
  "ItemProcessor": {
    "ProcessorConfig": { "Mode": "DISTRIBUTED", "ExecutionType": "STANDARD" },
    "StartAt": "ProcessObject",
    "States": { "ProcessObject": { "Type": "Task", "Resource": "arn:aws:lambda:...:function:ProcessOne", "End": true } }
  }
}

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

Step Functions в сравнении с EventBridge: Step Functions подходит, когда вы контролируете последовательность и результат — состояние, ветвления, повторы, утверждения. EventBridge подходит, когда производители событий не знают и не должны знать, кто является потребителем, а потребители подключаются независимо.

Уведомления о событиях S3

Для обработки загрузок практически в реальном времени настройте уведомления о событиях S3 на s3:ObjectCreated:* (или на более конкретный вариант, такой как Put, Post, CompleteMultipartUpload) с Lambda в качестве цели — с учётом вышеупомянутых оговорок о всплесках нагрузки. Меры предосторожности:

• Установите зарезервированный параллелизм (reserved concurrency), чтобы защитить нижестоящую базу данных.
• Включите DLQ или назначение для сбоев (on-failure destination) для «отравленных» сообщений.
• Направляйте события S3 через EventBridge, когда нескольким потребителям нужны одни и те же события. Прямые конфигурации уведомлений S3 ограничены по количеству и выразительности; веерное распределение (fan-out) через EventBridge с преобразователями входных данных для каждой цели масштабируется гораздо лучше.

Потоковая обработка: Kinesis Data Streams vs. Firehose

Kinesis Data Streams (KDS) — это шардированный, упорядоченный, воспроизводимый журнал с хранением данных от 24 часов до 365 дней. Порядок сохраняется в пределах одного шарда и определяется ключом секционирования (partition key) — это критически важно для агрегации данных по устройствам или клиентам. Несколько потребителей могут считывать данные независимо (используйте enhanced fan-out для изоляции пропускной способности на каждого потребителя). Выбирайте KDS, когда вам нужно упорядоченное воспроизведение, несколько независимых потребителей или высокая пропускная способность на шард.

Kinesis Data Firehose — это полностью управляемый поток доставки данных в S3, Redshift, OpenSearch или Splunk со встроенной буферизацией (60 с или 1–128 МБ), опциональным преобразованием с помощью Lambda, сжатием (GZIP, Snappy) и конвертацией в Parquet/ORC. Не нужно управлять шардами. Firehose — это выбор с низкими операционными затратами, когда кастомные потребители и воспроизведение не требуются, а нужно просто доставлять данные практически в реальном времени.

Канонический конвейер для аналитики в реальном времени выглядит так: источники данных → KDS → Firehose → S3 (Parquet) → Athena/QuickSight, с опциональным обогащением данных с помощью Lambda в Firehose.

AWS Transfer Family для управляемого SFTP

Когда партнёрам требуется передача данных по SFTP, FTPS или FTP в S3 или EFS, AWS Transfer Family предоставляет управляемую, высокодоступную (multi-AZ) конечную точку, которая работает по протоколам, уже используемым клиентами. Аутентификация поддерживает пользователей, управляемых сервисом, SSH-ключи или кастомные IdP через API Gateway/Lambda. Файлы попадают напрямую в S3 с применёнными SSE и политиками жизненного цикла; политики IAM с ограниченной областью действия (scope-down) предоставляют каждому пользователю доступ только к определённому префиксу.

Создание такого решения самостоятельно на EC2 требует настройки безопасности OpenSSH, установки патчей, обеспечения высокой доступности между зонами (AZ), ротации ключей и отправки логов — всё это берёт на себя Transfer Family. Выбирайте его всякий раз, когда стоит задача «партнёры присылают нам файлы по SFTP», и вы хотите, чтобы файлы оказывались в S3 с минимальными операционными издержками.

Сборка канонического бессерверного паттерна

Простая в поддержке схема приёма ежечасных метрик для каждого клиента: датчики отправляют POST-запросы на API Gateway (HTTP API, региональный) → Lambda валидирует данные и публикует их в EventBridge → правила маршрутизируют событие в Lambda-функцию для записи в DynamoDB (ID клиента как ключ секции, часовой интервал как ключ сортировки) и, параллельно, в Firehose → S3 (Parquet) для аналитики. Новые потребители подключаются как дополнительные правила EventBridge, не затрагивая производителей — требование к расширяемости, которое один лишь SNS не смог бы удовлетворить так же чисто. В случаях, где важны стабильная пропускная способность и порядок (сверка счетов, потоки финансовых событий), замените EventBridge на Kinesis Data Streams и используйте enhanced fan-out для независимых потребителей.

Каталог антипаттернов: почему распространённые подходы приводят к сбоям

Использование NAT instance/gateway для трафика к сервисам AWS из Lambda в частных подсетях. NAT instance ограничивает пропускную способность сетевой картой одного EC2 и является SPOF; NAT gateway тарифицируется за гигабайт. Оба варианта избыточны для доступа к сервисам AWS. Используйте gateway endpoints для S3/DynamoDB и interface endpoints для всего остального.

Игнорирование холодных стартов в API, критичных к задержкам. В режиме on-demand контейнеры создаются только при поступлении запроса, поэтому при всплесках трафика нарушаются SLA. Настраивайте provisioned concurrency на уровне p95 для всплесков; используйте SnapStart для Java-нагрузок без жёстких требований к SLA.

Монолитная Lambda, которая получает полное событие и выполняет ветвление внутри себя. Это нарушает принцип наименьших привилегий (одна роль содержит все разрешения для последующих сервисов), связывает циклы развёртывания, мешает настраивать ресурсы для каждой отдельной задачи и масштабирует всю функцию по нагрузке самой активной ветви. Разделяйте функции по зонам ответственности; для их связи используйте EventBridge или Step Functions.

Прямые подключения к БД из множества функций Lambda. Общее число подключений равно количеству одновременных вызовов, так как контейнеры не разделяют пулы соединений. Решение: использовать RDS Proxy (пулинг соединений), reserved concurrency (ограничение частоты вызовов) или SQS (буферизация).

Синхронный вызов Lambda для приёма всплесков данных. Превышение concurrency приводит к ошибке 429 от API Gateway и 5xx для клиентов; прямые уведомления от S3 во время всплесков трафика молча отбрасывают события. Вставьте очередь SQS или используйте прямую интеграцию API Gateway → SQS.

Публичные URL-адреса функций Lambda с AuthType: NONE без проверки подписи внутри функции. Анонимные вычисления в публичном интернете. Используйте AWS_IAM для вызовов из AWS или проверяйте подписи для сторонних веб-хуков.

Пользовательский Lambda authorizer там, где подходит встроенный. Это добавляет задержку, ещё одну функцию, требующую обновлений, и путь выполнения кода, где ошибки в проверке подписи могут молча разрешить доступ. Предпочитайте авторизацию через IAM для субъектов AWS и Cognito authorizer для пулов пользователей.

Неправильный регион сертификата ACM для пользовательских доменов. Для edge-optimized эндпоинтов сертификат должен быть в регионе us-east-1; для regional — в том же регионе, где находится API.

Отсутствие AWS::Lambda::Permission для push-источников (EventBridge, S3, SNS). События соответствуют правилам, но вызовы молча отклоняются. Это разрешение отличается от роли выполнения (execution role): оно определяет, кто может вызывать функцию, а не что функция может делать.

Отсутствие идемпотентности. Повторные попытки происходят на каждом уровне: асинхронные вызовы, повторная доставка из SQS по истечении тайм-аута видимости, повторная обработка батчей в Kinesis. Без детерминированного ключа дедупликации и условной записи дубликаты неизбежны.

← Контейнеры и оркестрация · Все домены · Хранилища и жизненный цикл данных →

Отработать эти вопросы → · Тесты на время на ExamRoll.io →

Просмотреть Amazon →