MLA-C02 Cheat Sheet

A Cartesian cross join combines every row of one dataset with every row of the other. Use it only when all combinations are intended, such as constructing an explicit candidate grid. For ordinary enrichment, join on the relevant key to avoid an unintended explosion in intermediate data and processing cost.

Trap Selecting a Cartesian cross join to merge customer attributes into transaction rows, which creates combinations instead of matching each transaction's customer.

When an existing data lake needs relational database ingestion with minimal custom development, use an AWS Lake Formation database blueprint. The blueprint generates AWS Glue crawlers, jobs, and triggers to load and catalog the data. Choose a database snapshot for a full load or an incremental database blueprint for supported incremental ingestion.

Trap Using an Amazon Kinesis Data Streams stream as a relational extraction workflow, although producers must still extract and publish the database records.

When extracting a large DynamoDB dataset must not compete with application reads, export the table to Amazon S3 and process the exported data. Export requires point-in-time recovery and does not consume read capacity units. Export and S3 charges still apply, and asynchronous completion should not be treated as a fixed-time guarantee.

Trap Using a parallel table scan to avoid read-capacity consumption, although scan operations consume the table's read capacity.

AWS Glue's DynamoDB export connector can read an existing export from Amazon S3 instead of requesting a fresh table export. Reuse the export when repeated preprocessing experiments should use the same source snapshot. Request a new export when the dataset must reflect later table changes.

Trap Requesting a new table export for every transformation experiment, although the existing S3 export already contains the required snapshot.

A Glue connection to a private relational database must use a reachable VPC subnet and appropriate security groups in addition to valid database authentication. Glue attaches network interfaces using the connection's networking configuration. A successful credential check alone does not establish a path to the database endpoint.

Trap Rotating the database password to fix a connection timeout caused by a blocked network path, which does not change routing or security-group rules.

When a dataset resides on an NFS or SMB file server and must be copied into Amazon S3, use AWS DataSync with the appropriate source and destination locations. These file-server transfers require a DataSync agent. This is file movement; the downstream preprocessing job still performs record parsing and feature transformations.

Trap Using a Glue JDBC connection to copy an SMB document collection, although JDBC connects to database records rather than file shares.

Use a join when transaction rows need attributes from a customer table matched by a key. Use a union when datasets represent additional rows of the same logical schema. Align column meanings and data types before appending records, rather than interpreting a union as an entity match.

Trap Unioning customer profiles with transactions to enrich each transaction, although appending rows does not match customers to their transactions.

When every training example must survive enrichment, make the examples the left side of a left join. An inner join retains only matched keys and can silently change which examples remain. Inspect missing enrichment values and repeated keys because the join type does not itself clean or deduplicate the inputs.

Trap Choosing an inner join solely to add optional profile fields, which removes examples whose profile key has no match.

Amazon EBS exposes an attached volume as a block device rather than an object-storage location. To extract files from an existing EBS dataset, make its existing file system available on the attached EC2 instance and have the extraction process read the mounted files. A volume restored from a snapshot can already contain the file system and dataset.

Trap Formatting a restored dataset volume as if it were empty, which overwrites its existing file system and data.

When an existing Amazon EFS file corpus must be copied to Amazon S3 for preparation, configure an EFS source location and an S3 destination in AWS DataSync. For a transfer within the same AWS account, whether in the same Region or across Regions in the same AWS partition, no DataSync agent is required; DataSync accesses the EFS mount target through VPC network interfaces. Configure the location's subnet, security groups, and file-system access permissions so the source files are readable.

Trap Treating managed EFS as an on-premises NFS source requiring a deployed DataSync agent, which applies the self-managed file-server access path unnecessarily.

Extract Amazon RDS relational tables through an AWS Glue JDBC connection compatible with the database engine. Use a full table read when all source rows are required; for repeated incremental reads, enable JDBC bookmarks and select keys that satisfy the bookmark ordering requirements. User-defined bookmark keys must each be strictly monotonically increasing or decreasing, because Glue compares their values with saved progress to identify later rows. An update to an old row whose bookmark key remains unchanged is not newly discoverable through that key alone.

Trap Selecting a revision counter reused across different records as a bookmark key, which violates the required monotonic ordering across the dataset.

Use an AWS Glue for Spark OpenSearch Service connection when existing indexed documents must become input to dataset preparation. Select the source index and supply an OpenSearch query with pushdown so the service returns the relevant documents to a DynamicFrame. This native connection supports OpenSearch Service domains, not OpenSearch Serverless, so verify the source deployment type before choosing it.

AWS Glue Spark jobs run Apache Spark as the processing engine for batch dataset merging, including Join and Union transforms configured in the visual ETL editor. The Join transform takes two input datasets and explicit matching keys; the Union transform requires compatible input schemas and offers ALL or DISTINCT behavior. Select DISTINCT when the merged output must remove duplicate rows, rather than assuming that appending sources automatically deduplicates them.

When feature preparation repeatedly reads a subset of a wide dataset's columns, store the analytical copy in Parquet or ORC. Columnar layout and compression can reduce the data read by compatible query engines. CSV remains useful for simple interchange but does not provide the same column-oriented layout.

Trap Choosing CSV because it is human-readable when the controlling requirement is minimizing repeated wide-table column scans.

JSON is suitable for semi-structured records that contain named fields, nested objects, or arrays. CSV is a flat row-and-column representation, so nested content requires an agreed serialization or flattening convention. Choose the input format that the consumer actually supports rather than assuming every ML algorithm accepts nested JSON.

Trap Writing nested objects directly into ordinary CSV fields without an encoding convention, which leaves the intended structure ambiguous to the reader.

Amazon Data Firehose can convert JSON records to Parquet or ORC before delivery to Amazon S3 by using a schema in the AWS Glue Data Catalog. When the incoming records use another format, transform them into compatible JSON before conversion. Catalog fields govern which data can be represented in the converted output.

Trap Enabling Parquet conversion directly on raw CSV records, although the format-conversion stage expects JSON input.

When a dataset must be read immediately, choose a storage class that supports immediate access. S3 Glacier Flexible Retrieval and S3 Glacier Deep Archive require restoration before ordinary access, whereas S3 Glacier Instant Retrieval supports millisecond retrieval. A lower storage charge alone does not make a restore-based archive suitable for an immediately scheduled preprocessing run.

Trap Putting the next training run's only dataset copy in S3 Glacier Deep Archive to minimize storage cost while retaining an immediate-read requirement.

Use S3 Intelligent-Tiering when access frequency is difficult to predict and automatic movement between access tiers is useful. Its monitoring and automation have their own cost considerations, and optional archive tiers introduce retrieval considerations. A fixed infrequent-access class is a different choice when the access pattern is already known.

Trap Treating S3 Standard-IA as an automatic access-pattern optimizer, although it is a selected storage class rather than an automatic tiering mechanism.

When a dataset version must remain immutable for its retention period even against privileged users, use S3 Object Lock compliance mode. Governance mode permits authorized bypass, so it serves a different control requirement. Object Lock protects object versions rather than preventing the creation of a new version with the same key.

Trap Choosing governance mode for retention that administrators must not bypass, although specially authorized users can bypass governance retention.

Use an S3 Object Lock legal hold when preservation must continue without a predetermined expiration date. A fixed retention period instead protects a version until a specified date. Legal holds and retention periods are independent, so expiration of retention does not remove an active legal hold.

Trap Using only a fixed retention date for an investigation with an unknown end date, which allows the time-based protection to expire.

Partition an S3 analytical dataset by fields commonly used to restrict queries, such as event date or customer identifier. A partition-aware query engine can then prune irrelevant partitions and read only the relevant portion of the dataset. This optimization selects which groups of files to scan, complementing columnar formats that reduce which columns must be read within those files.

Version prepared datasets and record the source identities, source versions or extraction points, and transformations that produced each version. Retain the relevant source and output versions under the dataset's retention policy so a particular corpus can be reproduced and audited. Source metadata identifies where data came from, while transformation lineage explains how it became the prepared artifact.

Trap Keeping only the preparation code while overwriting the input and output datasets, which preserves transformation logic but loses the specific data used by an earlier run.

When independent applications must consume and replay the same incoming records, use Amazon Kinesis Data Streams and keep the required history within its retention window. Each consumer maintains its own progress through the stream. Amazon Data Firehose focuses on managed delivery to destinations rather than exposing an equivalent general-purpose replay log.

