Reference architectures

AWS Architecture Catalog

Twelve diagrams covering the most common patterns for publishing sites, running applications, processing data, adding AI and keeping services available, using only AWS services.

12diagrams
4categories
100%AWS services
My site on GitHub Pages →My site on S3 →
Diagram 1: static HTML site (Route 53 + CloudFront + S3)AWS CloudUsersR53Amazon Route 53DNSCFAmazon CloudFrontCDN + HTTPSACMAWS CertificateManagerS3Amazon S3(private bucket)CLIDeveloper(AWS CLI)123OAC41. The user enters the domain; Route 53 resolves the DNS record.2. CloudFront serves the site over HTTPS with an AWS Certificate Manager certificate.3. CloudFront fetches HTML, CSS and JS from the private S3 bucket through OAC.4. The developer uploads the files with AWS CLI (aws s3 sync).
01

Static HTML site

Route 53 resolves the domain, CloudFront serves the site over HTTPS, and S3 stores the files in a private bucket behind OAC.

Route 53CloudFrontS3ACM
View diagram →
Diagram 2: layered security for a static site (WAF, Shield, OAC, KMS)AWS CloudUsersR53Amazon Route 53DNSCFAmazon CloudFront+ AWS ShieldWAFAWS WAFrules and botsS3Amazon S3(private, OAC)KMSAWS KMS(encryption)12341. The user resolves the domain with Amazon Route 53, which points to CloudFront.2. AWS WAF inspects each request (OWASP, bots, rate limits); AWS Shield mitigates DDoS.3. CloudFront gets the content from S3 through OAC; the bucket is not public.4. The objects in the bucket are encrypted with AWS KMS.
02

Layered security

The static site with AWS WAF, Shield, OAC and KMS encryption to protect traffic and stored objects.

WAFShieldKMSOAC
View diagram →
Diagram 3: automated deployment (CodePipeline + CodeBuild + S3 + CloudFront)AWS CloudDeveloper(git / AWS CLI)S3Amazon S3(source code)CPAWS CodePipeline(orchestration)CBAWS CodeBuild(build and tests)S3Amazon S3(HTML site)CFAmazon CloudFront(invalidation)IAMAWS IAM(build role)Users1234561. The developer pushes the code to the source S3 bucket (git push or AWS CLI).2. CodePipeline detects the change and runs the pipeline stages.3. CodeBuild installs dependencies, runs the tests and generates HTML, CSS and JS.4. The output is published to the site S3 bucket.5. The CloudFront cache is invalidated so users get the new version.6. Users access the site through CloudFront.
03

Automated deployment (CI/CD)

CodePipeline and CodeBuild build and publish the site on every change, with a CloudFront cache invalidation.

CodePipelineCodeBuildIAMS3
View diagram →
Diagram 4: dynamic site with ALB, ECS Fargate and RDS in a VPCAWS CloudVPCUsersR53Amazon Route 53DNSCFAmazon CloudFrontCDN + HTTPSALBElastic LoadBalancer (ALB)ECSAmazon ECS(Fargate)RDSAmazon RDS(database)S3Amazon S3(static assets)1234561. The user resolves the domain with Amazon Route 53.2. Route 53 points to CloudFront, which uses an ACM certificate.3. CloudFront sends dynamic requests to the Application Load Balancer.4. The ALB distributes traffic to ECS (Fargate) tasks in private subnets.5. The tasks query and store data in Amazon RDS.6. Static files (CSS, JS, images) are served from Amazon S3.
04

Dynamic site with ALB, ECS and RDS

CloudFront sends dynamic requests to an ALB, which distributes them to ECS Fargate containers inside a VPC.

ALBECS FargateRDSVPC
View diagram →
Diagram 5: serverless site with login and API (Amplify, Cognito, API Gateway, Lambda, DynamoDB)AWS CloudUsersAMPAWS AmplifyHosting (HTML/JS)COGAmazon Cognito(login and tokens)APIAmazon APIGatewayλAWS Lambda(logic)DDBAmazon DynamoDB(data)123451. The user loads the HTML and JavaScript site from AWS Amplify Hosting.2. The user signs in with Amazon Cognito and receives a JWT token.3. The browser's JavaScript calls Amazon API Gateway with the token.4. API Gateway validates the token and invokes the Lambda function.5. Lambda reads or writes DynamoDB and returns the response.
05

Serverless with login and API

Amplify Hosting serves the front end, Cognito authenticates users, and API Gateway, Lambda and DynamoDB process each request.

AmplifyCognitoAPI GatewayLambdaDynamoDB
View diagram →
Diagram 6: asynchronous processing (API Gateway + SQS + Lambda)AWS CloudUsersAPIAmazon APIGatewaySQSAmazon SQS(queue)λAWS Lambda(processes)DDBAmazon DynamoDB(results)SNSAmazon SNS(notifications)DLQDead-letterqueue (DLQ)1234561. The client sends the request to Amazon API Gateway.2. API Gateway puts the message in SQS and responds without waiting for processing.3. Lambda consumes messages from the queue and runs the business logic.4. Lambda stores the result in Amazon DynamoDB.5. Lambda publishes an event to Amazon SNS to notify subscribers.6. Messages that fail repeatedly are moved to the dead-letter queue (DLQ).
06

