AWS Lambda

What Lambda is

Lambda runs your code in response to an event — an S3 upload, an API Gateway request, a DynamoDB Streams record, a schedule, a direct SDK call — without a server to provision, patch, or scale. You write a handler; Lambda packages it, invokes it, and adds or removes concurrent execution environments to match load. You pay per request plus the compute time you actually use, and nothing while it sits idle.

Design Beaver models Lambda as a compute node that can sit inside or outside a VPC, so it validates your event sources, its connections, and its IAM as you draw — not in a review three weeks later.

When to use Lambda (and when not to)

Reach for Lambda when the work is event-driven or bursty rather than constantly busy: processing an upload, reacting to a data change, handling an API request, running a scheduled job, or doing lightweight edge logic at the CDN. It shines when you don’t want to manage servers and each invocation finishes well inside 15 minutes.

Don’t reach for it when the workload is steady and constantly busy — an always-on instance or container is usually cheaper once utilization is high. It’s also the wrong tool for anything that needs more than 15 minutes per run, a latency-critical path that can’t absorb the occasional cold start, or a workload that wants a persistent filesystem and a full OS.

Variants: architecture and memory, not instance sizes

Lambda has no “instance types.” The two dials that matter are CPU architecture and memory — and memory is the real performance lever, because vCPU scales up with it.

Lambda pricing

You pay for what you invoke: a per-request charge plus duration billed in GB-seconds. Move a function to arm64 where your runtime supports it and the per-GB-second rate drops.

How Lambda connects to other services

This is where a picture of boxes and arrows usually hides the real work — the IAM, the direction, the requirement that makes each edge actually function. Design Beaver models each of these connections, so it knows what Lambda can talk to and what that connection needs to be correct.

• ↔S3security

  Lambda reads/writes S3 objects via the AWS SDK (e.g. generate a thumbnail and write it back to a bucket)

  IAM:s3:GetObjects3:PutObjects3:ListBucket

• ↔DynamoDBsecurity

  Lambda reads/writes DynamoDB items via the AWS SDK (typical serverless API backend pattern)

  IAM:dynamodb:GetItemdynamodb:PutItemdynamodb:Querydynamodb:UpdateItemdynamodb:DeleteItem

• →RDS

  Lambda queries an RDS database via a standard database driver/SDK, typically for a serverless API backend

• →EC2

  Lambda (attached to the same VPC) calls an internal service running on an EC2 instance, e.g. a private API or legacy backend not otherwise exposed

• ↔SQSsecurity

  Lambda sends messages to an SQS queue to decouple work — e.g. an API handler enqueues an email/notification job instead of doing it inline in the request

  IAM:sqs:SendMessagesqs:ReceiveMessagesqs:DeleteMessagesqs:GetQueueAttributes

• →SESsecurity

  Lambda sends transactional email through SES — e.g. a worker triggered by an SQS queue sends the confirmation email for a CRUD write

  IAM:ses:SendEmailses:SendRawEmail

• →SNSsecurity

  Lambda publishes a message to an SNS topic to fan an event out to multiple subscribers (e.g. notify several downstream systems after a write)

  IAM:sns:Publish

• →EventBridgesecurity

  Lambda publishes a custom event to an event bus with PutEvents, so other services can react through EventBridge rules without the function calling them directly — the producer stays decoupled from its consumers

  IAM:events:PutEvents

• →Secrets Managersecurity

  The function reads a secret (e.g. the database credentials for its RDS/RDS Proxy connection, or a third-party API key) from Secrets Manager at runtime via the AWS SDK instead of storing it in an environment variable

  IAM:secretsmanager:GetSecretValuesecretsmanager:DescribeSecret

• →RDS Proxy

  The function connects to an RDS Proxy endpoint instead of directly to RDS — the proxy pools and multiplexes connections so bursty, high-concurrency invocations don't exhaust the database's max_connections

What Lambda can’t connect to

Some edges look reasonable on a canvas but don’t exist in AWS. Design Beaver flags them instead of letting you draw a diagram that can’t be built.

• ✕Route 53

  Lambda is not a DNS-addressable target — Route 53 can't point a record directly at a Lambda function. (A Lambda Function URL has its own HTTPS endpoint that could be targeted with a regular CNAME/ALIAS-to-CNAME-target record, but that's a Route 53 -> generic-HTTPS-endpoint connection, not a Route 53 -> Lambda relationship recognized as an architectural edge here.)

Anti-patterns Design Beaver catches

These are the Lambda mistakes that pass a diagram review but break under load — the ones the validation engine flags as you draw.

Gotchas that bite in production

• Cold starts are real. The first invocation of a new or recently-idle environment pays initialization latency before your handler runs. Traffic with long gaps between calls feels this more than steady traffic.
• 15 minutes is a hard ceiling. No invocation runs longer, full stop. If a job genuinely needs more, orchestrate several invocations with Step Functions or move it to a container.
• VPC attachment has its own cold-start cost. Only attach Lambda to a VPC when it needs a VPC-resident resource like RDS or EC2 — S3 and DynamoDB APIs don’t need it, and attaching anyway is pure added latency.
• Lambda@Edge is not standard Lambda. Functions invoked by CloudFront have no VPC support and a 5-second timeout, not 15 minutes. Don’t carry standard-Lambda assumptions into an edge function.

Further reading

• Official AWS documentation
• Why we built a validation engine