Auto Scaling SageMaker Endpoints for Cost Optimization
A team is deploying a SageMaker endpoint for a model that was trained with scikit-learn. The endpoint receives spikes in traffic during business hours. The team wants to minimize cost while ensuring availability during spikes. Which endpoint configuration is MOST appropriate?
Quick Answer
The correct choice is a production variant endpoint with auto-scaling based on CPU utilization. This configuration directly addresses the challenge of auto scaling SageMaker endpoint cost spikes by dynamically adjusting instance count in response to real-time load, scaling up during business hours to maintain availability and scaling down during off-peak periods to minimize cost. Since scikit-learn models are CPU-bound, CPU utilization is the most relevant metric for triggering scaling actions, ensuring the endpoint handles traffic spikes efficiently without over-provisioning. On the AWS Certified Machine Learning Specialty MLS-C01 exam, this scenario tests your understanding of SageMaker production variants and auto-scaling policies, often appearing as a trap where candidates mistakenly choose GPU-based scaling or manual instance management. A key memory tip: for CPU-bound models like scikit-learn, think “CPU for compute” to avoid selecting memory or GPU metrics, and remember that production variants allow separate scaling policies per model version.
⚠ Common exam trap
Candidates often confuse serverless inference with cost optimization for predictable spikes, overlooking that auto-scaling with a relevant metric like CPU utilization provides both cost efficiency and availability for scheduled traffic patterns.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Use a production variant endpoint with auto-scaling based on CPU utilization
A production variant endpoint with auto-scaling based on CPU utilization allows the SageMaker endpoint to dynamically adjust the number of instances in response to traffic spikes, ensuring availability during business hours while minimizing cost by scaling down during off-peak periods. This approach is ideal for a scikit-learn model, which is CPU-bound, making CPU utilization a relevant and effective scaling metric.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Use SageMaker Serverless Inference
Why it's wrong here
Serverless may have cold starts and concurrency limits affecting availability.
- ✓
Use a production variant endpoint with auto-scaling based on CPU utilization
Why this is correct
Auto-scaling handles traffic spikes efficiently.
- ✗
Use a multi-model endpoint with a single instance type
Why it's wrong here
Multi-model endpoint does not auto-scale for traffic spikes.
- ✗
Deploy a single large instance that can handle peak load
Why it's wrong here
A single large instance is costly and may be underutilized.
Go deeper
Related to this question
About these practice questions
One of 1,672 original MLS-C01 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
Same concept, more angles
1 more way this is tested on MLS-C01
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. A startup is deploying a machine learning model for real-time recommendation on Amazon SageMaker. The model is a TensorFlow model (1 GB) and the endpoint uses a single ml.c5.2xlarge instance. The inference latency is currently 500 ms per request. The startup expects traffic to increase 10x in the next month. They want to maintain latency under 500 ms. What is the most cost-effective solution?
easy- A.Use SageMaker Batch Transform to process requests in batches
- B.Switch to a GPU instance type for faster inference
- ✓ C.Set up auto-scaling for the endpoint based on average latency or request count
- D.Upgrade to a larger CPU instance type, such as ml.c5.4xlarge
Why C: Auto-scaling dynamically adds instances based on demand, handling a 10x increase in traffic while maintaining latency under 500 ms. This is more cost-effective than over-provisioning a larger instance (D) or switching to an expensive GPU instance (B). SageMaker Batch Transform (A) is not suitable for real-time inference.
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This MLS-C01 practice question is part of Courseiva's free Amazon Web Services certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the MLS-C01 exam.