The situation
A three-hundred-person distributor has spent a year watching everyone else build things with generative AI, and in one week four requests land on the same architect’s desk.
Operations want answers out of internal documents. Delivery policies, supplier contracts and the staff handbook are spread across a document store and an S3 bucket, and finding anything means asking the one person who remembers where it lives. Engineering want help in the editor: the four developers are maintaining a decade-old order system and spend more time reading it than changing it. Product want a customer-facing assistant on the website that answers questions about products and delivery in the company’s own voice, behind the company’s own API. And two data scientists in the research corner want to run an open-weight model on instances they control, fine-tuned on eight years of supplier correspondence, with nothing leaving the account.
Nobody has named a service. What is circulating in the meeting invites is a list of names: Amazon Bedrock, Amazon SageMaker AI, SageMaker JumpStart, Amazon Quick, Kiro, Strands Agents and Amazon Bedrock AgentCore. Seven names, four requests, and no obvious mapping between them.
What actually matters
Sort the seven by who the output is for, because that separates finished products from building blocks before any technical argument starts. Some of these are applications with a user interface, a login and a connector catalogue, ready for a person who will never write code. Others are APIs, SDKs and runtimes that produce nothing at all until a developer assembles them into something. Handing Operations an SDK and handing Engineering a chat window are the same mistake in opposite directions. When a team wants to use generative AI, look at the finished products first. When a team wants to ship generative AI inside their own product, look at the building blocks.
The second sort is how much of the stack you want to own, which runs as a continuous line rather than a set of boxes. At one end sits a managed application where AWS runs the model, the retrieval layer and the interface, and your work is connecting data sources and setting permissions. In the middle sits a managed API where you own the prompt, the application and the data, and AWS owns the model and the servers under it. Further along you own model weights running on endpoints you configure, and at the far end you own instances, scaling and patching as well. Every step along that line adds control over the model and adds operational work in the same movement. A team of two data scientists and a team of forty platform engineers should not land in the same place.
This is where the advantages of using AWS GenAI services show up, and the guide lists them plainly: accessibility, a lower barrier to entry, efficiency, cost-effectiveness, speed to market, and the ability to meet business objectives. Accessibility and a lower barrier to entry are about who can start at all. A business analyst can connect a document source to a managed assistant this afternoon. The same result built from scratch needs a machine learning team the company does not have. Efficiency and cost-effectiveness follow from not building and running what somebody else already runs, and from paying per token or per user rather than for idle GPUs. Speed to market is the week between a request and a working demonstration, which decides whether the idea survives contact with a budget conversation. Meeting business objectives is the one that outranks the rest: a slower, more expensive path that actually answers the operations team’s question is better than a fast one that answers a different question well.
The infrastructure underneath brings its own benefits, and they are worth naming separately because they apply whichever building block you choose. Security is the ordinary AWS machinery applied to model calls. IAM decides which principals may invoke which models, and AWS KMS decides who holds the keys over stored prompts, documents and custom models. AWS PrivateLink keeps the traffic off the public internet by putting a private endpoint inside your own VPC. Compliance is evidence you can hand to an auditor, and AWS Artifact is where the reports and certifications for the services under you are downloaded rather than requested. The shared responsibility model draws the line the auditor will ask about: AWS is responsible for the security of the cloud, and you are responsible for security in it, which for a generative AI application means your data, your prompts, your access policies and your choice of region. Safety is the layer above all of that, and Amazon Bedrock Guardrails is where it lives: configurable filters on what goes into a model and what comes back, covering harmful content, denied topics, sensitive data and responses ungrounded in your source documents.
What we’ll filter on
- Audience: is the output for an employee, a developer, a customer, or for another piece of software?
- Operational ownership: how far along the line from managed application to your own instances is this team willing and able to sit?
- Data residency and control: where do the documents, prompts and weights sit, and does anything cross an account or a region boundary?
- Time to a first working version: days, weeks, or a quarter, and what the organisation is prepared to wait.
The landscape
Seven services, one paragraph each. Read them as a map rather than a shortlist, because three of the four requests will end up using more than one.
Amazon Bedrock
The managed API over hosted foundation models. You choose a model from a catalogue that includes Amazon Nova alongside models from other providers, call it over HTTPS, and pay for the tokens you send and receive. There are no instances in your account, nothing to patch, and no capacity to plan beyond choosing between on-demand and provisioned throughput. Around the raw invocation sit the features most applications need anyway: knowledge bases for retrieval over your own documents, agents for multi-step tasks, model evaluation, and Guardrails for the safety filters. Bedrock is where most custom generative AI applications on AWS begin, and it is a building block rather than a product, so somebody still has to write the application around it.
Amazon SageMaker AI
The machine learning platform for teams that want to own the model rather than call somebody else’s. Training jobs, notebooks, experiment tracking and inference endpoints all live here, and the same service covers a small tabular classifier and a fine-tuned open-weight language model. Choosing SageMaker AI means choosing instance types, endpoint configurations, autoscaling and a monitoring story, and getting in return full control over the weights, the fine-tuning data and the machines the model runs on. It is the natural home for the stages of an AI/ML pipeline that involve training something.
SageMaker JumpStart
The model hub inside SageMaker AI. It holds hundreds of open source pre-trained models and solution templates, and its job is getting one of them onto an endpoint without writing the hosting code. You browse, you deploy, and you get a SageMaker endpoint serving that model in your account, ready to fine-tune on your own data. JumpStart is a catalogue and a deployment path rather than a runtime of its own; the endpoint it creates is a SageMaker AI endpoint, billed by the hour the instance is up. Several open-weight models are reachable through both JumpStart and Bedrock, and the difference is who owns the machine.
Amazon Quick
The finished assistant over enterprise data. Connectors pull in documents from the systems a company already runs, and the service handles indexing and retrieval. Answers come back with citations. Access follows the permissions of the person asking, so nobody sees a document they could not have opened directly. Quick also covers the analytics side of the same estate, turning questions about business data into charts and dashboards. No model is chosen, no prompt is written, and no application is built. The work is connecting sources, setting permissions and deciding who gets a licence.
Kiro
The agentic development environment for people writing software. It sits where the developer already works, reads the codebase, and works from specifications and structured task lists rather than only from line-by-line autocompletion. Given a description of a change, it plans the work, proposes the edits across the files that need them, and runs the loop with the developer reviewing at each step. Kiro is aimed squarely at the engineering team and produces code, so it never appears in an architecture diagram of the application; it appears in the story of how that application got built.
Strands Agents
The open source SDK for building agents in code. You define a model, a set of tools and a prompt, and the framework runs the loop where the model decides which tool to call, sees the result, and decides again. It supports the Model Context Protocol for connecting to external tools, and works against models on Bedrock as well as models hosted elsewhere. Being a library, it runs wherever your code runs, which makes it the choice when the agent’s behaviour needs to be defined, versioned and tested like any other code. Other frameworks fill the same slot, and Strands is the AWS-published one.
Amazon Bedrock AgentCore
The managed runtime for agents in production. A framework such as Strands Agents describes what the agent does; AgentCore runs it and supplies the parts a long-running agent needs that a library does not provide. Sessions get their own isolated execution environment, and memory persists across turns and across conversations. A gateway turns existing APIs into tools the agent can call. Identity handles the agent acting on behalf of a user against systems that need their own credentials. It is framework-agnostic and model-agnostic, so adopting it is a hosting decision rather than a rewrite. It matters once an agent has real users rather than on the day it first works.
Evaluation
Side by side
| Service | Usable without writing code | You run the infrastructure | Your own model weights | Ships a user interface | Days to a first version |
|---|---|---|---|---|---|
| Amazon Bedrock | ✗ | ✗ | ✗ | ✗ | Days |
| Amazon SageMaker AI | ✗ | ✓ | ✓ | ✗ | Weeks |
| SageMaker JumpStart | ✗ | ✓ | ✓ | ✗ | Days |
| Amazon Quick | ✓ | ✗ | ✗ | ✓ | Days |
| Kiro | ✓ | ✗ | ✗ | ✓ | Hours |
| Strands Agents | ✗ | ✗ | ✗ | ✗ | Days |
| Amazon Bedrock AgentCore | ✗ | ✗ | ✗ | ✗ | Weeks |
Read the first and fourth columns together and the products separate from the building blocks cleanly: Amazon Quick and Kiro are things a person opens, and the other five are things a developer calls. Read the second and third columns and the ownership line appears: only the two SageMaker entries put weights and machines in your account, and they are the only two where somebody is on call for an endpoint.
The last column is the one that gets argued about in the meeting, and it is a measure of the first working version rather than the finished one. Kiro is installed and useful in an afternoon. Quick is a connector and a permissions review. Bedrock is an API call in an hour and an application around it in a fortnight. SageMaker AI is a week before anything serves a request, and AgentCore is fast to deploy onto but only after there is an agent worth deploying.
Which request goes where
The ordering matters more than the boxes. Asking “which model should we use” before asking “is there already a product for this” is how a company ends up building its own document assistant while paying for one it already had. The ownership gate sits third because it is the expensive answer, and it should be reached by elimination rather than by enthusiasm.
The solution
Operations get Amazon Quick. The request is answers from internal documents for people who will not write code, the connectors already cover the document store and the bucket, and answers arrive with citations under the asker’s own permissions. Building the same thing on Bedrock with a knowledge base is entirely possible and takes a quarter. Do it when the answer has to appear inside another product, or when the retrieval behaviour needs tuning Quick does not expose. That is a buy-or-build decision with a clear default, and the default is buy.
Engineering get Kiro, and it never shows up in the architecture. It is a licence and an installation, it works on the existing repository, and it makes the other three projects arrive sooner because somebody has to write the application around Bedrock either way. Kiro, Quick and Bedrock all answer questions, which is exactly why the three get blurred together; they answer for different audiences.
Product get Amazon Bedrock. A customer-facing assistant behind the company’s own API needs the prompt, the tone, the retrieval over the product catalogue and the error handling to belong to the application. None of that survives being handed to a finished product. Turn on model access for the specific models you intend to use, because that is a separate account-level grant from the IAM permission to invoke them. Put Amazon Bedrock Guardrails in front of it before it faces a customer, configured for denied topics, sensitive information and grounding against the catalogue. Keep the first version a plain request and response: an application becomes agentic when it plans and acts, and most assistants that answer questions never need to. When this one grows tools, define them with Strands Agents and deploy onto Amazon Bedrock AgentCore for the session isolation, memory and identity handling that a production agent needs.
Research get SageMaker AI, with the model coming from SageMaker JumpStart. Deploy the open-weight model from the hub onto an endpoint, fine-tune it on the correspondence corpus, and accept the endpoint as an operational commitment: instance types, autoscaling, and a bill that runs whether requests arrive or not. That last part is the one that surprises teams arriving from Bedrock, where an idle application costs nothing. Set a shutdown schedule for the experimentation endpoint on day one, and read the serving options before settling on a real-time endpoint, because a batch job suits an eight-year correspondence archive better than an endpoint waiting for traffic.
Three things apply across all four. Region selection is where data residency is decided, and model availability differs by region, so check that the model you want exists in the region your data has to stay in before the design hardens. Security controls are the same ones the company already runs: IAM for who may invoke what, KMS for keys over anything stored, PrivateLink for keeping traffic inside the VPC. And the split of duties under the shared responsibility model does not move because the workload is generative: AWS runs the infrastructure and the managed services, you own your data, your access decisions and what your application does with a model’s output.
Worked example
Trace the customer assistant through the four filters and the answer arrives in about a minute. The audience is a paying customer using the company’s website, so the output has to appear inside a product the company controls, which rules out both finished assistants. The operational ownership the team wants is minimal: four developers maintaining an order system will not also carry inference endpoints, which rules out SageMaker AI and JumpStart. Data residency says the catalogue and the conversation logs stay in ap-southeast-2, which is a region check on the model list rather than a change of service. Time to a first working version is three weeks, because a budget conversation happens at the end of the month.
That lands on Amazon Bedrock. The version that goes to the budget conversation is a knowledge base over the product catalogue, one model chosen after comparing two or three on real customer questions, a prompt in version control, and Guardrails in front. The agent conversation is deferred, because nothing in the request needs the assistant to take an action rather than answer. Cost is a token-per-conversation estimate at that stage, which is a calculation with a few surprises in it once retrieved documents start filling the prompt.
What’s worth remembering
- Sort the seven services by who the output is for first: Amazon Quick and Kiro are finished products a person opens, and Amazon Bedrock, SageMaker AI, SageMaker JumpStart, Strands Agents and Amazon Bedrock AgentCore are building blocks a developer calls.
- Amazon Bedrock is the managed API over hosted foundation models including Amazon Nova with no instances in your account, while Amazon SageMaker AI runs your own weights on endpoints you configure, and SageMaker JumpStart is the hub that puts an open source pre-trained model onto one of those endpoints.
- Strands Agents is the open source SDK that describes an agent’s loop and Amazon Bedrock AgentCore is the managed runtime that gives it session isolation, memory, a tool gateway and identity in production.
- The advantages of the managed path are accessibility, a lower barrier to entry, efficiency, cost-effectiveness, speed to market and the ability to meet business objectives, and the last of those decides when the slower path is still right.
- The infrastructure benefits are security through IAM, AWS KMS and AWS PrivateLink, compliance evidence through AWS Artifact, a shared responsibility model that leaves your data and your access decisions with you, and safety through Amazon Bedrock Guardrails.
- Region selection is how data residency is enforced and model availability varies by region, so confirm the model exists where the data must stay before the architecture is agreed.