Skip to content

Deployment Order

Deployment Order

The cdk-express-pipeline is utilized to create Waves and Stages, enabling the controlled deployment of resources. This enables deployments from any build systems, like GitHub, GitLab, Jenkins, and even local environments.

Internally, the DLZ creates phases, which is a collection of waves. Each phase typically consists of a global wave and optionally one or more regional waves which are deployed sequentially. Waves contains stages which are groupings of stacks deployed in parallel. For the DLZ the stage and dependencies between stacks within the same stage are of little importance as we rely on waves only.

The regions are defined in the config, you can only have a single Global region and optionally one or more Regions.

const dlz = new DataLandingZone(app, {
...
regions: {
global: Region.EU_WEST_1,
regional: [Region.US_EAST_1],
},
});

To recap:

  • Phase - A collection of Waves, this is a logical grouping only, and not implemented in code. Deployed sequentially, one after the other.
  • Wave - A collection of Stages. Deployed sequentially, one after the other.
  • Stage - A collection of Stacks. Deployed in parallel.
  • Stack - A collection of AWS resources. Deployed in parallel when possible as determined by stack dependencies within the Stage.

General structure

Conceptually the DLZ deployment order has the following structure:

A brief description of the resources deployed in each phase:

  • Root Phase - Deploys to the root account, resources like the Organisation’s SCPs, and IAM Identity Center resources etc.
  • Security OU - Audit Phase - Deploys to the audit account, resources like SecurityHub and Chatbot notifications.
  • Workload OU - Base Phase - Deploys to each account specified under workloads. IAM roles, which is a global service, would for example be deployed in the Global wave. While resources such as a VPCs will be deployed in both the Global and the Regional wave as per configuration. The majority of the services are deployed in this phase.
  • Workload OU - NCP1 + NCP2 + NCP3 Phases - NCP stands for Network Connections Phase, these phases are logically numbered to indicate the order of deployment to control dependencies between accounts and regions. It will deploy resources related to networking that require multiple steps, like VPC Peering. For example, for VPC Peering to work, NCP1 defines the peering roles. NCP2 creates the peering connections, knowing that it can use the cross account roles in all accounts. NCP3 creates the route table entries to allow traffic to flow between the VPCs knowing the VPC peering connections have been established.
  • Workload OU - DSP1 Phase - DSP is the abbreviation for Data Services Phase, this phase deploys resources like Lake Formation, etc.

Stacks

The printing of the deployment order can be controlled with the printDeploymentOrder flag. When set, the deployment order will be printed as shown below. This flag is set by default.

const dlz = new DataLandingZone(app, {
...
printDeploymentOrder: true,
});

Given two workload accounts, development and production:

const dlz = new DataLandingZone(app, {
...
organization: {
ous: {
workloads: {
accounts: [{
name: 'development',
type: DlzAccountType.DEVELOP,
...
},{
name: 'production',
type: DlzAccountType.PRODUCTION,
...
},
...AS MANY ACCOUNTS AS DESIRED...
]
},
},
...
}
});

Running cdk diff "**" will produce the following console output:

> Running: cdk diff "**"
ORDER OF DEPLOYMENT
🌊 Waves - Deployed sequentially
πŸ”² Stages - Deployed in parallel, all stages within a wave are deployed at the same time
πŸ“„ Stack - Dependency driven, will be deployed after all its dependent stacks, denoted by ↳ below it, is deployed
🌊 root--global
πŸ”² management
πŸ“„ dlz-global (root--global_management_eu-west-1)
🌊 security--audit--global
πŸ”² global
πŸ“„ dlz-global (security--audit--global_global_eu-west-1)
🌊 workloads--base--global
πŸ”² development--development
πŸ“„ dlz-global (workloads--base--global_development--development_eu-west-1)
πŸ”² production--production
πŸ“„ dlz-global (workloads--base--global_production--production_eu-west-1)
🌊 workloads--base--regional
πŸ”² development--development
πŸ“„ dlz-regional (workloads--base--regional_development--development_us-east-1)
πŸ”² production--production
πŸ“„ dlz-regional (workloads--base--regional_production--production_us-east-1)
🌊 workloads--ncp1--global
πŸ”² development--development
πŸ“„ dlz-ncp1-global (workloads--ncp1--global_development--development_eu-west-1)
πŸ”² production--production
πŸ“„ dlz-ncp1-global (workloads--ncp1--global_production--production_eu-west-1)
🌊 workloads--ncp2--global
πŸ”² development--development
πŸ“„ dlz-ncp2-global (workloads--ncp2--global_development--development_eu-west-1)
πŸ”² production--production
πŸ“„ dlz-ncp2-global (workloads--ncp2--global_production--production_eu-west-1)
🌊 workloads--ncp2--regional
πŸ”² development--development
πŸ“„ dlz-ncp2-regional (workloads--ncp2--regional_development--development_us-east-1)
πŸ”² production--production
πŸ“„ dlz-ncp2-regional (workloads--ncp2--regional_production--production_us-east-1)
🌊 workloads--ncp3--global
πŸ”² development--development
πŸ“„ dlz-ncp3-global (workloads--ncp3--global_development--development_eu-west-1)
πŸ”² production--production
πŸ“„ dlz-ncp3-global (workloads--ncp3--global_production--production_eu-west-1)
🌊 workloads--ncp3--regional
πŸ”² development--development
πŸ“„ dlz-ncp3-regional (workloads--ncp3--regional_development--development_us-east-1)
πŸ”² production--production
πŸ“„ dlz-ncp3-regional (workloads--ncp3--regional_production--production_us-east-1)
🌊 workloads--dsp1--global
πŸ”² development--development
πŸ“„ dlz-dsp1-global (workloads--dsp1--global_development--development_eu-west-1)
πŸ”² production--production
πŸ“„ dlz-dsp1-global (workloads--dsp1--global_production--production_eu-west-1)
🌊 workloads--dsp1--regional
πŸ”² development--development
πŸ“„ dlz-dsp1-regional (workloads--dsp1--regional_development--development_us-east-1)
πŸ”² production--production
πŸ“„ dlz-dsp1-regional (workloads--dsp1--regional_production--production_us-east-1)