Trap Choosing a Firehose delivery stream as the independent replay log, although its delivery interface is not the Kinesis Data Streams consumer model.

Amazon Data Firehose buffers incoming records before delivery according to the destination and configured buffering settings. Select settings that fit the required freshness rather than equating ingestion acceptance with destination availability. Larger delivery batches can improve write efficiency but can delay visibility of low-volume data.

Trap Increasing Firehose buffer intervals to solve a low-volume delivery-freshness problem, which extends the period before a buffer is delivered.

With partition-key-based record distribution, Kinesis Data Streams maps partition keys to shards, so a heavily reused key can concentrate writes on one shard. When throttling is concentrated rather than evenly distributed, review the key distribution as well as total capacity. In this mode, adding shards does not split a single partition key's records across multiple shards.

Trap Adding aggregate shard capacity while keeping all high-volume events under one partition key in a stream using partition-key-based record distribution, which leaves that key concentrated on one shard.

When multiple Kinesis consumers contend for shared read throughput, use enhanced fan-out for consumers that need dedicated delivery capacity. Shared-throughput consumers compete within the shard's shared read allowance. Enhanced fan-out addresses consumer contention, not a producer-side hot-key write bottleneck. Shards belong to the stream, not to producers (a Kinesis data stream is a set of shards^[1]): adding shards still leaves shared-throughput consumers splitting each shard's read throughput^[2].

Trap Adding shards solely to isolate competing readers without considering enhanced fan-out's per-consumer read capacity.

Kinesis Data Streams assigns sequence numbers to records within a shard. Use partitioning that keeps related events together when their relative order matters, and account for producer sequencing and retries. A multi-shard stream does not provide a single total order across unrelated partition keys.

Trap Sorting all stream records by sequence number as though sequence numbers form a globally ordered stream-wide counter.

Use event time in Amazon Managed Service for Apache Flink when features such as windowed transaction counts must reflect source-event timestamps despite delivery delays. Processing time instead follows the clock of the machine executing the operation, and ingestion time follows entry into the service. Select the time basis that matches the feature's business meaning.

Trap Using processing-time windows for event-occurrence statistics when network delays can move records into later processing windows.

Apache Kafka organizes records into named topics, with each topic divided into partitions that act as ordered logs. Producers append records to a partition and consumers read from positions within that log. Use partition-aware ingestion when related records need ordered processing; parallel partitions do not form one globally ordered topic log.

Use the same Apache Kafka consumer group for workers that should share one ingestion workload. Within a group, a partition is assigned to only one consumer at a time, so partition count bounds useful consumer parallelism. Use separate consumer groups when independent applications each need to consume the stream for their own purpose.

Trap Increasing topic replication to give more workers partition assignments, which adds redundant record copies rather than additional partitions for the group to share.

Apache Kafka offsets identify positions within topic partitions, and committed consumer-group offsets preserve consumption progress for resumption. Keep the intended group identity and its saved offsets when restarting an ingestion consumer. Replay also requires the source records to remain within the topic's retained history; saving a position does not retain the underlying records indefinitely.

Trap Relying on topic replication alone to resume a restarted consumer: replication adds copies of each partition for durability, while a consumer that rejoins its group resumes from the consumer group's committed offset.

When S3 delivery must group records by customer or the date the source event occurred, use Amazon Data Firehose dynamic partitioning with keys extracted from each record. Firehose evaluates the configured S3 prefix expression and groups records with the same result for delivery. Deriving date components from the record's event timestamp also places delayed events with their event-date data rather than merely with records that arrived together.

Amazon Data Firehose creates a separate buffer for every active dynamically evaluated S3 prefix, and each buffer is delivered independently when its size or time condition is met. Many low-volume prefixes can therefore produce small objects and a high active-partition count even when aggregate ingestion throughput is modest. Check partition cardinality and stalled deliveries when diagnosing active-partition errors: a partition remains active until its buffered data is delivered, and exceeding the active-partition quota routes excess records to the S3 error prefix.

Trap Increasing the buffering interval to address small files when active-partition capacity is already exhausted, which can keep more partition buffers active for longer.

Enable Firehose's new line delimiter option when downstream readers need newline-separated records within delivered S3 objects. This setting adds separators between output records, whereas multi-record deaggregation splits logical events bundled inside an input record. Choose the setting for the boundary that needs to change: output record separation or input event separation.

Trap Using Firehose's JSON-to-Parquet conversion to meet a newline-delimited text requirement, which produces a columnar format instead of the expected text records.

A missing or differently named field can prevent Firehose from extracting the configured dynamic partition key and evaluating the destination prefix. Firehose delivers records that fail parsing, key extraction, or prefix evaluation to the required S3 error prefix, organized by error type and accompanied by error details. Inspect those details and compare the failed record's field names and structure with the extraction expression before correcting the producer or routing configuration.

Trap Requesting a higher active-partition quota for missing-key errors, which changes partition capacity rather than repairing the record fields used for routing.

For an Amazon Redshift destination, Amazon Data Firehose first delivers streaming records to an S3 bucket and then issues a Redshift COPY command to load them into the cluster. Include that staging bucket in the delivery configuration and distinguish successful S3 delivery from completion of the Redshift load. If source-record backup is also enabled for transformed data, that optional backup serves a separate purpose from the S3 staging step.

When an existing PostgreSQL application must combine SQL data with embedding similarity search, use the pgvector extension on a supported Amazon RDS for PostgreSQL version. It supplies vector storage and similarity operations within the database. Keep this choice distinct from moving the dataset into a separate search service when the stated requirement is to retain relational integration.

Trap Moving relational records into an OpenSearch index solely to obtain vectors when the requirement specifically calls for SQL integration inside the existing database.

Use Amazon OpenSearch Service when an existing retrieval workload needs both full-text search and vector similarity. Store embeddings in a vector field and retain searchable text or structured fields for the other query requirements. Embedding generation remains a separate preparation step unless an explicitly configured model integration performs it.

Trap Selecting a vector-only similarity operation as a replacement for exact keyword matching when both retrieval behaviors are required.

Amazon S3 Vectors stores embeddings in vector indexes within vector buckets and exposes similarity-query operations. Use these resources when the specified workload needs S3-native vector storage and retrieval. Uploading arrays into ordinary S3 objects preserves the bytes but does not itself create a similarity-search index.

Trap Storing embeddings as JSON objects in a general-purpose S3 bucket and expecting object-list operations to perform nearest-neighbor search.

Configure an S3 vector index with the embedding model's selected output dimension. Every inserted vector must have exactly that number of values. Changing to a different output dimension requires a new index because the dimension of an existing index cannot be updated.

Trap Padding a newly generated shorter embedding with arbitrary values to reuse an incompatible index, which changes the intended vector representation.

Choose the index distance metric that the embedding model recommends. In S3 Vectors, cosine distance emphasizes vector direction, while Euclidean distance incorporates straight-line separation and therefore magnitude. Changing the metric of an existing S3 vector index requires a new index rather than an in-place setting change.

Trap Choosing cosine distance for a representation whose required similarity depends on vector magnitude as well as direction, although cosine comparison discards that magnitude distinction.

Keep attributes such as document category filterable when retrieval must restrict results by those attributes. S3 Vectors metadata is filterable unless configured as non-filterable; non-filterable fields can accompany returned vectors but cannot be used as query filters. Long source text that is returned for context is a suitable candidate for non-filterable metadata.

Trap Marking a required category-filter field as non-filterable to save filterable metadata space, which removes that field from filtering operations.

When an OpenSearch vector workload needs scalable similarity retrieval, an approximate nearest-neighbor index can avoid exhaustively comparing every stored vector. Approximation can miss neighbors that exact search would return, so evaluate recall as well as query latency. Use exact search when the required result guarantees and dataset size justify exhaustive comparison.

Trap Treating approximate nearest-neighbor results as guaranteed identical to exhaustive search merely because both return a requested number of neighbors.

After adding, modifying, or removing documents in a connected knowledge-base source, synchronize the source so the indexed content reflects those changes. Synchronization processes documents changed since the preceding sync rather than requiring every unchanged document to be processed again. Updating the source files alone does not complete the indexing step.

Trap Recreating the entire knowledge base after every document edit to refresh retrieval, although incremental synchronization processes the source changes.

