AWS Infrastructure and Services for Building GenAI Applications

Amazon Bedrock is the fully managed, serverless AWS service that gives you access to foundation models from Amazon and leading AI companies through a single API, and it is the first service to reach for when an application needs to call a ready-made model. Providers available through Bedrock include Amazon (the Nova models), Anthropic, Meta, Mistral AI, Cohere, AI21 Labs, and Stability AI, and the exact set of models differs by AWS Region.

Because Bedrock is serverless, you do not provision or manage any servers, GPUs, endpoints, or clusters. You send a prompt to a model and get a response back, and AWS scales the capacity behind it.

Switching models. Bedrock's Converse API uses one request and response format for every model that supports it, so moving to another provider's model, or comparing two models, is a change of model ID with no new infrastructure and no code rewrite. The lower-level InvokeModel API also works with any model, but its request body follows each provider's own format, so changing providers there means changing the payload too.

Bedrock also bundles higher-level building blocks so you do not have to assemble them yourself. Knowledge Bases connect a model to your own data so it can answer using that data (retrieval augmented generation, or RAG). Agents let a model carry out multi-step tasks by calling APIs and tools. Guardrails apply safety and privacy filters to inputs and outputs. Model customization fine-tunes a supported base model with your data. You will study each of these in depth in later domains; for this task, recognize them as Bedrock features and Bedrock as the fast, managed path to foundation models.

Amazon SageMaker AI is the AWS platform for building, training, and deploying machine learning models, and it is the service you choose when you need more control than Bedrock gives you. With SageMaker AI you can bring your own data and algorithms, train a model from scratch, fine-tune an existing model, and host the result on endpoints you configure, choosing the instance types and counts. That control comes with more responsibility: you make more decisions about instances, training jobs, scaling and deployment than you do with a serverless API.

Amazon SageMaker JumpStart is a machine learning hub inside SageMaker AI that shortens that path. It offers pre-trained, publicly available foundation models and prebuilt solutions that you deploy with a few clicks and can then fine-tune on your own data, so you skip training from scratch. The key difference from Bedrock is where the model runs: a JumpStart model is deployed to a SageMaker AI endpoint in your account, on an instance type you choose and pay for while it runs, whereas Bedrock serves its models serverlessly and you never pick an instance.

The customization paths also differ. SageMaker AI can train a brand-new model from scratch on your data. Bedrock model customization does not; it only adapts an existing base model (for example by fine-tuning) and gives you a private custom copy of it.

Two Bedrock features blur the line with SageMaker AI, and telling them apart depends on who trains the model and who chooses the hardware.

• Bedrock Custom Model Import lets you bring model weights you trained or fine-tuned elsewhere (for example in SageMaker AI) into Bedrock for supported model architectures. Bedrock then serves the model serverlessly through the same API as its other models. It does no training, and you choose no instances.
• Amazon Bedrock Marketplace gives access to a wider catalog of specialized models that you deploy to managed endpoints, choosing the instance type and number of instances. You then call them through Bedrock's APIs, but you cannot fine-tune them with Bedrock model customization.

Amazon Quick and Kiro are AWS's ready-to-use generative AI products for people rather than building blocks you call from code: Amazon Quick serves employees, and Kiro serves software developers.

Amazon Quick is an AI assistant and workspace for employees. Business users ask questions in natural language and get answers grounded in company data, documents, dashboards and connected applications such as Slack and Salesforce; Quick can also produce research reports and automate routine tasks and workflows. No one has to write or host an application. Amazon Quick is the successor to Amazon Q Business, which is no longer available to new customers, so for a new employee-assistant scenario the answer is Amazon Quick.

Kiro is AWS's agentic, spec-driven development environment. A developer describes what to build in natural language; Kiro turns that into a specification (requirements, a design and a task list), and AI agents then implement the tasks, with the developer reviewing the work. AWS recommends Kiro to developers in place of the Amazon Q Developer IDE plugins, which reach end of support on 30 April 2027. When a scenario is about writing and shipping software with AI agents, think Kiro.

Strands Agents is how you build an AI agent in code, and Amazon Bedrock AgentCore is where you run and operate agents in production; they solve different halves of the same job.

Strands Agents is an open-source SDK from AWS. You define an agent in a few lines of code (for example Python) by giving it a model, a prompt and a set of tools, and the model plans and calls the tools itself. Because it is a library, it runs anywhere, including a laptop.

Amazon Bedrock AgentCore is a set of managed services for deploying and operating agents securely at scale: a Runtime that hosts agents with an isolated session per user, Memory for short- and long-term memory, Identity for agent access to other systems, a Gateway that turns APIs and functions into tools agents can use, and Observability for tracing and monitoring. AgentCore is framework-agnostic: its Runtime hosts agents written with Strands Agents, LangGraph, CrewAI and other frameworks, so an existing agent can move to it without a rewrite. Strands is one way to write an agent, not a prerequisite for AgentCore.

Each AWS generative AI service in this task does one main job; use this table to fix them.

A quick check: calling a model points to Bedrock; building or training your own model points to SageMaker AI; an assistant that helps employees points to Amazon Quick; writing software with AI agents points to Kiro; writing an agent points to Strands Agents; running agents in production points to AgentCore.

The advantages of AWS managed generative AI services are 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 come first: a managed API means you can start using powerful foundation models without deep machine learning expertise, a data science team, or your own GPUs. Efficiency follows, because AWS runs the undifferentiated heavy lifting of provisioning, scaling, patching, and operating the model infrastructure, so your team spends its time on the application rather than the plumbing.

