Core ML Concepts

Before selecting any AWS service or algorithm, an ML engineer must correctly identify the type of problem they are solving. This foundational decision determines everything downstream, from which Amazon SageMaker built-in algorithm to deploy to which evaluation metric to track in production. The AWS Certified Machine Learning Engineer – Associate exam tests this skill repeatedly, expecting candidates to map business requirements to the right ML paradigm before touching any infrastructure.

This lesson covers five interconnected concepts that form the backbone of every ML system. You will learn to distinguish supervised learning from unsupervised learning, differentiate regression from classification, understand how clustering discovers structure in unlabeled data, diagnose overfitting and underfitting by comparing training and validation performance, and navigate the bias-variance trade-off that governs model-complexity decisions. Each concept maps directly to specific SageMaker built-in algorithms, such as Linear Learner for regression and classification, XGBoost for structured tabular data, and k-means for clustering, as well as evaluation metrics such as the F1 score and RMSE, which SageMaker Model Monitor can track in production.

Getting these decisions wrong is costly. Framing a regression problem as a classification problem, or deploying an overfit model to production, leads to wasted compute, unreliable predictions, and failed business outcomes.

Supervised vs. unsupervised learning

The first decision in any ML project is whether the available data has labels. This factor determines the modeling approach and the set of SageMaker algorithms available for training.

How supervised learning works

Supervised learning trains a model on a labeled data set in which each input example is paired with a known output. During training, the algorithm adjusts its internal parameters to minimize the difference between its predictions and the true labels. Once trained, the model generalizes these learned patterns to make predictions on new, unseen data.

In the AWS ecosystem, supervised learning workflows typically begin with labeled data stored in Amazon S3. An AWS Glue job can clean and catalog this data before a SageMaker training job consumes it. SageMaker’s Linear Learner and XGBoost algorithms are the primary built-in options for supervised tasks on structured data. Linear Learner supports both regression and binary classification modes, while XGBoost handles multiclass classification and regression with strong performance on tabular data sets.

Practical tip: On the exam, if a question describes a data set with known outcomes (for example, historical fraud labels or past sales figures), the answer almost always involves supervised learning.

How unsupervised learning works

Unsupervised learning operates on data without predefined labels. Instead of predicting a known output, the algorithm discovers hidden patterns, groupings, or anomalies within the data itself. SageMaker’s k-means algorithm groups similar data points into clusters, while Random Cut Forest (RCF)A SageMaker built-in algorithm that detects anomalous data points by measuring how much a point’s inclusion changes the structure of a randomly constructed forest of trees. identifies outliers in streaming or batch data.

Consider a retail company using AWS. For demand forecasting, where historical sales figures serve as labels, the team selects XGBoost in supervised mode. For customer segmentation, where no predefined groups exist, the same team uses k-means to discover natural groupings in purchase-behavior data. Both workflows pull data from S3, but the presence or absence of labels drives the algorithm choice.

The following markmap provides a structured view of how these paradigms branch into specific problem types and their corresponding SageMaker algorithms.

With the paradigm distinction established, the next step is understanding the two major supervised learning output types.

Regression vs. classification

Both regression and classification fall under supervised learning, but they differ fundamentally in what the model outputs. Confusing the two leads to selecting the wrong algorithm, loss function, and evaluation metric, all of which the exam tests directly.

Regression predicts a continuous numerical value. When a business asks “how much” or “how many,” the problem is regression. Predicting the dollar amount of a customer’s next purchase, forecasting monthly revenue, or estimating temperature all produce continuous outputs. Regression models are evaluated using metrics like RMSE (Root Mean Squared Error)A metric that measures the average magnitude of prediction errors by taking the square root of the mean of squared differences between predicted and actual values, penalizing larger errors more heavily. and MAE (Mean Absolute Error).

Classification assigns inputs to discrete categories. When the business question is “which category” or “yes/no,” the problem is classification. Detecting fraudulent transactions, predicting customer churn, or categorizing support tickets all produce categorical outputs. Classification models are evaluated using the F1 score, precision, recall, and AUC.

In SageMaker, Linear Learner supports both modes. You configure the algorithm’s predictor_type hyperparameter as either regressor or binary_classifier. XGBoost similarly handles both by setting the objective parameter to reg:squarederror for regression or binary:logistic for classification. SageMaker Model Monitor can then track the appropriate metric in production, triggering CloudWatch alarms when RMSE drifts for regression models or when the F1 score degrades for classifiers.

The following table provides a quick-reference comparison for distinguishing these two task types.

With supervised learning’s two output types clarified, the next concept addresses what happens when no labels exist at all.

Clustering fundamentals

Clustering is an unsupervised technique that groups similar data points based on feature similarity, without any predefined labels guiding the process. It sits at the exploratory end of the ML pipeline and often serves as a precursor to supervised modeling.

Common use cases include customer segmentation for targeted marketing campaigns, grouping application logs for operational insights, and building recommendation systems. In each case, the algorithm receives raw, unlabeled feature vectors stored in Amazon S3 and produces cluster assignments as output.

