AWS Architecture Patterns

Reference Architectures for AWS — A Pattern Library by Workload Shape

Battle-tested AWS blueprints — Pool/Silo/Bridge SaaS, Lakehouse vs Warehouse, RAG-on-Bedrock, zero-trust networking. Picking a single AWS service? Use the Decision Hub. Picking the whole architecture? You are in the right place.

Browse the patterns

Pick a single service →

What's in the library

Pattern categories

Blueprints in library

60+

AWS services covered

AWS Pro

Reviewed by certified architects

Reference blueprints

Featured architecture patterns

Each pattern is a complete blueprint — services, isolation model, trade-offs, cost notes, and the comparison guides that go a layer deeper.

Serverless

Event-driven microservices on AWS — EventBridge, Pipes, and the Outbox Pattern

Production event-driven architecture on AWS — EventBridge custom buses, EventBridge Pipes for the transactional outbox, SQS dead-letter queues, Step Functions for orchestration, and Lambda or Fargate workers. Decouple services without dual-writes.

View the pattern

AI & ML

Generative AI RAG on Bedrock — S3 Vectors + Knowledge Bases

Production retrieval-augmented generation on AWS — Bedrock Knowledge Bases on S3 Vectors for cost-efficient retrieval, Bedrock Guardrails for safety, and per-tenant inference profiles for spend caps. The 2026 AWS-native default for enterprise RAG.

View the pattern

Security & Compliance

HIPAA on AWS for healthtech — The Smallest Defensible Footprint

BAA-eligible reference architecture for a Series A healthtech on AWS — Cognito, ALB, Fargate, Aurora encrypted with KMS CMKs, S3 with object-level encryption, CloudTrail Lake, AWS Config HIPAA conformance pack, GuardDuty, Macie, Audit Manager, and Bedrock for HIPAA-eligible AI features.

View the pattern

Data & Analytics

Lakehouse on AWS — S3 Tables, Iceberg, Athena, and Redshift Spectrum

Production lakehouse reference architecture on AWS — S3 Tables (managed Apache Iceberg), Glue Data Catalog, Athena, Redshift Spectrum, Lake Formation, and Managed Service for Apache Flink for streaming ingest. The AWS-native default for unified analytics in 2026.

View the pattern

SaaS

Multi-Tenant SaaS on AWS — Pool, Silo, and Bridge

Production-ready multi-tenant architecture for SaaS on AWS. Covers tenant isolation models (pool, silo, bridge), per-tenant cost attribution, noisy-neighbor mitigation, and the trade-offs CTOs actually wrestle with at Series B and beyond.

View the pattern

Security & Compliance

Zero-trust VPC on AWS — VPC Lattice, Verified Access, and IAM-everywhere

Identity-aware networking on AWS — VPC Lattice for service-to-service auth, IAM Roles Anywhere for non-AWS workloads, AWS Verified Access for human and device trust, Verified Permissions for fine-grained authz, PrivateLink for SaaS consumption. No implicit trust based on IP or VPC peering.

View the pattern Need a pattern we haven't built? Tell us the workload and we'll add the most-requested patterns first.

Decision framework

How to choose the right architecture pattern

Four steps that work for almost every AWS workload — from picking an isolation model for a new SaaS to choosing the analytics shape for a regulated workload.

Identify the workload archetype

Transactional SaaS, analytics, AI inference, event-driven, or static-edge — the archetype eliminates 80% of the pattern catalog before you weigh a single trade-off.

Capture the hard constraints

Compliance scope (HIPAA, PCI, SOC 2, FedRAMP), average ACV, latency budget, and team size become non-negotiable filters that reshape every blueprint.

Pick the blueprint default for that archetype

For most workloads there is a single defensible default — Pool-tier SaaS for early-stage, Bridge for scaling, Silo for enterprise; Lakehouse for unified analytics; RAG-on-Bedrock for AI features. Start there; deviate only with reason.

Validate against AWS Well-Architected before production

Run the AWS Well-Architected Tool against the blueprint. The five pillars (operational excellence, security, reliability, performance, cost) catch issues a pattern guide cannot encode for your specific workload.

