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.
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 inAWS.
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.
Example alignment of CI/CD accounts to workload accounts
Considering use of multi-tenant shared CI/CD services
We don’t recommend using a common CI/CD account in support of a diverse set of workloads because of the inherent difficulties in managing and securing the environment. In this approach, a wide array of teams likely needs access to the common CI/CD services. Separating access between teams within a common CI/CD account and limiting adverse impacts across many workload accounts is more complicated and prone to error than using a distinct CI/CD account for each group of workloads.
Enabling team access to production CI/CD services
Team members who own certain workloads require some degree of access to the production CI/CD services associated with those workloads. At minimum, the ability to monitor execution of CI jobs and CD pipelines is required.
Depending on the process by which CI jobs and CD pipelines are promoted to your production CI/CD accounts, some limited degree of write access to CI jobs and CD pipelines might be necessary for designated administrators within the teams that own the CI jobs and CD pipelines.
Whether team members require direct access to the accounts in which the CI/CD service resides depends on the type of CI/CD tooling that you’re using. For example, if you’re managing your own CI/CD tooling, then it’s likely that access controls are managed within the CI/CD tooling and that authentication occurs outside the context of the account in which the CI/CD tooling resides. In this example, team members likely won’t need direct access to the CI/CD accounts.
If you’re using AWS managed CI/CD services, then team members require at least read access to the CI/CD accounts to monitor execution of CI jobs and CD pipelines.
In the following diagram, teams who own the workloads associated with each production CI/CD account are shown accessing the CI/CD resources in their respective accounts.
Teams accessing workload-specific CI/CD accounts
Providing CD pipeline access to workload accounts
If your CD pipelines use deployment methods and tools to push changes to workload environments, then either your CD pipelines or the deployment tools to which deployment tasks are delegated require sufficient write access to the target workload environments.
An alternative method of deploying changes to workload environments is the pull style of deployment that intentionally avoids requiring CD pipelines to have write access to target workload environments. In the pull model, tools within the target workload environments have the permissions necessary to both detect changes of interest (for example, newly promoted artifacts or configuration changes) and to deploy those changes locally within the workload environment.
Testing changes to your CI/CD capabilities
We recommend that you establish non-production test accounts in your Deployments OU. These accounts can be used to test changes to how you use and manage your CI/CD capabilities before promoting those changes to your production CI/CD environments.
Establishing a set of test accounts for your CI/CD is most important when you’re planning to manage CI/CD tools in AWS. To support and evolve your use of these tools, you should have a test environment separate from production.
If you use AWS managed CI/CD related services including AWS CodePipeline, AWS CodeBuild,
AWS Proton
As a general practice, your test CI/CD environments should not have access to any of your production CI/CD and production workload environments. Instead, your test CI/CD environment access should be constrained to non-production workload environments.
Developing and testing CI jobs and CD pipelines
The Deployments OU is not intended to be used as a means for teams to develop and test CI jobs and CD pipelines. Rather, just like the development and early testing of any other workload, we recommend that you develop and test CI jobs and CD pipelines in your development AWS environments.
As with other types of code, you can promote source for CI jobs and CD pipelines to your production CI/CD environments using processes tailored for the promotion of CI jobs and CD pipelines. This approach enables you to minimize the access required in your production CI/CD environments and constrain your test CI/CD environments in your Deployments OU to testing of the CI/CD capabilities themselves.
Example structure
In the following example, a series of production accounts represent centrally-managed, shared CI/CD services and a set of federated, business unit-managed CI/CD resources.
In a typical scenario, the stable, production-quality CI/CD capabilities in the accounts qualified with -prod are expected to effect changes across both production and non-production workload environments. The -prod qualifier is simply denoting that these are your stable, production-quality CI/CD environments.
The example accounts in the Test OU are qualified with -test. These accounts are intended to represent environments in which you might test changes to your CI/CD platforms or how you use managed CI/CD services before you apply those changes to your stable, production-quality CI/CD environments.
For general guidance on separating production and non-production workloads and resources, refer to Organizing workload-oriented OUs.
Example structure of Deployments OU
