AWS integration pattern comparison matrix
Four mechanisms carry most service-to-service traffic on AWS. They are not interchangeable, and the choice is usually settled by three questions: does the caller need an answer, how big is the payload, and what happens when the consumer is down.
Quotas below are defaults and most are adjustable through Service Quotas. Several are per-Region rather than global, and the Regional variation is large enough to change a design — where that is the case it is stated. Verified against AWS documentation on 10 September 2026; follow the links before committing a number to a capacity plan.
| Characteristic | REST API (API Gateway) | EventBridge | SQS | Kinesis Data Streams |
|---|---|---|---|---|
| Maximum throughput | 10,000 requests/second per account per Region by default (2,500/s in a number of newer Regions); adjustable | PutEvents 10,000/s in us-east-1, us-west-2 and eu-west-1; 400–2,400/s in most other Regions. Invocations (rule matches sent to targets) 18,750/s in those three Regions, lower elsewhere. Per Region, not per bus; adjustable | Standard: very high, effectively unlimited API calls per second per action. FIFO: 300 transactions/second per partition (3,000 messages/s with batches of 10). FIFO high throughput: up to 70,000 TPS — 700,000 messages/s batched — in us-east-1, us-west-2 and eu-west-1; lower elsewhere | On-demand: scales automatically to 10 GB/s write and 20 GB/s read in us-east-1, us-west-2 and eu-west-1; 200 MB/s write elsewhere by default. Provisioned: 1 MB/s or 1,000 records/s write per shard, 2 MB/s read per shard |
| Maximum payload size | 10 MB request payload | 256 KB per event entry | 1 MiB per message. The Extended Client Library stores the body in S3 and sends a reference, raising the effective limit to 2 GB | 10 MiB per record before base64 encoding; 10 MiB per PutRecords request in total |
| Latency | Milliseconds, synchronous | Near real time; typically sub-second but not guaranteed | Standard: variable, messages available immediately. FIFO: ordered within a message group | Sub-second; ordered within a shard |
| Delivery guarantee | None built in — the caller implements retries | At least once, with a retry policy and DLQ support | At least once (standard); exactly-once processing within the deduplication window (FIFO); DLQ support | At least once, in order within a shard |
| Cost model | Per request, plus data transfer | Per event published (AWS-service events on the default bus are free) | Per million requests, plus storage | On-demand: per GB ingested and retrieved. Provisioned: per shard-hour, plus PUT payload units |
| Scaling | Raise the account throttle quota; use Regional endpoints and per-stage throttles | Automatic within the Regional quota | Automatic; no capacity to manage | On-demand mode auto-scales shards. Provisioned mode requires splitting and merging shards yourself; default shard quota is 20,000 per account in us-east-1, us-west-2 and eu-west-1 and 1,000–6,000 elsewhere |
| Use when | The caller needs the answer before it can continue; CRUD; API-first designs | Routing one event to many independent consumers; content-based rules; cross-account and SaaS integration | Decoupling producers from consumers; job queues; levelling a bursty workload; strict ordering per key with FIFO | Ordered, replayable, high-volume streams; several consumers reading the same data independently; analytics and log ingestion |
| Avoid when | The work is long-running or asynchronous, or you need built-in retries and a dead-letter path | Payloads exceed 256 KB, ordering across events must be strict, or the latency budget is single-digit milliseconds | You need replay, or several independent consumers of the same message (put SNS or EventBridge in front) | Volume is low and steady — provisioned shards are billed whether used or not; on-demand mitigates this but does not eliminate it |
Reading the table
Section titled “Reading the table”Payload size is where designs most often break. The old 256 KB SQS limit is widely remembered and no longer correct — SQS now takes 1 MiB — but the newer limits still bite: EventBridge is capped at 256 KB, and a payload larger than any of these should be written to S3 with only a pointer on the wire. That is the claim-check pattern, and it is the right answer far more often than raising a quota.
“Unlimited” is a Regional statement. Standard SQS scales to very high call rates and EventBridge scales automatically, but EventBridge’s throughput quotas differ by more than an order of magnitude between us-east-1 and a smaller Region, and Kinesis on-demand mode scales fifty times higher in the three largest Regions than elsewhere. A design validated in us-east-1 can fail its load test in eu-west-2 for no reason other than the quota table.
Delivery guarantees compose badly. At-least-once everywhere means consumers must be idempotent everywhere. This is a property of the whole chain, not of one hop: an idempotent consumer behind a non-idempotent one buys nothing.
Additional considerations
Section titled “Additional considerations”Cross-Region. REST APIs go global through CloudFront (edge-optimised endpoints); EventBridge rules can target a bus in another Region; SQS queues are Regional and cross-Region delivery is something you build; Kinesis has no built-in cross-Region replication, so it is done with a consumer that re-publishes.
Implementation effort. REST and SQS are straightforward. EventBridge is moderate — most of the effort goes into event patterns and getting the filter scope right. Kinesis in provisioned mode is the most involved, because shard management, partition-key distribution and consumer checkpointing are all yours.
Observability. API Gateway has per-stage metrics, access logs and execution logs; EventBridge publishes rule-level metrics and supports archive and replay; SQS exposes queue depth, age of oldest message and DLQ counts; Kinesis has enhanced (shard-level) monitoring, which is worth turning on before you need it.