AWS Service Quotas and Limits

The plan: launch in three weeks, expecting 5,000 requests/sec at
peak, on a brand new production account created last month.

Nobody has looked at a quota. Every number below is a default.

WHAT THE DEFAULTS ALLOW
  Lambda concurrent executions   1,000 per Region  (adjustable)
  API Gateway throttle          10,000 rps        (adjustable)
  NAT gateways per AZ                5            (adjustable)
  Elastic IPs per Region             5            (adjustable)
  Lambda function timeout          900 s          (NOT adjustable)
  Lambda sync payload                6 MB         (NOT adjustable)

THE TWO CATEGORIES, AND THE TWO DIFFERENT PLANS
  Adjustable → request the increase now, not in week three.
    Increases are reviewed and may be approved, denied, or
    partially approved, and reviews take time.

  Not adjustable → these are design inputs. No request will move
    the 15-minute Lambda ceiling or the 6 MB payload, so any
    workload that needs more must be shaped differently.

New accounts also start with reduced Lambda concurrency and
memory quotas that AWS raises automatically based on usage — so
a load test on a fresh account measures the account, not the code.

STEP 1 — list the quotas this workload actually consumes
  Not every quota. The ones on the request path and the ones
  that grow with customers:
    Lambda concurrent executions      per Region
    API Gateway throttle rate         per Region
    RDS max_connections               per instance class
    Elastic IPs, NAT gateways per AZ  per Region
    SQS in-flight messages            per queue

STEP 2 — record the APPLIED value for each, not the default
  get-service-quota per quota code, into the runbook. This is
  the number capacity planning uses.

STEP 3 — alarm on utilization where the quota supports it
  Threshold 70%. Notification to the team that owns the service,
  not to a shared mailbox nobody reads.

STEP 4 — alarm on throttling as the backstop
  Lambda Throttles > 0, API Gateway 429 count > 0. These fire
  when step 3 was missed or when a spike outran the trend.

STEP 5 — review quarterly, and after any growth event
  A quota raised for last year's peak is not automatically right
  for this year's. Recheck the applied values, not the defaults.

Proposal: "Generate customer PDF exports in a Lambda function
triggered by an API call. Return the PDF in the response."

Three limits contradict this, and all three are non-adjustable.

1. TIMEOUT — 900 seconds maximum.
   The largest customer's export takes about 6 minutes today and
   grows with their data. This is not a problem yet, which is
   exactly what makes it dangerous: it fails first for the
   biggest, most valuable customer, and only in production.

2. PAYLOAD — 6 MB synchronous response.
   A 40 MB PDF cannot be returned this way at all. Not slowly:
   not at all. No quota increase exists for this.

3. CONCURRENCY — 1,000 per Region by default.
   Every export holds an execution environment for minutes, so a
   few hundred concurrent exports exhaust the account's Lambda
   capacity — including the functions doing unrelated work.

THE REDESIGN, which the limits wrote for us
   POST /exports          → Lambda, ~50 ms: create a job, enqueue,
                            return 202 with a job id
   SQS → ECS task         → renders with no time limit
                          → writes the PDF to S3
   GET /exports/{id}      → 200 with a presigned S3 URL when ready

Same services, different shape. The function does the fast part,
the container does the slow part, S3 carries the bytes.