Pattern comparisons

Pattern-level comparison tables

The trade-offs that matter when picking a complete blueprint, not a single service. The highlighted row is the AWS-native default for that category in 2026.

Multi-tenant SaaS — Pool vs Bridge vs Silo

Three isolation models, three different cost ceilings and compliance postures. The default is Pool until ACV or contract terms force you up the ladder.

Tier	Cost per tenant	Onboarding speed	Enterprise compliance fit	Noisy-neighbor risk	Per-tenant cost attribution
Pool Default Default for early-stage and product-led-growth SaaS	Lowest — shared compute and DB amortized across all tenants	Instant — no provisioning step	Weakest — many enterprise procurement teams reject pure pool	Highest — disciplined engineering required on every query	Hard — needs Split Cost Allocation Data + tenant tags everywhere
Bridge	Mid — pooled compute, dedicated database per tenant	Minutes — per-tenant DB cluster provision	Strong — "your data is on its own cluster" passes most reviews	Mid — DB isolated, compute still shared	Easier — DB cost is per-tenant by definition
Silo	Highest — dedicated VPC, DB, KMS key, often dedicated CI/CD	Hours to days — full per-tenant provision	Strongest — single-tenant isolation is what auditors expect	Lowest — physical isolation by design	Trivial — every resource is per-tenant by construction

Pool Default

Default for early-stage and product-led-growth SaaS

Cost per tenant: Lowest — shared compute and DB amortized across all tenants
Onboarding speed: Instant — no provisioning step
Enterprise compliance fit: Weakest — many enterprise procurement teams reject pure pool
Noisy-neighbor risk: Highest — disciplined engineering required on every query
Per-tenant cost attribution: Hard — needs Split Cost Allocation Data + tenant tags everywhere

Bridge

Cost per tenant: Mid — pooled compute, dedicated database per tenant
Onboarding speed: Minutes — per-tenant DB cluster provision
Enterprise compliance fit: Strong — "your data is on its own cluster" passes most reviews
Noisy-neighbor risk: Mid — DB isolated, compute still shared
Per-tenant cost attribution: Easier — DB cost is per-tenant by definition

Silo

Cost per tenant: Highest — dedicated VPC, DB, KMS key, often dedicated CI/CD
Onboarding speed: Hours to days — full per-tenant provision
Enterprise compliance fit: Strongest — single-tenant isolation is what auditors expect
Noisy-neighbor risk: Lowest — physical isolation by design
Per-tenant cost attribution: Trivial — every resource is per-tenant by construction

Per-tenant cost attribution requires AWS Split Cost Allocation Data + a mandatory tenant_id tag enforced via SCP — design that in on day one.

Data architecture — Lakehouse vs Warehouse vs Data Lake

The three dominant shapes for analytics on AWS in 2026. Lakehouse is the new default; warehouse still wins for sub-second BI; raw data lake is rarely the right end state on its own.

Pattern	SQL latency	Streaming fit	Cost per TB	Schema flexibility	BI tool support
Lakehouse (S3 Tables + Athena + Redshift Spectrum) Default Default for new analytics platforms in 2026	Seconds — Athena / Spectrum query open table formats directly	Strong — Iceberg + Firehose + MSK Connect ingest streams natively	Lowest — S3 storage, separate compute, pay-per-query	High — schema evolution baked into Iceberg / Delta	Strong — QuickSight, Tableau, Power BI all read via Athena / Redshift
Warehouse (Redshift / managed Snowflake-equivalent)	Sub-second — columnar storage tuned for BI workloads	Mid — streaming ingest works but adds operational tax	Mid — coupled storage + compute (RA3 separates them somewhat)	Mid — schema migrations require ALTER TABLE coordination	Strongest — every BI tool ships a first-class Redshift connector
Data Lake (raw S3 + Glue catalog)	Slow — Athena scans without table-level optimizations	Strongest — append raw events, partition by date	Lowest — pure S3, no table-format overhead	Highest — schema-on-read; anything goes	Weakest — BI tools struggle without a curated layer above

