Study the architecture, understand the tradeoffs, then open the real diagram and adapt it.
Core AWS patterns
Focused diagrams that answer popular AWS service choices, resilience, networking, asynchronous work, authentication, and cost-aware delivery.
Foundational patterns
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 is the serverless API baseline that most production APIs grow from rather than away from: a managed HTTPS entry point, stateless function compute, on-demand data storage, and observable execution. It is deliberately compact so the first real decisions stay legible. Adding authentication, caching, asynchronous work, and a second Region each attaches to this shape without replacing it, which is why it is worth understanding before the additions arrive.
Explore the architecture
This VPC pattern makes exposure decisions explicit and auditable. The load balancer and NAT gateway are the only resources in the public path; application compute accepts traffic solely from the load balancer security group; the database accepts connections solely from the application security group and has no route to or from the internet. Because every layer is enforced by a route table and a security group reference rather than by convention, you can answer "what is reachable from the internet?" by reading the diagram. Everything else in a production build, such as a second Availability Zone, VPC endpoints, and flow logs, attaches to this skeleton without changing it.
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 an EC2 host fleet. A protected global edge forwards to a Multi-AZ load balancer, Fargate tasks stay private and reach data services over the VPC network, and managed image, secret, and observability services support the runtime. Every component here is one an ordinary web application needs eventually, which is why this shape is a common destination for teams outgrowing a single server and for teams who found Lambda too constraining.
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
This retrieval-augmented generation architecture separates the API contract, orchestration logic, owned knowledge, vector search, and foundation model. It provides a clear baseline for grounding model responses in private documents while keeping ingestion, evaluation, authorization, and conversation storage as explicit next decisions.
Explore the architecture
This streaming analytics architecture decouples burst absorption, event transformation, durable delivery, query, and visualization. Each responsibility scales independently, while S3 preserves the complete history needed for replay, deeper analysis, and later changes to dashboard logic.
Explore the architecture
This Kubernetes architecture makes the primary operating boundaries visible without drawing every cluster object. Public ingress, private compute, cache, and relational state are separated so platform teams can reason about scaling, availability, deployment, and data ownership independently.
Explore the architecture
This multi-Region serverless pattern makes regional independence explicit. DNS, compute, and data behavior are separated so teams can discuss routing policy, write ownership, replication conflicts, dependency locality, failover, and failback before declaring the application regionally resilient.
Explore the architecture
This hub-and-spoke network architecture separates private connectivity from VPC routing and workload placement. It gives teams a clear place to discuss route-table isolation, shared services, inspection, address planning, redundant circuits, and the boundary between network and application ownership.
Explore the architecture
This media architecture decouples a fast, durable upload from long-running transcoding and global delivery. Separate source and rendition stores preserve originals, workflow state makes retries visible, and CloudFront keeps viewer traffic away from the processing path.
Explore the architecture
This lakehouse architecture makes the progression from source-aligned data to curated analytical products explicit. Durable S3 zones preserve replayability, managed transformation creates trusted datasets, and serverless query and dashboard services keep the first platform operationally light.
Explore the architecture
This multi-account security architecture separates evidence collection, immutable retention, investigation, and reporting. It creates a clear baseline for deciding who owns the log archive, which administrators can change collection, how long evidence is retained, and how incidents are queried.
Explore the architecture
This GraphQL architecture separates the client-facing schema, application logic, transactional write model, and asynchronous search model. The split keeps user mutations fast while making OpenSearch replaceable and rebuildable from durable DynamoDB records and change events.
Explore the architecture
This migration architecture separates continuous data replication from application traffic cutover. It helps teams reason about compatibility, target validation, replication lag, reconciliation, write freeze, rollback, and the exact moment Aurora becomes the production system of record.
Explore the architecturePopular AWS comparisons
Each guide gives you a direct verdict, a side-by-side matrix, and both editable paths on one canvas.
Choose an ALB for HTTP applications that need content-based routing, redirects, OIDC or Cognito authentication, Lambda targets, or AWS WAF. Choose an NLB for non-HTTP protocols, static IP addresses, source-IP preservation, PrivateLink endpoint services, or extremely high connection throughput. The editable diagram keeps both paths side by side so you can preserve the one that fits your protocol and delete the other.
Explore the architecture
Choose ECS on Fargate when the goal is to run containers with the smallest AWS operations footprint and no Kubernetes requirement. Choose EKS when Kubernetes itself is a strategic interface, the team needs its ecosystem or portability, or many product teams need a common platform abstraction. EKS can still run selected pods on Fargate, which is why separating orchestrator from capacity is essential to a correct decision.
Explore the architecture
Choose Lambda for short, stateless, event-driven work with variable traffic and a supported runtime model. Choose Fargate for long-running services, background consumers, larger dependencies, custom runtimes, persistent connections, or an existing container image. Real systems often use Fargate for the always-on API and Lambda for bursty side jobs, so the architecture need not force every workload into one compute model.
Explore the architecture
Choose Fargate when removing host management and isolating capacity per task matter more than the lowest steady-state unit cost. Choose ECS on EC2 when the workload needs GPUs, privileged or daemon access, specialized instances, very high sustained utilization, or deeper control over placement and networking. Capacity providers make this a per-service or mixed-cluster decision rather than an irreversible platform choice.
Explore the architecture
Choose Lambda when work is short, stateless, event-driven, and benefits from scaling to zero. Choose EC2 when the application needs a persistent process, custom operating system, specialized hardware, unrestricted runtime behavior, host agents, or predictable continuous capacity. The strongest architectures often use Lambda around an EC2 core for automation and events rather than forcing every component onto the same compute service.
Explore the architecture
SQS answers who should process this unit of work next; SNS answers which subscribers should receive a copy of this notification. They are commonly used together: a publisher sends one event to SNS, and each durable consumer owns an SQS subscription queue with separate retries, scaling, and a dead-letter queue. The editable comparison diagram shows the pure patterns before you combine them.
Explore the architecture
Choose SNS when a producer needs straightforward, high-throughput fanout to queues, functions, HTTP endpoints, mobile push, SMS, or email. Choose EventBridge when events need richer content matching, routing across accounts and buses, SaaS sources, schema discovery, API destinations, or controlled replay. Use both only when their responsibilities are explicit, not because two buses feel safer than one.
Explore the architecture
Choose SQS for jobs, commands, and asynchronous work where one consumer path should complete each message. Choose Kinesis for telemetry, clickstreams, change records, and event histories that require per-key ordering, multiple independent processors, or replay. The choice is queue semantics versus stream semantics, not simply low throughput versus high throughput.
Explore the architecture
Choose Step Functions when sequence, branching, compensation, human or timed waits, and per-execution visibility are part of the business process. Choose SQS when producers need durable decoupling and consumers need a backlog they can process at their own pace. Many production workflows use SQS inside one step or after completion, because orchestration and backpressure solve different problems.
Explore the architecture
Choose RDS when relationships, SQL, joins, constraints, ad hoc queries, or broad transactional semantics are central. Choose DynamoDB when access patterns are known, key-based operations dominate, traffic can scale sharply, and serverless operations matter. Many systems use RDS for authoritative business transactions and DynamoDB for carts, sessions, idempotency, or high-scale lookup paths.
Explore the architecture
Choose Aurora when a MySQL- or PostgreSQL-compatible workload benefits from distributed cluster storage, rapid replica creation, reader endpoints, fast failover options, or Aurora-specific global and serverless features. Choose a standard RDS engine for exact engine compatibility, versions or licenses Aurora does not support, simpler steady workloads, or a lower-cost footprint at modest scale.
Explore the architecture
Choose Aurora Serverless v2 for variable, spiky, multi-tenant, development, or uncertain relational demand that benefits from automatic capacity adjustment. Choose provisioned RDS for stable utilization, exact instance characteristics, reserved capacity economics, or database engines outside Aurora. Minimum serverless capacity, connection load, caches, and steady baseline demand determine whether automatic scaling actually saves money.
Explore the architecture
Choose S3 for static assets, backups, logs, archives, artifacts, media, data lakes, and applications designed around object APIs. Choose EFS for shared Linux directories, content management, home directories, lift-and-shift file dependencies, and workloads that need many clients to mount one file system. Do not mount an object store abstraction merely to avoid changing code without testing semantics and performance.
Explore the architecture
Choose EBS when one instance or compatible attachment set needs low-latency block storage with explicit volume performance. Choose EFS when many Linux instances, ECS tasks, EKS pods, or Lambda functions need the same files across Availability Zones. Availability scope alone is not enough: the application attachment model, filesystem ownership, I/O size, metadata operations, and failure behavior should decide.
Explore the architecture
Choose API Gateway for public or partner APIs that need API keys, usage plans, authorizers, per-client throttling, stages, transformations, WebSockets, or direct service integrations. Choose ALB for high-volume HTTP routing to ECS, EKS, EC2, IP, or Lambda targets when load balancing is the main requirement. Request economics can favor ALB at sustained volume and API Gateway at small or variable scale, but features often decide first.
Explore the architecture
Choose CloudFront for websites, APIs, downloads, media, or other HTTP workloads that benefit from caching, edge logic, origin shielding, signed access, and AWS WAF. Choose Global Accelerator for static global IP addresses, non-HTTP protocols, source-IP-aware applications, rapid regional endpoint failover, or dynamic traffic that should remain on the AWS backbone. They can be complementary in a broader edge strategy but should not be stacked without a requirement.
Explore the architecture
Choose VPC peering for a small, stable number of direct VPC relationships where pairwise routes remain easy to understand. Choose Transit Gateway when many VPCs, accounts, hybrid networks, segmentation domains, or centralized inspection paths need one governed routing hub. Count future connections and traffic paths before cost, because a full peering mesh grows quadratically and becomes the expensive option operationally even when service charges are lower.
Explore the architecture
Use VPC endpoints for high-value or high-volume supported services when private routing, endpoint policy, and reduced NAT processing create value. Keep NAT Gateway for package repositories, public APIs, and destinations without endpoint support. Most production VPCs use both: gateway endpoints for S3 and DynamoDB, interface endpoints for selected services, and zonally aligned NAT gateways for the remaining internet egress.
Explore the architecture
Use security groups to express which application tiers and resources may communicate, ideally through references to other security groups rather than broad IP ranges. Use network ACLs when a subnet needs an explicit deny, coarse IP-based boundary, or backup control against a missing resource rule. Because NACLs are stateless, inbound and outbound rules must both allow response ports, which makes aggressive policies harder to operate.
Explore the architecture
Use CloudWatch to operate applications and infrastructure in real time: latency, errors, capacity, logs, traces, dashboards, and alerts. Use CloudTrail for governance, security investigations, compliance evidence, and change attribution. Mature environments use both by retaining authoritative CloudTrail records in protected S3 and routing high-value audit events into CloudWatch or a security platform for alerting.
Explore the architectureHow to read them
Most AWS diagrams fail in the same way: they show which services are present and stay silent on the decisions. Service icons are an inventory. An architecture is the set of choices about what is reachable, what is replicated, and what happens when one part of it fails. Every diagram in this library is drawn to make those choices visible.
Four things carry almost all of the meaning. Boundaries come first: the AWS Cloud, the Region, the VPC, and the subnet tier a resource sits in. Nesting is not decoration, it is the statement of what can reach what. Direction comes second, because a connection drawn without an arrow hides whether a component initiates or accepts, which is the difference between a NAT gateway and an internet gateway. State comes third: where data lives, whether it is replicated across Availability Zones, and what is lost if a zone goes away. Exposure comes last and matters most, because a reader should be able to point at the public entry points and count them on one hand.
Availability Zones deserve a specific note. Redundancy is claimed far more often than it is drawn. A genuinely multi-zone design shows mirrored subnets with real occupants in each zone, not a second empty box labeled with a zone name. If a diagram claims high availability and only one zone contains anything, the claim is aspirational.
Scope each diagram to one question. A drawing that explains resilience needs zones and replication; a drawing that explains request flow does not. Attempting both on one canvas produces a picture that answers neither, which is why the library is organized by architectural question rather than by service.
Common questions
