Skip to main content
In this lesson you’ll learn how SageMaker project templates connect a CI/CD system with SageMaker Pipelines to automate repeatable ML workflows. The goal is to standardize and scale ML development so teams can manage many projects without multiplying operational complexity. We’ll cover:
  • What SageMaker project templates provide
  • How templates provision and link AWS resources (Git repos, CI/CD, SageMaker Pipelines)
  • Typical model build and model deploy workflows created by templates
  • Where CloudFormation and AWS Service Catalog fit into the workflow
  • Best practices and tradeoffs (including Git repository options)
SageMaker project templates help teams adopt consistent repo layouts, CI/CD triggers, and SageMaker Pipelines behavior so data scientists, data engineers, and MLOps professionals can collaborate using the same patterns. Why consistency matters
  • Faster onboarding: a predictable repo structure and pipeline behavior shortens ramp-up for engineers moving between projects.
  • Reliable governance: consistent experiment tracking and model versioning simplifies auditing and model comparisons.
  • Lower engineering overhead: reusable templates reduce bespoke automation work and help enforce compliance and reproducibility.
A presentation slide titled "Problem: Challenges in Scaling and Managing ML Workflows" that lists four issues: lack of standardization in development/deployment, inconsistent CI/CD for ML, collaboration challenges among data engineers/scientists/MLOps/DevOps, and complexity in experiment tracking and model versioning.
Choose one Git provider and be consistent across your organization. SageMaker project templates give you the scaffolding to enforce a single, supported Git workflow (CodeCommit or an external provider like GitHub/GitLab/Bitbucket).

​
What SageMaker project templates provide

SageMaker project templates are CloudFormation-based blueprints that provision and link the AWS resources required for an ML project. They automate infrastructure provisioning and CI/CD glue so teams can begin development with a standardized stack. Typical components provisioned by templates:
  • Source repository (AWS CodeCommit or an external Git-compatible provider)
  • CI/CD orchestration (AWS CodePipeline or integrations with Jenkins, etc.)
  • Build/runtime orchestration (CodeBuild or an external build server)
  • SageMaker Pipelines for preprocessing, training, and model registry lifecycle
  • Optional MLOps components, like Model Monitor and deployment automation
Table — Common resources created by SageMaker project templates:
Resource TypePurposeExample
Source repoStore code/artifacts and trigger CICodeCommit, GitHub, GitLab, Bitbucket
CI/CD OrchestratorManage pipeline stages (source/build/deploy)CodePipeline, Jenkins
Build workerRuns build steps; invokes SageMaker PipelinesCodeBuild, external CI
SageMaker PipelinesData processing, training, and model registrationSageMaker Pipelines DSL
Model registry & endpointsStore and deploy model artifactsSageMaker Model Registry, Endpoints
When you deploy a template, it often creates a CodePipeline and CodeBuild project tied to a repo. CodeBuild commonly serves as the bridge that starts a SageMaker Pipeline (via SDK or CLI) to run data processing, training, and model registration.
A diagram titled "Solution: SageMaker Projects" showing SageMaker Project Templates in the center connected by arrows to AWS services and CI/CD tools: AWS CodeCommit, CodePipeline, CodeBuild, Git-compatible repos, and Jenkins. The image illustrates integration points for SageMaker project templates with version control and build/deployment pipelines.

​
High-level flow (example)

  1. A SageMaker project template (CloudFormation) provisions required AWS and CI/CD resources.
  2. A source commit to the provisioned Git repo triggers a CodePipeline source stage.
  3. CodePipeline runs a build stage (e.g., CodeBuild).
  4. CodeBuild invokes a SageMaker Pipeline that performs data processing, training, and model registration.
  5. A separate model-deploy pipeline picks up registered models from the model registry and deploys to an endpoint.
This layered approach lets you customize or extend specific stages (e.g., swap CodeBuild for a Jenkins build server) while keeping a consistent provisioning mechanism.

​
CloudFormation and infrastructure-as-code

SageMaker project templates are implemented with CloudFormation templates. CloudFormation is AWS’s native Infrastructure-as-Code (IaC) tool: you declare resources in YAML/JSON and CloudFormation creates and configures them. While other IaC tools such as Terraform are popular, the SageMaker project templates rely on CloudFormation under the hood.

​
Model build vs model deploy separation

Templates often create separate repos and pipelines for build and deploy. This separation is intentional:
  • Model build repository and pipeline: preprocessing, feature engineering, training, experiment tracking, and model registration into the model registry.
  • Model deploy repository and pipeline: deployment manifests and scripts that consume model registry artifacts to create or update SageMaker endpoints.
Separating build and deploy gives teams control over lifecycle stages (e.g., allow data scientists to register models while a separate ops team approves deploys).

​
Build orchestration with CodeBuild (bridge to SageMaker Pipelines)

Within CodePipeline, CodeBuild commonly runs the build steps. The repository includes a Buildspec.yml file that directs CodeBuild—typically its main responsibility is to start the SageMaker Pipeline using the AWS SDK/CLI. Example minimal buildspec snippet: 
version: 0.2

phases:
  install:
    runtime-versions:
      python: 3.8
    commands:
      - pip install -r requirements.txt
  build:
    commands:
      - |
        aws sagemaker start-pipeline-execution \
          --pipeline-name my-sagemaker-pipeline \
          --region $AWS_DEFAULT_REGION
artifacts:
  files:
    - '**/*'
