Three-tier app in a VPC architecture
The same three-tier shape drawn the way AWS actually organises it: edge in the public subnets, app and data in the private ones, two availability zones, and the pieces that live outside the VPC outside the box.
Every resource, and what it costs.
Projections from August 2026 list prices for always-on resources. Connect an account and these become the figures your provider actually bills.
| Node | Type | What it is | Projected |
|---|---|---|---|
| Domain | Network | 1 zone + queries, certificate free | $1.00/mo |
| Load balancer (ALB) | Network | 1 ALB + light LCU usage | $23/mo |
| NAT gateway | Network | 1 gateway + 100 GB | $37/mo |
| App service ×3 | Compute | 3 × 0.25 vCPU · 0.5 GB | $27/mo |
| Primary database | Database | db.t4g.large · multi-AZ · 100 GB | $211/mo |
| ElastiCache Redis | Database | cache.t4g.small | $25/mo |
| User uploads | Storage | 100 GB standard | $3.00/mo |
Every figure is a projection from AWS list prices, before anything is built.
Similar templates.
Container behind a load balancer
The smallest thing that serves real traffic: a public load balancer in two availability zones and one Fargate container. About four minutes to create and roughly 4¢ an hour, so it is the cheapest way to find out whether a deploy works end to end.
Three-tier web application
The default shape: load balancer, containerised app tier, managed Postgres, cache and asset storage.
Serverless API
HTTP API with function compute and a key-value store. Scales to zero; the floor is the gateway.
Open Three-tier app in a VPC on the canvas.
It loads as an editable graph. Ask Archie to change it, then approve the plan and it is built in your own AWS account.