Deployments OU - Organizing Your AWS Environment Using Multiple Accounts
Using CI/CD capabilities residing outside of your AWS environmentSeparating CI/CD management capabilities from workloadsRunning CI jobs and CD build stages in deployment accountsAligning CI/CD accounts with groups of workloads

Deployments OU

The Deployments OU contains resources and workloads that support how you build, validate, promote, and release changes to your workloads. You might already be using continuous integration/continuous delivery (CI/CD) capabilities to help manage and automate how changes to various types of source code are processed.

You might already be using continuous integration/continuous delivery (CI/CD) capabilities to help manage and automate how changes to various types of source code are processed.

Using CI/CD capabilities residing outside of your AWS environment

If you already use on-premises and/or managed CI/CD and related capabilities that reside outside of your AWS environment and you do not expect to use and/or manage CI/CD services within your AWS environment in the near term, you might not immediately need to establish the Deployments OU and an associated set of CI/CD oriented accounts.

In this scenario, you must work through any access and potential network connectivity dependencies between your CI/CD capabilities residing outside of your AWS environment and your workloads environments in AWS.

Separating CI/CD management capabilities from workloads

If you intend to deploy and/or manage your own CI/CD capabilities in AWS or use AWS managed CI/CD services, we recommend that you use a set of production deployment accounts within the Deployments OU to house the CI/CD management capabilities.

Reasons for separating your CI/CD management capabilities from your workload environments include:

  • Critical roles played by CI/CD capabilities — Your CI/CD capabilities are responsible for orchestrating quality validation, security compliance checks, building and publishing production candidate artifacts, promoting artifacts, and ultimately triggering release of artifacts to production environment.

    Given the critical nature of these roles, it’s important that you can apply appropriate policies and operational practices to your CI/CD capabilities that are different than those applied to your workload environments.

    For example, your CI jobs and CD pipelines typically need write access to publish and promote candidate artifacts to an artifact management service. However, your production workload environments should only require read access to artifact management services in order to obtain the already built and promoted artifacts.

  • CD pipelines affect non-production and production workload environments – When CD pipelines orchestrate the validation of changes and ultimately trigger the release of changes to production, the pipelines often need to access workloads residing in both non-production test and production workload environments. For example, if you manage your CI/CD capabilities in your production workload environments, then you must allow the production workload environments to access your non-production environments. By centralizing your CI/CD capabilities in your CI/CD accounts, you can avoid enabling your production workload environments access to non-production environments.

  • CI/CD capabilities depend on unique tooling – Your CI/CD management capabilities, CI jobs, and CD pipelines often depends on tools that are different from those required to run and operate your workloads. Limiting the use of these tools to your CI/CD accounts can help you reduce the complexity and attack surface of your workload environments.

Running CI jobs and CD build stages in deployment accounts

Because CI jobs and CD pipeline build stages are responsible for generating formal candidate artifacts, we recommend that you perform these activities in a production environment. Rather than perform these activities in your production workload environments, we recommend that you run them in your production CI/CD accounts.

Aligning CI/CD accounts with groups of workloads

We recommend that you define CI/CD accounts in the Deployments OU that are aligned with how you group related workloads in your workload-oriented OUs. By doing so, you can more easily align the security policies and operational requirements of each group of workloads with their companion CI/CD account.

This approach helps limit the scope of impact of an issue in a CI/CD account to a single workload or group of workloads. Any access issues and resource conflicts that arise in one CI/CD account will most likely impact only the associated group of workloads and the accounts in which the workloads reside.

In the following diagram, Workload 1 represents a workload that is dedicated to its own production account. Workloads 2, 3, and 4 are configured as a group of related workloads and are managed in a separate production account.

A companion set of test accounts contain test instances of the workloads. In each test account, there are likely be multiple workload environments for a given workload so that various forms of testing can be supported at the same time.

A CI/CD account has been created to support Workload 1 and a second CI/CD account has been created to support the set of related workloads 2, 3, and 4. The CI/CD resources in each production CI/CD account might need to interact with the target workload environments in both the test and production accounts.