AWS DevOps, AI/ML, and Governance Selection Playbook (2026)

Scope

This playbook covers practical decision boundaries for:

• CodeDeploy and Elastic Beanstalk
• CodePipeline and CodeBuild
• SageMaker and Amazon Bedrock
• SageMaker and Rekognition
• AWS Organizations and AWS Control Tower
• AWS DMS and AWS Snow Family

Guidance reflects AWS public documentation and service behavior as of May 18, 2026.

Design principle

Treat delivery automation, AI platform choices, governance structure, and migration strategy as interconnected platform decisions. Teams often optimize one area in isolation and create friction in others.

1) AWS CodeDeploy and Elastic Beanstalk

Choose CodeDeploy when:

• You need deployment orchestration controls across compute targets with explicit rollout strategies.
• You want deployment control separated from application platform abstraction.

Choose Elastic Beanstalk when:

• You need a managed application platform experience with integrated environment-level deployment behavior.
• Team prefers faster platform onboarding over fine-grained deployment system composition.

Guidance:

• CodeDeploy is deployment orchestration-centric.
• Beanstalk is managed application platform-centric.

CLI checkpoint

aws deploy list-applications
aws deploy list-deployment-groups --application-name YOUR_APP
aws elasticbeanstalk describe-environments

2) AWS CodePipeline and AWS CodeBuild

Choose CodePipeline when:

• You need end-to-end CI/CD workflow orchestration across stages.

Choose CodeBuild when:

• You need managed build/test execution jobs.

Relationship:

• CodePipeline orchestrates stages.
• CodeBuild performs build/test units within pipelines (or standalone where needed).

CLI checkpoint

aws codepipeline list-pipelines
aws codebuild list-projects
aws codepipeline get-pipeline --name YOUR_PIPELINE

3) Amazon SageMaker and Amazon Bedrock

Choose SageMaker when:

• You need full ML lifecycle control for training, tuning, deployment, and custom model workflows.

Choose Amazon Bedrock when:

• You need managed access to foundation models for generative AI use cases with reduced model infrastructure overhead.

Architecture guidance:

• Bedrock for rapid generative AI application development.
• SageMaker for custom ML workflows and advanced model lifecycle control.

CLI checkpoint

aws sagemaker list-endpoints --max-results 20
aws sagemaker list-training-jobs --max-results 20
aws bedrock list-foundation-models --by-output-modality TEXT

4) Amazon SageMaker and Amazon Rekognition

Choose SageMaker when:

• You need broader custom ML capability and model lifecycle control.

Choose Rekognition when:

• You need managed prebuilt computer vision capabilities for image/video analysis use cases.

Decision rule:

• Rekognition for specific CV workloads with managed APIs.
• SageMaker for custom model development and broader ML engineering flexibility.

CLI checkpoint

aws rekognition list-collections --max-results 20
aws sagemaker list-models --max-results 20

5) AWS Organizations and AWS Control Tower

Choose AWS Organizations when:

• You need foundational multi-account governance structures and policy boundaries.

Choose AWS Control Tower when:

• You want a managed landing-zone framework that builds on Organizations with standardized governance workflows.

Relationship:

• Organizations is foundational account/policy structure.
• Control Tower provides managed landing-zone governance patterns on top.

CLI checkpoint

aws organizations list-roots
aws organizations list-accounts
aws controltower list-enabled-controls --target-identifier YOUR_OU_ARN

6) AWS DMS and AWS Snow Family

Choose AWS DMS when:

• You need logical database migration/replication workflows and optional ongoing change synchronization.

Choose Snow Family when:

• Data volume and connectivity constraints favor offline physical transfer.

Common enterprise combination:

• Snow for initial bulk baseline data movement.
• DMS for delta replication and controlled cutover.

CLI checkpoint

aws dms describe-replication-instances
aws dms describe-replication-tasks
aws snowball list-jobs

Tutorial lab: CI/CD and governance inventory

#!/usr/bin/env bash
set -euo pipefail

aws codepipeline list-pipelines >/tmp/pipelines.json
aws codebuild list-projects >/tmp/build-projects.json
aws deploy list-applications >/tmp/codedeploy-apps.json
aws elasticbeanstalk describe-environments >/tmp/beanstalk-envs.json
aws organizations list-accounts >/tmp/org-accounts.json
aws controltower list-enabled-baselines >/tmp/ct-baselines.json

