Study the architecture, understand the tradeoffs, then open the real diagram and adapt it. Each guide explains the request flow, design decisions, operational checks, and limits that matter in production.
Real architecture flows
Services, boundaries, and connections shown in context.
Production questions
Failure modes, controls, and operational checks for each pattern.
Editable starters
Open any diagram on the canvas and make it fit your workload.
Core AWS patterns
These focused designs isolate ideas such as Multi-AZ resilience, private networking, asynchronous work, authentication, and cost-aware serverless delivery.
This starter architecture separates ingress, presentation, application logic, and relational data so each tier can fail and scale independently. It is a practical baseline for teams moving a conventional web application onto AWS without collapsing every responsibility into one server.
Explore the architecture
This architecture is the smallest useful serverless API baseline: a managed HTTPS entry point, stateless function compute, on-demand data storage, and observable execution. It is intentionally compact so the first production decisions remain easy to see.
Explore the architecture
This VPC pattern makes exposure decisions explicit. The load balancer and NAT gateway live in the public path, application compute accepts traffic only from the load balancer, and the database has no direct route from the internet.
Explore the architecture
This design accepts uploads immediately and lets workers process them at a controlled rate. S3 protects the source file, SQS absorbs bursts and retries, Lambda performs bounded work, and separate result and status stores make completion observable.
Explore the architecture
This architecture focuses on one failure question: what happens when an entire Availability Zone becomes unavailable? Healthy application capacity remains in the other zone, the load balancer removes failed targets, and RDS can promote its synchronous standby.
Explore the architecture
This architecture separates identity verification from application authorization. Cognito authenticates the user, API Gateway validates the presented token, Lambda enforces business rules, and DynamoDB remains behind the application boundary.
Explore the architecture
This design minimizes always-on infrastructure while a product is finding its traffic pattern. Static assets live in S3, API Gateway and Lambda handle requests on demand, and DynamoDB starts with pay-per-request capacity.
Explore the architecture
This diagram is deliberately incomplete. Its clean request path makes the risks easy to discuss: one application instance, a Single-AZ database, and no visible recovery or operational controls. Use it as a review exercise before opening the editable version and improving it.
Explore the architectureProduction systems
Follow larger designs across edge security, compute, state, event processing, delivery pipelines, analytics, IoT, and machine learning operations.
This architecture combines a protected synchronous API with a durable asynchronous work path. Tenant identity travels from Cognito into application authorization, domain events decouple background work, and DynamoDB plus S3 provide scalable tenant state and assets.
Explore the architecture
This reference expands the three-tier baseline with a global edge, separate scaling domains, caching, read scaling, private egress, secrets, backups, and operations. It is intended for teams evaluating a conventional production web platform rather than a minimal learning diagram.
Explore the architecture
This architecture runs a production container service without managing an EC2 host fleet. A protected global edge forwards to a Multi-AZ ALB, Fargate tasks stay private, and managed data, image, secret, and observability services support the runtime.
Explore the architecture
This design accepts an order through an authenticated API, publishes a durable domain event, and uses a saga to coordinate payment, inventory, fulfillment, and notification. It separates request latency from business processing while preserving explicit recovery paths.
Explore the architecture
This architecture keeps large upload bytes out of the API, lands every object in an encrypted trust boundary, scans before promotion, quarantines suspicious files, and exposes processing status to the application. It is a security-focused workflow rather than a generic upload shortcut.
Explore the architecture
This architecture supports both near-real-time processing and batch-oriented curation. Kinesis fans data into a fast Lambda path and a Firehose landing path, Glue creates query-ready datasets, and Lake Formation applies governance across Athena, Redshift, and QuickSight.
Explore the architecture
This delivery architecture turns a source change into a tested, scanned, approved, and deployed Fargate release. It keeps build artifacts and container images distinct, makes the production approval visible, and delegates infrastructure updates to CloudFormation.
Explore the architecture
This architecture authenticates a device fleet, buffers telemetry, preserves raw events, derives searchable and time-series views, raises operational alerts, and presents fleet trends. Each storage path serves a distinct access pattern instead of treating one database as universal.
Explore the architecture
This architecture runs scheduled or on-demand scoring as a durable workflow. Step Functions coordinates jobs, AWS Batch supplies container compute, ECR pins the runtime, an approved SageMaker model supplies the artifact, and S3 preserves inputs and predictions.
Explore the architecture