GenAI reference architectures on AWS — the seven canonical patterns.

IHow to read this catalogue — patterns, not products

A reference architecture is a named, reusable shape: a set of components wired in a known way to solve a recurring problem. It is not a product you buy or a single service you turn on — it is the blueprint you assemble from AWS services. The value of naming them is that it makes the build decision a selection, not an invention.

Most teams starting a generative-AI project on AWS face the same paralysis: the stack has dozens of relevant services (Amazon Bedrock, SageMaker, Q, OpenSearch, Lambda, Step Functions, ECS, and more) and it is not obvious which to combine. The good news is that the space of useful combinations is small. Across the production systems people actually ship, almost everything is one of seven patterns — or a composition where one pattern calls another.

These seven are ordered roughly by complexity, from a stateless chatbot you can stand up in an afternoon to a multi-account enterprise platform that takes a quarter. Reading them in order is also a decision tree: start at the top, and stop at the first pattern that meets your requirement. The single most common and most expensive early mistake is reaching for a heavier pattern than the problem needs — building a DIY RAG pipeline when managed RAG would have answered the same questions, or fine-tuning a model to memorise facts that RAG retrieves more cheaply and keeps current.

For each pattern below you get four things: the shape (what is wired to what), the AWS services that typically implement it, when to use it and when not to, and a pointer to the deep build guide. Section VIII collects every service into one matrix so you can see at a glance which patterns share which building blocks. Section IX compares all seven side by side on the dimensions that drive the choice — build effort, control, latency, and cost shape.

One framing to keep throughout: Amazon Bedrock is the spine. Six of the seven patterns use Bedrock to serve foundation models through one API, with your data kept private to your account and never used to train the base models. The only pattern that can live without Bedrock is the self-hosted-model architecture (pattern 6), and even that often pairs with Bedrock for the models you do not want to host yourself.

IIPatterns 1–4 — chatbot, managed RAG, DIY RAG, agentic workflow

The first four patterns cover the overwhelming majority of generative-AI applications: answer a question, answer it from your data, answer it from your data with custom retrieval, or take an action. Each builds on the one before.

These four are the workhorses. If you are building a customer-facing assistant, an internal knowledge tool, or a workflow that uses an LLM to decide and act, you are almost certainly building one of these. They share the same generation layer — a foundation model on Bedrock — and differ in what surrounds it.

IIIPatterns 5–7 — batch document processing, fine-tuned / self-hosted model, enterprise platform

The last three patterns cover the heavier end: processing documents at volume offline, owning a model's weights or hosting, and the platform layer that lets a whole organisation build the first six safely. These are where SageMaker, batch inference, and multi-account governance enter.

Patterns 5 through 7 are not "advanced" in the sense of better — they solve different problems. Pattern 5 is about throughput and cost on offline work; pattern 6 is about control over the model itself; pattern 7 is about letting many teams build patterns 1–6 without each reinventing security and governance.

IVComposing the patterns — real systems are combinations

The seven patterns are building blocks, and most production systems use more than one. Knowing the common compositions saves you from treating them as mutually exclusive choices when they are really layers.

The patterns nest naturally because they share the same Bedrock generation layer. An agent (pattern 4) routinely calls a Knowledge Base (pattern 2) as one of its tools, so it can both answer from your documents and act. A managed RAG assistant (pattern 2) may sit behind the chatbot interface of pattern 1. A fine-tuned model (pattern 6) can be the generation model inside a RAG pipeline (patterns 2–3) — RAG for the facts, fine-tuning for the behaviour. And in a mature organisation, every one of these runs on top of the enterprise platform (pattern 7), which supplies the model access, guardrails, networking, and cost controls they all need.

Two compositions are worth calling out because they are so common. First, agentic RAG: an agent whose primary tool is a Knowledge Base, giving you grounded answers and the ability to take follow-up actions — the shape behind most "do something with my data" assistants. Second, RAG over a fine-tuned model: keep volatile knowledge in the retrieval layer where it stays current and citable, and use a lightly fine-tuned model only to lock in a house style or output format. Reaching for fine-tuning to store facts that change is the classic anti-pattern; this composition is the right way to combine the two.

The practical implication is the same as the selection rule: start at the simplest pattern that works, and add a layer only when a concrete requirement appears. A chatbot becomes managed RAG when answers must be grounded; managed RAG becomes an agent when the assistant must act; any of them moves onto the enterprise platform when a second team needs the same rails. Each step is a deliberate addition, not a rewrite — which is exactly why naming the patterns is useful.

VWhere Bedrock ends and SageMaker begins

Almost every pattern question eventually reduces to one decision: managed foundation models through Amazon Bedrock, or full model control through Amazon SageMaker. They are complementary, not competing, and the line between them is clean.

