You're building your startup's backend. You've read the AWS docs. You know you need an API, compute, a database, and storage. But you don't know if the architecture you're designing will actually hold up when real users hit it.
This guide takes you from a blank canvas to a validated, simulated, deployment-ready architecture in five minutes. No AWS account required. No infrastructure spend. Just design, simulate, and know.
The architecture
Lambda → S3
This is the most common serverless architecture for a SaaS API. API Gateway receives requests. Lambda processes them. DynamoDB stores the data. S3 handles file storage. It scales, it's cost-effective at low traffic, and it's the architecture most startups end up building anyway.
The question isn't whether this architecture works. The question is whether your specific configuration of it works at the traffic you're planning for. Let's find out.
Five steps, five minutes
Drag services onto the canvas
Open PinPole. From the AWS service library on the left, drag API Gateway, Lambda, DynamoDB, and S3 onto the canvas. Place them in roughly the order data flows through them.
Wire them together
Click API Gateway's output and drag to Lambda's input. Click Lambda's output and drag to DynamoDB. Add a second connection from Lambda to S3. PinPole validates each connection in real time — if a connection isn't architecturally valid, it's blocked before you can create it.
Configure each service
Click any service to open its configuration panel. Set Lambda memory to 512MB, timeout to 10 seconds. Set DynamoDB to on-demand capacity. Leave API Gateway and S3 at defaults. Every configuration field references the actual AWS service quota for the region you've selected.
Simulate at your expected traffic
Select the Ramp traffic pattern. Set your starting RPS to 10 (launch day) and target RPS to 10,000 (growth target). Hit Simulate. Watch per-node metrics update in real time — concurrency, throughput, queue depth, cost.
Read the recommendations, apply the fixes
PinPole's recommendation engine will flag anything that breaks under the simulated load. Lambda concurrency too low? One click to fix. DynamoDB hot key detected? One click to apply sharding. Re-simulate to confirm. Export to Terraform when you're ready.
What you'll learn in the first simulation
Most first-time architects discover three things in their first PinPole simulation:
Lambda's default concurrency is too low for growth. At 10,000 RPS with a 200ms function, you need 2,000 concurrent executions. The default is 1,000. PinPole catches this immediately.
API Gateway's default timeout is shorter than Lambda's. If your Lambda timeout is 10 seconds but API Gateway's integration timeout is 29 seconds, you're fine. But if you set Lambda to 30 seconds, you've created a timeout trap. PinPole flags mismatched timeouts as a warning.
The cost at 10 RPS is nothing. The cost at 10,000 RPS is real money. The ramp simulation shows you exactly when your monthly cost crosses from trivial to significant, and which service is the primary cost driver at each stage of growth.
What comes next
Once your basic architecture is validated, you can add complexity incrementally. Add Cognito for authentication. Add SQS for async processing. Add CloudFront for caching. Each time you add a service, re-simulate to make sure the new component doesn't introduce a bottleneck or cost surprise.
When you're ready to deploy, export to Terraform HCL or AWS CDK and run through your own pipeline. Or use PinPole's built-in deployment with STS AssumeRole — no long-lived credentials, full audit trail.
Your architecture, validated in 5 minutes
Free tier. No credit card. No AWS account needed to design and simulate.
Start building →