4.1.3. Containers: Pre-built vs. BYOC

💡 First Principle: SageMaker runs all training and inference inside containers. You either use AWS-provided pre-built containers (for supported frameworks) or bring your own container (BYOC) for custom frameworks. The exam tests when each approach is appropriate and what BYOC requires.

Pre-built containers exist for major frameworks: TensorFlow, PyTorch, MXNet, scikit-learn, XGBoost, Hugging Face. These containers are maintained by AWS, include necessary dependencies, and integrate with SageMaker's training/hosting infrastructure automatically. Use pre-built containers whenever possible—they save setup time and receive security patches.

Script Mode uses a pre-built container but lets you supply your own training/inference script. This is the sweet spot: you get the framework container without building it yourself, but you control the model code. If a question mentions "custom training logic with PyTorch," the answer is Script Mode with the PyTorch pre-built container.

BYOC is necessary when you need a framework SageMaker doesn't provide pre-built containers for (e.g., R, Julia), custom dependencies that conflict with the pre-built container, or proprietary code that must run in a specific environment. BYOC containers must implement specific interfaces (for SageMaker to call train and serve).

⚠️ Exam Trap: BYOC is the last resort, not the first choice. If a question describes a "custom PyTorch model," the answer is Script Mode with the PyTorch pre-built container—not BYOC. BYOC is only correct when the framework itself isn't supported. Watch for explicit mentions of unsupported frameworks or custom runtime requirements.

Reflection Question: A team has an ML model written in R. They want to deploy it on SageMaker. What approach must they use, and what are the container requirements?