SageMaker Pipelines: An Architecture Deep-Dive

About the author: I'm Charles Sieg, a cloud architect and platform engineer who builds apps, services, and infrastructure for Fortune 1000 clients through Vantalect. If your organization is rethinking its software strategy in the age of AI-assisted engineering, let's talk.

I have deployed SageMaker Pipelines across production ML platforms ranging from simple training-to-deployment workflows to multi-model ensembles with conditional quality gates. It is a fundamentally different orchestration paradigm than what most teams expect. The SDK trades orchestration flexibility for zero-cost execution, native SageMaker integration, and first-class support for the ML lifecycle patterns that actually matter in production: parameterization, caching, experiment tracking, and model registration. This article goes deep on the internal workings. How the execution engine resolves dependencies. How caching decisions happen. How data moves between steps. How to design pipelines that hold up under real operational pressure. If you are still deciding between Pipelines and Step Functions, I cover that comparison in Building Large-Scale SageMaker Training Pipelines with Step Functions. I assume here that you have already committed to Pipelines and want to know what is actually going on beneath the Python API.

When to Choose SageMaker Pipelines

The orchestrator decision comes first. Get it wrong, and the friction compounds for months. I have built production pipelines with Step Functions, SageMaker Pipelines, MWAA, and custom Lambda-based orchestration, and each one has a narrow sweet spot.

My recommendation: choose SageMaker Pipelines when your workflow is SageMaker-native, your branching logic stops at quality gates, and you want zero orchestration cost. Go with Step Functions when you need to orchestrate services beyond SageMaker, require complex conditional logic, or need human approval gates as a first-class primitive.

Zero orchestration cost tips the scale for most ML teams. A Step Functions standard workflow running a 15-step training pipeline twice daily incurs modest costs per execution. Scale that to dozens of models, each with multiple pipeline variants across dev/staging/prod, and the state transition charges become a real line item. Pipelines eliminates it entirely.

You pay for that in flexibility. SageMaker Pipelines cannot orchestrate DynamoDB writes, ECS tasks, SNS notifications, or any of the 200+ services Step Functions integrates natively. Need to update a feature store outside SageMaker? Send a Slack notification? Trigger a downstream application workflow? You are stuck using LambdaStep or CallbackStep as escape hatches. Both work, but they add complexity that quickly erodes the simplicity advantage you chose Pipelines for in the first place.

Decision Matrix

I use this matrix when making the orchestrator decision for a specific pipeline:

Pipeline Architecture Fundamentals

The SDK presents a clean Python API. Beneath it sits a compilation step, a JSON definition format, and an execution engine with specific behaviors around dependency resolution, step scheduling, and failure handling. You need to understand all three layers if you want pipelines that behave predictably in production.

The Pipeline Object Model

A SageMaker Pipeline is defined using four core SDK concepts:

Calling pipeline.create() or pipeline.upsert() compiles the Python object graph into a JSON pipeline definition and uploads it to the SageMaker Pipelines service. This compilation step is where dependency resolution happens. The SDK analyzes which steps reference outputs from other steps and constructs the DAG automatically. You never define edges explicitly; data dependencies imply them.

This implicit resolution has a sharp edge. On one hand, you cannot accidentally create a disconnected step that runs in isolation. If a step references another step's output, the dependency is guaranteed. On the other hand, you must understand exactly what constitutes a data dependency in the SDK. Miss one, and two steps that should run sequentially will fire in parallel. I have seen this cause subtle data corruption in production that took days to trace.

Pipeline Execution Lifecycle

Calling pipeline.start() hands control to the execution engine. Knowing this lifecycle well makes the difference between quickly diagnosing a failed pipeline and staring at logs for hours.

flowchart TD
    A[Pipeline Definition
in SDK] --> B[Compile to
JSON DAG]
    B --> C[Upload to
SageMaker Service]
    C --> D[Start Execution
with Parameters]
    D --> E[Resolve
Dependencies]
    E --> F[Schedule
Ready Steps]
    F --> G{Step
Type?}
    G -->|Processing| H[Launch
Processing Job]
    G -->|Training| I[Launch
Training Job]
    G -->|Condition| J[Evaluate
Condition]
    G -->|Register| K[Register
Model Package]
    H --> L{Step
Succeeded?}
    I --> L
    J --> L
    K --> L
    L -->|Yes| M[Mark Complete,
Schedule Dependents]
    L -->|No| N{Retry
Policy?}
    N -->|Retry| F
    N -->|Fail| O[Mark Failed,
Propagate]
    M --> P{More
Steps?}
    P -->|Yes| F
    P -->|No| Q[Pipeline
Succeeded]
    O --> R[Pipeline
Failed]

