SageMaker AI Integration Patterns

The usual progression is that data scientists develop and test models in notebooks, the resulting workflow is expressed as a SageMaker Pipeline or a Step Functions state machine, and that automation handles production deployment and retraining. Notebooks stay useful afterwards for ad-hoc analysis and investigation, but they stop being the thing that runs in production.

The diagram maps the main integration paths around SageMaker AI.

flowchart TD %% Data Sources S3[(S3 Data Lakes)] RDS[(RDS)] RedShift[(Redshift)] DynamoDB[(DynamoDB)] Kinesis[Kinesis Data Streams] %% Data Processing Glue[AWS Glue ETL] EMR[EMR] Lambda[Lambda] %% SageMaker AI Components subgraph SageMaker [Amazon SageMaker AI] Studio[SageMaker Unified Studio] Training[Model Training] Processing[Data Processing] HPO[Hyperparameter Optimization] Pipeline[SageMaker Pipeline] Endpoint[Model Endpoints] Registry[Model Registry] end %% Deployment & Monitoring CloudWatch[CloudWatch] EventBridge[EventBridge] StepFunctions[Step Functions] %% Applications API[API Gateway] AppRunner[App Runner] ECS[ECS/EKS] %% Data Flow Patterns S3 --> Studio S3 --> Training S3 --> Processing RDS --> Glue RedShift --> Glue DynamoDB --> Lambda Kinesis --> Lambda Glue --> S3 EMR --> S3 Lambda --> S3 Studio --> Training Studio --> Processing Studio --> HPO Training --> Pipeline Processing --> Pipeline HPO --> Pipeline Pipeline --> Registry Registry --> Endpoint Endpoint --> CloudWatch Endpoint --> EventBridge %% Application Integration StepFunctions --> Pipeline StepFunctions --> Training StepFunctions --> Processing API --> Endpoint AppRunner --> Endpoint ECS --> Endpoint %% Monitoring Flow CloudWatch --> EventBridge EventBridge --> Lambda classDef aws fill:#FF9900,stroke:#232F3E,stroke-width:2px,color:white class S3,RDS,RedShift,DynamoDB,Kinesis,Glue,EMR,Lambda,Studio,Training,Processing,HPO,Pipeline,Endpoint,Registry,CloudWatch,EventBridge,StepFunctions,API,AppRunner,ECS aws

1. Data sources

• S3 for the data lake and for training data and model artefacts
• RDS and Redshift for structured operational and warehouse data
• DynamoDB for high-volume key-value data
• Kinesis Data Streams for real-time events

Training jobs read from S3, so anything not already there passes through a processing step first.

2. Processing layer

• AWS Glue for serverless ETL from relational sources into S3
• Amazon EMR for large-scale Spark processing
• AWS Lambda for lightweight, event-driven transformation

3. SageMaker AI

• SageMaker Unified Studio as the development environment
• Model training with built-in or custom algorithms
• Processing jobs for feature engineering at scale
• Hyperparameter optimisation for automatic tuning
• SageMaker Pipelines as the definition of the workflow
• Model Registry for versioning and approval
• Endpoints for serving

4. Deployment and monitoring

• CloudWatch for metrics and logs from jobs and endpoints
• EventBridge for reacting to state changes — a completed training job, an endpoint entering service, an alarm firing
• Step Functions where the workflow spans more than SageMaker AI itself and needs branching, waits or human approval steps

5. Application integration

• API Gateway for a REST interface in front of an endpoint, usually with Lambda between them
• App Runner for containerised applications calling the endpoint
• ECS or EKS where the consuming application already runs on containers

Choosing between SageMaker Pipelines and Step Functions

SageMaker Pipelines is the better fit when the whole workflow is inside SageMaker AI: it understands training jobs, processing jobs and model registration natively and keeps lineage. Step Functions is the better fit when the workflow crosses services — waiting on a Glue job, calling an external API, pausing for human approval — or when it needs to coordinate several pipelines. The two compose: a Step Functions state machine that starts a SageMaker Pipeline is common.