When source PDFs contain page images rather than an extractable text layer, use OCR such as Amazon Textract to obtain text. Ordinary PDF text extraction is appropriate for digitally authored documents with embedded text. Inspect the extracted output because document layout can affect reading order and field interpretation.

Trap Using a text-only PDF parser on scanned page images, which have no embedded text for that parser to extract.

When preparing web pages as a text corpus, extract the passages that bear on each page's subject rather than keeping a raw HTML dump, so less of the model's input goes to boilerplate and navigation, and keep the headings, which help RAG models understand document structure. When menus repeat across pages, a dump of every visible string can overrepresent those menus rather than each page's subject.

Trap Using a dump of every visible string as clean article content, which includes repeated navigation and unrelated page elements.

Use Amazon Transcribe batch transcription for media files in Amazon S3 and streaming transcription for live media streams. Supported audio formats differ between these modes, so a format accepted by a batch job is not automatically a valid streaming encoding. Validate the actual encoding before choosing the ingestion mode.

Trap Sending a WAV file unchanged as streaming PCM because batch transcription accepts WAV, although a WAV container is not raw PCM stream encoding.

Use Transcribe speaker partitioning when multiple speakers share one audio channel and their speech must be distinguished. Use channel identification when speakers are already separated into different audio channels. Both can produce a single transcript file, so the number of output files is not the selection criterion.

Trap Selecting channel identification to separate speakers mixed into one channel, which provides no separate channels for that feature to identify.

Amazon Transcribe streaming requests require the audio sample rate, while batch requests can omit it. When supplied, the rate must describe the actual audio; changing the declared number does not resample the recording. A mismatch can make a transcription request fail.

Trap Declaring a higher sample rate to improve low-fidelity audio, which changes request metadata rather than the samples themselves.

For batch transcripts that must remain available as training data, specify an Amazon S3 output bucket you control and grant Transcribe permission to write there. Service-managed output provides temporary download access and is removed when the transcription job expires. A temporary download link is not a durable dataset location.

Trap Saving only the service-managed transcript download URL as the permanent dataset reference, although that URL expires.

An image corpus needs decodable files in formats and dimensions supported by the consuming workflow. During ingestion, identify corrupted images and create resized working copies where required, while retaining the original assets and a source reference linking each prepared image to its origin. Data Wrangler supports image import, corrupted-image removal, and resizing; a Ground Truth input manifest's source-ref entries can preserve the association between an S3 image location and its dataset record.

Trap Replacing the image corpus with OCR text, which preserves extracted characters but not the visual assets required by an image workflow.

Use the Feature Store online store for low-latency access to current feature values and the offline store for historical training datasets and batch analysis. A feature group can use either store or both. The offline store preserves history in Amazon S3 rather than acting as the low-latency current-value lookup.

Trap Querying the offline store for every latency-sensitive inference request because it contains the complete history, which substitutes analytical access for the online lookup path.

Before ingesting features, define the feature names and types, the record identifier, and the event-time feature. The record identifier identifies the entity, while event time identifies when the feature record applies. Validate incoming values against this contract rather than treating a feature group as an arbitrary schemaless document collection.

Trap Using the ingestion job's run identifier as every entity's record identifier, which collapses unrelated entities under the same lookup key.

When an ingested record has a later event time than the existing record for that entity, it can replace the current online value. Older historical records are written to the configured offline history instead of replacing newer online state. This allows historical backfills without making current features stale.

Trap Assuming the last-arriving historical record becomes the online value solely because it was ingested last, which ignores event-time ordering.

When a historical dataset should populate only the offline store, explicitly target that store during ingestion. Otherwise, Feature Store targets the stores configured for the feature group, subject to event-time rules. Store targeting controls where records are ingested; it does not create a store that was never configured.

Feature Store PutRecord performs a full-record overwrite, so provide the feature values that the resulting record must contain. Use UpdateRecord with the Standard_V2 online store tier when the requirement is to change individual feature values without replacing the rest. Selecting the write semantics prevents an ingestion update from unintentionally dropping unrelated values.

Trap Sending only one changed feature in a full-record replacement and expecting omitted features to be merged automatically.

Use streaming record writes when updated features must become available as individual source updates arrive. Use a batch processing workflow, such as a Data Wrangler export executed as a SageMaker AI Processing job, for scheduled bulk feature preparation and ingestion. Both approaches populate feature groups rather than requiring separate feature definitions for each arrival mode.

Trap Building a separate feature repository solely because source updates arrive in batches, although Feature Store supports batch ingestion.

Feature Store's offline store is append-only historical storage in Parquet, so a raw query can return several versions of the same entity. Select the required time horizon and handle deleted or duplicate records when constructing a training dataset. The dataset-building helpers can perform this filtering; a raw table scan does not inherently represent one current row per entity.

Trap Treating every offline history row as an independent current entity, which mixes multiple feature versions into the training population.

Choose a foundation model by checking input and output modalities separately. A model that understands images and produces text can describe an image but is not thereby an image generator. For image creation, select a model explicitly supporting image output, such as Stability AI Stable Image Ultra in Amazon Bedrock.

Trap Choosing a multimodal understanding model for image generation because image input support is mistaken for image output support.

A foundation model's context window and maximum output tokens constrain different parts of a request. When processing long documents, compare the model card's context window and maximum output tokens with the required input context and response length; a large context window does not imply equally long generated responses. Choose a model that satisfies both constraints.

Trap Selecting solely by context-window size when the required response exceeds the model's separate output limit.

When several Amazon Bedrock models support the task, evaluate their responses on prompts representative of that task. Use the relevant quality metrics and compare results before selecting a model. Supporting text generation establishes compatibility, not that a model meets a particular domain's accuracy or response-quality requirement.

Trap Selecting from the model card's modality support alone, which establishes supported inputs and outputs rather than measured task quality.

Choose among foundation models using task quality, latency, and cost together. Amazon Bedrock offers model variants with different capability and price-performance profiles, so a simpler text task can be served by a faster, lower-cost option if it passes the required evaluation. More capable models remain appropriate when the task requires the additional capability.

Trap Choosing the most capable model for every request without checking whether the additional capability is needed within the latency and cost budgets.

When the application needs semantic representations for a vector index, use an embedding model such as Amazon Titan Text Embeddings. It returns numeric vectors; the vector database performs similarity search. A separate generative model can use the retrieved text to compose an answer.

Trap Using a text-generation response as the vector-index value, because generated prose is not the embedding representation the index searches.

Amazon Bedrock model capabilities are not uniform across a family or across versions. Check the chosen model's support for required features such as streaming, fine-tuning, and the intended API before committing to it. A model can support inference while lacking a customization feature available on another member of its family.

Trap Choosing a model by family name and inheriting another family member's fine-tuning support, which is specified per model.

When prompting is insufficient for a well-defined output style, format, or task behavior, consider supervised fine-tuning with representative input-output pairs. Training adjusts model parameters toward the demonstrated responses. The technique is a behavior-customization choice rather than the default mechanism for supplying continually changing reference information.

Trap Choosing retrieval alone to teach a persistent output style, because retrieved reference passages supply context rather than parameter updates from demonstrations.

When a supported customization workflow must adapt a model on a compute budget that covers only adapter training, consider LoRA, a parameter-efficient fine-tuning method. It trains small adapter matrices while the base model weights stay frozen, which SageMaker AI documents as lower cost, faster training, and smaller artifacts. Full fine-tuning updates all model weights and is a different resource commitment.

Trap Choosing full fine-tuning for an adapter-only resource budget, because it updates all model weights.

When response quality can be scored but there is no single desired answer for each input, consider supported reinforcement fine-tuning in Amazon Bedrock. Reward functions evaluate generated responses and supply feedback for iterative learning. Supervised fine-tuning instead learns from labeled input-output demonstrations.

Trap Choosing supervised fine-tuning with only unlabeled prompts and no target responses, which omits the demonstrations that supervised training needs.

When a capable teacher model meets quality requirements but is too expensive or slow for the target workload, evaluate Amazon Bedrock Model Distillation with a supported student. Bedrock generates teacher responses for use-case prompts and fine-tunes the student on those responses. Evaluate the resulting student's task quality rather than assuming it inherits all of the teacher's capabilities.

Trap Using a prompt router when a separately trained student is required, because routing selects among existing models without transferring teacher behavior.