echo "DevOps and governance inventory written to /tmp"

Tutorial lab: AI platform inventory

#!/usr/bin/env bash
set -euo pipefail

aws sagemaker list-endpoints --max-results 50 >/tmp/sm-endpoints.json
aws sagemaker list-training-jobs --max-results 50 >/tmp/sm-training.json
aws bedrock list-foundation-models --by-output-modality TEXT >/tmp/bedrock-models.json
aws rekognition list-collections --max-results 50 >/tmp/rekognition-collections.json

echo "AI inventory snapshots written to /tmp"

Deep-dive scenario A: enterprise release modernization

A large application estate needs controlled deployments and standardized pipelines.

Pattern:

• CodePipeline as central release workflow.
• CodeBuild for test/build execution stages.
• CodeDeploy or platform-native deployment mechanism based on target runtime strategy.
• Beanstalk only where managed app platform model fits and migration strategy is explicit.

Deep-dive scenario B: generative AI product with compliance constraints

A product team needs rapid generative features plus governance.

Pattern:

• Bedrock for fast foundation-model integration.
• SageMaker for custom model lifecycle where needed.
• Organizations/Control Tower controls for account boundaries and policy enforcement.

This split supports speed without sacrificing governance.

Deep-dive scenario C: hybrid migration with constrained links

A migration program needs to move large historical data and minimize cutover risk.

Pattern:

• Snow for initial offline bulk load.
• DMS for change replication and final cutover synchronization.

This reduces migration duration and operational risk in constrained network conditions.

Governance controls

1. CI/CD policy controls and deployment approval boundaries.
2. Model usage governance and data handling constraints.
3. Multi-account guardrails and baseline enforcement.
4. Migration runbooks with rollback and validation steps.

Anti-patterns to avoid

• Treating CodeBuild as full pipeline orchestration system.
• Using Beanstalk and CodeDeploy without clear ownership boundaries.
• Selecting SageMaker or Bedrock based on trend pressure instead of workload need.
• Launching multi-account environments without Organizations/Control Tower governance.
• Running large migration cutovers without combining offline and online movement strategies where required.

Final recommendations

For most teams in 2026:

• Use CodePipeline for workflow orchestration and CodeBuild for build/test stages.
• Use CodeDeploy when deployment orchestration control is primary; use Beanstalk where managed app platform abstraction fits.
• Use Bedrock for rapid generative AI integration; use SageMaker for custom model lifecycle depth.
• Use Rekognition for managed CV use cases where prebuilt capabilities fit.
• Use Organizations as foundation and Control Tower for managed landing-zone governance.
• Combine Snow and DMS intentionally for large migration programs with constrained transfer windows.

References

• https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html
• https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html
• https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html
• https://docs.aws.amazon.com/sagemaker/latest/dg/whatis.html
• https://docs.aws.amazon.com/bedrock/latest/userguide/what-is-bedrock.html
• https://docs.aws.amazon.com/rekognition/latest/dg/what-is.html
• https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html
• https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html
• https://docs.aws.amazon.com/dms/latest/userguide/Welcome.html
• https://docs.aws.amazon.com/snowball/latest/developer-guide/whatissnowball.html

Extended implementation framework

CI/CD architecture boundaries

A stable DevOps platform defines clear boundaries:

• source control and review policies
• build/test execution
• artifact management
• deployment orchestration
• post-deploy validation and rollback

CodePipeline should orchestrate these stages, while CodeBuild and deployment services execute scoped tasks.

Deployment governance model

For production changes, define:

• approval criteria by environment
• canary/blue-green strategy where applicable
• rollback triggers
• release ownership
• evidence capture requirements

This model prevents ad hoc release behavior and reduces incident risk.

Beanstalk modernization strategy

If Beanstalk exists in the estate:

• document why each environment remains on Beanstalk
• define migration paths for container-first futures where appropriate
• standardize observability and security controls regardless of platform

Avoid unmanaged divergence between Beanstalk and non-Beanstalk delivery paths.

AI platform decision framework

Bedrock-first patterns

Use Bedrock when:

• product teams need fast foundation-model integration
• managed model access and reduced infrastructure overhead are priorities
• rapid experimentation and deployment velocity are strategic

SageMaker-first patterns

Use SageMaker when:

• model training, tuning, custom deployment, and ML lifecycle control are core requirements
• data science teams need deeper model engineering workflows

