Lesson 012 · AWS Learning Path

AWS 012: Client-server and three-tier applications

Anil Jalela · Published Jul 7, 2025 · 5 min read

The problem

A learner sees one website and assumes one server performs every function. In reality, the browser, DNS, network edge, presentation code, business logic, cache, database, object storage, identity, and monitoring can be separate components with different security and scaling needs.

Before choosing AWS services, model the request and the responsibility of each tier.

Learning outcomes

You will be able to:

1. identify client and server roles in a request-response interaction;
2. distinguish presentation, logic, and data tiers;
3. explain why logical tiers do not require one server each;
4. trace a request and response across boundaries;
5. identify state, trust, scaling, and failure concerns for each tier.

Client-server model

A client initiates a request for a service. A server listens for supported requests, processes them, and returns a response.

Client -- request --> Server
Client <-- response -- Server

The words describe roles, not permanent device types. One service can be a server to a browser and a client to a database or downstream API.

Examples:

• a browser is an HTTP client to a web endpoint;
• an application service is a client to a database;
• a monitoring agent is a client to a metrics endpoint.

Three logical tiers

Presentation tier

Interacts with the user or API consumer.

Responsibilities can include:

• displaying content;
• collecting input;
• client-side validation;
• calling application APIs;
• managing user-facing sessions safely.

Logic tier

Implements business behavior.

Responsibilities can include:

• authorization decisions;
• validation that cannot be trusted to the client;
• workflows and calculations;
• data access;
• integration with other services.

Data tier

Stores and retrieves durable or temporary data.

It can include:

• relational or non-relational databases;
• object storage;
• file systems;
• caches;
• search or analytics stores.

[Browser or mobile client]
           |
           v
[Presentation endpoint]
           |
           v
[Application logic]
           |
           v
[Database, objects, cache]

Logical tier is not physical server

All tiers can run on one machine in a small development environment. Each tier can also use many services and instances in production.

Examples:

• static presentation files can be served from object storage and a content-delivery network;
• logic can run on VMs, containers, or functions;
• data can use several purpose-built stores.

Separating concerns supports independent scaling and security, but too many components can add operational complexity.

Trace one request

Scenario: a learner submits an assessment answer.

1. The client resolves the application name.
2. A secure connection reaches the presentation or API endpoint.
3. Identity information is authenticated.
4. The logic tier validates the request and checks authorization.
5. The logic tier writes the answer to the data tier.
6. The data tier confirms the write according to its consistency behavior.
7. The logic tier returns a result.
8. The client displays success.
9. Logs, metrics, and traces provide operational evidence.

A visible success message is not enough if the write was never committed or the user was not authorized.

Trust boundaries

Never trust a value only because browser code validated it. A user can modify the client request.

At each boundary define:

• identity;
• allowed actions;
• input validation;
• encryption in transit;
• timeout and retry;
• rate limit;
• logging and sensitive-data handling;
• failure response.

The data tier should not be directly reachable by ordinary internet clients unless a deliberately selected service pattern requires it.

State and scaling

A stateless logic instance does not keep required user state only in its local memory or disk. Any healthy instance can process the next request using an appropriate shared or external state service.

This supports horizontal scaling and replacement.

Stateful design is not wrong, but state placement changes:

• routing;
• failover;
• replication;
• consistency;
• backup;
• recovery;
• deployment.

Practical modelling exercise

Create:

mkdir -p "$HOME/nitwings-aws/evidence/aws-012"

Create three-tier-request.md for this workload:

Learners sign in, browse lessons, stream images or video, submit answers, and view progress. Instructors publish content. Progress must survive application replacement.

Include:

1. actors;
2. presentation responsibilities;
3. logic responsibilities;
4. data categories;
5. request flow for submitting an answer;
6. trust boundaries;
7. state that must survive;
8. expected failure behavior;
9. one metric and one log per tier;
10. items deliberately not assigned to an AWS service yet.

Use this diagram and improve it:

Learner
  |
  v
Presentation tier
  |
  v
Logic tier
  | \
  |  \--> Object content
  v
Progress data

Expected decisions

• credentials are not stored in browser code;
• server-side logic revalidates input and authorization;
• progress is external to replaceable logic instances;
• static media and transactional progress have different storage needs;
• each boundary has timeout, error, and evidence behavior;
• the model does not prematurely choose EC2, Lambda, RDS, or DynamoDB.

Failure analysis

Troubleshoot from symptom to boundary. Do not restart every server.

Common misconceptions

• Three tiers do not mean exactly three machines.
• A public presentation tier does not require a public database.
• Client-side validation is not a security control by itself.
• Load balancing does not externalize state.
• A cache is not automatically the durable data store.
• Microservices are not required for a three-tier architecture.

Knowledge check

1. Can one component be both client and server?
2. Which tier owns business authorization?
3. Why should progress not live only on one application instance?
4. Does a three-tier model require three EC2 instances?
5. What proves an assessment write succeeded?

Expected answers: yes; logic; replacement or scaling would lose it; no; durable data-tier evidence and correct application response.

Completion gate

Pass when three-tier-request.md includes the ten required elements, traces one complete request and failure, and clearly separates logical responsibilities from future AWS service selection.

No AWS resources were created.

Official sources

• AWS three-tier architecture overview
• Traditional three-tier web hosting
• AWS Security Reference Architecture
• AWS Well-Architected Framework