Short overview of six core AWS services: what they do, and their main bottlenecks and restrictions to keep in mind when designing systems.
Lambda
What it is: Serverless functions. You upload code; AWS runs it in response to events or HTTP requests. You pay per invocation and compute time. No servers to manage.
Bottlenecks & restrictions:
- Cold start – First request (or after idle) can be hundreds of ms to a few seconds while the runtime starts.
- Timeout – Max 15 minutes per invocation. Long jobs need Step Functions or another worker.
- Memory – 128 MB to 10,240 MB; CPU scales with memory. More memory = higher cost per second.
- Payload size – Request/response synchronous payload max 6 MB (direct invoke). Event payload (e.g. SQS) max 256 KB.
- Concurrency – Account and per-function limits (default 1,000 concurrent executions per account in many regions). Burst limits apply; can throttle under spike.
- Ephemeral storage – /tmp is limited (512 MB to 10 GB). Not for large or persistent data.
SQS (Simple Queue Service)
What it is: Managed message queue. Producers send messages; consumers poll or get messages. Decouples components and smooths load. Standard (at-least-once, best-effort ordering) and FIFO (exactly-once, ordered per group).
Bottlenecks & restrictions:
- Message size – Max 256 KB per message. For larger payloads use S3 and put a reference in the message.
- Visibility timeout – Message is hidden after being received until timeout (or delete). Too short = duplicate processing; too long = slow retries. Max 12 hours.
- Retention – Messages kept 1 minute to 14 days (default 4 days). After that they are deleted.
- FIFO throughput – 300 msg/s without batching, 3,000 msg/s with batching. Standard queues scale much higher but no strict ordering.
- Receive – Max 10 messages per ReceiveMessage call. Long polling reduces empty responses but doesn’t remove throughput limits.
DynamoDB
What it is: Managed NoSQL key-value and document database. Single-digit ms latency, automatic scaling. You define partition key (and optional sort key); data is distributed by partition key.
Bottlenecks & restrictions:
- Item size – Max 400 KB per item. Large documents or blobs should go to S3 with a reference in DynamoDB.
- Partition throughput – Provisioned mode: each partition has a throughput cap. Hot partition (one key getting most traffic) can throttle; design keys for even distribution.
- RCU/WCU – In provisioned mode you set read/write capacity. Bursts use burst capacity; sustained over-provision can throttle. On-demand avoids capacity planning but can be more expensive at very high steady load.
- Partition key limits – Max 2 partition key values per second per partition in provisioned mode (unless you have enough capacity). Choose partition keys so workload spreads across partitions.
- Queries – Query returns items from one partition (same partition key). Scan reads the whole table; expensive on large tables.
API Gateway
What it is: Managed API layer. You create REST or WebSocket APIs that integrate with Lambda, HTTP endpoints, or other AWS services. Handles auth, throttling, and request/response mapping.
Bottlenecks & restrictions:
- Payload size – Max 10 MB request payload. Response payload max 10 MB. Larger payloads use S3 or streaming.
- Timeout – Integration timeout max 29 seconds. Long-running work should be asynchronous (e.g. return 202 and poll or use callbacks).
- Rate limits – Default 10,000 requests/second per account (varies by region). Per-client throttling can be set via usage plans and API keys.
- Request/response size and time – Large headers or bodies count toward the 10 MB and 29 s limits; WebSocket has its own message size limits.
EventBridge
What it is: Serverless event bus. Producers publish events; rules route them to targets (Lambda, SQS, SNS, Step Functions, etc.). Used for decoupling, event-driven workflows, and SaaS integrations.
Bottlenecks & restrictions:
- Event size – Max 256 KB per event. For larger payloads put data in S3 and send a reference in the event.
- Targets per rule – Max 5 targets per rule (soft limit; can request more). For fan-out to many targets use SNS or multiple rules.
- Rate and throughput – Default limits on events per second per account/region. High volume may need limit increase or batching.
- Retry and DLQ – Failed targets are retried; after max retries events can go to a dead-letter queue. Configure timeouts and retries to avoid long backpressure.
CloudWatch
What it is: Monitoring and observability: metrics, logs, alarms, dashboards. Lambda, API Gateway, and many other services send metrics and logs to CloudWatch by default.
Bottlenecks & restrictions:
- Log retention – By default logs can be kept from 1 day to “never expire.” Long retention increases storage cost; set retention policies per log group.
- Log size – Single log event max 256 KB. Log stream and ingestion have limits; very high volume may require sampling or separate streams.
- Metrics – Custom metrics have a limit on unique metric dimensions per account. High cardinality (e.g. unique ID per metric) can hit limits and cost more.
- Queries and insights – Logs Insights queries and metric math count toward costs. Large scans and long time ranges are more expensive.
- Alarms – Max 5,000 alarms per account per region. Composite alarms and high granularity can use this up quickly.
Summary
Lambda: cold starts and 15 min timeout. SQS: 256 KB messages and visibility/throughput limits. DynamoDB: 400 KB items and partition throughput. API Gateway: 10 MB payload and 29 s timeout. EventBridge: 256 KB events and targets per rule. CloudWatch: retention, log size, and metric/alarm limits. Design with these in mind to avoid throttling and cost surprises.