Lakehouse (S3 Tables + Athena + Redshift Spectrum) Default

Default for new analytics platforms in 2026

SQL latency: Seconds — Athena / Spectrum query open table formats directly
Streaming fit: Strong — Iceberg + Firehose + MSK Connect ingest streams natively
Cost per TB: Lowest — S3 storage, separate compute, pay-per-query
Schema flexibility: High — schema evolution baked into Iceberg / Delta
BI tool support: Strong — QuickSight, Tableau, Power BI all read via Athena / Redshift

Warehouse (Redshift / managed Snowflake-equivalent)

SQL latency: Sub-second — columnar storage tuned for BI workloads
Streaming fit: Mid — streaming ingest works but adds operational tax
Cost per TB: Mid — coupled storage + compute (RA3 separates them somewhat)
Schema flexibility: Mid — schema migrations require ALTER TABLE coordination
BI tool support: Strongest — every BI tool ships a first-class Redshift connector

Data Lake (raw S3 + Glue catalog)

SQL latency: Slow — Athena scans without table-level optimizations
Streaming fit: Strongest — append raw events, partition by date
Cost per TB: Lowest — pure S3, no table-format overhead
Schema flexibility: Highest — schema-on-read; anything goes
BI tool support: Weakest — BI tools struggle without a curated layer above

S3 Tables (managed Apache Iceberg) made Lakehouse the AWS-native default in 2024; expect it to subsume most new warehouse workloads by 2027.

Real-world stacks

Use-case based recommendations

The blueprint combinations we'd pick for each maturity stage — not a list of services, but the patterns that compose into a defensible architecture.

Startup MVP

Pre-product-market-fit, small team, speed beats cost optimization

Multi-tenancy: Pool tier — shared Aurora Serverless v2 with row-level security
Data: Single-table DynamoDB or Aurora — defer the lakehouse until you have an analytics story
AI features: Bedrock Knowledge Bases on S3 Vectors — cheapest managed RAG on AWS
Security: AWS Organizations + Cognito — skip Control Tower until headcount > 10

Multi-tenant SaaS pattern → AWS Serverless Consulting →

Scaling SaaS

Steady traffic, tens of millions of requests/month, first enterprise deals on the board

Multi-tenancy: Bridge tier — pooled compute, dedicated DB cluster per enterprise tenant
Data: Lakehouse on S3 Tables — Athena for ad-hoc, Redshift Spectrum for dashboards
Eventing: EventBridge + SQS outbox — decouple services without dual-writes
Observability: CloudWatch + X-Ray, or Datadog if budget allows

Multi-tenant SaaS pattern → AWS Architecture Review →

Enterprise / regulated

HIPAA, PCI, SOC 2, or FedRAMP scope; multi-account; central security team

Multi-tenancy: Silo tier — dedicated VPC, KMS CMK, and per-tenant CI/CD
Network: Zero-trust VPC — VPC Lattice + IAM Roles Anywhere + PrivateLink, no peering
Data: Warehouse with row-level security + Lake Formation tag-based access control
Governance: Control Tower + Security Hub + GuardDuty across every account

AWS Cloud Security → Cloud Compliance Services →

Cost vs performance

Tradeoffs we see on every architecture review

Four cost-vs-performance principles that change which architecture pattern wins. None of these show up in a reference diagram — they show up in your bill and your on-call rotation.

Pool before silo until ACV justifies the silo cost line.

Below ~$50K ACV, silo infrastructure typically costs more than the deal margin. Sell pool to everyone and offer bridge for a 2x price uplift; reserve silo for procurement-driven contracts.

Right-size before re-architecting.

Most pattern swaps are premature. A workload running hot on Aurora rarely needs a lakehouse — it usually needs a read replica and a query-plan review. Re-architect only after you have evidence the current pattern is the bottleneck.

Pick a single source of truth for analytics.

Running both a warehouse and a lakehouse in parallel doubles the storage bill, the ETL surface area, and the on-call rotation. Choose one as the system of record; the other is a derived view at most.

Budget for the operational tax of every pattern.