Think of the execution engine as a pull-based scheduler. It maintains a frontier of steps whose dependencies are satisfied, launches them, waits for completion, then advances the frontier. Steps whose dependencies are all satisfied run in parallel automatically. You do not configure parallelism at the pipeline level; it emerges entirely from the DAG structure. This is elegant when it works. It also means your only lever for controlling execution order is the dependency graph itself.

Pipeline Definition as JSON

The compiled pipeline definition is a JSON document stored by the SageMaker service. Each call to pipeline.upsert() creates a new version, and you can roll back to a previous one. The JSON structure contains:

• Pipeline parameters with types and default values
• Steps with their configurations, inputs, outputs, and dependencies
• Conditions with their branching logic
• Property references that wire step outputs to step inputs

Two reasons to care about the JSON format. First, it is what gets versioned, so store it in source control alongside your pipeline code. Second, when debugging pipeline failures, the JSON definition is ground truth. The SDK objects are a convenience layer for generating it; they are not what the engine actually executes.

Pipeline Steps in Depth

SageMaker Pipelines provides a step type for every major SageMaker operation. Each one maps to a SageMaker API call, but layers on pipeline-aware features: parameterization, caching, property references, and retry policies. Knowing the full catalog saves you from building custom workarounds for capabilities that already exist in the SDK.

ProcessingStep

ProcessingStep is the workhorse. It runs a SageMaker Processing job with your container, input data, and output locations. I lean on it for three distinct purposes:

1. Data preprocessing: Cleaning, normalization, train/test splitting
2. Feature engineering: Computing derived features, encoding categoricals, generating embeddings
3. Model evaluation: Running the trained model against a holdout set and computing metrics

Container choice is the decision that matters here. The built-in processors (SKLearnProcessor, PySparkProcessor) are fine for prototyping. For production, I always use custom containers. Always. The built-in ones change library versions without warning, and I have had a production pipeline break because a scikit-learn minor version bump changed default behavior in a preprocessing function.

TrainingStep

TrainingStep wraps CreateTrainingJob with pipeline-aware configuration. Compared to calling the SageMaker API directly, you gain three capabilities:

• Parameter references for instance type, instance count, and hyperparameters, allowing you to change these at execution time without modifying the pipeline definition
• Property references for input data channels, wiring the output of a ProcessingStep directly as the training data input
• Step caching to skip training entirely if inputs and configuration have not changed

I use a ParameterString for the training instance type on every pipeline. Development runs on ml.m5.xlarge, production on ml.p3.2xlarge. Same pipeline definition, different execution parameters. Simple, and it prevents the configuration drift that plagues teams maintaining separate dev and prod pipeline definitions.

TuningStep

TuningStep runs a hyperparameter tuning job, which is itself an orchestrator. It launches multiple training jobs with different hyperparameter configurations and picks the best one. You end up with nested orchestration: the pipeline orchestrates the tuning job, which orchestrates the training jobs.

Here is my blunt advice: do not put TuningStep in your production pipeline. A 20-trial tuning job on GPU instances can cost hundreds of dollars and run for hours. Run tuning as a separate, manually-triggered pipeline. Take the best hyperparameters from that run and bake them into the production training pipeline as fixed parameters. Your nightly retraining pipeline should be predictable in cost and duration, and TuningStep is the enemy of both.

ConditionStep

ConditionStep is the quality gate mechanism. It evaluates conditions against step outputs and branches execution accordingly. The supported condition types:

Conditions reference step properties (like a JsonGet from a processing job output) or pipeline parameters. The typical flow: a ProcessingStep computes evaluation metrics, writes them to a JSON property file, and a ConditionStep reads those metrics to decide whether to register the model or kill the pipeline. Straightforward when it works. The gotcha is that JsonGet path expressions must exactly match the JSON structure your processing script emits, and there is no schema validation at compile time.

CallbackStep and LambdaStep