Amazon Bedrock customization training charges depend on the tokens processed during training, including repeated passes through the training corpus. Increasing the epoch count therefore increases training work even when the dataset is unchanged. Choose training duration from validation results and the budget rather than treating additional epochs as free quality improvement.

Trap Budgeting training from the corpus size alone, which ignores repeated token processing across epochs.

When an existing foundation model needs deeper familiarity with domain terminology and writing patterns and a substantial unlabeled corpus is available, consider supported continued pre-training. It continues training the existing model on raw domain documents rather than requiring input-output demonstrations, and you can then fine-tune the adapted model for downstream tasks with significantly fewer labeled records. Supervised fine-tuning instead teaches demonstrated task responses, while RAG supplies current reference material at inference time without retraining the model whenever that material changes.

Trap Using model distillation to introduce a new domain corpus, although distillation transfers a teacher's task behavior through generated responses rather than learning directly from unlabeled documents.

For labeled tabular data, choose classification when the required output is a discrete category and regression when it is a continuous value. Amazon SageMaker AI algorithms such as Linear Learner and XGBoost support these problem families. Configure the learning objective for the target rather than inferring it from whether the input columns are numeric.

Trap Choosing regression for numeric class codes, because a numeric encoding does not turn categorical outcomes into continuous targets.

When the task is to group customers by similar measured behavior without predefined segment labels, consider the Amazon SageMaker AI K-Means algorithm. Clustering discovers groupings from feature similarity. Supervised classification is appropriate when labeled examples define the categories to predict.

Trap Choosing a supervised classifier for an unlabeled segmentation dataset, which supplies no target categories for supervised training.

For an unlabeled dataset where the objective is to flag observations that differ from normal patterns, consider Amazon SageMaker AI Random Cut Forest. It is an unsupervised anomaly-detection algorithm. Its anomaly scores identify unusual observations for investigation rather than directly establishing a business label such as confirmed fraud.

Trap Treating an anomaly score as a confirmed fraud classification, which substitutes unusualness for a labeled business outcome.

When the required prediction is future behavior from historical time-series observations, consider Amazon SageMaker AI DeepAR. Forecasting differs from assigning a category to the current record. Select and evaluate the forecasting approach against the future values the application must predict.

Trap Choosing K-Means to produce future numeric forecasts, because clustering groups observations rather than predicting a future sequence.

When a document corpus has no topic labels and the requirement is to discover themes, use an unsupervised topic model such as LDA or Neural Topic Model. Use supervised text classification when the required categories are already defined and labeled examples are available. The distinction is whether topics are discovered or supplied as targets.

Trap Choosing an unsupervised topic model for exact business-category prediction, because discovered topics need not correspond to the required labels.

When an application must locate multiple objects within an image, choose object detection rather than image-level classification. Supported Amazon SageMaker AI object-detection models return bounding boxes and labels. Image classification is appropriate when a label for the image as a whole satisfies the task.

Trap Choosing image classification for a bounding-box requirement, because image-level labels do not locate individual objects.

For a computer-vision task requiring pixel-level category assignments, select semantic segmentation. Amazon SageMaker AI provides a built-in semantic-segmentation algorithm for this fine-grained output. Bounding-box detection is sufficient when approximate object locations, rather than pixel boundaries, meet the requirement.

Trap Choosing object-detection boxes for a pixel-mask requirement, because a rectangle does not classify each enclosed pixel.

When labeled documents must be assigned to predefined categories, Amazon SageMaker AI BlazingText provides an optimized text-classification implementation. It also offers Word2vec functionality, but that mode produces word representations rather than category predictions. Choose the mode that matches the required output.

Trap Selecting BlazingText's Word2vec mode for direct document-category predictions, because word embeddings are representations rather than classification outputs.

When paired examples map an input sequence to an output sequence, consider a sequence-to-sequence approach. Amazon SageMaker AI's built-in algorithm supports tasks such as translation and summarization. This differs from text classification, which selects a category instead of generating a new sequence.

Trap Using a text classifier for translation, because its category output cannot express an arbitrary translated sentence.

When a requirement calls for directly understandable decision logic, choose an inherently interpretable candidate, such as a simple linear model or small decision tree, if it meets the required predictive performance. Its weights or decision rules expose how inputs determine predictions, which can justify accepting lower accuracy than a more complex candidate. Post-hoc feature attribution explains aspects of an already trained model's behavior; it does not make that model's internal decision logic inherently simple.

When an Amazon SageMaker AI built-in algorithm fits the data and prediction task, supply data, hyperparameters, and compute configuration to run training. The algorithm implementation is already provided. This reduces development effort compared with writing an equivalent training implementation in a framework script.

Trap Reimplementing an available built-in algorithm in a framework script when the sole requirement is equivalent training with minimal custom code.

When a supported pretrained model or solution template already fits the application task, use Amazon SageMaker JumpStart as a starting point. It offers reusable options for tasks such as text analysis and computer vision. This avoids implementing and training a comparable model from scratch while preserving the need to evaluate it on the intended workload.

Trap Starting a new model-training implementation for a task already satisfied by a suitable pretrained model, which adds development and training work.

When the existing application needs supported foundation models through a managed service, choose Amazon Bedrock rather than building model-serving infrastructure. Bedrock exposes foundation-model capabilities through APIs and supplies associated customization and evaluation features. Amazon SageMaker AI remains appropriate when the workflow requires greater control over custom model development and training.

Trap Building a custom model-serving stack for a supported Bedrock model when the requirement is managed API access with minimal hosting operations.

When a business task matches a pretrained AWS AI capability, use the task-specific service if it meets the required quality and customization needs. Services such as Amazon Textract and Amazon Comprehend expose document-analysis functions directly. A custom training workflow earns its additional effort when the managed capability does not satisfy the task.

Trap Training a custom model solely to reproduce an adequate pretrained API, which adds model-development work without satisfying an additional requirement.

Amazon SageMaker AI built-in algorithms do not all support the same CPU, GPU, or multi-instance training configurations. Select resources supported by the chosen algorithm rather than assuming every managed algorithm distributes automatically. For example, the built-in sequence-to-sequence algorithm supports GPU training on a single machine, including supported multi-GPU instances.

Trap Adding multiple training instances to an algorithm documented for single-machine training, because managed execution does not override algorithm support.

When a supported prediction task needs automated model development with minimal manual experimentation, use Amazon SageMaker Autopilot. Its AutoML workflow performs data analysis and preprocessing, explores algorithms, searches hyperparameters, trains candidates, and ranks them using validation performance. Manually selecting a built-in algorithm is appropriate when the algorithm is already chosen, while a custom training script provides control over training logic that the automated workflow does not supply.

Trap Using automatic model tuning alone as a replacement for an AutoML workflow, although tuning optimizes the supplied training configuration rather than supplying the whole preprocessing and candidate-development process.

When users need to build, evaluate, and use a custom predictive model without writing code, choose Amazon SageMaker Canvas for a supported prediction task. Its interface lets users import their data, build a model trained on that data, evaluate its performance, and generate predictions. Supported custom-model tasks include regression, classification, and time series forecasting, so the selection depends on both the required prediction type and the need for a no-code workflow.

Trap Using Canvas Ready-to-use models for a requirement to train a custom predictor on the user's data, because those models provide pretrained AI capabilities rather than that custom training workflow.

When answers need current private reference information, use RAG to add relevant source material to the prompt. The model can use this context without being retrained whenever the information changes. Fine-tuning is better suited to changing learned task behavior than to maintaining a frequently updated reference corpus.

Trap Repeatedly fine-tuning solely to refresh a changing reference catalog, which turns content updates into training jobs.

For an existing document repository in Amazon S3, Amazon Bedrock Knowledge Bases can manage ingestion, chunking, embedding, and retrieval for a RAG application. It maintains the relationship between indexed chunks and their sources. This supplies a managed retrieval layer rather than requiring a custom document-to-vector pipeline.

Trap Using Amazon Textract as the semantic-search index, because document extraction does not provide the vector-retrieval layer.

When an application needs retrieved passages for its own downstream generation logic, use the Retrieve operation of Amazon Bedrock Knowledge Bases. RetrieveAndGenerate combines retrieval with model invocation and returns a generated answer with source citations. Choose according to whether the application or the managed operation should compose the answer.

