AWS · Editable reference architecture

AWS 3-Tier Production Architecture

Separate internet-facing entry points, application compute and persistent data in an AWS three-tier architecture. Customize a working diagram of request routing, caching and database access before discussing your deployment with the team.

Open & Edit in DrawArc (Free, No Login Required)

Your changes stay in a separate draft on this browser. Download an editable project to keep a portable copy.

Read the step-by-step architecture tutorial →

LinkedIn X (Twitter)WhatsApp

6 components · 5 connections · Open the editor to zoom, move nodes and edit source.

Architectural overview

A three-tier application divides presentation, business logic and data storage into distinct responsibilities. In this reference, a browser reaches CloudFront before a load balancer forwards application requests to ECS services. The application reads PostgreSQL and Redis through explicit connections. These boundaries help a reviewer distinguish public traffic from internal dependencies without reading deployment configuration.

Use the diagram to decide where TLS terminates, which endpoints are public and how application services reach storage. The grouped data tier is a logical boundary: a drawing alone does not create private subnets, security groups or database credentials. Add availability zones, routing tables and failure paths to match your environment rather than treating the starter as a complete infrastructure specification.

Before implementation, document peak request volume, latency targets, backup retention and database recovery objectives. Consider what happens when Redis is unavailable and how the application limits database connections during a traffic spike. Replace the generic service names with the actual deployment units and annotate ownership so this diagram can accompany a design review or onboarding document.

The real-world problem

A growing customer portal needs to serve cacheable content quickly while keeping business logic and transactional records behind controlled entry points. A traffic spike must not turn into unlimited database connections.

Data flow

Connections from this diagram. Branches and control signals are not a single chronological sequence.

Web client → CloudFront: HTTPS.
CloudFront → Application load balancer: Origin request.
Application load balancer → ECS application: Application traffic.
ECS application → RDS PostgreSQL: SQL.
ECS application → Redis cache: Cache reads and writes.

Security boundaries

Cache only eligible public content at CloudFront; define authenticated-response cache keys and bypass rules before serving private pages.
Restrict load-balancer-to-application and application-to-database traffic with explicit network rules. Use workload identity and a secrets manager rather than embedding credentials.
Authorize each application operation independently of network placement; TLS and private subnets do not establish record ownership.

Failure handling

Redis is unavailable

Response: Use a bounded database fallback or a clear degraded response; avoid a retry storm and cache stampede.

Verify: Disable the cache during a load test and check database connection limits and error rates.

An application target fails

Response: Remove unhealthy targets and maintain suitable spare capacity across chosen failure domains; configure request timeouts.

Verify: Terminate one target and measure failed requests and recovery time.

Database data is deleted incorrectly

Response: Restore a tested backup into an isolated environment and reconcile writes against agreed recovery objectives.

Verify: Run a restore drill and verify records, access and measured recovery duration.

Trade-offs and alternatives

Add Redis caching

Benefit: Can reduce repeated database reads.
Cost: Invalidation, extra operations and potentially stale results.
Alternative: Start with database indexes and measured query improvements when traffic is modest.

Use container services

Benefit: Independent application scaling and deployment.
Cost: Capacity policies, image maintenance and database pressure still need ownership.
Alternative: Evaluate a simpler managed runtime or functions for short, event-oriented workloads.

When to use this architecture

Review a containerized web application whose presentation, compute and database responsibilities need clear separation.
Explain public entry points and internal application-to-data access during a security or reliability discussion.
Create a starting architecture for an API-backed product, then add environment-specific scaling and recovery decisions.

Key components

Web client: Browser application initiating authenticated HTTPS requests.
CloudFront: Caches eligible content and routes application traffic to the origin.
Application load balancer: Distributes incoming requests across healthy application targets.
ECS application: Runs application logic in independently deployable containers.
RDS PostgreSQL: Stores transactional records with an explicit backup and recovery policy.
Redis cache: Caches disposable data; define expiry and database fallback behavior.

Questions about this template

Does this diagram deploy resources to AWS?

No. It is an editable architecture reference. Provisioning, IAM policies, networking and cost validation remain separate implementation work.

Can I replace ECS with EC2 or EKS?

Yes. Change the compute component, icon and connections in the canvas or ArchScript source to reflect your actual platform.

Related architecture templates

AWS