SageMaker’s built-in k-means algorithm is the primary tool for clustering tasks. A SageMaker training job ingests data from S3, iteratively assigns data points to the nearest centroidThe center point of a cluster, computed as the mean of all data points assigned to that cluster, which shifts during training until assignments stabilize., and updates centroid positions until convergence. The number of clusters, $k$, is a critical hyperparameter. Setting $k$ too low merges distinct groups, while setting it too high fragments meaningful segments. SageMaker Hyperparameter Optimization (HPO) can automate the search for an optimal $k$ by running multiple training jobs with different values and selecting the configuration that minimizes the objective metric.

A key difference from supervised methods is that clustering results require human interpretation. There are no ground-truth labels to compute accuracy against. Domain experts must examine the resulting clusters and assign business meaning, such as labeling one cluster as “high-value repeat customers” and another as “price-sensitive one-time buyers.”

Note: Clustering often feeds into supervised workflows. A team might first segment customers using k-means, then build separate classification models for each segment to predict churn, improving overall prediction quality.

The following diagram illustrates how k-means transforms unstructured data into actionable groupings.

Understanding clustering completes the picture of ML problem types. The next section shifts focus from what type of model to build to how well that model performs.

Overfitting, underfitting, and bias-variance

Even after selecting the correct ML paradigm and algorithm, a model can still fail in production if its complexity is poorly calibrated. Two failure modes dominate this space, and the bias-variance trade-off provides the theoretical framework for understanding them.

Diagnosing overfitting and underfitting

Overfitting occurs when a model becomes so complex that it memorizes noise and idiosyncrasies in the training data rather than learning generalizable patterns. The telltale signature is high training accuracy paired with significantly lower validation or test accuracy. In SageMaker, this can show up as a widening gap between training loss and validation loss, tracked in CloudWatch metrics during a training job.

Underfitting is the opposite failure mode. The model is too simple to capture meaningful relationships in the data, resulting in poor performance on both the training and validation sets. Both loss curves remain high and flat, indicating that the model lacks the capacity to learn the underlying patterns.

Diagnosing these issues requires comparing two numbers: training error and validation error.

• Large gap (low training error, high validation error): This pattern signals overfitting, where the model has memorized training examples but cannot generalize.

• Both errors high: This pattern signals underfitting, where the model lacks sufficient complexity to represent the data’s structure.

• Both errors low and close together: This is the target state, indicating that the model generalizes well.

The bias-variance trade-off

The bias-variance trade-offA fundamental ML concept describing the tension between a model's ability to fit training data closely (low bias, high variance) and its ability to generalize to unseen data (high bias, low variance), where the optimal model minimizes total error from both sources. provides the theoretical lens for these observations. Bias measures how far a model’s average predictions are from the true values, reflecting the error introduced by simplifying assumptions. Variance measures how much predictions fluctuate across different training sets, reflecting sensitivity to data noise.

High bias produces underfitting. A linear model applied to a highly nonlinear relationship will consistently miss the true pattern regardless of how much data it sees. High variance produces overfitting. A deep decision tree with no depth limit will perfectly trace every training point but produce wildly different predictions on new data.

Total prediction error can be expressed as:

Because irreducible noise is fixed, the engineer’s job is to minimize the sum of bias squared and variance.

Practical remedies in SageMaker

Addressing these issues maps directly to specific SageMaker capabilities and modeling techniques.

• For overfitting: Apply regularization (L1/L2 penalties in Linear Learner), use early stopping to halt training when validation loss stops improving, increase training data volume, or reduce model complexity by limiting tree depth in XGBoost.

• For underfitting: Increase model complexity by adding more layers or features, improve feature engineering using SageMaker Data Wrangler, or switch to a more expressive algorithm, such as moving from Linear Learner to XGBoost.

• For automated tuning: SageMaker HPO runs multiple training jobs across hyperparameter ranges, selecting the configuration that optimizes the validation metric, effectively searching for the sweet spot between bias and variance.

In production, SageMaker Model Monitor can continuously evaluate deployed model performance against baseline metrics. When data drift causes a previously well-calibrated model to overfit or underfit on new data distributions, Model Monitor can trigger CloudWatch alarms, enabling the engineering team to retrain before business impact occurs.

Practical tip: On the exam, if a question mentions “training accuracy is much higher than validation accuracy,” the answer involves overfitting remedies like regularization or early stopping, not adding more features or increasing model complexity.

The following diagram visualizes the three states of model complexity and their relationship to the bias-variance trade-off.

Conclusion

This lesson established five foundational decisions that every ML engineer must make before writing a single line of training code. Supervised vs. unsupervised learning determines whether labeled data is required. Regression vs. classification depends on whether the output is a continuous value or a discrete category. Clustering discovers structure in unlabeled data but requires domain expertise to interpret. Overfitting and underfitting are diagnosed by comparing training and validation loss curves. The bias-variance trade-off provides the theoretical framework for calibrating model complexity, with SageMaker HPO automating the search for optimal hyperparameters and SageMaker Model Monitor helping maintain reliability after deployment. Each of these decisions maps directly to a specific SageMaker built-in algorithm and evaluation metric, making them high-frequency exam topics. With these core concepts established, you are now ready to explore model selection strategies, where the focus shifts to choosing between linear models, tree-based models, and deep learning based on real-world constraints such as data size, interpretability requirements, and infrastructure costs.