AWS Three-Tier Microservices Architecture

System Design · flowchart diagram · CC-BY-4.0

Reference three-tier microservices architecture on AWS — edge (CloudFront/WAF), app (ALB + service fleet), and data (Aurora/Redis/S3) tiers with async SQS workers.

Source: https://docs.aws.amazon.com/wellarchitected/latest/framework/welcome.html
Curated by Archigram editorial
aws microservices three-tier alb rds sqs lambda

Mermaid source

flowchart LR
    subgraph Client
        U[Users]
    end
    subgraph Edge[Edge Layer]
        CF[CloudFront CDN]
        WAF[AWS WAF]
    end
    subgraph App[Application Tier]
        ALB[Application Load Balancer]
        API1[Order Service]
        API2[Catalog Service]
        API3[User Service]
    end
    subgraph Data[Data Tier]
        RDS[(Aurora Postgres)]
        REDIS[(ElastiCache Redis)]
        S3[(S3 Bucket)]
    end
    subgraph Async[Async Layer]
        SQS[SQS Queues]
        LAM[Worker Lambdas]
    end

    U --> CF
    CF --> WAF
    WAF --> ALB
    ALB --> API1
    ALB --> API2
    ALB --> API3
    API1 --> RDS
    API2 --> RDS
    API3 --> RDS
    API1 --> REDIS
    API2 --> REDIS
    API1 --> SQS
    SQS --> LAM
    LAM --> S3
    LAM --> RDS

What this diagram shows

A canonical AWS three-tier microservices layout. Traffic enters through CloudFront and AWS WAF, terminates at an Application Load Balancer, fans out to a fleet of stateless service containers (Order, Catalog, User), and the services share an Aurora Postgres primary, an ElastiCache Redis layer for hot reads, and S3 for blob storage. Heavy work (notifications, image processing, analytics writes) is handed to SQS-backed Lambda workers so the synchronous request path stays fast.

When to use it

Reach for this pattern when you need a clear separation between presentation, application, and data concerns and you want each service to scale independently. It works well for B2C and B2B SaaS apps in the 10k–10M monthly users range, where a managed RDS handles writes, Redis absorbs read traffic, and SQS smooths out spikes. It is a good starting point if you are migrating off a single monolith and want to extract two or three services without committing to full event-driven architecture yet.

How to adapt it for your project

Swap the AWS-specific components for their cloud equivalents — Cloud Load Balancing + Cloud SQL on GCP, Front Door + Azure SQL on Azure. If you do not need three services yet, collapse them into one and keep the layered shape; the diagram still earns its keep as a deployment topology. For higher reliability, duplicate the Application and Data tiers across two Availability Zones and put the Aurora cluster in multi-AZ mode. If you outgrow Aurora, replace with Citus or Vitess and shard by tenant.

Key concepts

Related diagrams