Trap Calling RetrieveAndGenerate for a retrieval-only component, which adds answer generation that the application intends to control separately.

When the reference data already resides in a supported structured store, Amazon Bedrock Knowledge Bases can translate natural-language questions into suitable queries and retrieve the results. GenerateQuery provides query conversion separately when the application needs that control. This pattern uses the existing schema rather than requiring an unstructured-document vector workflow.

Trap Exporting every table row to text solely to enable retrieval, despite a supported structured-store connection that can query the data directly.

When a RAG workload needs facts connected through multiple document relationships, consider Amazon Bedrock Knowledge Bases GraphRAG with Amazon Neptune Analytics. It expands initial vector-search results by traversing related graph nodes or chunks. This is useful when independently similar passages omit relationships needed for a complete answer.

When a document workflow needs form fields or table cells rather than just recognized text, choose Amazon Textract document analysis. Its form and table capabilities extract structured relationships from the document. Text detection (DetectDocumentText) is sufficient when words and lines alone satisfy the requirement.

Trap Choosing text detection (DetectDocumentText) for structured form extraction, because recognized words alone do not supply form and table relationships.

When a workflow must process multipage documents, choose an appropriate asynchronous Amazon Textract operation. Synchronous processing is suited to supported single-page documents when immediate response latency matters. Select the processing mode from document structure and response timing together.

Trap Selecting synchronous document processing for a multipage input, which exceeds the documented single-page scope of that mode.

When the application needs invoice or receipt information, use Amazon Textract AnalyzeExpense rather than assembling equivalent extraction from text detection. The specialized analysis is designed for these document types. Generic document analysis remains suitable for other forms and tables.

Trap Using only text detection and custom parsing for standard expense extraction, which discards the purpose-built invoice and receipt capability.

When a document workflow needs specific information expressed as questions, use the Queries feature in Amazon Textract document analysis. It targets the requested information rather than requiring the application to inspect every extracted word. Custom Queries can adapt this pretrained capability to a particular document use case.

When generic image labels do not cover proprietary products or logos, use Amazon Rekognition Custom Labels with examples of the required categories. It supports custom visual classifiers without requiring a from-scratch vision implementation. General label detection is appropriate when the pretrained categories already meet the requirement.

Trap Relying on generic label detection to distinguish proprietary product categories that its pretrained label set does not define.

For image or video moderation, use Amazon Rekognition content-moderation capabilities. They return unsafe-content categories and confidence information that an application can apply to its review policy. This is different from ordinary object labeling or detecting sentiment in text.

When a review praises one product but criticizes another, use Amazon Comprehend targeted sentiment to associate sentiment with individual entities. Document-level sentiment summarizes the overall text and can obscure these differences. Choose the scope of sentiment analysis to match the business question.

Trap Using a single document sentiment label for entity-specific feedback, which collapses different opinions into an overall result.

Use Amazon Comprehend custom classification to assign documents to your own categories. Use custom entity recognition to locate domain-specific terms and noun phrases within text. A document's category and the entities mentioned inside it are separate outputs, so select the custom model type accordingly.

Trap Choosing a document classifier to locate occurrences of domain-specific entities, because category assignment does not extract entity spans.

For small interactive document-analysis workloads, use Amazon Comprehend real-time operations where supported. For large document sets, use asynchronous analysis jobs. The processing choice should reflect the required response timing and workload rather than forcing a large corpus through an interactive workflow.

Trap Submitting an asynchronous corpus-analysis job for an immediate per-request response, because completion occurs through the job workflow.

When an application needs text from live audio, use Amazon Transcribe streaming for a supported language and Region. For recordings already stored in Amazon S3, use batch transcription. Both convert speech to text, but their input delivery and response timing fit different workloads.

Trap Choosing batch transcription of S3 recordings for a live transcription requirement, because the workflow expects stored media rather than the ongoing stream.

When an application needs synchronous predictions with low latency and sustained throughput, use Amazon SageMaker AI real-time inference. Keep sufficient serving capacity available for the response-time requirement; Asynchronous Inference is appropriate when the caller can collect its result later.

Trap Using batch transform for an interactive transaction, which returns results through an offline job rather than the transaction's synchronous response.

When predictions are needed for a stored dataset rather than individual online requests, use Amazon SageMaker AI batch transform. The job provisions compute for the workload and writes results to Amazon S3, avoiding the need to maintain a continuously running inference endpoint.

Trap Keeping a real-time endpoint running between scheduled scoring jobs, which reserves serving infrastructure even when the offline workload has no requests.

When an application can wait for a result and submits large or long-running requests, use Amazon SageMaker AI Asynchronous Inference. Requests identify input in Amazon S3, and outputs are written to S3 rather than returned as synchronous predictions. Optional Amazon SNS notifications tell the application when processing succeeds or fails.

Trap Using Serverless Inference merely because traffic is intermittent, which does not supply the asynchronous S3 request-and-result workflow.

When inference traffic is intermittent and the application tolerates cold starts, use on-demand Amazon SageMaker AI Serverless Inference. SageMaker AI launches and scales compute with traffic and scales it to zero when idle, without requiring instance selection or instance-scaling policies.

Trap Choosing a continuously provisioned real-time endpoint for an idle-cost requirement despite accepting cold starts, which retains provisioned capacity between traffic bursts.

Amazon SageMaker AI Serverless Inference does not support, among other features, GPUs, VPC configuration, Model Monitor, data capture, multiple production variants, or inference pipelines. When any of these is a deployment requirement, choose a compatible hosting mode such as real-time inference rather than treating all endpoint modes as interchangeable.

Trap Adding provisioned concurrency to a serverless endpoint to obtain GPU support, which warms serverless capacity without changing the endpoint's feature support.

When many models use the same ML framework and have compatible serving requirements, a SageMaker AI multi-model endpoint can host them in a shared serving container and instance fleet. Sharing raises utilization compared with a separate endpoint for every model. The application must tolerate loading delays for infrequently used models.

Trap Using an inference pipeline to host independent tenant models, which chains processing stages rather than selecting one model for each tenant request.

A SageMaker AI multi-model endpoint loads models on demand and caches them in memory. Under memory pressure it unloads unused models, which can remain on the instance's storage volume for faster reloading. A model with strict latency requirements or disproportionately high traffic is a better candidate for dedicated hosting than for competing with infrequent models in this cache.

Trap Increasing the total number of model files in S3 to warm the endpoint, which does not load those models into serving memory.

To add a compatible model to an existing SageMaker AI multi-model endpoint, upload its artifact to the endpoint's configured S3 location and invoke that model. SageMaker AI loads the requested artifact dynamically, so adding a model does not require an endpoint update.

Trap Creating a production variant for every newly added tenant model, which uses variant-based deployment instead of the endpoint's dynamic model-loading mechanism.

When inference requires preprocessing, prediction, and postprocessing as a connected sequence, use a SageMaker AI inference pipeline. The containers run in order, passing each stage's output to the next. This keeps the serving transformations with the model instead of requiring the client to coordinate separate stage invocations.

Trap Using direct invocation of one container to run the entire chain, which addresses an individual container rather than serially executing all stages.

When separate models use different frameworks but should share SageMaker AI endpoint resources, a multi-container endpoint can expose containers through direct invocation. Each request selects its intended container rather than traversing an inference pipeline.

Trap Putting incompatible serving frameworks into one multi-model serving container, which assumes the shared-container compatibility that the models do not have.

SageMaker AI inference components describe a model and its CPU, accelerator, and memory requirements separately from the endpoint. Use them when several models should share endpoint infrastructure while being added, removed, or updated independently. The resource specification makes allocation explicit rather than assuming every model needs the same share of the host.

Trap Using endpoint traffic weights as GPU-memory reservations, which changes request routing rather than specifying a model's accelerator and memory requirements.

A model does not need a SageMaker AI training job to be hosted by SageMaker AI. For an externally trained model supported by an AWS-provided inference container, supply the model artifacts in Amazon S3 and select a compatible framework and version. The hosting configuration also needs a SageMaker AI execution role with access to the required resources.

Trap Retraining an otherwise compatible model solely to obtain a SageMaker AI training-job record, which is not a prerequisite for deployment.

The S3 bucket containing a SageMaker AI model's artifacts must be in the same AWS Region as the model being created. When moving an externally trained model to another Region, place the artifacts in an appropriate regional bucket before creating the hosting model.