These are your escape hatches. CallbackStep sends a message to an SQS queue with a callback token and waits for an external system to respond. LambdaStep invokes a Lambda function synchronously. Every production pipeline I have built uses at least one of these.

LambdaStep handles lightweight tasks where spinning up a Processing job would be absurd: sending notifications, writing metadata to DynamoDB, triggering downstream systems, computing simple derived values. I reserve CallbackStep for genuine external integrations where the pipeline must park and wait. In practice, that means human approval workflows or third-party model validation services. If you find yourself using CallbackStep for anything else, you are probably overcomplicating things.

Pipeline Parameters and Dynamic Configuration

Parameters make a single pipeline definition reusable across environments, datasets, and model variants. Without them, you end up maintaining a separate pipeline for every combination of instance type, dataset, and threshold. I have inherited codebases with dozens of near-identical pipeline definitions. It is a maintenance nightmare that parameters solve completely.

Parameter Types

Every parameter has a name, type, and default value. The default kicks in when the parameter is omitted at execution time. Set your defaults to the production configuration. That way, a bare pipeline.start() with no parameter overrides produces a production-ready model. I learned this lesson after someone accidentally ran a production pipeline with dev-sized instances because the defaults pointed at ml.m5.large.

Parameterization Patterns

I follow a consistent parameterization strategy across all production pipelines:

Environment-based parameterization is the pattern that matters most. One pipeline definition serves dev, staging, and production. Only the parameter overrides change at execution time:

This eliminates environment-specific pipeline definitions. Configuration drift between staging and production is one of the most common causes of "it worked in staging" failures in ML platforms. A single parameterized definition removes that entire category of bugs.

Step Caching

Step caching saves enormous amounts of money and time. Most teams either ignore it or configure it wrong. When enabled, the execution engine checks whether a step has already run with identical inputs and configuration. If so, it skips execution and reuses the previous output. On an iterative development cycle where you are tweaking one step and re-running the full pipeline, caching can cut your bill by 80% or more.

How Caching Works

The caching mechanism computes a cache key for each step based on:

1. Step type and configuration: The step's SageMaker API parameters (instance type, container image, hyperparameters)
2. Input data references: The S3 URIs of input data (the paths only, not the data contents)
3. Pipeline parameters: The resolved values of any parameters referenced by the step
4. Step dependencies: The cache keys of upstream steps

When the engine encounters a cacheable step, it computes the key and checks the cache store. On a hit, the engine grabs the outputs from the previous execution and proceeds to dependent steps immediately. No job launch, no compute charges, near-zero latency.

Cache Configuration

Caching is configured per step with two parameters:

Pay close attention to expire_after. Without it, a cached step never re-executes as long as its inputs look the same. Your training step could silently use month-old results forever. I set expire_after to P7D (7 days) for training steps and P1D (1 day) for processing steps. This forces periodic reprocessing and retraining even when the S3 paths have not changed, catching data drift that appends new records to the same prefix without altering the path.

When Caching Helps vs. Hurts

I see the same caching mistake repeatedly: teams enable caching on training steps in a scheduled production pipeline. The pipeline runs nightly, the S3 paths stay the same (data is appended to the same prefix), and the cache key never changes. The training step never re-executes. The model goes stale. Nobody notices until performance degrades weeks later. Fix this with a short TTL, or inject a date-based parameter that forces cache invalidation on each run.

Conditions and Branching

ConditionStep handles quality gates, metric-based routing, and conditional model registration. The branching logic is nowhere near as rich as Step Functions' Choice state. For ML pipelines, that rarely matters. The patterns you actually need (threshold checks on model metrics, conditional registration) are well covered.

Quality Gate Pattern

Every production pipeline I build has a quality gate after model evaluation. A ProcessingStep computes evaluation metrics and writes them to a property file. A ConditionStep reads those metrics and decides: register the model, or halt the pipeline.

flowchart TD
    A[Processing:
Data Prep] --> B[Training:
Model Training]
    B --> C[Processing:
Evaluate Model]
    C --> D[Condition:
Accuracy >= 0.90?]
    D -->|True| E[Condition:
Latency <= 100ms?]
    D -->|False| F[Fail:
Below Accuracy
Threshold]
    E -->|True| G[RegisterModel:
Approve for Deploy]
    E -->|False| H[RegisterModel:
Flag for Review]
    G --> I[Processing:
Generate Report]
    H --> I

