Workloads and environments - Organizing Your AWS Environment Using Multiple Accounts

Workloads and environments

This section defines basic terms and concepts related to workloads. Becoming aware of these concepts helps you understand our recommendations for organizing your workload-oriented OUs.

Workloads

Many of your top-level OUs will house collections of applications, cloud resources, and data in the form of workloads. A workload is a discrete collection of components and data that you manage. A workload can be a commercial off-the-shelf (COTS) application or your own custom application and data service.


          This image shows the composition of a workload, including App/Data components,
            infrastructure components, and data.

Composition of a workload

Workload environments

For a given type of workload, you typically have multiple instances. This setup means that you can experiment, develop, and test changes to the workload before you promote and deploy those changes to the production instances of the workload. A given instance of a workload is a workload environment.

Whether your workload is a COTS application, a custom application, a custom data service, or a foundational security or infrastructure capability, you often need separate non-production workload environments to support your software development lifecycle (SDLC) processes. You can have multiple SDLC processes depending on the diversity of your workload portfolio and your company organization.

The following example shows multiple environments of a workload across non-production test and production workload environments.


          This image shows an example of multiple environments of a workload, including
            non-production and production environments.

Example of multiple environments of a workload

With COTS applications, you might not perform custom development, apart from implementing custom integrations with your own systems. However, you can experiment with and formally test new versions of the COTS applications in non-production environments before deploying them to production.

For detailed examples of common purposes of workload environments in relation to an SDLC, see Appendix B – Worksheet: Mapping workload environment purposes to hosting environment types.

Workload accounts

In your on-premises context, you can refer to the places where your workloads reside as hosting environments. For example, you might have a dedicated production hosting environment in which your production workload environments reside.

In AWS, each of your workload environments is typically contained in an account, where each account is similar to a distinct hosting environment.

Depending on how you choose to scope your workload accounts, you might have a single workload environment per account. Or, you might have multiple workload environments and perhaps multiple workload types in the same workloads account.

The following diagram shows two degrees of scoping production workload accounts. In one example, a workload account is dedicated to a single workload environment. In the other example, multiple workload types reside in a single production workload account.


          This image shows example workload accounts with different degrees of
            scoping.

Example workload accounts with different degrees of scoping