Lambda帐户并发性

Lambda帐户并发性

关注
发信
关注(28)粉丝(399)

AWS Lambda帐户并发性，限制

本文介绍了AWS Lambda帐户并发性，限制的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！

问题描述

出于性能原因，我正在考虑不使用API​​网关.相反，我想将lambda函数直接公开到Web.未经身份验证的IAM凭证是必需的，并由AWS JavaScript SDK提供.我意识到，如果一个坏演员试图以天文数字的速度调用我的功能并引起重大的计费问题，这可能是一个问题.我认为这不太可能发生，因为有人特别需要将我的应用程序作为目标，请求IAM凭据，然后调用该请求...

为了保护我的Lambda函数免受攻击，我正在考虑使用帐户并发功能.默认情况下，帐户并发功能限制为该帐户上的1,000个并发请求.我能够指定特定于Lambda函数的储备并发性，以减少剩余的整体帐户并发限制(其余帐户的并发限制).

这项工作是否可行:创建虚拟Lambda函数(不可公开访问)，将虚拟Lambda函数保留的并发设置得很高，例如950 ...这将为我的真正的" Lambda函数留下50个并发的lambda请求...这似乎是在不使用API​​网关等情况下限制lambda的简单方法.

有想法吗?

解决方案

如您所描述的，作为一种保护形式的限制是完全可行的:)无需像您描述的那样创建第二个 dummy函数.

Lambda带有 Reserved Concurrency 限制，使您可以设置并发接受的Lambda的最大数量.如果请求数超过该限制，则溢出请求将收到错误500响应.

要设置并发限制，您有几个选择:

控制台

在AWS控制台内部导航到您的lambda，在配置页面中向下滚动到 Concurrency 框，然后选择 Reserved Concurrency (输入所需的数字50) >

命令行

要通过命令行修改保留并发，请使用以下命令:

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

无服务器框架文件

如果使用无服务器框架部署功能，则可以为文件的function部分中的任何lambda修改保留并发.

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

现在，当测试您的lambda时，您会看到 with 和 Reserved Concurrency 设置的多余请求都返回了错误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

具有保留的并发限制:

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.

I am considering NOT using API gateway for performance reasons. Instead, I want to expose a lambda function directly to the web. Unauthenticated IAM credentials are required, and provided by the AWS JavaScript SDK. I realize this could be a concern if a bad actor tries to invoke my function at an astronomical pace and cause major billing issues. I don't think this is likely as someone would specifically have to target my application, request IAM credentials and then invoke the request... a lot of work for little gain, but...

In order to protect my Lambda Function from an attack I was considering the account concurrency feature. By default, the account concurrency feature is limited to 1,000 concurrent requests on the account. I am able to specify reserve concurrency specific to a Lambda function which reduces the remaining overall account concurrency limit (the concurrency limit for the rest of the account).

Would this work: create a dummy lambda function (not publicly accessible), set the dummy Lambda function reserved concurrency really high, e.g. 950... this would leave 50 concurrent lambda requests for my "real" Lambda function... this seems like a simple way to throttle a lambda without using API gateway, etc.

Thoughts?

解决方案

Throttling as you described as a form of protection is completely doable :)and without the need to create a second dummy function as you described.

Lambdas come with a Reserved Concurrency limit that enables you to set a maximum number of concurrent accepted lambdas. If the number of requests exceeds that limit the overflow requests will receive an error 500 response.

To set the concurrent limit you have several options:

The Console

Inside the AWS console navigate to your lambda, in the configurations page scroll down to the Concurrency box, and select Reserved Concurrency (entering your desired number 50)

The Command Line

To modify the Reserved Concurrency via the command line use the following command:

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

Serverless Framework File

If your deploying your functions with the serverless framework you can modify the Reserved Concurrency for any lambda inside the function section of you file.

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

Now when testing your lambda, you'll see that with the Reserved Concurrency set the excess requests were returned an error 500 code, and thus protected the system.

Without Reserved Concurrency Limit:

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

With Reserved Concurrency 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

The outputs above were generated using the lambdaLoadTesting tool without reservedConcurrency AND with it set to 25.

这篇关于AWS Lambda帐户并发性，限制的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！

09-06 03:27
Powered by LMLPHP ©2024 Lambda帐户并发性 0.036575