AWS in the labs and Playground: sources and assumptions
The AWS labs and Playground examples use real service names and limits. This page lists every number they rely on and says whether AWS documents it or we assumed it, so you can check any figure yourself.
- Documented figures are default quotas read from the AWS documentation on 2026-10-18. All limits are the default quotas in us-east-1 for a mature account. New accounts start lower and most of these quotas can be raised in Service Quotas.
- Assumed figures cover what AWS does not publish, such as requests per second for one container or database. They are labelled wherever they appear. Load-test your own service.
- Cost counts instance-hour charges only (compute, database and cache nodes, shards, load balancer hours). Pay-per-use services (requests, data transfer, storage) are not in the total, so a bill will be higher.
- The simulators are simplified. They model capacity, queueing, throttling and failover; they do not model cold starts, network partitions, burst credits or every service feature. Where the model differs from AWS, the component notes say so.
AWS labs
ECS Service Auto ScalingCloudFront and API Gateway throttlingElastiCache and Aurora ReplicasKinesis Data StreamsS3, SQS and MediaConvertALB, ECS and Aurora across Availability ZonesSQS, SNS and workersOpenSearch, ElastiCache and AuroraAPI Gateway, Lambda and DynamoDBCloudFront, ALB, ECS and Aurora
Playground examples
10 AWS reference architectures (pick one from the Example menu)
- Documented
Amazon CloudFront
drawn as “CloudFront”
Edge cache. Serves cacheable reads from a point of presence near the viewer; only misses and writes reach the origin.
- One node is
- 1 distribution
- Capacity
- 250,000 requests/s per distribution (default quota)
- Cost counted
- Pay per request and per GB
AWS documents
- Default quota: 250,000 requests per second per distribution (can be raised).
- Only HTTP GET responses are cached; POST and PUT go to the origin.
Modelling assumptions
- A 90% cache hit ratio is typical for static or popular content. Yours depends on content and TTLs.
- 20 ms is a typical edge response time, not a guarantee.
- Documented
Application Load Balancer
drawn as “ALB”
Spreads HTTP requests across targets in several Availability Zones and stops sending to unhealthy ones.
- One node is
- 1 load balancer
- Capacity
- Scales automatically; AWS publishes no request-rate ceiling
- Cost counted
- $0.0225/hour (≈$16/month) plus LCU usage
AWS documents
- Elastic Load Balancing scales the load balancer as traffic changes, and "can scale to the vast majority of workloads automatically".
- Health checks route traffic only to healthy targets. By default each target is checked every 30 seconds and taken out of service after 2 consecutive failures (about 60 seconds); the interval can be as low as 5 seconds.
- If every target fails its health checks at once, the load balancer fails open and sends traffic to all of them.
Modelling assumptions
- Treated as never being the bottleneck, because AWS publishes no request-rate ceiling. Scaling is automatic but not instant.
- 2 ms is an assumed added latency.
- Documented
Amazon API Gateway
drawn as “API Gateway”
Managed front door. The account-wide throttle is shared by every API in the Region; requests beyond it get HTTP 429.
- One node is
- the account's throttle in this Region
- Capacity
- 10,000 requests/s per account per Region (default, can be raised); token-bucket burst of 5,000
- Cost counted
- Pay per request
AWS documents
- Default throttle quota: 10,000 requests per second per account per Region across all API types, with a token-bucket burst capacity of 5,000.
- The quota is per account and Region, not per API, and can be increased.
- You can set lower throttling targets per stage, per method, or per client in a usage plan. AWS describes throttles as best-effort targets rather than guaranteed ceilings.
Modelling assumptions
- 15 ms is an assumed added latency.
- In regions such as Milan, Jakarta or Zurich the default is only 2,500 requests/s.
- Assumed
Amazon ECS on AWS Fargate
drawn as “ECS service”
Your application containers behind a load balancer. Add tasks to add capacity.
- One node is
- 1 Fargate task (2 vCPU, 4 GB)
- Capacity
- ≈1,000 requests/s per task (assumed: 30 ms handler, ~30 concurrent requests)
- Cost counted
- ≈$72/month per task (2 vCPU × $0.04048 + 4 GB × $0.004445 per hour)
AWS documents
- Fargate on-demand price in us-east-1 (Linux/x86): about $0.04048 per vCPU-hour and $0.004445 per GB-hour.
Modelling assumptions
- AWS publishes no requests-per-second figure for a task: it depends entirely on your code. 1,000/s assumes a 30 ms request and about 30 requests in flight. Load-test your own service.
- Assumed
ECS tasks consuming from SQS
drawn as “ECS worker”
Background workers. They read messages from a queue in batches of up to 10 and write results in batches.
- One node is
- 1 Fargate task (1 vCPU, 2 GB)
- Capacity
- ≈1,000 messages/s per task (assumed: batches of 10, 100 ms per batch, 10 batches in parallel)
- Cost counted
- ≈$36/month per task (1 vCPU, 2 GB)
AWS documents
- SQS batch actions send, receive or delete up to 10 messages per request.
- Fargate on-demand price in us-east-1: $0.04048 per vCPU-hour and $0.004445 per GB-hour.
Modelling assumptions
- Throughput per task depends on what each message does; 1,000/s assumes light work.
- The model writes 1 batched call to the database per 10 messages.
- Derived
AWS Lambda
drawn as “Lambda”
Serverless functions. Scaling is automatic, but account concurrency is a shared quota, and a throttled synchronous call gets HTTP 429.
- One node is
- the account's concurrency in this Region (default 1,000)
- Capacity
- 10,000 requests/s = 10 × the 1,000 default concurrent executions (the account-wide requests-per-second limit)
- Cost counted
- Pay per request and per GB-second
AWS documents
- Default concurrent executions: 1,000 per Region (can be raised to tens of thousands).
- Lambda enforces a requests-per-second limit equal to 10 times the account concurrency limit, so 10,000 requests per second by default. AWS notes it is not accurate to say each execution environment is limited to 10 requests per second; only overall concurrency and overall requests per second are considered.
- A function can add 1,000 new execution environments every 10 seconds.
Modelling assumptions
- 100 ms average duration. Concurrency = requests per second × duration in seconds, so at 100 ms 1,000 concurrent executions serve 10,000 requests/s, exactly the requests-per-second limit. Functions faster than 100 ms hit the requests-per-second limit before the concurrency limit.
- Cold starts are not modelled.
- Assumed
Amazon ElastiCache for Redis
drawn as “ElastiCache”
In-memory cache in front of the database. Answers repeated reads in about a millisecond.
- One node is
- 1 node (cache.r6g.large, 13 GiB)
- Capacity
- ≈100,000 simple operations/s per node (assumed)
- Cost counted
- ≈$150/month per node ($0.206/hour)
AWS documents
- cache.r6g.large on-demand price in us-east-1: $0.206 per hour, 13.07 GiB of memory (per published price listings; check the AWS pricing page).
Modelling assumptions
- AWS publishes no operations-per-second figure per node: it depends on command mix and value size. 100,000/s assumes small GET/SET operations.
- An 80% hit rate is an assumption; it depends on your keys and memory.
- Assumed
Amazon Aurora (writer instance)
drawn as “Aurora writer”
The one writer of an Aurora cluster. You cannot add more writers; scale writes up with a bigger instance, and reads out with replicas.
- One node is
- 1 writer (db.r6g.xlarge, 4 vCPU, 32 GiB)
- Capacity
- ≈6,000 simple queries/s (assumed)
- Cost counted
- ≈$379/month (db.r6g.xlarge, instance only; storage and I/O extra)
AWS documents
- An Aurora cluster has one primary (writer) instance and up to 15 Aurora Replicas.
- Aurora synchronously replicates writes across Availability Zones to six storage nodes of the cluster volume.
- If the writer fails and a replica exists, it is promoted; service is typically restored in under 60 seconds and often under 30.
- If no replica exists, the writer is recreated, which typically takes under 10 minutes.
Modelling assumptions
- AWS publishes no queries-per-second figure per instance: it depends on schema, indexes and queries. 6,000/s assumes simple indexed OLTP queries.
- Price is community-reported and rounded; check the AWS pricing page for your engine and Region.
- Assumed
Amazon Aurora Replica (reader instance)
drawn as “Aurora reader”
A reader that shares the cluster's storage volume, so it serves reads without replaying every write, and is the failover target.
- One node is
- 1 reader (db.r6g.xlarge)
- Capacity
- ≈6,000 simple queries/s each (assumed); up to 15 readers
- Cost counted
- ≈$379/month each
AWS documents
- Up to 15 Aurora Replicas per cluster; they use asynchronous replication that does not affect the primary's performance.
- The writer and every Aurora Replica see the data as one shared logical cluster volume, so "minimal additional work is required to replicate a copy of the data for each Aurora Replica".
- Replica lag is usually much less than 100 ms after the writer has written an update, and rises when writes are heavy.
- Spread the writer and readers across at least two Availability Zones.
Modelling assumptions
- Reader throughput equals the writer's: same instance class and query mix.
- Replica lag is not modelled.
- Documented
Amazon SQS (standard queue)
drawn as “SQS queue”
Durable buffer between producers and consumers. Standard queues deliver at least once and do not guarantee order.
- One node is
- 1 standard queue
- Capacity
- Nearly unlimited throughput (standard queue)
- Cost counted
- Pay per request
AWS documents
- Standard queues support a very high, nearly unlimited number of API calls per second.
- Messages are kept 4 days by default, up to 14 days.
- FIFO queues are limited: 300 API calls/s per action (3,000 messages/s with batches of 10) unless high-throughput mode is on.
Modelling assumptions
- 10 ms is an assumed SendMessage latency.
- This is a standard queue. A FIFO queue would have the throughput limit above.
- Documented
Amazon SNS (standard topic)
drawn as “SNS topic”
Fan-out. Every subscriber (often an SQS queue each) receives every message.
- One node is
- the account's publish quota in this Region
- Capacity
- 30,000 messages/s published per account in us-east-1 (default, can be raised)
- Cost counted
- Pay per publish and delivery
AWS documents
- Default publish quota per account: 30,000 messages/s in us-east-1, 9,000 in us-west-2 and eu-west-1, 1,500 in several other Regions and 300 elsewhere.
- A standard topic supports up to 12,500,000 subscriptions.
Modelling assumptions
- 10 ms is an assumed publish latency.
- Documented
Amazon Kinesis Data Streams (provisioned)
drawn as “Kinesis”
Ordered, replayable log. Add shards to add write throughput; records with the same partition key stay in order on one shard.
- One node is
- 1 shard
- Capacity
- 1,000 records/s or 1 MB/s written per shard; 2 MB/s read per shard
- Cost counted
- ≈$11/month per shard ($0.015/shard-hour) plus PUT payload units
AWS documents
- Each shard supports writes of up to 1,000 records/s and 1 MB/s, and reads of up to 2 MB/s (5 GetRecords calls/s).
- Enhanced fan-out gives each registered consumer its own 2 MB/s per shard, up to 20 consumers per stream.
- Retention is 24 hours by default and extends up to 365 days.
- On-demand mode starts at 4 MB/s write and scales automatically.
Modelling assumptions
- Records are assumed to be ≤1 KB, so the 1,000 records/s limit binds before 1 MB/s.
- 30 ms is an assumed put latency.
- A hot partition key can overload one shard even when the stream is under its total limit; not modelled here.
- Documented
Amazon S3
drawn as “S3 bucket”
Object storage. Request rate scales per key prefix, so spreading keys over prefixes spreads load.
- One node is
- 1 key prefix
- Capacity
- at least 3,500 writes/s or 5,500 reads/s per prefix (modelled at the write floor)
- Cost counted
- Pay per request and per GB stored
AWS documents
- S3 supports at least 3,500 PUT/COPY/POST/DELETE or 5,500 GET/HEAD requests per second per partitioned prefix, and there is no limit to the number of prefixes.
- Scaling to a new higher rate is gradual; you may see 503 Slow Down responses meanwhile.
- Small-object latency is roughly 100–200 ms.
Modelling assumptions
- 3,500/s is the documented write floor, used for reads too so the model is conservative. Each extra node stands for one more prefix.
- Assumed
Amazon OpenSearch Service
drawn as “OpenSearch”
Search and analytics index. A secondary copy of your data, not a system of record.
- One node is
- 1 domain (3 × r6g.large.search data nodes)
- Capacity
- ≈3,000 simple queries/s per domain (assumed)
- Cost counted
- ≈$366/month (3 data nodes at $0.167/hour; dedicated masters and storage extra)
AWS documents
- r6g.large.search on-demand price in us-east-1: $0.167 per hour, 2 vCPU, 16 GiB (per published price listings; check the AWS pricing page).
Modelling assumptions
- AWS publishes no queries-per-second figure for a domain: it depends on index size, query complexity and shard layout. 3,000/s assumes simple queries on a modest index.
- Derived
AWS Elemental MediaConvert
drawn as “MediaConvert”
File-based video transcoding. Jobs run in the background, limited by queue concurrency and the job-submission rate.
- One node is
- the account's on-demand queue in this Region
- Capacity
- ≈3.3 one-minute jobs/s: 200 concurrent jobs (default queue) ÷ 60 s, under the 5 CreateJob requests/s quota
- Cost counted
- Pay per minute of output
AWS documents
- Default concurrent jobs for a new on-demand queue in us-east-1: 200 (up to 500 with a quota increase).
- CreateJob request rate: 5 per second with a burst of 100 (can be raised).
- Concurrent jobs per account across all on-demand queues: 2,000 in us-east-1.
Modelling assumptions
- Each job is assumed to take one minute. Longer videos take longer, so throughput in jobs/s falls.
- Assumed
Application Auto Scaling (ECS service)
drawn as “Auto Scaling”
Target-tracking scaling. New tasks take time to start and pass health checks, so a sudden spike is served by too few tasks for a while.
- One node is
- 1 scaling policy
- Capacity
- Control plane; adds and removes tasks to hold a utilisation target
- Cost counted
- No charge for the scaling policy
AWS documents
- Application Auto Scaling adjusts the desired task count of an ECS service in response to a CloudWatch metric, so it is reactive, not instant.
- Scheduled scaling and predictive scaling can add capacity ahead of an expected spike.
Modelling assumptions
- The model sizes the next component to its load and caps it at 6 instances. A start-up delay of about 60 s is assumed in the Playground; real start-up time depends on image size and health-check settings.