AWS

AWS has no single AI product. Bedrock provides managed foundation model access, with Knowledge Bases, Guardrails, and Agents built on top of it. SageMaker covers custom training, hosting, and MLOps. Textract and Kendra handle documents and enterprise search. Each is a separate service with its own API, IAM policy, and line on the bill.

That is the platform's defining trade-off. Databricks and Snowflake put AI inside a data platform, so governance and lineage come free but the AI layer is only as useful as the data already sitting there. AWS assembles the same capability from components: more integration work up front - wiring S3, OpenSearch Serverless, Lambda, and IAM roles together - and no data-platform lock-in in return. Bedrock does not care where your warehouse lives. The compensating strength is that every service inherits the account it runs in - same IAM, same VPC, same compliance posture (FedRAMP, HIPAA, SOC 2), same billing relationship. For an organisation already deep in AWS, that shortens the path to production more than any capability table suggests.

When to choose AWS: workloads already run in AWS, Anthropic Claude is central to the architecture, out-of-the-box content safety is a hard requirement, or compliance certification drives the platform decision. Not when you need GPT or Gemini natively (neither is on Bedrock), model catalog breadth is the priority, or agents have to sit inside Microsoft 365 workflows.

Architecture

Bedrock is the centre of gravity. SageMaker feeds it custom and self-hosted models, Textract and Kendra feed it content, and Bedrock Agents consume it. The connections are not automatic: each arrow above is an IAM role and an API call you write, not an inherited platform relationship.

---

Built-in AI Capabilities

Data Science and ML (SageMaker)

Generative AI (Bedrock)

Guardrails is the strongest part of this layer and the clearest reason to prefer Bedrock over calling a model vendor's API directly. Contextual grounding in particular checks whether a response is actually supported by the retrieved context, which catches the RAG failure mode that most content filters miss. See Guardrails & Safety for the pattern independent of platform.

Agentic AI (Bedrock Agents)

Bedrock Agents is a genuinely managed agent service, which Databricks and Snowflake do not offer. The cost is a heavier developer experience: an agent that a framework expresses in twenty lines becomes an agent resource, an alias, an OpenAPI schema, a Lambda, and three IAM roles. See AI Agents for the architectural pattern behind the plumbing.

Documents and Enterprise Search

This is a real AWS strength and the layer most often underrated in platform comparisons.

The production document pattern chains two services: Textract extracts structure, then a Bedrock model extracts meaning from that structure. Sending a raw scan straight to a multimodal model skips a step that is cheaper and more accurate to do with a purpose-built extractor. See OCR + Document Processing.

---

Available Models

Claude on Bedrock is the reason most reasoning-heavy workloads land here. The trade-off is catalog breadth: Vertex AI offers more model options, and platforms with a model gateway (Microsoft Foundry, or Databricks routing to external providers) can put GPT and Claude behind one endpoint. Bedrock cannot.

---

Custom AI Enablement: Managed RAG with Citations

The pattern that distinguishes AWS from platform-native AI layers: a full retrieval-and-generation pipeline in one API call, with source attribution returned automatically. No chunking code, no vector store to operate, no citation-tracking layer to build.

import boto3

runtime = boto3.client("bedrock-agent-runtime", region_name="us-east-1")

response = runtime.retrieve_and_generate(
    input={"text": "What is the return policy for electronics?"},
    retrieveAndGenerateConfiguration={
        "type": "KNOWLEDGE_BASE",
        "knowledgeBaseConfiguration": {
            "knowledgeBaseId": "KB-12345",
            "modelArn": (
                "arn:aws:bedrock:us-east-1::foundation-model/"
                "anthropic.claude-sonnet-4-20250514"
            ),
            "retrievalConfiguration": {
                "vectorSearchConfiguration": {
                    "numberOfResults": 5,
                    "overrideSearchType": "HYBRID",  # vector + keyword
                }
            },
        },
    },
)

print(response["output"]["text"])

for citation in response["citations"]:
    for ref in citation["retrievedReferences"]:
        print(ref["location"]["s3Location"]["uri"])

The work moves from writing a pipeline to configuring one. Chunking strategy (hierarchical parent/child chunks beat fixed-size on complex documents), search type, and result count are the levers that decide answer quality. RAG covers how to tune them and how to evaluate the result.

---

Cost Model

AWS AI costs split by service rather than arriving as one platform bill:

• Bedrock on-demand - per input and output token, no commitment. The default for development and variable traffic. Batch inference runs the same models asynchronously at roughly 50% of on-demand cost
• Provisioned Throughput - fixed hourly rate for reserved capacity and predictable latency, and the usual path for serving fine-tuned models. Billed whether or not traffic arrives
• SageMaker - compute hours on the underlying instance, for both training jobs and endpoints. Endpoints bill while idle
• Knowledge Bases - per query plus the cost of the vector store (OpenSearch Serverless has a minimum capacity floor)
• Guardrails - per text unit of 1000 characters, input and output billed separately
• Kendra - index capacity billed hourly, independent of query volume

---

AWS vs Microsoft Azure

The two hyperscalers rate comparably on platform comparison for knowledge and GenAI. They differ in where the effort goes.

The honest read: pick AWS when the infrastructure is already there, Claude is the model you want, or a compliance regime makes the account boundary the deciding factor. Pick Azure when the organisation runs on M365 and agents need to reach Teams and SharePoint natively, or when the roadmap needs both pro-code and low-code agent paths. Neither is a data platform, which is the whole point - both sit beside Snowflake or Databricks rather than replacing them. Target Architectures collects reference end-state designs per platform, including the AWS end state.

---

Key Takeaways

• AWS assembles its AI stack from separate services rather than shipping one platform. That means more integration work than Databricks or Snowflake, and in exchange no data-platform lock-in - Bedrock is indifferent to where your warehouse lives.
• Bedrock Knowledge Bases is the fastest path to production RAG on AWS. One retrieve_and_generate call returns a grounded answer with citations, with no retrieval pipeline to maintain. Databricks has no managed equivalent; Snowflake's Cortex Search gets close but leaves generation and source attribution to the caller.
• Guardrails is the differentiator for user-facing applications. Content filters, PII handling, denied topics, and contextual grounding ship as configurable policy, not as something you build. Budget 10-20% over inference cost for it.
• The document story (Textract for structure, Bedrock for meaning) is a genuine strength that platform comparisons routinely undercount. Chain them rather than sending raw scans to a model.
• SageMaker and Bedrock answer different questions. SageMaker is for teams that own the training loop; Bedrock is for teams that consume models. Decide which applies before designing anything. The catalog is the main constraint on the Bedrock side: no GPT and no Gemini is a platform-level limitation, not something to engineer around.
• Fixed-cost components (Provisioned Throughput, idle endpoints, OpenSearch minimums, Kendra index hours) usually outweigh token spend. Audit standing capacity before it becomes the bill.