Descriptions of example workload hosting environment types
The following descriptions provide more detail for the example workload hosting environment types. These examples and descriptions are meant to act as a reference and starting point for you to modify and extend depending on your needs.
Each workload hosting environment type is not intended to represent a single account in your overall AWS environment. Rather, a workload hosting environment type is meant to help you think about the overall categorization of and distinction between the accounts in which your workloads reside. You might end up having numerous accounts of any given hosting environment type.
For example, if there are significantly different security and operations needs of the environment types that you identify, then those environments might help you refine your overall OU structure for workloads.
For a set of example attributes for each of the example hosting environment types, refer to Appendix C.
Corporate desktop environments
Depending on the degree of access your builders have on their corporate desktops, they might perform much of their day-to-day, non-cloud work locally on their desktops. As you adopt AWS, many of your builder teams will start creating and managing AWS resources and workloads in their sandbox and development AWS environments.
Sandbox environments
Sandbox environments are environments allocated to individuals in which they have significant degrees of administrative access so that they can learn and dive deep into a wide variety of AWS services and other technologies. Typically, sandbox environments do not have access to your internal networks, services, and data.
Foundational guardrails are used to mitigate the risk of this extensive access. For more information, refer to Sandbox OU.
Development environments
An extension of your corporate desktops that enable your builder teams to carry out formal development tasks both with and in AWS that cannot occur only on their local corporate desktops.
Development environments are often allocated on a team and/or individual basis. Depending on the permissions granted to your builder teams, varying degrees of self-paced learning, experimentation, and prototyping can also occur in development environments.
Foundational guardrails and shared infrastructure services that are treated as production stable resources are typically used to ensure the proper degrees of access control and stability of development environments.
Data-oriented development environments
A hybrid of the attributes of development and production environments. Data scientists and data engineers need an environment in which they can develop and perform early forms of testing machine learning and other algorithms that require access to production data.
Given the hybrid nature of this environment type, the guardrails and controls for data development are typically a blend of those used to support development and production environments.
Test environments
A type of workload hosting environment in which changes are formally validated before they are promoted for release to production environments. Depending on how you view this overall stage of your SDLC and the distinct security and operational requirements of it, you might end up dividing this overall type into multiple types of environments.
Typically, test environments are secured and managed in much the same manner as production environments so that validation efforts occur in production-like environments and issues are detected prior to release to production.
Production environments
Highly secured, formally managed hosting environments in which production data and workloads reside.