Blended patterns

Many teams use both:

• Bedrock for generative app features
• SageMaker for custom predictive or specialized model workflows

The key is clear ownership and workload-fit boundaries.

Rekognition decision clarity

Rekognition is often the fastest path for managed computer vision use cases where prebuilt APIs meet requirements. Move to SageMaker-based custom CV only when feature/performance needs exceed managed service fit.

This avoids overengineering and accelerates delivery.

Multi-account governance at scale

Organizations and Control Tower should be treated as foundational platform architecture.

Recommended control model:

• account segmentation by environment and domain
• policy boundaries through organizational units
• baseline controls and landing-zone standards
• continuous review of account drift and guardrail coverage

Control Tower simplifies landing-zone consistency, while Organizations remains core governance foundation.

Migration strategy with DMS and Snow

Use a two-phase migration model for large constrained moves:

1. Snow for offline baseline transfer.
2. DMS for ongoing replication and final cutover synchronization.

Benefits:

• reduced initial transfer time in limited-bandwidth environments
• lower cutover risk through incremental delta sync
• better operational control during transition windows

Advanced CLI lab: release and governance posture

#!/usr/bin/env bash
set -euo pipefail

# Pipeline posture
aws codepipeline list-pipelines
aws codepipeline list-pipeline-executions --pipeline-name YOUR_PIPELINE --max-items 10
aws codebuild list-projects
aws codebuild batch-get-projects --names YOUR_BUILD_PROJECT

# Deployment posture
aws deploy list-applications
aws deploy list-deployments --application-name YOUR_APP --max-items 10
aws elasticbeanstalk describe-environments

# Governance posture
aws organizations list-accounts
aws organizations list-policies --filter SERVICE_CONTROL_POLICY
aws controltower list-enabled-controls --target-identifier YOUR_OU_ARN

# Migration posture
aws dms describe-replication-tasks
aws snowball list-jobs

Scenario D: startup scaling from simple CI to controlled releases

A startup begins with simple build jobs and manual deploys. As usage grows, outages from inconsistent releases increase.

Recommended evolution:

• introduce CodePipeline orchestration
• standardize CodeBuild test stages
• implement deployment gates and rollback rules
• codify infrastructure changes in IaC

This progression improves reliability without slowing product velocity.

Scenario E: enterprise AI platform expansion

An enterprise wants generative AI features quickly but must keep governance strong.

Pattern:

• Bedrock for quick feature delivery.
• SageMaker for custom models and advanced ML operations.
• account segmentation through Organizations/Control Tower.
• security and data governance controls enforced by platform policy.

This model balances speed and compliance.

Scenario F: global migration under network constraints

A global estate has large legacy databases and limited transfer windows.

Pattern:

• Snow devices move historical bulk datasets.
• DMS handles ongoing delta replication.
• controlled final cutover with validation and rollback plans.

This hybrid approach reduces downtime pressure and migration uncertainty.

Reliability controls for delivery and AI workloads

• pre-deploy integration tests
• post-deploy synthetic checks
• rollback automation thresholds
• model input/output monitoring
• cost and usage anomaly alerts

Reliability controls should be uniform across application and AI feature pipelines.

Security and compliance baseline

For DevOps and AI platform operations:

• least-privilege IAM roles for pipelines and model services
• secret management for tokens and service credentials
• artifact and model lineage tracking
• audit logging for release and governance changes

For migration workflows:

• encrypted transfer paths
• controlled chain-of-custody for physical devices
• validation evidence and reconciliation logs

Cost management guidance

1. Track CI/CD costs by pipeline and team.
2. Optimize build runtime and eliminate redundant stages.
3. Track AI inference/training costs by product use case.
4. Control model selection and token usage policies.
5. Review migration tooling cost against timeline benefits.

Cost management should be continuous and product-aligned.

Anti-pattern expansion

• pipeline sprawl without ownership
• build jobs with no quality gates
• manual production deployments without auditability
• choosing AI platform by brand preference instead of workload fit
• multi-account growth without governance baseline
• migration cutovers without rehearsal and rollback validation

Documenting anti-patterns helps teams avoid repeated mistakes.

Quality gates before major launch

• pipeline and deployment rollback tested
• release metrics and alarms validated
• AI model and data governance controls reviewed
• account guardrails verified
• migration runbook tested if data movement is in scope

