A Cost-Conscious AWS Architecture for a Startup Web App
This design minimizes always-on infrastructure while a product is finding its traffic pattern. Static assets live in S3, API Gateway and Lambda handle requests on demand, and DynamoDB starts with pay-per-request capacity.
Published August 18, 2026
Reference architecture
Architecture diagram
Open on the canvasCost-conscious startup AWS architecture diagram with an S3 web application, API Gateway, Lambda, and on-demand DynamoDB. The image links to a fully editable BuildPlane starter.
Overview
A lean startup architecture that pays mostly for actual use. S3 hosts the static frontend, while API Gateway, Lambda, and DynamoDB provide an on-demand backend without a permanently running compute fleet.
Components
- S3 Web Application: Hosts the static frontend without a web-server fleet.
- API Gateway: Publishes managed HTTPS routes and scales without reserved application capacity.
- Lambda and DynamoDB: Run product logic and store records with pay-per-request starting points.
Application Flow
- A browser loads the static product frontend from the S3 web bucket.
- The frontend sends dynamic requests to API Gateway.
- API Gateway invokes the Lambda function for product operations.
- Lambda reads and writes product records in the on-demand DynamoDB table.
Customize First
- Set budgets and billing alarms before inviting users.
- Add CloudFront before launch when the frontend needs HTTPS delivery and caching.
- Add authentication when the product begins storing user-specific data.
- Revisit reserved capacity after traffic becomes predictable enough to justify it.
Design rationale
Decisions that shape this architecture
Avoid paying for idle application servers
API Gateway and Lambda charge mainly when requests arrive. This is attractive before traffic becomes stable enough to justify reserved compute.
Separate the static frontend from the API
S3 can hold the built application while the backend scales independently. Add CloudFront for a production public frontend with HTTPS and global caching.
Delay capacity commitments
DynamoDB on-demand capacity is simple during uncertain growth. Revisit provisioned or reserved pricing after usage becomes predictable.
Before production
Operational checks
Create AWS Budgets and billing alarms before inviting users.
Set concurrency, API throttling, and data-retention limits to bound surprise spend.
Track cost per request and cost per active user as the product grows.
Review CloudWatch log retention because verbose logs can become a material cost.
Scope and tradeoffs
What this diagram does not solve
Low idle cost is not always the lowest unit cost
At sustained high volume, containers, reserved compute, or provisioned database capacity may deliver a lower cost per request.
The minimal version omits several launch controls
Add CloudFront, authentication, backups, alarms, least-privilege IAM, and deployment automation according to the product risk.
Common questions
Frequently asked questions
Why is serverless attractive for a startup?
It reduces server operations and idle compute cost while traffic is small or unpredictable, letting the team defer capacity planning.
Is S3 website hosting enough for production?
A public product normally places CloudFront in front of the S3 origin for HTTPS, caching, access control, and a custom domain.
When should the architecture move away from on-demand pricing?
Review alternatives when traffic and storage patterns are stable enough to compare reserved or provisioned options with the operational cost of changing them.
Keep exploring
Related AWS architectures
Serverless REST API Architecture on AWS
This architecture is the smallest useful serverless API baseline: a managed HTTPS entry point, stateless function compute, on-demand data storage, and observable execution. It is intentionally compact so the first production decisions remain easy to see.
Explore the architecture
Serverless Multi-Tenant SaaS Architecture on AWS
This architecture combines a protected synchronous API with a durable asynchronous work path. Tenant identity travels from Cognito into application authorization, domain events decouple background work, and DynamoDB plus S3 provide scalable tenant state and assets.
Explore the architecture
Containerized Web Service with Amazon ECS and Fargate
This architecture runs a production container service without managing an EC2 host fleet. A protected global edge forwards to a Multi-AZ ALB, Fargate tasks stay private, and managed data, image, secret, and observability services support the runtime.
Explore the architectureFrom reference to working draft
Adapt this architecture with your AWS AI Agent
Start from the exact diagram in this guide. Change requirements, challenge a decision, or ask what fails first, while keeping the architecture editable.