AWS Pipeline Deployment Patterns: Single- and Multi-Account Strategies

This guide explores the architectural patterns used to deliver code from a central CI/CD pipeline to one or more AWS accounts. Understanding these patterns is critical for the DOP-C02 exam, particularly regarding security isolation, blast radius reduction, and automation at scale.

Learning Objectives

After studying this guide, you should be able to:

• Distinguish between single-account and multi-account pipeline architectures.
• Configure cross-account IAM roles and S3 bucket policies for artifact sharing.
• Implement the centralized "Tooling Account" pattern for enterprise CI/CD.
• Manage KMS encryption keys for cross-account artifact access.
• Automate account onboarding using AWS Control Tower and Account Factory.

Key Terms & Glossary

• Tooling Account (Shared Services): A dedicated AWS account that hosts the CI/CD pipelines (CodePipeline, CodeBuild) and artifact repositories.
• Target Account: The environment account (e.g., Development, Staging, Production) where resources are actually deployed.
• Cross-Account Role: An IAM role in the target account that trusts the Tooling Account, allowing the pipeline to perform deployment actions.
• Artifact Store: An S3 bucket (usually in the Tooling account) that holds the output of build stages before they are deployed.
• Bucket Owner Full Control: A required S3 ACL setting when a pipeline in one account writes an artifact to be used by a role in another account.

The "Big Idea"

In a professional DevOps environment, isolation is safety. While a single-account setup is easier to manage, it lacks the security boundaries required for production. Multi-account patterns use AWS Organizations to separate environments (Dev, Test, Prod), ensuring that a misconfiguration or security breach in a development environment cannot impact the production system. The pipeline acts as the "secure bridge" between these isolated islands.

Formula / Concept Box

Hierarchical Outline

1. Single-Account Pattern
   • Use Case: Small projects, startups, or local sandboxes.
   • Pros: Simple IAM, no cross-account overhead, single billing.
   • Cons: High blast radius; no strict isolation between Dev and Prod.
2. Multi-Account Patterns
   • Centralized Pipeline (Recommended): One "Tooling" account manages the flow to multiple target accounts.
   • Decentralized Pipeline: Each account has its own pipeline (rarely used for large scale).
3. Cross-Account Implementation Steps
   • Step 1: Create S3 Bucket in Tooling Account (with KMS encryption).
   • Step 2: Create IAM Role in Target Account (e.g., CrossAccountDeployRole).
   • Step 3: Update Tooling KMS Key Policy to allow Target Role to decrypt.
   • Step 4: Configure CodePipeline Stage to assume the Target Role.

Visual Anchors

Centralized Pipeline Flow

IAM Trust Relationship (TikZ)

Definition-Example Pairs

• Pattern: Pipeline-to-Account Mapping
  • Definition: The logic defining which branch/revision triggers a deployment to a specific environment.
  • Example: A main branch push triggers a deployment to the Staging account, while a release tag triggers a deployment to the Production account via the same pipeline.
• Pattern: Cross-Account KMS
  • Definition: Using a Customer Managed Key (CMK) in the Tooling account to encrypt artifacts that must be read by the Target account.
  • Example: When CodeBuild finishes, it encrypts the ZIP artifact with KMS-Key-A. CodeDeploy in the Prod account uses its cross-account role to call kms:Decrypt using KMS-Key-A to access the code.

Worked Examples

Scenario: Configuring Cross-Account S3 Access

Problem: A pipeline in Account A (Tooling) needs to deploy a CloudFormation template to Account B (Production). The template is stored in an S3 bucket in Account A.

Step 1: The Bucket Policy (in Account A)

Step 2: The KMS Key Policy (in Account A) You cannot use the default aws/s3 key for cross-account access. You must use a CMK.

Checkpoint Questions

1. Why can't you use the default managed KMS key (aws/s3) for cross-account CodePipeline deployments?
2. In a multi-account setup, which account should host the CodePipeline resource itself?
3. What is the purpose of the RoleArn parameter in a CodePipeline stage configuration?
4. What S3 ACL must be applied to objects uploaded to a cross-account bucket to ensure the target account can manage them?

Muddy Points & Cross-Refs

• Bucket Owner Full Control: This is a common point of failure. If the Tooling account uploads an object to the Target account's bucket without this ACL, the Target account owner actually won't have permissions to delete or modify that object.
• Region vs. Account: Don't confuse multi-region with multi-account. You can have a single-account pipeline deploying to multiple regions, or a multi-account pipeline deploying within one region. For DOP-C02, expect questions that combine both (e.g., deploying to Prod-US-East-1 and Prod-EU-West-1 from a Tooling account).

Comparison Tables