DLZ is only using Waves and not Stages to control dependency, so let’s break this down into the β€œPhases” of deployment and focus on the stacks (removing the stages) that are deployed in each phase.

Each stack is identified by the πŸ“„ symbol, and has the following format:

πŸ“„ <stack-name> (<stack-id>)
  • <stack-name> - The name of the stack as seen in the AWS Console
  • <stack-id> - The unique identifier of the stack that we use to target for CDK commands like diff, deploy, destroy etc.

Root Phase

🌊 root--global
πŸ“„ dlz-global (root--global_management_eu-west-1)

Security OU - Audit Phase

🌊 security--audit--global
πŸ“„ dlz-global (security--audit--global_global_eu-west-1)

Workload OU - Base Phase

🌊 workloads--base--global
πŸ“„ dlz-global (workloads--base--global_development--development_eu-west-1)
πŸ“„ dlz-global (workloads--base--global_production--production_eu-west-1)
🌊 workloads--base--regional
πŸ“„ dlz-regional (workloads--base--regional_development--development_us-east-1)
πŸ“„ dlz-regional (workloads--base--regional_production--production_us-east-1)

Workload OU - NCP1 Phase

🌊 workloads--ncp1--global
πŸ“„ dlz-ncp1-global (workloads--ncp1--global_development--development_eu-west-1)
πŸ“„ dlz-ncp1-global (workloads--ncp1--global_production--production_eu-west-1)

Workload OU - NCP2 Phase

🌊 workloads--ncp2--global
πŸ“„ dlz-ncp2-global (workloads--ncp2--global_development--development_eu-west-1)
πŸ“„ dlz-ncp2-global (workloads--ncp2--global_production--production_eu-west-1)
🌊 workloads--ncp2--regional
πŸ“„ dlz-ncp2-regional (workloads--ncp2--regional_development--development_us-east-1)
πŸ“„ dlz-ncp2-regional (workloads--ncp2--regional_production--production_us-east-1)

Workload OU - NCP3 Phase

🌊 workloads--ncp3--global
πŸ“„ dlz-ncp3-global (workloads--ncp3--global_development--development_eu-west-1)
πŸ“„ dlz-ncp3-global (workloads--ncp3--global_production--production_eu-west-1)
🌊 workloads--ncp3--regional
πŸ“„ dlz-ncp3-regional (workloads--ncp3--regional_development--development_us-east-1)
πŸ“„ dlz-ncp3-regional (workloads--ncp3--regional_production--production_us-east-1)

Workload OU - DSP1 Phase

🌊 workloads--dsp1--global
πŸ“„ dlz-dsp1-global (workloads--dsp1--global_development--development_eu-west-1)
πŸ“„ dlz-dsp1-global (workloads--dsp1--global_production--production_eu-west-1)
🌊 workloads--dsp1--regional
πŸ“„ dlz-dsp1-regional (workloads--dsp1--regional_development--development_us-east-1)
πŸ“„ dlz-dsp1-regional (workloads--dsp1--regional_production--production_us-east-1)

Stacks patterns

The DLZ uses stack IDs to enable precise targeting of specific stacks, allowing for controlled and efficient deployments. Below are some commonly used patterns that can be applied with the CDK command:

  • ** - Target all stacks
  • root--* - Target all stacks in the root phase
  • security--* - Target all stacks in the security phase
  • workloads--* - Target all workload stacks in all phases
  • workloads--base--* - Target all workload stacks of the base phase
  • workloads--ncp* - Target all workload stacks of all the NCP phases
  • workloads--ncp1--* - Target all workload stacks of the NCP1 phase
  • workloads--ncp2--* - Target all workload stacks of the NCP2 phase
  • workloads--ncp3--* - Target all workload stacks of the NCP3 phase
  • workloads--dsp1--* - Target all workload stacks of the DSP1 phase

Stacks can be targeted by global/regional waves as well, for example:

  • workloads--base--global_* - Target all workload global stacks in the base phase
  • workloads--base--regional_* - Target all workload regional stacks in the base phase

They can also be targeted by account type, for example:

  • *_*--development_* - Target all stacks in the workload phase of type development (specified in the config by type: DlzAccountType.DEVELOP)
  • *_*--production_* - Target all stacks in the workload phase of type production (specified in the config by type: DlzAccountType.PRODUCTION)

Basic deployment

The basic version deploys all the stacks of the DLZ as defined by the deployment order.

Terminal window
cdk deploy "**"

Advanced deployment

The advance deployment deploys the phases individually, allowing for manual approval steps between the deployment of the development and production accounts in the workload OU.

Terminal window
cdk deploy "root--*"
cdk deploy "security--*"
cdk deploy "*_*--development_*"
**[MANUAL APPROVAL]**
cdk deploy "*_*--production_*"