Choose AWS AI Services by Use Case, Not Hype
AWS offers a wide AI and machine learning portfolio, which makes service selection easy to overcomplicate. The simplest decision rule is to start with the business task and choose the highest-level managed service that meets the requirement. Use a specialized AI API when the job is well defined, Amazon Bedrock when the application needs foundation models and generative AI capabilities, and Amazon SageMaker AI when the organization needs deeper control over building, training, customizing, or operating machine learning models.
This use-case orientation is central to the current AWS Certified AI Practitioner AIF-C01 exam. AWS’s 2026 in-scope list includes Amazon Bedrock, Amazon Comprehend, Amazon Lex, Amazon Nova, Amazon Personalize, Amazon Polly, Amazon Rekognition, Amazon SageMaker AI, Amazon Textract, Amazon Transcribe, Amazon Translate, and related services. Candidates are expected to recognize what these services are for, not implement every one.
The practical objective is avoiding two opposite mistakes: building custom ML when a managed API already solves the task, or forcing a generative AI model into a problem that has a more deterministic specialized service.
Use Amazon Bedrock when the product needs foundation models
Amazon Bedrock is designed for building generative AI applications with foundation models. It provides managed model access and supporting capabilities such as knowledge bases, agents, guardrails, evaluation, and customization options. It is appropriate for tasks such as generation, summarization, conversational assistance, reasoning over text, and multimodal experiences where a foundation model is the right primitive.
Bedrock is not automatically the answer to every AI problem. If the requirement is simply to transcribe audio or extract text from a document, a specialized service may be cheaper, easier to evaluate, and more predictable.
Bedrock becomes especially attractive when the application needs to compare foundation models, ground responses in enterprise knowledge, apply model-independent guardrails, or orchestrate generative workflows. Those capabilities are valuable because they address the surrounding application problem, not because every workload needs an LLM.
Understanding this boundary is part of the broader AWS AI Practitioner skill set: choose the technology that matches the job rather than the one receiving the most attention.
Use Amazon SageMaker AI when you need deeper ML control
Amazon SageMaker AI supports the machine learning lifecycle for organizations that need to prepare data, build or customize models, train, tune, deploy, and operate ML workloads with more control. It fits cases where a managed AI API or general foundation model does not meet the requirement.
Examples include custom predictive models, specialized computer vision, domain-specific classification, or ML workflows with bespoke training and deployment needs. The organization accepts more engineering responsibility in exchange for greater control.
SageMaker AI is also relevant when teams need repeatable experiments, governed model artifacts, custom training jobs, or controlled endpoints as part of a broader ML platform. Those needs are materially different from simply calling a managed foundation model for text generation.
PrepAway’s overview of machine learning on AWS helps place SageMaker AI in the larger service landscape and distinguish full ML engineering from the more business-oriented AIF-C01 level.
Use Amazon Textract when the problem is document extraction
Amazon Textract is designed to extract printed text, handwriting, forms, and tables from documents. That is a different problem from asking a generative model to “read” an image of a document and reproduce its contents.
For invoices, forms, applications, statements, and scanned records, structured extraction can be more appropriate because the application often needs specific fields and geometry rather than an open-ended narrative. The extracted data can then feed validation rules, analytics, search, or a downstream generative workflow.
A common architecture uses specialized extraction first and generative AI later. The important point is that the foundation model does not have to perform every stage.
Use Amazon Transcribe, Polly, and Translate for language transformation tasks
Amazon Transcribe converts speech to text. Amazon Polly converts text to speech. Amazon Translate performs machine translation. These are focused services with clear inputs and outputs, which makes them useful building blocks for contact centers, accessibility features, media workflows, and multilingual applications.
A generative model can also work with language, but using one for a specialized transformation should have a reason. If the requirement is accurate transcription, the speech service is designed specifically for that job. If the requirement is an interactive assistant that reasons over the transcript, Bedrock may enter the workflow after transcription.
Service selection should therefore follow the pipeline. One application can combine specialized AI and generative AI without treating them as substitutes.
Use Comprehend when the task is natural-language analysis
Amazon Comprehend provides managed natural-language processing capabilities for analyzing text, such as entities, key phrases, sentiment, and other language features. It can be appropriate when the application needs structured analysis rather than generated prose.
For example, a customer-feedback pipeline may classify or analyze large volumes of comments and then use a generative model to summarize trends for an analyst. The structured NLP output and the generative summary solve different parts of the problem.
This distinction also helps evaluation. A classification or extraction service can often be measured against labeled ground truth more directly than an open-ended generative response.
Use Rekognition when the task is image or video analysis
Amazon Rekognition provides managed computer-vision capabilities for images and video. If the business requirement is detecting objects, scenes, text, faces where appropriate, or other supported visual features, a specialized computer-vision service may be the most direct option.
Multimodal foundation models can reason over images in broader ways, but that flexibility comes with different cost, latency, and evaluation characteristics. A deterministic workflow that only needs a supported visual label may not benefit from generative reasoning.
The choice should be made from the output the application needs. “Uses images” is not enough to decide between a computer-vision API and a multimodal foundation model.
Use Lex, Personalize, and other specialized services for established patterns
Amazon Lex supports conversational interfaces with intents and slots, while Amazon Personalize supports recommendation experiences. These services embody established application patterns that do not always require a general-purpose foundation model.
A structured transactional bot that collects a few known fields and routes a request may be simpler with an intent-based approach. A recommendation system built from user-item interactions has different requirements from a generative chat assistant. Foundation models can augment these systems, but they should not replace specialized logic without a clear benefit.
Organizations should compare maintenance effort, predictability, explainability, cost, and user experience when deciding whether to introduce generative behavior into an established workflow.
Data and security requirements can determine the service before model quality does
Service choice also depends on where data resides, which regions are supported, how IAM permissions are structured, what encryption and logging controls are required, and whether the organization needs private or restricted access patterns. An excellent model is not a valid option if the surrounding service cannot satisfy the workload’s compliance requirements.
Organizations should also consider operational ownership. A business team may be able to consume a managed API with little ML expertise, while a custom SageMaker AI platform requires engineering, MLOps, monitoring, and lifecycle skills. The right service fits the team that must operate it after the prototype succeeds.
Generative AI applications should consider guardrails, retrieval authorization, prompt logging, tool permissions, and model access. Traditional ML workloads need secure training data, endpoints, artifacts, and pipelines. Specialized APIs need the same discipline around identity and sensitive inputs.
The AWS Certified AI Practitioner scope includes security and governance because choosing an AI service is also choosing an operational and security model.
Prototype the simplest viable option and measure it
Architecture diagrams can make service selection look more precise than it is. A small prototype with representative data often reveals whether the chosen service meets quality, latency, cost, and operational requirements. Compare alternatives using the same test cases.
If a specialized service satisfies the requirement, keep the architecture simple. If it fails because the task requires broader context or generation, evaluate Bedrock. If the problem needs custom model development or control over training and deployment, evaluate SageMaker AI. The escalation in complexity should be justified by evidence.
For more advanced generative AI implementation, the AWS Generative AI Developer – Professional AIP-C01 exam represents a deeper technical step beyond the foundational practitioner level.
The right AWS AI service is the one that removes unnecessary complexity.
Service choice should make the system easier to build, secure, evaluate, and operate. The newest service is not automatically the best fit, and a foundation model is not automatically more capable for a narrow deterministic task. Match the service abstraction to the problem.
Maintain a decision record that explains the use case, alternatives considered, expected data, quality threshold, cost assumptions, security requirements, and reasons for the final selection. Revisit that decision when AWS introduces materially better capabilities or when the product requirements change.
Within the wider AWS certification landscape, AIF-C01 provides the vocabulary for these choices. The practical skill is not remembering the largest possible service list. It is recognizing which category of AWS AI capability solves the user’s problem with the least unnecessary complexity.
Architects should also resist selecting services only from a memorized exam list. AWS changes names, introduces capabilities, and expands service scope over time. The durable decision pattern is to identify the task category first—generation, extraction, speech, vision, language analysis, recommendation, or custom ML—and then verify which current service best satisfies it.