Asynchronous processing

API Gateway queues messages in SQS, Lambda processes them in the background, and failed messages land in a DLQ.

SQSLambdaSNSDynamoDB
View diagram →
Diagram 7: events and orchestration (EventBridge + Step Functions)AWS CloudAPIAmazon APIGatewayEBAmazonEventBridgeSFNAWS StepFunctionsλAWS Lambda(validation)λAWS Lambda(payment)AURAmazon AuroraServerless v2123451. API Gateway receives the HTTP request and publishes an event to EventBridge.2. EventBridge evaluates its rules and sends the event to Step Functions.3. Step Functions invokes the validation Lambda function.4. If validation succeeds, Step Functions invokes the payment Lambda function.5. The payment function records the transaction in Aurora Serverless v2.
07

Events and orchestration

EventBridge routes events and Step Functions coordinates the validation and payment Lambda functions on Aurora.

EventBridgeStep FunctionsLambdaAurora
View diagram →
Diagram 8: real time (AppSync + DynamoDB Streams + Lambda)AWS CloudUsersGQLAWS AppSync(GraphQL)DDBAmazon DynamoDB(table)λAWS Lambda(processes)123DynamoDB Streams451. The user sends a GraphQL mutation to AppSync.2. AppSync writes the change to the Amazon DynamoDB table.3. DynamoDB Streams emits the change and a Lambda function receives it.4. Lambda sends the event back to AppSync.5. AppSync pushes the event to subscribed clients over WebSocket.
08

Real time

AppSync receives mutations, DynamoDB Streams detects changes, and clients receive updates over WebSocket.

AppSyncDynamoDBStreamsLambda
View diagram →
Diagram 9: data and analytics (Firehose + S3 + Glue + Athena + QuickSight)AWS CloudAPPApplications(events)FHAmazon DataFirehoseS3Amazon S3(data lake)ATHAmazon Athena(SQL)QSAmazonQuickSightGLUEAWS Glue(catalog and ETL)123451. Applications send records or events to Amazon Data Firehose.2. Firehose batches the records and writes them to S3.3. Athena queries the S3 files with SQL.4. QuickSight visualizes Athena results in dashboards.5. Glue maintains the table catalog that Athena uses.
09

Data and analytics

Data Firehose writes events to an S3 data lake; Glue catalogs the data, Athena queries it and QuickSight visualizes it.

FirehoseS3GlueAthenaQuickSight
View diagram →
Diagram 10: generative AI with RAG (Bedrock + OpenSearch + Lambda)AWS CloudUsersAPIAmazon APIGatewayλAWS Lambda(orchestrates RAG)BDKAmazon Bedrock(model and embeddings)OSAmazon OpenSearch(vectors)S3Amazon S3(documents)12345ingestion1. The user sends the question to Amazon API Gateway.2. API Gateway invokes the Lambda function that orchestrates the RAG flow.3. Lambda searches OpenSearch for the most similar document chunks.4. Lambda sends the question and the retrieved context to an Amazon Bedrock model.5. Bedrock returns the answer, and the result reaches the user through API Gateway.
10

Generative AI with RAG

Lambda retrieves relevant chunks from OpenSearch and sends them to a Bedrock model to answer from your own documents.

BedrockOpenSearchLambdaS3
View diagram →
Diagram 11: managed Kubernetes (Route 53 + ALB + EKS + RDS + ECR)AWS CloudUsersR53Amazon Route 53(DNS)ALBElastic LoadBalancer (ALB)EKSAmazon EKS(pods)RDSAmazon RDS(Aurora)ECRAmazon ECR(images)123451. The user resolves the domain with Amazon Route 53.2. Route 53 directs traffic to the Application Load Balancer created by the Ingress controller.3. The ALB sends requests to the pods in the EKS cluster.4. The pods query the database in Amazon RDS or Aurora.5. On deployment, the cluster pulls the images from Amazon ECR.
11

Managed Kubernetes

Route 53 and an ALB deliver traffic to EKS pods, which query RDS or Aurora and pull their images from ECR.

EKSALBECRRDS
View diagram →
Diagram 12: multi-region and disaster recovery (Route 53 + ECS + Aurora Global)AWS CloudPrimary region (us-east-1)Secondary region (us-west-2)UsersR53Amazon Route 53(failover)ECSAmazon ECS(active app)AURAurora(writer)ECSAmazon ECS(standby)AURAurora(reader)1234replication1. The user resolves the domain with Route 53.2. While the primary region passes its health checks, Route 53 sends traffic to ECS in us-east-1.3. If the primary region fails, Route 53 redirects traffic to the secondary region (failover path).4. Aurora Global Database replicates data from the primary to the secondary region.
12

Multi-region and disaster recovery

Route 53 with failover sends traffic to the primary region and, if it fails, to the secondary, where Aurora Global keeps a replica.

Route 53ECSAurora Global
View diagram →