Chaining multiple ConditionSteps gives you multi-criteria quality gates. Each condition evaluates a single metric and branches accordingly. Because if_steps and else_steps accept lists, you can place entire sub-workflows in each branch. I have seen teams try to cram multiple metric checks into a single LambdaStep to avoid chaining. Resist that urge. Separate ConditionSteps give you clearer DAG visualization and better failure diagnostics.

Condition Limitations

The limitations are real, though, and you should know them before committing:

No loops. That is the one that bites hardest. Step Functions lets you implement a retry-with-different-configuration pattern using a Choice state that loops back to the training state. SageMaker Pipelines simply cannot do this. If you need iterative refinement (train, evaluate, adjust hyperparameters, retrain), you have two options: implement it within a single TrainingStep using early stopping and checkpoints, or use a LambdaStep to trigger an entirely new pipeline execution with adjusted parameters. Neither is elegant, but both work.

Data Flow Between Steps

Data flow between steps is where pipelines either work cleanly or fall apart in confusing ways. SageMaker Pipelines provides two mechanisms: step properties for S3 URIs and job metadata, and property files for structured data like evaluation metrics.

Step Properties

Every step exposes properties that downstream steps can reference. During pipeline definition, the SDK creates placeholder references. At execution time, the engine substitutes actual values once the upstream step completes. You write code that looks like it is passing a string, but the SDK is actually building a reference that gets resolved later.

These property references create implicit dependencies. When step B references step A's ModelArtifacts.S3ModelArtifacts, the engine guarantees step A completes before step B starts. This is how you build sequential pipelines without explicitly declaring "step A before step B." The dependency is embedded in the data reference itself.

Property Files and JsonGet

Property files handle structured data exchange: evaluation metrics, configuration outputs, computed values. A step writes a JSON file to its output, and downstream steps extract values from that JSON using JsonGet.

The pattern is:

1. A ProcessingStep writes a JSON file (e.g., evaluation.json) to its output path
2. The step declares this output as a PropertyFile
3. A downstream ConditionStep or step uses JsonGet to extract specific values

This is what powers quality gates. The evaluation ProcessingStep computes metrics and writes them as JSON. The ConditionStep uses JsonGet to pull the accuracy value and compare it against a threshold. If your processing script writes the JSON in an unexpected structure, the condition silently returns False. I always log the actual JSON output during development so I can verify the path expression is correct.

Common Data Flow Pitfalls

Experiment Tracking Integration

SageMaker Pipelines integrates natively with SageMaker Experiments. The engine automatically tracks pipeline executions, step parameters, and model metrics. I rely on this integration constantly for comparing pipeline runs, tracking model lineage, and figuring out why a Tuesday training run produced a worse model than Monday's.

What Gets Tracked Automatically

Each pipeline execution automatically creates experiment tracking artifacts:

Experiment Organization

SageMaker Experiments uses a three-level hierarchy. It maps cleanly to pipeline concepts:

This mapping enables queries like "show me all training runs for the fraud detection model in the last 30 days, sorted by accuracy." Each trial component stores everything: hyperparameters, instance type, data paths, metrics, model artifacts. You can reproduce any pipeline execution exactly. That reproducibility alone justifies the overhead of setting up experiment tracking properly.

Comparing Pipeline Executions

SageMaker Studio gives you side-by-side comparison of pipeline executions through the Experiments integration. I use this constantly to answer questions like:

• "Why did last night's pipeline produce a worse model than last week's?"
• "Which hyperparameter change caused the accuracy improvement?"
• "How does model performance differ across training dataset versions?"

The comparison surfaces differences in parameters, metrics, and execution metadata. Nine times out of ten, the "identical" pipeline that produced different results had a container image update, an upstream dataset change, or an unfixed random seed. The comparison tool pinpoints these differences immediately.

Model Registry Workflows

The Model Registry is where SageMaker Pipelines pulls ahead of every other orchestrator. Step Functions can register models via API calls, sure. Pipelines gives you RegisterModel as a first-class step type with native approval workflows, model versioning, and inference specification baked in. The difference in operational overhead is substantial.

Registration Architecture

Once a model passes your quality gates, the RegisterModel step creates a model package in the Model Registry. It captures comprehensive metadata:

Approval Workflow