Cost-effectiveness comes from paying only for what you use instead of buying and running hardware that sits idle, and from being able to choose a smaller, cheaper model when it is good enough. Speed to market is a major draw: because the models and building blocks are ready to call, you can move from idea to a working prototype in days rather than months.

Together these let you meet business objectives faster. You can test whether generative AI actually solves a problem, then scale it up if it does, without a large upfront commitment. In short, managed services trade some control for speed, simplicity, and lower risk.

AWS infrastructure gives generative AI applications four benefits the exam names: security, compliance, responsibility and safety.

Security: your data is protected with encryption in transit and at rest, you control access with AWS Identity and Access Management (IAM), and private connectivity (AWS PrivateLink) keeps traffic off the public internet. Amazon Bedrock does not store or log your prompts and completions (model invocation logging is an opt-in setting you turn on yourself, sending logs to your own destination), does not use them to train any models, and does not share them with the model providers; the providers have no access to your data, and your content stays within your control.

Compliance: AWS services operate within a wide range of compliance programs and certifications, which helps you meet regulatory obligations in regulated industries without building that foundation yourself.

Responsibility: AWS provides tools that put safeguards around model behaviour. Amazon Bedrock Guardrails let you define denied topics the application must refuse to discuss, content filters for harmful categories, word filters, and sensitive-information filters that block or mask personally identifiable information such as phone numbers, applied to both prompts and responses and across the models you use.

Safety: under the AWS shared responsibility model, AWS secures the underlying infrastructure while you configure access, data and safeguards, and private networking and monitoring let you run generative AI within your own secure environment rather than sending data to an unmanaged third party.

Security and governance are covered in depth in a later domain; here, connect each benefit to the idea that AWS gives you a trusted foundation to build generative AI on.

Most Amazon Bedrock inference is priced per token: on-demand, you pay for the input tokens you send and the output tokens the model generates, at per-token rates that depend on the model, with no per-call fee and no hourly endpoint charge. That gives you three cost levers: prompt length, response length (asking only for what you need and setting a maximum output token limit) and model size, since larger, more capable models cost more per token. When a smaller model meets the quality target, it is the cheaper choice.

Prompt caching lowers cost and latency only when the same prompt prefix repeats across requests, such as long instructions or a shared document; it does nothing for text that is unique to each request.

Provisioned Throughput reserves a fixed amount of model capacity, which gives predictable throughput and a lower effective cost per request when traffic is steady and heavy, but you pay for the capacity whether or not you use it.

Custom models add costs that prompting a base model does not have: customization (fine-tuning) is billed by the tokens processed during training (roughly training data size multiplied by the number of epochs), each custom model you keep incurs a monthly storage charge, and inference on it runs through Provisioned Throughput or, for supported models, an on-demand custom model deployment billed per token. Because fine-tuning bakes knowledge in at training time, facts that change often would mean paying to retrain repeatedly; grounding a base model in a knowledge base keeps answers current without those recurring costs.

On Bedrock you can pay more for faster responses or pay less by accepting slower ones, using service tiers and batch inference.

• Service tiers apply to on-demand, synchronous calls. Priority costs a premium for faster, more consistent responses, which suits latency-sensitive, customer-facing work. Standard is the normal price. Flex is discounted for work that tolerates slower and more variable processing but still needs individual synchronous API calls. (A separate Reserved tier reserves capacity ahead of time; Priority is the fastest of the on-demand tiers, not a capacity guarantee.)
• Batch inference runs a large set of prompts asynchronously: Bedrock reads them from Amazon S3 and writes the results back. For supported models it costs about 50% less than on-demand, but it is not real time, so it fits jobs that can wait hours, not interactive features.

Model availability on Bedrock differs by AWS Region, and capacity in one Region is finite, so availability, redundancy and regional coverage are cost and design decisions. Check that the model you need is offered in the Region where you run, and remember that running closer to your users can reduce latency.

Cross-Region inference addresses throttling and availability without infrastructure or routing code: you call the model through an inference profile, and Bedrock routes each request to a Region in that profile with spare capacity, at no commitment.

• A geographic inference profile (for example US, EU or APAC) routes only among Regions in that geography, so it adds capacity while respecting a data-residency rule such as EU-only processing.
• A global inference profile can route to supported Regions worldwide, giving the most available throughput, and suits workloads with no data-residency requirement.

Other ways to handle peaks behave differently. Raising an on-demand quota through Service Quotas, or sending requests at the Priority tier, still depends on the home Region's capacity. Provisioned Throughput guarantees capacity but requires paying for reserved model units, and building your own multi-Region failover adds routing logic you must maintain.

Choose Amazon Bedrock when the team wants to consume foundation models quickly with little machine learning expertise, and Amazon SageMaker AI when it needs to build, train or host models with full control; many organizations use both.

Scenario: a retail company wants to add a customer-service chatbot to its website in the next few weeks. It has no machine learning team and wants to answer questions using its existing help-center documents. Amazon Bedrock is the right choice: the team can call a foundation model through the API and use Knowledge Bases to ground answers in the help-center content, shipping quickly with minimal expertise. Later, the same company needs a specialized model trained on its own proprietary product data, with full control over training and hosting to meet strict internal requirements. That is a job for Amazon SageMaker AI. Many organizations use Bedrock first for speed, then adopt SageMaker AI where a custom model earns its extra effort.