Team operating model

A practical platform operating model includes:

• DevOps platform owner
• AI platform owner
• governance owner
• migration owner for large transitions
• monthly architecture review with reliability/cost/security KPIs

Clear ownership is more important than perfect organizational charts.

Leadership review template

Review monthly:

• deployment success/failure trend
• recovery time after failed releases
• pipeline duration and cost trends
• AI feature latency/cost metrics
• account governance drift and remediation status
• migration milestone and risk status

This keeps decision-makers aligned to platform health, not only feature delivery.

Final executive summary

• CodePipeline orchestrates delivery; CodeBuild executes build/test.
• CodeDeploy handles deployment orchestration; Beanstalk remains a managed app platform option where it fits.
• Bedrock accelerates generative AI application delivery; SageMaker serves custom ML lifecycle depth.
• Rekognition provides managed CV capabilities where prebuilt services satisfy needs.
• Organizations provides governance foundation; Control Tower standardizes landing-zone operations.
• DMS and Snow together provide a practical large-scale migration strategy.

Closing guidance

Strong platforms in 2026 are composable and governance-aware. Keep service boundaries clear, operational controls explicit, and adoption iterative. That combination enables teams to move fast without creating hidden systemic risk.

Adoption roadmap by quarter

Quarter 1

• standardize pipeline templates
• enforce build/test quality gates
• define deployment rollback policy
• inventory AI workloads and platform fit

Quarter 2

• implement governance guardrails in account structures
• enforce release evidence capture
• optimize build and deployment performance
• introduce migration readiness standards

Quarter 3

• refine model governance and cost controls
• automate compliance checks in CI/CD
• run migration rehearsals for critical datasets
• expand reliability testing for platform components

Quarter 4

• audit platform maturity across teams
• retire redundant pipelines and outdated controls
• publish next-year optimization plan for cost, reliability, and compliance

A phased roadmap keeps progress realistic and sustainable.

Practical KPI targets

Set baseline targets and improve over time:

• release success rate
• mean time to rollback
• pipeline lead time
• build failure recurrence rate
• AI inference cost per successful user workflow
• governance drift closure time

Metrics should drive platform improvements, not vanity reporting.

Additional runbook reminders

• document emergency release freeze procedure
• keep model rollback mechanism tested
• define migration stop criteria during cutover
• ensure on-call contacts are current in runbooks

Final note for engineering managers

Investing in platform clarity early reduces hidden coordination costs later. Clear ownership, predictable pipelines, disciplined governance, and realistic migration patterns compound into faster and safer delivery across product lines.

Decision review prompts

Before approving platform choices, ask:

• Are deployment and build tools mapped to clear responsibilities?
• Is AI platform choice tied to explicit workload requirements?
• Are governance controls enforceable and observable?
• Is migration approach realistic for data volume and network constraints?
• Are rollback and recovery tested, not assumed?

These prompts expose hidden risk quickly.

Continuous improvement loop

1. Measure delivery and platform outcomes.
2. Identify top friction and failure patterns.
3. Prioritize highest-impact platform fixes.
4. Ship improvements with ownership and deadlines.
5. Re-measure and repeat.

This loop keeps platform evolution aligned to business outcomes.

Final closing guidance

Platform decisions should be revisited as product shape changes. The right choice in early-stage growth may differ from the right choice at enterprise scale. Keep architecture adaptive, evidence-driven, and operationally accountable. Platform reliability is not a one-team responsibility. Encourage product teams to participate in release quality, model safety reviews, and migration rehearsals. Shared responsibility improves both delivery speed and operational safety. Keep platform documentation current for pipeline architecture, model lifecycle controls, account governance structure, and migration runbooks. Documentation drift is a hidden tax that slows onboarding and incident response. Use retrospectives after major releases and migrations to capture what worked, what failed, and which controls need adjustment. Retrospective quality directly influences platform maturity over time. Consistent platform conventions reduce cognitive load for engineers moving between teams. Standard naming, tagging, and release patterns make troubleshooting faster and governance audits cleaner. Treat governance controls as product enablers, not delivery blockers, by automating policy checks and making outcomes transparent. Good platform engineering makes safe delivery the easiest delivery path. Keep platform standards simple, explicit, and reviewable. Align platform roadmaps with product goals and risk tolerance. Iterate, measure, and improve relentlessly. Own outcomes, not tools.