Trap Granting broader S3 permissions to compensate for a cross-Region artifact bucket, which changes authorization but not the regional deployment requirement.

When a supported foundation-model architecture has been customized outside Amazon Bedrock and managed Bedrock inference is required, use Custom Model Import. Compatibility with the documented architecture and configuration is a prerequisite; this is an import of model weights, not a generic container-hosting service. Imported models can be invoked with on-demand inference.

Trap Uploading an arbitrary inference Docker image to Custom Model Import, which expects compatible model artifacts rather than a general-purpose serving container.

For a Custom Model Import job whose source is Amazon S3, prepare the model files in Hugging Face weights format and give the import service role access to them. Cross-account buckets and KMS keys require corresponding access grants. A correct file format does not substitute for permission to read or decrypt the source.

Trap Granting only model-invocation permission to the import job role, which authorizes inference rather than reading the source artifacts.

When an existing Kubernetes deployment already packages ML services as standalone container images, publish those images to Amazon ECR and deploy them to the specified Amazon EKS cluster. Reference the complete ECR image location and provide image-pull permissions. Moving the hosting platform does not itself require changing the trained model or rewriting the workflow into another ML framework.

Trap Rebuilding the services in a new ML orchestration framework for a lift-and-shift requirement, which adds application changes that the existing container deployment does not need.

When a supported Bedrock model needs dedicated capacity and consistent throughput, use Provisioned Throughput. On-demand inference is the alternative when usage-based access without a provisioned-capacity commitment meets the workload requirements. Verify the chosen model and Region support the intended provisioning option.

Trap Selecting batch inference to reserve capacity for synchronous application requests, which creates asynchronous jobs instead of a dedicated online serving resource.

When a large collection of prompts can be processed asynchronously, submit a Bedrock batch inference job with input files in Amazon S3 and collect the output files from S3. Each input record is processed independently. This mode is not suited to tool-calling conversations that require exchanges between the model and the client.

Trap Submitting an interactive agent tool-use conversation as a batch job, which cannot perform the required back-and-forth tool interactions.

Deleting a Bedrock custom model deployment removes that on-demand serving resource but does not delete its underlying custom model. If inference is needed again, create a new deployment from the retained model. This separates serving-resource cleanup from model retention.

Trap Deleting the underlying custom model to stop using one deployment, which removes the retained model rather than only its serving resource.

When the stated deployment permits inference across multiple AWS Regions, a system-defined Bedrock cross-Region inference profile can distribute supported model requests among its defined Regions. The application invokes the profile instead of managing separate regional model invocations itself. Choose a profile whose routing scope meets the application's location requirements.

Trap Using an arbitrary single-Region model identifier to obtain multi-Region routing, which does not select a cross-Region inference profile.

When a reusable foundation model must run with explicitly selected SageMaker AI hosting compute and deployment settings, choose a compatible model from SageMaker JumpStart and deploy it to a SageMaker AI endpoint. JumpStart supplies pretrained models while SageMaker AI provides configurable managed hosting. Choose Amazon Bedrock's serverless model access instead when the requirement is to invoke a supported foundation model through an API without selecting and managing its serving infrastructure.

When a conversational application must use a consistent message-based invocation contract across supported Amazon Bedrock models, use Converse, or ConverseStream when responses must stream. This lets the application reuse its message-handling code across models that support the interface instead of adopting each model's base inference request format. Model-specific inference options can still be supplied separately, so a shared interface does not make every model's capabilities identical.

Trap Using InvokeModelWithResponseStream as the cross-model message abstraction because it streams output, although its request body still follows the selected model's inference format.

When a required foundation model is offered through Amazon Bedrock Marketplace, subscribe to the catalog model and deploy it to a SageMaker AI-managed endpoint. Select the endpoint's instance type and instance count rather than treating this as ordinary serverless Bedrock model access. Invoke the deployment through Bedrock InvokeModel, or Converse for compatible models, using the endpoint ARN to identify the deployment.

Trap Using Custom Model Import to activate a Marketplace catalog subscription, although import requires model artifacts from an external customization environment rather than a catalog subscription.

When existing agent code needs managed deployment, Amazon Bedrock AgentCore Runtime supports agents built with supported frameworks or custom agent implementations. It is not restricted to foundation models accessed through Amazon Bedrock. This lets a deployment preserve its chosen agent framework and model integration within the Runtime service contract.

Trap Rewriting a working agent to a different framework solely to use AgentCore Runtime, which is framework agnostic.

When an agent must use an existing Lambda function or an API described by an OpenAPI specification, AgentCore Gateway can expose that backend through tools compatible with Model Context Protocol. The gateway adapts access to the existing capability; it does not replace the backend's business logic.

Trap Importing API documentation into a knowledge base as a substitute for a tool integration, which makes descriptions retrievable but does not execute the backend action.

Use Model Context Protocol when an AgentCore-hosted service exposes tools to agent clients. Use the Agent-to-Agent protocol when the requirement is agent discovery and communication between agents. AgentCore Runtime supports both protocols, but a tool server and a collaborating agent are different integration roles.

Trap Selecting an MCP tool-listing interface as an A2A agent-discovery interface, which substitutes tool discovery for the agent communication contract.

AgentCore Runtime supports inbound authentication for clients invoking an agent and outbound authentication for the agent accessing other services. Configure each path for its caller and target, including delegated user access when required. Successful authentication into the agent does not itself establish the agent's credentials for a third-party tool.

Trap Reusing the existence of an inbound authenticated session as proof of downstream API authorization, which leaves the tool's outbound authentication requirement unresolved.

An AgentCore Runtime application must expose the endpoints and message format required by its selected protocol. For example, HTTP request handling and an MCP tool server follow different contracts. Configure the runtime protocol and the application's server consistently rather than deploying a container that merely starts successfully.

Trap Choosing the HTTP runtime protocol for an application that exposes only an MCP server, which mismatches the runtime's expected request interface.

An Amazon Bedrock Agents Classic action group defines available actions and their inputs through an OpenAPI schema or function details. Configure Lambda execution when Bedrock should pass the selected action and elicited parameters to a Lambda function. Choose return control when the calling application should execute the action instead; Bedrock returns the selected action and parameters in the agent invocation response. The schema describes the available operation, while the chosen execution path supplies its implementation.

Trap Using an AgentCore Gateway tool definition as the Bedrock Agents Classic action-group configuration, even though Gateway adapts backends into MCP tools rather than defining this agent's action group.

For client-side tool calling in Amazon Bedrock, supply tool definitions with the model request so the model can select a tool and return the inputs it needs. Application code then executes the requested tool and sends its result back in the conversation, allowing the model to continue generation using that result. This model-level interaction is distinct from configuring fulfillment for a Bedrock Agents Classic action group. In supported server-side tool-use configurations, Bedrock executes registered tools on the application's behalf instead; execution ownership depends on the selected mode.

When an existing Amazon Bedrock Agents Classic deployment should answer from a Bedrock knowledge base, associate that knowledge base with the agent and provide instructions describing its contents and when to query it. The agent includes these instructions in its prompt context to decide whether retrieval is appropriate for the user's request. Creating and populating the knowledge base alone does not establish this agent integration. Prepare the agent after changing its configuration before testing the retrieval behavior.

Trap Adding an action-group schema as the native knowledge-base integration, although action definitions describe operations and inputs rather than establishing the agent's knowledge-base association.

When an existing Amazon Bedrock Agents Classic deployment must analyze uploaded files, produce visualizations, or perform calculations, enable code interpretation so the agent can generate and run code in a secure test environment. The agent can return results from actual execution rather than only generating code text. Enable Code Interpreter in the agent builder, then save and prepare the agent before testing the changed configuration.

Trap Using an action group's return-control mode as a managed code executor, although that mode sends the selected action and inputs back to application code for fulfillment.

When knowledge-base queries need both meaning-based matching and raw-text matches, configure hybrid search on a supported vector store with a filterable text field. Semantic search uses vector embeddings alone. Verify the existing store and text-field configuration support hybrid retrieval instead of assuming every vector index can execute it.

Trap Adding a reranker as a substitute for raw-text retrieval when lexical candidates are missing, which only reorders the candidates already retrieved.