Amazon Bedrock is the managed foundation-model API. You get many models — Anthropic (Claude), Meta (Llama), Mistral, Amazon (Nova + Titan), Cohere, Stability AI, AI21, DeepSeek — through one interface, with enterprise security and privacy (your prompts and data are not used to train the base models and stay in your account and Region). On top of the raw models, Bedrock layers the capabilities the patterns above lean on: the Converse API, Agents, Knowledge Bases (managed RAG), Guardrails, fine-tuning and custom models, model distillation, Flows, Prompt Management, batch inference, provisioned throughput, prompt caching, and model evaluation. For patterns 1–5 and the managed half of pattern 6, Bedrock is the whole serving layer — you never touch infrastructure.

Amazon SageMaker is the end-to-end ML platform for when you need to build, train, and host models yourself: the Studio IDE, JumpStart's catalogue of open models, training jobs, and endpoints (real-time, serverless, asynchronous). You reach for SageMaker in the self-hosting half of pattern 6 — running a specific open-weights model in your own VPC, training or heavily fine-tuning a model with full control, or serving on custom hardware such as AWS Trainium and Inferentia via the Neuron SDK. SageMaker gives maximum control at the cost of owning the operational surface that Bedrock hides.

The rule of thumb across all seven patterns: default to Bedrock; move to SageMaker only when you need to own the model or the hardware. Bedrock is the spine because it serves the models without infrastructure; SageMaker is the workbench you pull out when managed serving cannot give you the control a specific requirement demands. Many enterprise platforms (pattern 7) standardise on Bedrock for general use and keep SageMaker available for the teams that genuinely need it. The deeper Bedrock-vs-SageMaker comparison lives on its own page in the AWS AI & Bedrock hub.

VIThe cost shape of each pattern

Each pattern has a characteristic cost shape — what you pay for, when, and which lever controls it. Knowing the shape before you build prevents the most common budget surprises, almost all of which come from a baseline you did not expect or generation tokens you did not meter.

The figures and ranges in this section are representative as of 2026 to convey shape, not quotes — always check the AWS pricing page (and the third-party vendor for Pinecone) for current rates. Two cost ideas recur across every pattern. Generation tokens — input plus output, priced per model — are usually the largest line in any interactive pattern, which is why model choice, fewer/tighter chunks, prompt caching, and tight max-token limits are the highest-leverage levers. And a baseline you pay regardless of traffic — chiefly an always-on vector store (patterns 2–3) or a hosted SageMaker endpoint (pattern 6) — is what surprises teams that budgeted only for per-call costs.

Bedrock's pricing modes map onto the patterns directly. On-Demand (per 1K input/output tokens) suits interactive patterns 1, 2, 4. Batch (~50% cheaper) is the right mode for pattern 5's offline volume. Provisioned Throughput (reserved capacity) fits steady high-volume production and pattern 7's shared platform. Prompt caching cuts the cost of repeated context across all of them. Customisation and storage fees apply when you fine-tune (pattern 6). The table below summarises where the money goes per pattern.

VIIA decision tree for picking your pattern

Run your use case through these questions in order. The first one whose answer is "yes" points you at the pattern to build — and tells you which deep guide to open next.

• Does the assistant need to take actions (call APIs, update systems, run multi-step tasks), not just answer? — Yes → Pattern 4, agentic workflow (Bedrock Agents). If it also needs your documents, that is agentic RAG (pattern 4 + 2). Open Build an AI agent on AWS.
• Must answers come from your own documents / knowledge? — Yes, and standard chunking is fine → Pattern 2, managed RAG (Bedrock Knowledge Bases). Yes, but you need custom chunking, hybrid search, or row-level isolation → Pattern 3, DIY RAG. Open How to build RAG on AWS.
• Is the work high-volume and offline (no real-time user waiting)? — Yes → Pattern 5, batch document processing (Bedrock batch inference + Textract + Step Functions). Use batch mode for ~50% off.
• Do you need a specific output style/skill a base model won't reliably produce, or must you host a specific open model in your VPC? — Style/skill on labelled data → fine-tune (pattern 6, Bedrock custom model). Own the model/hardware/data path → self-host (pattern 6, SageMaker + Trainium/Inferentia). But if the goal is knowledge, use RAG instead.
• Are several teams going to build GenAI and need shared security, guardrails, networking, and cost control? — Yes → Pattern 7, enterprise multi-account platform (Organizations + Bedrock gateway + Guardrails + PrivateLink + FinOps). Open Generative AI on AWS for enterprises.
• None of the above — you just need a model to answer from its own knowledge or a supplied prompt? — Pattern 1, simple chatbot (Bedrock Converse API + Guardrails). The fastest pattern to ship. Open Build a chatbot on AWS.

VIIIServices-used matrix — which pattern uses what

Every pattern is assembled from a shared set of AWS services. This matrix shows, for each core service, which of the seven patterns relies on it — so you can see the common spine (Bedrock everywhere) and where the heavier services (SageMaker, Trainium, Organizations) only appear at the deep end.

Read each row as "this service is used by these patterns." A dot in a cell means the service is a typical building block of that pattern; it is not an exhaustive dependency list, but it captures the components you would actually name on an architecture diagram. The pattern numbers map to the catalogue above: 1 chatbot · 2 managed RAG · 3 DIY RAG · 4 agentic · 5 batch · 6 fine-tuned/self-hosted · 7 enterprise platform.