The approval status field gates deployment. I always register production models with PendingManualApproval status. Auto-approving models into production is a recipe for an incident. Someone needs to look at the metrics, compare them against the currently deployed model, and make a conscious decision.

flowchart LR
    A[Pipeline:
Train & Evaluate] --> B[RegisterModel:
Pending Approval]
    B --> C[Model Registry:
New Version]
    C --> D{Reviewer
Decision}
    D -->|Approve| E[Status:
Approved]
    D -->|Reject| F[Status:
Rejected]
    E --> G[EventBridge:
Approval Event]
    G --> H[Deploy Pipeline:
Create Endpoint]
    H --> I[Production
Endpoint]
    F --> J[Notification:
Review Feedback]

The whole approval workflow is event-driven. When a model's approval status changes, EventBridge emits an event that triggers a deployment pipeline. I like this decoupling. The training pipeline's job ends at model registration. A separate deployment pipeline (SageMaker Pipeline, Step Functions workflow, or CodePipeline) handles the deployment lifecycle. Different teams can own each pipeline. Different release cadences, different approval chains.

Model Package Groups

Model package groups organize versions of a single model or model family. I have settled on this naming convention after trying several others that caused confusion at scale:

Each group maintains an ordered list of model versions with their approval status, metrics, and lineage metadata. Rollback becomes straightforward: if a newly deployed model degrades in production, approve the previous version and trigger a redeployment. I have done this at 2 AM during an incident, and the process took under five minutes.

Cross-Account Model Registry

Most organizations I work with run separate AWS accounts for dev, staging, and production. The Model Registry supports cross-account sharing via resource policies. The standard pattern:

1. Training account: Runs pipelines, registers models
2. Model Registry account: Hosts the central registry (often the staging or shared services account)
3. Production account: Reads approved models and deploys endpoints

Resource policies on the model package group grant read access to downstream accounts. The production account can only deploy models that passed through the official pipeline and approval workflow. No ad-hoc model uploads, no "I just trained this on my laptop and pushed it to prod" situations. Your security team will thank you.

CI/CD Integration

Your pipeline definition is code. It belongs in a Git repository, deployed through a standard CI/CD pipeline. SageMaker Pipelines sits within this broader CI/CD workflow as the ML-specific execution engine, triggered by whatever CI/CD orchestrator your team already uses.

CI/CD Architecture

flowchart LR
    A[Git Commit:
Pipeline Code] --> B[CI Build:
Lint & Test]
    B --> C[CI Build:
Build Containers]
    C --> D[Deploy:
Upsert Pipeline
to Dev]
    D --> E[Execute:
Dev Pipeline Run]
    E --> F{Dev
Passed?}
    F -->|Yes| G[Deploy:
Upsert Pipeline
to Staging]
    F -->|No| H[Alert:
Dev Failure]
    G --> I[Execute:
Staging Pipeline
Run]
    I --> J{Staging
Passed?}
    J -->|Yes| K[Deploy:
Upsert Pipeline
to Prod]
    J -->|No| L[Alert:
Staging Failure]
    K --> M[Production:
Scheduled Execution]

Three functions, every time:

1. Pipeline code validation: Lint, unit test, and compile the pipeline definition
2. Pipeline deployment: Upsert the pipeline definition to each environment
3. Pipeline execution: Trigger a test execution in dev/staging to validate the pipeline works end-to-end

Pipeline Versioning

SageMaker Pipelines versions pipeline definitions automatically with each pipeline.upsert(). For production, that is nowhere near enough. You need to track which Git commit produced which pipeline version. When a pipeline execution fails at 3 AM, "some version of the pipeline" is useless information.

After trying each of these in isolation, I settled on a combination. The pipeline name includes a major version for breaking changes that require a new pipeline. The pipeline's tags include the Git commit SHA and CI build number. Human-readable versioning and exact source code traceability. Both matter; neither is sufficient alone.

Environment Promotion

One pipeline definition, promoted across environments. The same code runs in dev, staging, and production. Only the execution parameters differ, following the parameterization patterns I described earlier.

Notice that CI/CD does not execute the production pipeline directly. It only deploys the definition. Execution comes from a schedule (EventBridge rule), a data arrival event, or a manual trigger. This separation prevents a code merge from accidentally kicking off a $500 training run on production data.

Integration with AWS CI/CD Services

