AWS Лямбда-аккаунт Параллелизм, Регулирование - PullRequest
Новая
       29

AWS Лямбда-аккаунт Параллелизм, Регулирование

0 голосов
/ 16 марта 2019

Я рассматриваю НЕ использовать API-шлюз по соображениям производительности.Вместо этого я хочу представить лямбда-функцию непосредственно в Интернете.Требуются неаутентифицированные учетные данные IAM, предоставляемые AWS JavaScript SDK.Я понимаю, что это может быть проблемой, если плохой актер пытается вызвать мою функцию в астрономическом темпе и вызвать серьезные проблемы с оплатой.Я не думаю, что это вероятно, поскольку кто-то конкретно должен был бы нацелиться на мое приложение, запросить учетные данные IAM и затем вызвать запрос ... много работы для небольшого выигрыша, но ...

Для того, чтобызащитить мою лямбда-функцию от атаки, которую я рассматривал для обеспечения параллелизма учетной записи.По умолчанию функция одновременного доступа к учетной записи ограничена 1000 одновременных запросов к учетной записи.Я могу указать резервный параллелизм, специфичный для лямбда-функции, которая уменьшает оставшийся общий лимит параллелизма аккаунта (лимит параллелизма для остального аккаунта).

Будет ли это работать: создать фиктивную лямбда-функцию (не публично)доступный), установите фиктивную лямбда-функцию зарезервированной параллелизма на действительно высоком уровне, например, 950 ... это оставило бы 50 одновременных лямбда-запросов для моей "настоящей" лямбда-функции ... это кажется простым способом регулирования лямбды без использования шлюза API,и т.д.

Мысли?

Ответы [ 2 ]

2 голосов
/ 16 марта 2019

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

Лямбды поставляются с ограничением Reserved Concurrency , которое позволяет вам установить максимальное количество одновременно принятых лямбд. Если количество запросов превышает это ограничение, запросы на переполнение получат сообщение об ошибке 500.

Для установки одновременного лимита у вас есть несколько вариантов:

Консоль

В консоли AWS перейдите к своей лямбде, на странице конфигурации прокрутите вниз до поля Concurrency и выберите Reserved Concurrency (введите желаемое число 50)

enter image description here

Командная строка

Чтобы изменить Зарезервированный параллелизм через командную строку, используйте следующую команду : 

aws lambda put-function-concurrency --function-name YOUR_FUNCTION_NAME_HERE --reserved-concurrent-executions 50

Файл Serverless Framework

Если вы развертываете свои функции с помощью серверной платформы, вы можете изменить Reserved Concurrency для любой лямбды в разделе function вашего файла. 

service: stackoverflow # NOTE: update this with your service name

provider:
  name: aws
  runtime: python3.7
  stage: ${opt:stage, 'dev'}
  region: ${opt:region, 'us-east-1'}
  profile: ${opt:profile, 'default'}
  environment:
    region: ${self:provider.region}
    stage: ${self:provider.stage}
  stackTags:
    Owner : krapes
    Project : concurrencyLimits
    Service : concurrencyLimits
    Team : brokenLeg
  stackPolicy: # This policy allows updates to all resources
    - Effect: Allow
      Principal: "*"
      Action: "Update:*"
      Resource: "*"

  iamRoleStatements:



functions:
  dummy:
    handler: dummy.main
    timeout: 10
    ## This parameter sets the reserved concurrency for the lambda 'dummy'
    reservedConcurrency: 50
#    events:
#      - http:
#          method: GET
#          path: /dummy
#          resp: json

#plugins:
#  - serverless-python-requirements


custom:
  pythonRequirements:
     dockerizePip: non-linux

Теперь, когда тестирует вашу лямбду, вы увидите, что с Зарезервированным параллелизмом , установившим избыточные запросы, были возвращены код ошибки 500 и, таким образом, защищены система.

Без зарезервированного параллелизма Ограничение: 
Details (average, fastest, slowest):
  DNS+dialup:   0.0009 secs, 2.0200 secs, 6.0415 secs
  DNS-lookup:   0.0002 secs, 0.0000 secs, 0.0185 secs
  req write:    0.0000 secs, 0.0000 secs, 0.0030 secs
  resp wait:    3.5561 secs, 2.0199 secs, 6.0414 secs
  resp read:    0.0001 secs, 0.0000 secs, 0.0032 secs

Status code distribution:
  [200] 5000 responses
С зарезервированным параллелизмом Limit: 
Details (average, fastest, slowest):
  DNS+dialup:   0.0007 secs, 0.0094 secs, 5.6580 secs
  DNS-lookup:   0.0000 secs, 0.0000 secs, 0.0119 secs
  req write:    0.0000 secs, 0.0000 secs, 0.0033 secs
  resp wait:    1.1845 secs, 0.0093 secs, 5.5826 secs
  resp read:    0.0000 secs, 0.0000 secs, 0.0032 secs

Status code distribution:
  [200] 1638 responses
  [500] 3362 responses

Приведенные выше результаты были получены с помощью инструмента lambdaLoadTesting без reservedConcurrency И с его значением 25.

0 голосов
/ 16 марта 2019

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

Не уверен, что вы подразумеваете под "неаутентифицированными учетными данными"? Если вы хотите, чтобы ваш клиент вызывал вашу функцию Lambda напрямую, тогда вашему клиенту нужны учетные данные и соответствующая политика, которая разрешает вызов Lambda.

...