CodeBuild acts as the orchestrator that converts a Git commit into a running SageMaker Pipeline execution.
A flow diagram titled "Solution: SageMaker Templates" that maps model build and deploy pipelines using CodeCommit, CodePipeline, CodeBuild, and S3 feeding SageMaker Pipelines into a model registry and finally a SageMaker endpoint. The left side shows SageMaker Project and CloudFormation templates.
Some SageMaker templates provision AWS CodeCommit repositories automatically; others expect you to supply an external Git repo URL. Choose the Git provider that aligns with your organization’s policies and developer workflows. If using GitHub/GitLab/Bitbucket, create the repo externally and pass its URL to the template during deployment.

​
Third-party Git providers and template behavior

  • Templates can link to any Git-compatible repository, but SageMaker does not create external third-party repos for you. You must create those repos (or ensure they exist) and supply the URL when deploying a project template.
  • Templates that reference CodeCommit can create a repo automatically in supported accounts—this explains why some older or default templates may assume CodeCommit.

​
Model-build workflow example

A typical model-build repo (for example, hosted on Bitbucket) might include:
  • preprocessing scripts: process.py
  • feature engineering: feature.py
  • training driver: train.py
  • a Buildspec.yml to instruct CodeBuild to start the SageMaker Pipeline
Workflow:
  • A developer modifies feature.py and pushes to main.
  • The pipeline source stage detects the change and starts the pipeline.
  • CodeBuild runs Buildspec.yml and invokes the SageMaker Pipeline, which runs: Clean data → Feature engineering → Train → Register (→ optional deploy or test).
A workflow diagram titled "SageMaker Templates" showing a model-build Git repo with files (process.py, feature.py, train.py, Buildspec.yml) connected to a CodePipeline (Source → Build). The pipeline feeds a sequence of steps at the bottom: Clean Data, Feature Engineer, Train, Register, and Deploy.

​
Provisioning a SageMaker project from Studio

You can create a project directly from SageMaker Studio:
  • Studio → Deployments → Projects → Create project
  • Choose a template and supply project details (including third-party Git repo URLs when requested)
The Studio UI lists built-in templates. Note: some templates may be legacy or unavailable in certain accounts/regions—review template details and pick options that match your organization’s support and compliance posture.

​
Available template variations

Common built-in template patterns include:
  • Model build & train with third-party Git using CodePipeline (build-only)
  • Model build, train & deploy with third-party Git using CodePipeline (build + deploy)
  • Model build/train/deploy with Jenkins (requires an existing Jenkins server)
  • Model build/train/deploy with integrated Model Monitor
  • Simple model deployment using CodePipeline and a third-party Git repo
Table — Example template types and when to use them:
Template TypeUse CaseConsiderations
Build-only (CodePipeline)CI for training & registryGood for automated training workflows
Build + Deploy (CodePipeline)End-to-end automationUse when automated deployments are allowed
Jenkins-basedExisting Jenkins infraRequires Jenkins integration setup
With Model MonitorProduction monitoring includedAdds monitoring/alerting stages
Simple deployLightweight endpoint updatesFast iteration for simple workloads

​
Organization templates

Under the Organization Templates tab you can publish custom templates tailored to your enterprise policies. These enforce configuration, IAM, and networking defaults so teams start projects that already conform to organizational standards.
A slide titled "Workflow: SageMaker Projects" showing the AWS SageMaker "Create project" UI with a Templates panel listing MLOps project templates. A highlighted callout reads "Launch custom project templates."

​
Using AWS Service Catalog with SageMaker projects

Many enterprises expose SageMaker project templates through AWS Service Catalog. Service Catalog provides a controlled, app-store-like interface where authorized users request pre-approved templates without needing direct console permissions. The Service Catalog item can launch a SageMaker project CloudFormation template on behalf of the requester—enforcing governance, role separation, and pre-approved configurations.
A slide titled "Workflow: SageMaker Projects" with a left-side flowchart showing AWS Service Catalog → SageMaker Project Template → CloudFormation Template. The right side lists four points: simplifies provisioning, offers a storefront-like experience, lets users request services without direct permissions, and example options (3-tier web app, Hadoop cluster, SageMaker Project).

​
Benefits of SageMaker project templates

  • Faster project setup — get a working scaffold on day zero.
  • Consistent CI/CD — easier to maintain, debug, and scale.
  • Stronger governance — enforce templates, policies, and compliance.
  • Easier cross-team collaboration — standard patterns reduce re-learning.
  • Scalable operations — automation minimizes manual provisioning and custom engineering.
Many organizations pre-populate repositories with standard scripts, linters, and testing utilities so teams have a repeatable, organizationally-aligned starting point.
A slide titled "Results: SageMaker Projects" showing five numbered panels that list benefits: faster ML development with automation; consistent CI/CD workflow management; better governance and compliance; easier collaboration across teams; and scalable ML deployment with monitoring and retraining. Each panel includes an icon and brief explanatory text.

​
Recap

  • SageMaker project templates use CloudFormation to provision and link required resources: source repos, CodePipeline, CodeBuild (or external CI), and SageMaker Pipelines.
  • Templates typically separate build and deploy pipelines; CodeBuild often acts as the bridge that invokes SageMaker Pipelines.
  • Use built-in templates or publish organization-specific templates. For enterprise-level governance, surface templates via AWS Service Catalog.
  • Choose your Git provider based on organizational policy and developer workflows. Templates may provision CodeCommit repos automatically, or accept external repo URLs (GitHub, GitLab, Bitbucket, etc.) as inputs.
A presentation slide titled "Summary" showing five numbered points about SageMaker project templates and deployment. The points mention CI/CD and SageMaker Pipelines, customizable templates, migrating away from CodeCommit, using CloudFormation for IaC, and sharing templates via Service Catalog.
This concludes the lesson. A demonstration will follow to show creating a SageMaker project from a template and walking through the template deployment and pipeline execution. Further reading and references:

Watch Video