What are typical firewall traffic flows for a web server, and how does a 3-tier e-commerce architecture look?
A public web server has three traffic types: HTTPS in from the Internet, SMTP/SQL out to the Intranet (order-confirmation email, database), and SNMP out to the Intranet (monitoring). A concrete 3-tier e-commerce example stages these across firewalls — the Web server in DMZ 1, the App server in DMZ 2, and the Database in the Intranet — so a request must pass a firewall boundary (and its allowed protocol) to step one tier deeper. The diagram below shows both the tiers and the allowed flow on each hop.
* 3-tier e-commerce example: Web (DMZ 1) → App (DMZ 2) → Database (Intranet), with the allowed traffic flow labelled on every firewall hop. *
The concrete 3-tier e-commerce example, tier by tier:
Read the diagram top to bottom — it is one customer request walking inward, crossing a firewall (and one narrow allowed protocol) at each step:
| Hop | From → To | Allowed flow | Why only this |
|---|---|---|---|
| 1 | Internet client → Web server (DMZ 1) | HTTPS in, tcp/443 | The only tier the public may reach |
| 2 | Web server → App server (DMZ 2) | App call (defined API) | Web tier holds no data; it delegates business logic |
| 3 | App server → Database (Intranet) | SQL (SQLnet), DB port only | Only the app tier may query the data tier |
The web server has a hybrid role: incoming public traffic + outgoing internal traffic (it also emits SMTP for order emails and SNMP for monitoring back into the Intranet). This is exactly why it lives in a DMZ — it has authorized paths inward that an attacker could abuse if they take over the box, so each of those paths is a single tightly-scoped rule.
The key idea is the staging: a packet from the Internet must traverse a firewall boundary to reach each deeper tier. The presentation/web tier is the most exposed (DMZ 1), the business-logic/app tier is one step deeper (DMZ 2), and the data tier sits deepest in the Intranet.
The 3-tier architecture maps cleanly to security tiers:
| Tier | Component | Trust Level |
|---|---|---|
| Client | User's browser | Untrusted (anyone) |
| Web (presentation) | Web server | Public-facing, exposed |
| Application (business logic) | App server | Trusted only by web server |
| Database (data) | Database server | Most-protected; only app server can connect |
The attack containment story:
| Attacker compromises | Reaches |
|---|---|
| Web server only | Static content + can call app server (per defined API) |
| App server | Can query database (per defined queries) |
| Database directly | All data (catastrophic — but database is hardest to reach) |
Each tier transition crosses a firewall, with progressively narrower allowed traffic. By the time data is reachable, the attacker has had to compromise three separate systems.
The reality of cloud:
In AWS / Azure, this maps to:
| AWS | Equivalent |
|---|---|
| Internet ALB | Outer firewall |
| Web tier ASG | Web server in public subnet |
| App tier ASG | App server in private subnet |
| RDS database | Database in private subnet, security group locked to app tier |
The "subnets + security groups" pattern in AWS is essentially the 3-tier DMZ model translated to cloud.
Tip: When you see a startup or new product hosting "all on one server" — web, app, database — that's a security smell. The 3-tier architecture isn't about scale, it's about blast-radius reduction. Even a low-traffic site benefits from putting the database on its own (locked-down) host.
Go deeper:
Multitier architecture (Wikipedia) — the presentation/application/data tiers the card maps onto DMZ zones.