람다는 동일한 함수의 여러 인스턴스를 병렬로 실행할 수 있는데 이것은 concurrency와 scaling limit에 의해 제한받는다.

1. Reserved Concurrency

AWS에서는 계정당 총 1000개 까지의 lambda concurrency를 가질 수 있다. 따라서 특정 람다에 갑자기 1000개 이상의 리퀘스트가 폭주해버리면 다른 람다는 실행될 수가 없기에 다른 람다에 대한 리퀘스트는 거부된다. 이것은 throttling이라고 하는데 더이상 가능한 concurrency가 없기에 다른 람다에 대한 추가적인 요청이 들어오지 못하는 것이다.

따라서 람다를 생성할 때는 각 람다별로 reserved concurrency를 적절한 규모로 설정하는 것이 중요하다. 각 람다는 이 파라미터를 갖고 있고 해당 값 이내에서만 concurrency를 가질 수 있다. 마찬가지로 이때도 본인의 concurrency limit을 넘어서는 리퀘스트가 오면 throttled된다.

이렇게 각 람다별로 적절한 reserved concurrency를 설정해야 비용 절감, 디도스 방지 등을 할 수 있다. 참고로 람다를 생성할 때 Unreserved account concurrency 옵션을 설정할 수도 있는데 이렇게 되면 Public pool에 있는 concurrency 중에서 다른 람다에 의해 이미 reserved 된 양을 제외한 범위 내에서만 concurrency를 사용할 수 있다. 다른 람다들이 본인의 reserved concurrency를 설사 사용하고 있지 않더라도 해당 제한은 똑같이 적용된다. 만약 각 람다의 reserved concurrency들로 Public pool의 concurrency가 가득차버린다면 해당 람다는 실행되지 못하겠지(?)

2. Provisioned Concurrency

Lambda concurrency의 가장 큰 문제점은 람다의 cold start 문제이다. cold start란 람다가 첫 리퀘스트를 처리할 때 말그대로 늦게 뜬다는 말이다. 이러한 현상은 람다가 worker(당신의 함수를 실행하는 컨테이너)와 함수 모듈을 초기화하는데 시간이 걸리기 때문이다. 물론 한번 함수를 invoke하고 나면 컨테이너가 일정 기간(약 30~45분?) stays warm 한다.

Provisioned concurrency는 컨테이너 등을 미리 준비해서 여러분의 람다 함수가 즉시 리퀘스트를 콜드 스타트 없이 바로 처리할 수 있도록 하는 것이다. Provisioned concurrency의 경우 Reserved Concurrency와 달리 추가 비용이 있다.