AWS offers AI services at very different levels of abstraction. A team can call a managed API for document extraction, build a generative AI application on foundation models, or train and deploy a custom machine-learning model. Choosing well begins with the business decision the system must support, the data available, the level of customization required, and the operational responsibility the organization is prepared to own. Starting with a favorite service often produces an unnecessarily complex solution.
The current AWS Certified AI Practitioner AIF-C01 guide reflects this decision-oriented view. Its domains cover AI and machine-learning fundamentals, generative AI, foundation-model applications, responsible AI, and security/governance. The exam is foundational, but the underlying architectural habit is valuable at any level: match the problem to the right category of capability before choosing a product.
Decide whether the problem needs prediction, generation, extraction, or search
Different AI workloads produce different kinds of outputs. A predictive model estimates a class, score, probability, or numeric value from features. A generative model creates or transforms text, images, code, or other content. Extraction identifies structured information in documents or media. Search and retrieval locate relevant information from a knowledge source. Many business requests become easier to design once the expected output is named precisely.
For example, “use AI for invoices” might mean extracting vendor, line-item, and total fields from documents, predicting which invoices are likely to be disputed, or generating a summary for an approver. Those are not one problem. Amazon Textract is a natural managed capability for document text and structure extraction, while a custom prediction may belong in SageMaker AI and a narrative summary may fit a foundation-model workflow.
Understanding basic machine-learning concepts prevents teams from labeling every intelligent feature as generative AI. The simplest capable service is usually easier to secure, test, and operate.
Use managed AI APIs when the task is common and bounded
AWS provides purpose-built AI services for common capabilities such as text analysis, speech, vision, document processing, conversation, and personalization. Amazon Comprehend can analyze natural language, Amazon Transcribe converts speech to text, Amazon Polly produces speech, Amazon Rekognition analyzes images and video, and Amazon Textract extracts text and structured document data. These services reduce the need to train and host a model for tasks AWS already packages as an API.
Managed services are strongest when the desired behavior fits the service’s supported features and the organization values speed over deep model customization. The team still needs to evaluate accuracy, data handling, supported Regions and languages, quotas, latency, and cost. A service being managed does not remove the need for application-level quality testing.
Before training a custom model, test whether a managed API can satisfy the acceptance criteria. The custom approach should earn its additional lifecycle cost through materially better fit, control, or performance.
Consider operational maturity too. A team that has never managed model deployment may gain more business value from a bounded managed service than from a sophisticated custom model it cannot monitor or retrain reliably. Architecture should match the organization that must run it after the proof of concept is over.
Choose Amazon Bedrock when the requirement is foundation-model application development
Amazon Bedrock provides access to foundation models and managed capabilities for building generative AI applications. This is the natural area when the application must generate, summarize, classify, transform, converse, or reason over text and other supported modalities using large foundation models. Teams can select models from the model catalog according to capability, latency, context needs, cost, supported Regions, and model-provider terms.
Bedrock also provides application building blocks around the model. Knowledge Bases support retrieval-augmented generation, Agents can orchestrate model-driven actions, Guardrails can apply configurable safeguards, and evaluation features help compare model or RAG performance. Those capabilities are often more important than the raw model API because production systems need grounding, access control, monitoring, and testing.
Generative AI should not be chosen merely because the interface can be conversational. A deterministic workflow or conventional search experience may be more reliable for tightly constrained tasks. The architecture should justify why generation adds value.
For applications that combine several model calls, treat orchestration as a cost and reliability concern. A chain that classifies a request, retrieves context, asks a model to draft an answer, runs a second model for critique, and invokes a tool may be useful, but it creates more latency, failure points, and token consumption than a single bounded inference. Add stages because they resolve a measured quality problem, not because an agent framework makes them easy to add.
Use SageMaker AI when custom model development is the real requirement
Amazon SageMaker AI is oriented toward building, training, tuning, deploying, and operating machine-learning models when the organization needs more control over the model lifecycle. Typical reasons include proprietary training data, custom algorithms, specialized feature engineering, model experimentation, controlled deployment patterns, and MLOps requirements that go beyond calling a prebuilt AI API.
This is a different commitment from consuming a managed AI service. The organization owns decisions about datasets, training jobs, validation, model artifacts, deployment, monitoring, and retraining. That can be justified for a core predictive capability, but it is unnecessary for many standard use cases. An AWS machine-learning engineering perspective is useful because it highlights the broader lifecycle around models rather than focusing only on training.
The approved inventory also includes MLA-C01, which represents a deeper implementation layer than AIF-C01. Use that distinction conceptually: foundational service selection and production machine-learning engineering are related but not interchangeable skills.
Match retrieval and knowledge requirements to the data architecture
Many business AI use cases depend less on training than on giving a model reliable access to enterprise knowledge. Retrieval-augmented generation can fetch relevant passages from approved data and provide them as context for generation. Amazon Bedrock Knowledge Bases can abstract much of the retrieval pipeline, but teams still need to decide which sources are authoritative, how data is chunked and indexed, how freshness is maintained, and how access controls are enforced.
RAG is not simply “connect the model to all company documents.” Retrieval quality determines whether useful context is available, while generation quality determines how that context is used. Evaluate retrieval and generation separately where possible. A model cannot answer from a document that was never retrieved, and a perfect retriever cannot prevent a model from producing an unsupported response.
Data quality remains fundamental. The same principles behind data science and analytics foundations apply: provenance, completeness, relevance, and appropriate preprocessing shape the result before model choice even becomes important.
For enterprise knowledge, freshness and authorization are often more important than model size. A smaller model supplied with the correct current document can outperform a larger model answering from general knowledge. Treat source selection, synchronization, and permission-aware retrieval as first-class architecture decisions rather than plumbing beneath the AI layer.
Choose multimodal services according to the original information type
Business processes often combine text, documents, images, audio, and structured records. Prefer services that understand the original information type rather than converting everything through a brittle intermediate step. A call recording may require transcription before language analysis. A scanned form may need document-aware extraction rather than generic optical character recognition. Images may require object or label analysis before a downstream decision.
For multimodal generative models, evaluate whether one model can handle the required inputs with acceptable accuracy and cost. Simpler pipelines can reduce operational complexity, but specialized services may still outperform a general model on narrow tasks. Benchmark representative examples rather than assuming “multimodal” means equally strong performance across every modality.
Also consider output requirements. A regulatory workflow may need structured fields with confidence scores and deterministic validation, while a customer-support experience may value natural-language generation. The downstream consumer should shape the service choice.
Evaluate latency, scale, and cost before declaring a technical winner
Two services can both solve a problem functionally while producing very different operational economics. Measure expected request volume, payload size, concurrency, batch-versus-real-time needs, model token usage, provisioned capacity options, data-transfer patterns, storage, and downstream processing. A prototype with ten requests does not reveal the cost behavior of a production workload with millions of transactions.
Latency should be decomposed as well. Retrieval, model inference, external tool calls, guardrails, and application logic each contribute. A larger foundation model may improve quality but violate the response-time objective. A custom model may be cheaper at sustained volume but require more engineering and operational ownership. The right choice reflects total business value, not one benchmark score.
Use cost controls and observability from the beginning. AI workloads can change consumption quickly as prompts grow, users experiment, or agents invoke multiple tools. Budgets, quotas, usage metrics, and request tracing help teams understand whether the architecture is behaving as intended.
Build security and governance into the service-selection decision
Security requirements can rule out an otherwise attractive technical option. Evaluate IAM permissions, data residency, encryption, logging, network access, model-provider data handling, sensitive-information controls, and whether the service is available in the required Region. The AWS security toolkit becomes part of the AI architecture because models still run inside an identity, network, data, and audit environment.
Generative AI introduces additional concerns such as prompt injection, sensitive-data disclosure, unsafe content, hallucination, and excessive agent permissions. Bedrock Guardrails can provide configurable safeguards, but application authorization and least privilege are still required. A guardrail should not be mistaken for an access-control system.
For higher-risk use cases, require human review where the consequence of an incorrect output is significant. The service choice should support the governance model instead of forcing policy to adapt to a prototype.
Use a decision matrix that keeps business value visible
A practical selection process scores candidate approaches against the factors that matter for the use case: required capability, expected quality, customization, data sensitivity, time to market, latency, scale, integration effort, operational ownership, compliance, and cost. The matrix does not need to be complex. Its purpose is to prevent a team from optimizing one technical dimension while ignoring the business constraint that actually determines success.
Proofs of concept should test the hardest uncertainty, not just demonstrate that an API call works. If quality is the risk, use difficult representative examples. If cost is the risk, test realistic volume and prompt size. If security is the risk, validate authorization and data boundaries. If the use case is new to the team, an AWS machine-learning starter view can help separate foundational concepts from production responsibilities.
The final choice may combine services: Textract for document extraction, Bedrock for explanation, and conventional business rules for approval, for example. Good architecture is not about picking the most advanced AI service. It is about assigning each part of the problem to the capability that solves it with the least unnecessary risk and complexity.
Keep the decision record after deployment. Record why a service was selected, what alternatives were tested, which quality thresholds were accepted, and what assumptions were made about volume, data, and compliance. When requirements change, the team can revisit those assumptions instead of treating the original architecture as permanent.