Lesson 022 · AWS Learning Path

AWS 022: Model a three-tier application before choosing AWS services

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

The problem

A team chooses EC2, Lambda, containers, or a database before documenting what the application must do. The result is a list of services without traffic flow, trust boundaries, availability targets, recovery behavior, or ownership.

Architecture begins with requirements and relationships. AWS service selection comes later.

Final outcome

You will produce a three-tier logical model for a training portal, trace four important request paths, identify failure and security boundaries, and write a short decision record. No AWS resources are created.

Scenario

The portal must:

• let learners browse public course descriptions;
• authenticate enrolled learners;
• accept assessment submissions;
• show progress;
• support 2,000 concurrent learners during an exam window;
• preserve completed submissions;
• recover service within two hours;
• lose no more than 15 minutes of accepted progress data;
• retain audit records;
• protect personal data;
• allow controlled deployments without exposing the database.

Unanswered requirements must be recorded as assumptions, not silently invented.

The three logical tiers

Learner or administrator
          |
          v
[Presentation tier]
TLS, web delivery, input boundary
          |
          v
[Application tier]
authentication, authorization, rules, APIs
          |
          v
[Data tier]
durable records, indexes, backup, recovery

The diagram is logical. A tier is a responsibility boundary, not necessarily one server, subnet, Availability Zone, or AWS service. A managed front end may serve the presentation tier. A serverless function, container, or instance can run application logic. Different data models can support different data needs.

Start with flows

Document these paths:

1. Browse catalog: learner to presentation to application to catalog data.
2. Sign in: learner to identity boundary, then session or token returned.
3. Submit assessment: learner to application validation and authorization, then durable write and acknowledgement.
4. Administrator publishes content: administrator identity, privileged authorization, controlled update, and audit record.

For each flow state:

• source and destination;
• protocol or logical interface;
• identity;
• data classification;
• expected response;
• timeout and retry behavior;
• audit evidence;
• what happens if a dependency fails.

Separate control and data planes

The data plane serves learners and processes assessments. The control plane creates or changes infrastructure, deployments, identity policy, configuration, and backups.

An administrator changing a deployment is not the same flow as a learner submitting an answer. Mixing these paths can expose management interfaces or grant the application unnecessary permissions.

Availability and recovery

Translate the scenario:

• RTO of two hours means the service must be restored within two hours after an accepted disruption scenario.
• RPO of 15 minutes means recovery must not lose more than 15 minutes of accepted progress data.
• 2,000 concurrent learners is a load condition, not a complete capacity plan.

Ask what must remain available. Browsing catalog content might tolerate stale cached data. Accepting an assessment requires durable, idempotent processing and a clear acknowledgement. Do not claim success before the durable write completes if the business cannot accept loss.

Multiple Availability Zones can reduce a zonal failure risk, but only if every critical dependency, route, deployment process, and data layer is designed and tested for that failure.

Security boundaries

Mark these boundaries:

• untrusted internet to public entry point;
• authenticated learner session;
• privileged administrator path;
• application identity to data access;
• secrets and key management;
• log and audit destinations;
• deployment identity to control plane.

The database should not become public merely because the web tier is public. The application should receive the minimum data actions it needs. Authentication proves an identity; authorization decides what that identity may do.

Capacity and state

Classify state:

Horizontal scaling is easiest when application workers do not keep the only copy of important state on a local disk.

Practical method

Create:

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

Create three-tier-model.md with:

1. scenario and assumptions;
2. measurable functional and nonfunctional requirements;
3. the logical three-tier diagram;
4. four end-to-end flows;
5. trust and data-classification boundaries;
6. availability, RTO, and RPO interpretation;
7. capacity assumptions;
8. observability and audit evidence;
9. unresolved questions;
10. service-selection criteria.

Do not select AWS services until the criteria are complete.

Service-selection worksheet

Only after modelling, compare categories:

One possible future mapping is CloudFront and a public entry layer, a load-balanced or serverless application tier, and a managed data service. It is not automatically correct. Requirements decide.

Failure review

For each tier, answer:

• What if one instance or execution fails?
• What if one Availability Zone is unavailable?
• What if the database is slow but reachable?
• What if a write times out after committing?
• What if identity is unavailable?
• What if a deployment introduces a bad version?
• What evidence distinguishes each failure?

The timed-out write question introduces idempotency. A retry must not create two assessment submissions.

Common design errors

Architecture scenarios

1. Static catalog demand grows globally but submissions remain regional. Scale and cache the presentation path without assuming the transaction path has the same need.
2. Submission processing can tolerate seconds of delay but must not lose accepted work. Consider durable asynchronous decoupling and idempotent consumers.
3. Regulation requires data residency. Region selection and replication boundaries change.
4. RPO becomes zero for completed submissions. A periodic 15-minute backup alone no longer meets the requirement.

Completion gate

Pass when three-tier-model.md contains measurable requirements, four complete flows, explicit trust boundaries, RTO/RPO interpretation, failure analysis, and service-selection criteria. The design must distinguish logical tiers from physical resources and explain one safe retry.

No AWS resources were created.

Official sources

• AWS Well-Architected Framework
• Reliability Pillar
• Security Pillar
• AWS architecture decision records