Use the Bedrock Knowledge Bases Retrieve operation when the application needs relevant source chunks but will manage generation itself. Use RetrieveAndGenerate when Bedrock should retrieve context and generate an answer with citations. This choice determines whether the managed knowledge-base call owns only retrieval or the combined retrieval-and-generation path.

Trap Calling Retrieve and expecting a synthesized answer with generated citations, which adds a generation responsibility that the retrieval-only operation does not perform.

When retrieval finds candidate documents but their ordering is insufficient, configure a supported reranking model in the Bedrock knowledge-base query. The reranker assesses retrieved candidates for relevance before the selected context is used. It refines retrieval results rather than changing the generation model's sampling behavior.

Trap Lowering generation temperature to improve document ranking, which changes response sampling rather than the ordering of retrieved candidates.

When answers must use documents from a specified department, date range, or category, apply a Bedrock knowledge-base metadata filter. The document metadata must be ingested and supported by the vector store. Filtering constrains the eligible results rather than merely requesting that the language model ignore unwanted sources after retrieval.

Trap Adding a department instruction only to the generation prompt, which does not constrain the documents returned by the retrieval query.

Bedrock knowledge-base retrieval returns up to the configured number of results. With hierarchical chunking, the limit counts retrieved child chunks, and children sharing a parent can be consolidated into the parent chunk in the response. Consequently, fewer final results can be correct behavior even when the requested limit is higher.

Trap Treating parent-chunk consolidation as missing indexed documents, which mistakes retrieval assembly for an ingestion failure.

When one knowledge-base query combines multiple information needs, enable query decomposition to break it into smaller subqueries. Bedrock can execute several retrieval queries and use their results to form the final response. This addresses a broad or compound query rather than simply requesting more candidates for the unchanged query.

Trap Increasing the retrieval result limit as a substitute for separating multiple information needs, which still searches with the original compound query.

When users express document constraints in natural language, Bedrock Knowledge Bases can use a supported model and a supplied metadata schema to generate retrieval filters. Describe the available metadata attributes so the model can map user intent to actual fields. Explicit filters remain appropriate when the application already knows the required filter values.

When a RAG response path requires Bedrock Guardrails, configure the chosen guardrail identifier and version for knowledge-base response generation. This applies the specified controls to that generation path rather than relying only on prompt wording. Verify that the intended model and guardrail features are supported together.

Trap Adding safety instructions to a prompt as an equivalent to attaching the configured guardrail, which does not enable the managed guardrail controls.

For an existing Amazon SageMaker Model Monitor deployment, enable inference data capture, establish baseline statistics and constraints, and configure a monitoring schedule. Capture supplies observations in Amazon S3; the scheduled analysis compares those observations with the baseline and reports violations.

When a deployed model was deliberately updated for a new validated dataset, regenerate the monitoring baseline from that dataset and update the monitoring schedule to use its statistics and constraints. An old baseline can flag expected changes as violations. Investigate unexpected production drift rather than automatically redefining it as normal.

Trap Retuning model hyperparameters to correct alerts caused by a stale comparison baseline, although hyperparameters do not update the monitor's reference data.

Amazon SageMaker Model Monitor expects the baseline and inference datasets to agree on feature count and order. Align the captured input with the training feature schema before interpreting violations. A reordered or additional column can make the monitor compare different features rather than detect a genuine distribution change.

Trap Increasing drift tolerances after a preprocessing column-order change, which relaxes checks without repairing the feature correspondence.

Amazon SageMaker Model Monitor computes built-in statistics and metrics on tabular data. For an image classifier, its tabular prediction outputs can be monitored, but the built-in analysis does not calculate distribution statistics directly over raw image inputs. Image-input drift requires a suitable separate analysis pipeline.

Trap Selecting the built-in tabular analyzer to compare raw image pixel distributions, although that analyzer operates on tabular features.

When predictions are generated by recurring Amazon SageMaker AI batch transform jobs, capture their inputs and outputs and run monitoring against that captured data. Existing Model Monitor customers can monitor batch transform as well as real-time inference. Batch transform support does not extend to every endpoint type: Model Monitor still cannot monitor a multi-model endpoint.

Trap Migrating recurring offline predictions to a permanently running real-time endpoint solely to obtain monitoring, although batch transform data capture is supported.

Amazon SageMaker Model Monitor supports inference pipelines, but its capture and analysis apply to the entire pipeline rather than each container independently. Use the pipeline boundary data for overall quality checks. Diagnosing an intermediate transformation requires additional visibility into that stage.

Trap Using the pipeline's standard capture output as an intermediate-container trace, although capture occurs at the whole-pipeline boundary.

Amazon SageMaker AI data capture stops capturing requests at high disk utilization to avoid affecting inference requests. If endpoint invocations continue but captured records disappear, inspect disk utilization before interpreting the gap as a traffic change. AWS recommends keeping disk utilization below 75 percent for continued capture.

Trap Recreating the drift baseline to repair missing capture records, although baseline generation does not relieve endpoint disk pressure.

When Model Monitor is unavailable to a new customer, adapt one of the AWS-published open-source SageMaker AI monitoring solutions, such as the Real-Time Inference Monitoring with Evidently AI + SNS solution, within the existing deployment. Capture production inference observations and configure its scheduled SageMaker Processing analysis to compare recent data with a reference dataset using statistical drift tests. Set the monitoring window, relevant features, and drift thresholds for the workload, retain the resulting metrics and reports, and connect threshold violations to Amazon SNS notifications. This makes distribution monitoring an operational pipeline without depending on a Model Monitor monitoring schedule.

Trap Using endpoint CPU utilization and invocation-error alarms as the distribution-drift detector, because operational health metrics do not compare production feature distributions with reference data.

Amazon SageMaker Model Monitor does not support endpoints that host multiple models, even for customers eligible to keep using the service. A workload that must retain a multi-model endpoint therefore needs another compatible monitoring approach. Support for an inference pipeline is a separate capability and does not make multi-model endpoint monitoring eligible.

When an existing Model Monitor deployment must measure production predictive quality, supply ground-truth labels and compare them with captured predictions. Accuracy and similar supervised metrics require known outcomes. Data-quality monitoring instead checks feature statistics and constraints and can operate before outcome labels arrive.

Trap Choosing data-quality constraints to measure prediction accuracy when outcome labels are available, although those constraints describe input data rather than prediction correctness.

Amazon SageMaker Model Monitor merges ground truth with captured predictions using a unique record identifier. A caller-supplied inference identifier takes precedence when present; otherwise the captured event identifier is used. Preserve the matching identifier when outcomes arrive later so quality measurements compare each prediction with its own outcome.

Trap Joining labels to predictions by upload order, although delayed labels need not arrive in prediction order.

Model Monitor ground-truth labels are uploaded to Amazon S3 as JSON Lines in time-organized paths. The path date represents label collection time and need not equal the original inference date. Configure the monitoring job with the ground-truth location rather than assuming labels are embedded in the original capture files.

Trap Discarding later-arriving labels because their S3 date differs from the prediction date, although label collection and inference can occur at different times.

For existing Amazon SageMaker Clarify customers, bias drift monitoring evaluates bias metrics on live prediction data and can expose changes after deployment. A model that passed a training-time bias assessment can behave differently when its production population changes. Use bias metrics and appropriate thresholds to monitor this behavior rather than relying only on aggregate accuracy.

SageMaker Clarify bias-drift monitoring compares the bias metric's confidence interval with the allowed range. An alert is raised when the intervals do not overlap, rather than simply whenever the sample estimate lies outside the allowed range. This reduces alerts caused by noisy estimates from small monitoring windows.

Trap Using a single out-of-range sample estimate as proof of a Clarify bias violation, although the confidence interval may still overlap the allowed range.

When the concern is a change in which features influence a deployed model, existing SageMaker Clarify customers can use feature-attribution drift monitoring. It compares live feature-attribution rankings with a baseline while accounting for baseline importance. This identifies changed prediction drivers even when a general input-quality check does not explain the behavior.

In an existing SageMaker Clarify workflow, launch a processing job programmatically when post-training bias analysis is needed on demand. Configure the input dataset, output location, model or endpoint, and bias-analysis settings, then launch the post-training bias analysis. This is an explicitly submitted analysis job rather than a recurring monitoring schedule.

Trap Launching only pre-training bias analysis when the requirement is to assess bias in a trained model's predictions.

