Descriptions of example attributes
The following descriptions elaborate on the meaning of each of the example attributes of workload hosting environment types. These examples and descriptions are meant to act as a reference and starting point for you to modify and extend to suit your needs.
Note
In the table of example attributes of workload hosting environment types, you’ll see a close alignment between test and production environment types. This is a typical approach used by organizations to help ensure that testing occurs in production-like environments prior to changes being promoted to production environments.
If this degree of alignment is important to you, then it can factor into how closely you align your production OU to test environment OUs, both in terms of SCPs and overall security baselines.
Owners/tenants
These are the teams or individuals accountable for the environment and the workloads deployed to it.
Sandbox, development, and data-oriented development
Although sandbox environments are typically allocated on an individual basis and development environments are often allocated on a team basis, your requirements might vary. For example, in support of short duration events, such as company hackathons, you might need to allocate sandbox environments to teams. Similarly, you might have the need for individual owned development environments if team owned environments don’t meet your needs.
Regardless of whether a team or an individual owns an environment, you should consider applying virtually the same attributes across a given type of environment.
Test and production
The ownership and tenancy model typically depends on the operational model you use. For example, in a more traditional centralized operational model, your operations team might own the production and test environments and possibly the workloads residing in them.
In a more federated DevOps style operating mode, individual application and data services teams might own their own production and test environments and the workloads residing in them.
Tolerance for extended outages
This refers to the tolerance of the business for extended outages of a given type of environment. For example, if access to a particular type of environment is down for several hours, what’s the impact to the business?
Generally, organizations treat the environments in which they perform their formal day-to-day work as needing to have production qualities in terms of stability and access.
Corporate desktops
An inability to use corporate desktops for any appreciable length of time is considered to be a significant impact in most organizations.
Sandbox
In our example definition of sandbox environments, they are not typically viewed as having a great deal of importance to everyday formal tasks.
Development and data oriented development
To the extent that development and early testing of code for a variety of foundation and business workloads occurs through development environments, extended outages of development environments can have a significant impact on your business.
Test
Similar to development, your ability to validate important changes will be severely impacted due to extended outages of your test environments.
Internet access
This refers to the extent to which access to and from the internet is allowed.
Sandbox and development outbound access
Typically, users of sandbox and development environments benefit from the ability to download packages from the internet. For example, access to public language platform and OS-native package repositories, including npms, rpms, PyPi modules, etc. Additionally, sandbox and development environments typically benefit from having access to public web services to support experimentation, development, and early testing.
In either case, you might implement filters on outbound requests to the internet to reduce the risk of accessing malicious or unauthorized software packages and services.
Sandbox and development inbound access
Sandbox environments might have the ability to contain workloads that are accessible from the internet. Given that they contain internal data and Intellectual Property (IP), inbound access from the internet is not typically allowed for development environments. In this respect, your AWS development environments might be similar to your corporate desktops.
Test and production internet access
Outbound and inbound internet access with test and production environments is typically more controlled than in lower environments. For example, you might require defined connectivity for each workload that performs outbound requests to the internet or receives inbound requests.
Internal network access
This refers to the extent to which workloads in an environment are allowed to connect to other internal services whether they reside in your on-premises or on AWS environments.
Sandbox
Given the broad administrative access and bidirectional connectivity with the internet, sandbox environments are typically inhibited from accessing internal data and services.
Development
Development environments, like corporate desktops, are typically allowed to connect to your source code management, artifact management, CI/CD, and deployment/release automation services. These environments also typically have connectivity to shared infrastructure services, such as DNS resolution and user authentication and identity management instances populated with test data.
Data
This refers to the overall type of data allowed in each environment.
Sandbox
Unlike corporate desktops and development environments, sandbox environments are typically intended to house only public data. Due to the risk of data loss and unintended exposure, intellectual property (IP) and internal data are typically not allowed in sandbox environments.
IP often includes proprietary source code, configuration data, artifacts (such as applications and binary packages), non-public test data, business, and operational data.
Development and test
Use of sensitive production data is typically prohibited in these environments.
Data oriented development
A variation of a development environment is one that supports the needs of data scientists and data engineers. These teams typically need direct human access to cloud environments to develop and iterate on machine learning (ML) models. Because these workloads need access to production sensitive data, additional guardrails and controls are typically applied to these forms of development environments.
Third-party software and cloud services
This refers to the extent to which third-party and overall cloud services are allowed in each environment. Typically, your existing standards for acceptable use of third-party software and cloud services should extend to your AWS environments.
Degree of access
This refers to the extent to which people interacting with an environment have access to resources in the environment.
Foundation team development
Given the nature of their development work, your cloud foundation or cloud platform team of cross-functional network, security, and other responsibilities typically needs greater write access to foundational resources in their development environments.
Lifespan of resources
This refers to how long workloads and supporting resources are expected to live in a given environment. Even in development environments, teams should be encouraged to automate important configurations as much as feasible. Automation enables teams to recreate resources and workloads on demand so that they have less dependency on hand-built configurations.
Direct human write access to workload resources
This refers to whether human users have the ability to directly create, update, and delete workload resources.
Corporate desktop, sandbox, and development
Across corporate desktop, sandbox, and development environments, individuals and team often need to perform direct manual manipulation of cloud resources in early stages of experimentation. Later, as certain cloud resource and workload configurations mature, investment in automation often makes sense.
Production
In support of workloads in production environments, as a general recommendation, changes made to production should be automated. In these cases, human user write access to workload resources should not typically be necessary and not allowed.
Direct read access to production resources and data could be allowed on a least privileged basis to support audit and operational troubleshooting scenarios.
Break-glass scenarios should be supported to enable temporary write access with strict auditing under exceptional conditions.
Automated workload provisioning
This refers to the extent to which automated workload provisioning applies to a type of environment.
Corporate desktops
A modest degree of automated workload provisioning can be developed and tested on
local corporate desktops. To the extent that type 2 hypervisors
Sandbox
Because sandbox environments are not typically connected to your source code management systems and don’t usually contain internal data, there might be limited value in developing workload automation in sandbox environments. Reuse of open source or other third-party automation is typical in sandbox environments.
Development
Teams typically use a mix of manual and automated means to initially experiment and perform early iterations on their cloud resource configurations. Once teams mature their desired configurations, they typically invest in infrastructure as code (IaC) to automate workload configurations. Your standard source code management systems are typically used to house the IaC automation files.
Formal change management for workloads
This refers to whether formal change management processes are required to apply changes to workloads.
Corporate desktop, sandbox, and development
Formal change management does not typically apply to workloads contained in these environments.
Test
Minimally, we recommend that you at least test your change management processes in test environments.
Production
Typically, some form of change management process applies to all changes made to workload in your production environments.
Degree of centrally managed foundation
This refers the extent to which there’s a centrally managed set of foundation resources in a given environment.
Sandbox
In sandbox environments, given the experimental and wide-ranging administrative access, there might be little if any centrally managed foundation resources other than common enterprise guardrails (see next section).
Development
In development environments, you can provide centrally-managed foundation services to teams. By doing so, you can remove undifferentiated heavy lifting from their day-to-day work.
Test and production
Similar to development, you can relieve individual teams from needing to manage underlying foundation services.
Common enterprise guardrails
Across all of your AWS environments, you’ll benefit from applying a set of enterprise guardrails. The makeup and depth of these guardrails might vary across your types of environments depending on the level of risk to the business and the degree of access allowed to owners of the environments.
For example, AWS API logging using AWS CloudTrail and cloud resource configuration recording via AWS Config is typically a common guardrail applied across all environments.