EKS, multi-region active-active, and lakehouse all cost engineer-weeks per quarter to operate. The blueprint is free; the operations are not. Account for that in the team-size constraint before adopting.

Common pattern mistakes

Adopting silo by default for compliance theater
Most compliance frameworks (SOC 2, HIPAA, PCI) accept logical isolation if the controls are documented. Silo is genuinely required for a small set of contracts; defaulting to it costs 5-10x more than necessary.
Treating lakehouse and warehouse as substitutes
Lakehouse wins on streaming ingest and storage cost; warehouse wins on sub-second BI latency. Picking one based on cost alone routinely surfaces in dashboards that take 12 seconds to load — or ETL pipelines that fall over at peak.
Per-tenant Aurora cluster at sub-$5K ACV
A single Aurora cluster with multi-AZ runs $200+/month minimum. Provisioning one per tenant when ACV is below $5K destroys the unit economics. Use bridge tier with shared clusters partitioned by tenant_id schema.
Building a bespoke multi-tenancy framework
IAM tag conditions + Cognito groups + Aurora row-level security cover 90% of multi-tenant requirements. Building a custom framework ("our shared library that injects tenant_id everywhere") is the most expensive multi-tenancy mistake we see.

Stuck choosing between two patterns? Compare them in the comparison library or book a free architecture review.

Pattern library FAQ

Architecture patterns — quick answers

What is an architecture pattern, and how is it different from a service decision?

A pattern is a complete reference architecture — the AWS services, isolation model, data flow, security posture, and trade-offs needed to deliver an outcome (multi-tenant SaaS, real-time analytics, generative AI). A service decision picks one component (Lambda vs Fargate, Aurora vs DynamoDB). Patterns compose service decisions; the AWS Decision Hub at /decide/ is where you make the per-service picks that feed into the pattern you choose here.

When should I use /patterns/ vs /decide/?

Use /patterns/ when you are choosing the overall architecture for a new workload or a major rework — Pool vs Silo for SaaS, Lakehouse vs Warehouse for analytics, RAG-on-Bedrock vs custom inference for AI. Use /decide/ when you are stuck on a single AWS service pick — Lambda vs Fargate vs EKS, RDS vs Aurora vs DynamoDB. Both are reviewed by the same AWS Solutions Architects.

Are these patterns AWS Well-Architected?

Each pattern is reviewed against the AWS Well-Architected Framework — the five pillars are operational excellence, security, reliability, performance efficiency, and cost optimization. Patterns flag the trade-offs each design makes against the pillars (for example, Pool-tier SaaS optimizes cost but trades operational excellence for engineering discipline). For a workload-specific Well-Architected review, FactualMinds runs the official AWS Well-Architected Tool as a fixed-scope engagement.

How often are these patterns updated?

On every major AWS release (typically 4-6 times per year, plus re:Invent in December). Recent updates incorporate EKS Auto Mode (GA Dec 2024), Aurora DSQL for active-active SQL, Bedrock Knowledge Bases with S3 Vectors, and the current Graviton4 / Fargate pricing model. Each pattern has a Last Updated date in the page header.

Do you implement these patterns for clients?

Yes — FactualMinds (AWS Select Tier Consulting Partner) builds these patterns end-to-end for SaaS, healthtech, fintech, and enterprise customers. Most engagements pair an architecture review with the implementation; we can also stand the pattern up under a fixed-scope statement of work. Talk to AWS Experts to scope an engagement.

What is the cheapest pattern for an early-stage SaaS?

Pool-tier multi-tenant SaaS on Aurora Serverless v2 + DynamoDB + Cognito + Cloudfront, with Bedrock Knowledge Bases on S3 Vectors for any AI features. This stack scales to zero on idle and stays under the AWS free tier for the first ~12 months for most early-stage workloads. The Multi-Tenant SaaS on AWS pattern walks the full architecture and the trade-offs it makes to keep cost down.

Need help adopting one of these patterns?

Our AWS-certified architects build these patterns end-to-end for SaaS, healthtech, fintech, and enterprise customers. Tell us your constraints and we'll scope the engagement.

Talk to AWS Experts

Browse comparison guides