In an existing Amazon SageMaker Model Monitor setup, connect the emitted monitoring metrics to Amazon CloudWatch alerting for the selected quality thresholds. Scheduled checks produce the evidence; alarms turn qualifying deviations into notifications. Merely storing a report in Amazon S3 does not configure operator notification.

Trap Treating successful report generation as configured alert delivery, because the notification behavior requires the monitoring and alarm integration.

When comparing model candidates with live traffic, deploy Amazon SageMaker AI production variants and assign their relative traffic weights. Each variant can have its own model and instance configuration. Weighted routing sends each request to a selected variant so its response participates in the production experiment.

Trap Assigning more instances to a candidate as the traffic-split control, although instance count controls capacity and variant weights control weighted routing.

When requests from a controlled cohort must reach a specific Amazon SageMaker AI production variant, specify the target variant in the invocation. Explicit targeting takes precedence over the endpoint's traffic weights. Weighted routing is appropriate when the service should choose the variant instead.

Trap Relying on random traffic weights to keep a particular customer's requests on one variant, although weights do not encode that cohort assignment.

Amazon SageMaker AI responses identify the production variant that served the request, and CloudWatch exposes variant-level invocation and latency metrics. Retain that variant identity when comparing prediction-quality outcomes and operational behavior. Endpoint-wide averages blend the candidates and can conceal a poorly performing variant.

Trap Choosing the winning model from a single endpoint-wide latency average, which mixes observations from both candidates.

After observing better performance from an Amazon SageMaker AI production variant, update the existing variants' desired weights to send it more traffic. The weights-and-capacities update changes the distribution without replacing the endpoint configuration. Continue observing performance as exposure increases before removing the old variant.

Trap Creating a second endpoint solely to alter the traffic split between already deployed variants, although the existing endpoint supports weight updates.

For Amazon Bedrock streaming inference, time to first token measures how long a user waits for output to begin, while invocation latency extends to the last token. Monitor the former for perceived responsiveness and the latter for full-response completion. A longer generated answer can increase completion latency without a corresponding increase in the initial wait.

Trap Using full-response invocation latency alone to assess how quickly streaming output starts, although it includes the remaining generation time.

Amazon Bedrock's invocation count includes accepted requests that later produce client or server errors, but excludes throttled requests and requests rejected before processing during input validation. Throttles have their own metric and are not also counted as client or server errors. Interpret these categories separately when investigating inference reliability.

Trap Treating every failed attempt as a server error, which confuses rejected traffic, invalid requests, and failures after acceptance.

When a production foundation model returns timely but poor answers, use Amazon Bedrock evaluations on prompts representative of the application. CloudWatch runtime metrics describe operational behavior; evaluation jobs assess response effectiveness. A successful API response is not evidence that its content answers the user's question correctly.

Trap Using a low API error rate as the acceptance test for answer quality, although transport success does not assess response correctness.

When ongoing response assessment needs automated qualitative scoring, use an Amazon Bedrock model-evaluation job with a judge model. A second language model assesses the candidate's responses and provides scores with explanations. Select evaluation criteria and representative prompts that reflect the application's requirements.

When acceptable production responses depend on expert judgment or user preference, use Amazon Bedrock human-based model evaluation. Employees or domain specialists can rate responses against the chosen criteria. This adds human assessment where programmatic metrics alone do not capture the requirement.

Amazon Bedrock retrieve-only evaluations assess whether retrieved passages are relevant to the question and whether they cover the expected information. Context coverage requires ground-truth text in the evaluation dataset. Use these retrieval metrics when the suspected production failure occurs before answer generation.

Trap Evaluating only generated-answer fluency when investigating missing source passages, although fluent wording does not show whether retrieval found the required evidence.

Amazon Bedrock retrieve-and-generate evaluations include faithfulness, which measures whether the response avoids hallucinations relative to retrieved text. Correctness instead assesses how accurately the response answers the question. A response can be relevant and fluent while introducing claims unsupported by the retrieved evidence.

Trap Using retrieval context relevance as the only measure of answer faithfulness, although a model can invent details after receiving relevant passages.

Amazon CloudWatch generative AI observability provides prebuilt views for investigating generative AI workloads rather than requiring every monitoring view to be assembled from scratch. Its Model Invocations dashboard combines model usage, token consumption, latency, errors, and a curated invocation-log table that shows input and output content once Amazon Bedrock model invocation logging sends logs to CloudWatch Logs. End-to-end prompt tracing, curated metrics, and logs help correlate an application symptom with the responsible model, retrieval, or tool operation when the required telemetry is available.

Trap Using Amazon Bedrock model evaluation alone to investigate a live invocation's latency and errors, because response-quality scoring does not provide the correlated operational request path.

Use privacy-controlled production prompts, failed answers, and explicit user ratings to refresh representative evaluation cases for a foundation-model application. Review and correct those cases against reliable ground truth rather than treating generated answers or ratings as verified answers. Recurring failures can reveal changed user questions, unclear prompts, or missing retrieval knowledge, guiding prompt adjustments or retrieval-data updates and subsequent evaluation. Protect customer interactions under the applicable privacy and regulatory requirements before reusing them.

Trap Reaching immediately for model fine-tuning when failed answers concern a newly released product, because updating missing retrieval information may address the knowledge gap without changing model weights.

When a production agent fails during a sequence of model and tool calls, inspect the execution path and intermediate outputs in Amazon Bedrock AgentCore Observability. Step-level traces identify where coordination diverged or a tool operation failed. An end-to-end error count indicates frequency but does not identify the failed dependency.

Amazon Bedrock AgentCore emits built-in operational metrics, while additional application spans and traces require agent-code instrumentation. Enable the necessary observability outputs and instrument internal operations when debugging tool calls or multi-step coordination. OpenTelemetry-compatible telemetry supports correlation with the rest of the monitoring stack.

Trap Enabling a runtime metric dashboard as the only change needed for custom tool-level traces, although internal operations still require instrumentation.

Amazon Bedrock ConverseStream reports why a message stopped. Reaching the output-token limit indicates a length-limited answer; a tool-use stop indicates that the application must handle the tool request; a guardrail intervention indicates filtering. Inspect the stop reason before treating every ended stream as a completed answer.

Trap Treating a tool-use stop as a network truncation and retrying generation, although the model is requesting a tool interaction.

Streaming inference can encounter an error after the initial response has already been sent. Amazon SageMaker AI exposes a mid-stream error metric for these failures. Monitor stream completion and streaming errors rather than recording success solely from the initial response.

Trap Counting every stream with a successful initial status as a successful inference, which misses errors after streaming has begun.

For transient failures in an AWS Step Functions task, configure retries with increasing delays and a finite attempt limit. A matching catch handler provides a recovery path when the error remains after retry handling. This separates temporary service failures from failures that need explicit fallback or investigation.

Trap Routing the first transient failure directly to a permanent-failure branch, which bypasses the configured opportunity for recovery.

When many agent or inference tasks fail together, use jitter in AWS Step Functions retry delays to spread subsequent attempts over time. Exponential backoff increases the delay between retries, while jitter randomizes when each retry occurs. Combining them reduces the chance that clients repeatedly retry in lockstep.

Trap Giving every failed task the same fixed retry interval, which keeps recovery attempts synchronized.

For an agent or processing step orchestrated by AWS Step Functions, configure a task timeout and a matching recovery path so a stalled operation does not wait indefinitely. Heartbeat monitoring can detect a worker that stops reporting progress in workflows that use heartbeats. Route the resulting failure to the appropriate handler rather than counting the unfinished task as healthy.

Trap Increasing the retry count to detect an operation that never returns, although retries begin only after an error is reported.

Amazon SageMaker AI publishes pipeline execution metrics and separate step metrics for failures, successes, and duration. Use the pipeline and step dimensions to identify the stage responsible for a processing or inference-workflow regression. Overall execution duration alone cannot identify which step changed.

Trap Scaling the inference endpoint after seeing only a longer pipeline duration, although the delay may be in an upstream processing step.

Amazon Bedrock AgentCore runtime application logs include invocation request payloads and correlation identifiers but do not capture the agent response. If investigating incorrect returned content requires output visibility, instrument the application to record the necessary response information under the approved data-protection policy. A request payload in the runtime log is not evidence that the corresponding response was also captured.

Trap Searching only the built-in runtime application log for the generated response, although those records do not include a response payload.