If your team uses GitHub Actions or GitLab CI instead of AWS-native CI/CD, nothing changes structurally. The CI/CD runner assumes an IAM role with SageMaker permissions and calls pipeline.upsert() and pipeline.start() using the SageMaker SDK. I have set this up with all three; the IAM role configuration is the only part that varies.

Cost Architecture

The cost model is SageMaker Pipelines' strongest selling point to finance teams. The orchestration layer is free. No state transition charges, no hourly environment fees, no per-execution costs. You pay for the compute resources each step consumes and nothing else. Try explaining MWAA's hourly billing to a CFO who just wants to know what the ML platform costs; Pipelines makes that conversation much simpler.

Cost Breakdown

Cost Comparison: Pipelines vs. Step Functions

For a representative ML pipeline with 12 steps, running twice daily:

For a single pipeline, the orchestration cost difference barely registers. Scale to 50 model pipelines with 15+ steps each, and the delta gets meaningful. More importantly, zero orchestration cost removes a variable from capacity planning entirely. You never need to estimate state transition volumes or worry about cost spikes when someone kicks off a large hyperparameter sweep.

Cost Optimization Strategies

Monitoring and Debugging

You get pipeline-level visibility through SageMaker Studio and CloudWatch. Setting up proper monitoring before your first production deployment saves you from the 3 AM scramble of trying to figure out why a pipeline failed with no observability in place.

Pipeline Execution Visibility

SageMaker Studio displays pipeline executions as interactive DAG visualizations. For each execution, you can drill into:

CloudWatch Integration

Every step emits logs and metrics to CloudWatch:

These are the CloudWatch alarms I set up on every production pipeline, no exceptions:

Common Failure Patterns

Production Patterns

Getting a pipeline to work in a notebook is the easy part. Production deployment forces you to address multi-account architecture, infrastructure-as-code, scheduled execution, and network security. Skip any of these and you will regret it within weeks.

Multi-Account Architecture

Every production ML platform I have built spans multiple AWS accounts:

Cross-account access means IAM roles with trust policies. The pipeline execution role in the ML workload account assumes roles in the data account (for S3 access) and the registry account (for model registration). Yes, it is more complex than single-account deployment. Enterprise security teams will insist on it anyway, and they are right to. Get the IAM architecture correct from day one. Retrofitting cross-account access onto a running platform is painful.

Infrastructure-as-Code

Manage all pipeline infrastructure (IAM roles, S3 buckets, ECR repositories, EventBridge rules) with CDK or Terraform. The pipeline definition is Python code, but the surrounding infrastructure belongs in declarative IaC. I have watched teams hand-configure IAM roles through the console and spend weeks debugging permission issues that a CDK stack would have prevented.

Scheduled Execution

Production pipelines run on a schedule, triggered by data arrival, or both. EventBridge rules are the mechanism I use for all of these:

The EventBridge rule targets the StartPipelineExecution API with execution parameters in the input template. Different schedules can pass different parameters to the same pipeline. A daily run processes the last day's data; a weekly run processes the full week. Same pipeline, different parameterization, different schedule. Clean.

Network Security

Pipeline steps run as SageMaker jobs, and every production pipeline should run in a VPC with private subnets and VPC endpoints. No exceptions. I cover the full networking configuration for SageMaker jobs in Best Practices for Networking in AWS SageMaker, but the VPC endpoint requirements specific to pipelines deserve attention here.

Miss any of these VPC endpoints, and pipeline steps in private subnets cannot communicate with SageMaker APIs or access training data. The failure mode is particularly frustrating: the pipeline silently hangs until it times out. No error message, no log entry, just a step that sits in "InProgress" status forever. I have lost hours to a missing ECR endpoint.

Pipeline as a Product

In mature ML organizations, each pipeline is an internal product with its own versioning, documentation, SLAs, and monitoring. Here is how I structure every pipeline project:

This structure forces you to treat the pipeline as a deployable artifact with the same engineering rigor as any production service. ML teams that skip this step end up with Jupyter notebooks in production. Do not be that team.

Additional Resources

• SageMaker Pipelines Developer Guide
• SageMaker Pipelines SDK Reference
• SageMaker Model Registry
• SageMaker Experiments
• SageMaker Pipelines: Caching
• SageMaker Pipelines: Step Types
• SageMaker Pipelines: Cross-Account Support
• SageMaker Model Monitor