This whitepaper is for historical reference only. Some content might be outdated and some links might not be available. # Workload Isolation capability Workload Isolation capability The Workload Isolation capability enables you to create and manage isolated environments for your workloads. This approach reduces the impact of vulnerabilities and threats, and eases the complexity of compliance by providing mechanisms to isolate access to resources. **Stakeholders:** + Central IT (Primary) + Security + Operations **Personas: ** + **Cloud Team** - the team(s) who make cloud available to customers (such as App DevOps). + **DevSecOps** - The team defining, building, analyzing, and mitigating access and authorization to application workloads and data assets. + **Audit and Compliance / Governance, Risk Management, and Control** - The team(s) performing review and approval of control adherence or exception. **Supporting capabilities**: [Governance capability](governance-capability.md) and [Network Connectivity capability](network-connectivity-capability.md) **Scenarios:** + **CF7 - S1: Designing isolated resource environments** + **CF7 - S2: Isolated environment lifecycle management ** + **CF7 - S3: Baselining isolated environments** + **CF7 - S4: Repeatable patterns for isolated environments** Topics + [Overview](workload-isolation-boundary-overview.md) + [Design isolated resource environments](design-isolated-resource-environments.md) + [Provision processes for isolated environments](provision-processes-isolated-environments.md) + [Implement controls on isolated resource environments](implement-controls-isolated-resource-environments.md) + [Provision baseline standards to isolated resource environments](provision-baseline-standards-isolated-resource-environments.md) + [Provision pre-approved deployable architectures](provision-deployable-architectures.md) + [Decommission process for isolated resource environments ](decommission-process-isolated-resource-environments.md) # Overview Overview As you scale your cloud environment usage beyond a workload, it is important to develop repeatable processes for groups of isolated resources and workload provisioning within a set of guardrails. This maintains consistent controls and boundaries to support application development teams and other consumers. These controls will span cost, regulatory, and compliance domains with implementation often starting as runbook-based mechanisms and evolving into automated processes as business requirements drive the need to scale. By enabling automation, you can remove human error through use of CI/CD and Infrastructure as Code (IaC) principles. # Design isolated resource environments Design isolated resource environments Creating an identity and access management isolation boundary for workloads reduces the risk of a workload infrastructure update impacting a different workload, simplifies cost management, and allows application teams to operate within a bounded environment. Being able to implement preventative or detective controls on isolated resource environments will allow different controls for different workload types or Software Development Life Cycle (SDLC) environments (such as dev, test, prod). Workloads often have distinct security profiles that require separate control policies and mechanisms to support them. For example, it’s common to have different security and operational requirements for the non-production and production environments of a given workload. The resources and data that make up a workload are separated from other environments and workloads with defined isolation boundaries. You can group workloads with a common business purpose in distinct environments. This enables you to align the ownership and decision making with those environments, avoiding dependencies and conflicts with how workloads in other environments are secured and managed. Different business units or product teams might have different processes. Depending on your overall business model, you might choose to isolate distinct business units or subsidiaries in different environments. Isolation of business units can help them operate with greater decentralized control, but still provides the ability for you to implement overarching guardrails. This approach might also ease divestment of those units over time. For information about best practices for organizing your environment on AWS, refer to [Organizing your AWS environment using multiple accounts](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/organizing-your-aws-environment.html). # Provision processes for isolated environments Provision processes for isolated environments At a smaller scale, request and review processes for creating isolated resource environments often start with manual based inputs to a cloud management team through a ticketing system or other request process. The cloud team will then analyze the request and ensure a set of information is included such as: owner, email address, cost center, project number, and SDLC environment. Additional customer specific meta data may also be collected based on requirements. If an application review board or enterprise architecture board are present within the customer environment they may also review the request. For certain types of environments, it may be decided that approvals are not required or an auto-approval mechanism may be put in place. Once approved, the isolated environment is created with a baseline configuration and controls that apply to all environments. Configuration and controls may also be applied based on the metadata within the request. Non-production or production environments, for example, may have different requirements and controls applied. Baseline configurations might include the removal of default password configurations, authentication methods, integration with an existing identity provider, IP allocation, network segmentation and connectivity, logging, and security tooling. Additional customer required controls will be implemented at this point, often driven by industry specific regulatory requirements or cloud control best practice guidance through common frameworks such as [Cloud Security Alliance - Cloud Controls Matrix](https://cloudsecurityalliance.org/research/cloud-controls-matrix/) or [NIST Cybersecurity Framework (CSF) Reference Tool](https://www.nist.gov/cyberframework/nist-cybersecurity-framework-csf-reference-tool). As your environment matures, request, review, and approval processes can be automated using integration with existing IT service management or human workflow tools. Deployment processes can leverage automation through GitOps deployment pipelines and infrastructure as code. # Implement controls on isolated resource environments Implement controls on isolated resource environments Implementing controls on isolated resource environments provide cloud consumers the autonomy to build workloads to meet their business objectives while keeping the organization compliant to standards and regulations. Controls can take the form of either preventative or detective. **Preventative controls** prevent events from occurring based on a variety of criteria, including the event type, action, resource, caller identity, and more. For example, a preventative control might deny all users from deleting a specific resource. **Detective controls** are designed to detect, log, and alert after an event has occurred. These controls will not block actions from occurring, instead they can be used to provide notifications, generate incidents, or initiate automation to address the violation. Detective controls can be helpful in validating that preventative controls are working, auditing an environment, building automated responses to address violations, or measuring the success of process changes. The sooner a guardrail can be evaluated in the deployment process the better. Implementing preventative guardrails in the deployment process allows compliance risks to be caught earlier and before an attempt to deploy resources even occurs. Identifying risk earlier also saves time during deployments. Building controls into the deployment workflows allows for the inspection of code against standards which can enforce guardrail compliance as resources are being provisioned. # Provision baseline standards to isolated resource environments Provision baseline standards to isolated resource environments In addition to provisioning guardrails to isolated resource environments, it is also necessary to provision other baseline requirements within the environment. This can include roles, network components and connectivity, and security applications or services. In order to maintain consistency in configuration across different resource environments, the baseline configuration should be deployed in an automated fashion in existing or newly created isolated resource environments. This can include roles, network connectivity, or operational or security services. It is often helpful to be able to apply baseline configurations globally (to all isolated resource environments) or to logical groupings of the isolated resource environments. Global baselines will apply to all isolated resource environments and therefore should be considered carefully. Isolated resource environments should be grouped and organized in a way that allows baseline configurations to be applied to the logical grouping of environments. For example, it is common to apply stricter controls on production environments than in development environments. Therefore, production environments should be grouped in a way that allows for different baseline configurations to be applied to production environments and development environments. Once the different stakeholders are identified, we recommend you align them to the [Shared Responsibility model](https://aws.amazon.com/compliance/shared-responsibility-model/). This will enable you to define a cloud operating model for your environment, where all the different teams involved in creating or enhancing your environment are aware of what needs to be done to move forward. Processes and standards are easier to manage, and they are visible across your organization. # Provision pre-approved deployable architectures Provision pre-approved deployable architectures As you adopt the cloud you will see common workload patterns emerge, which may include standard 3-tier web applications, serverless frameworks, or many other architecture patterns. At the same time, certain skill sets may vary as teams learn to leverage the cloud. Common patterns may be implemented with any number of variations, along with potential for limited people knowledge has a risk to deploy non-compliant workloads. Pre-approving and building a pattern library will provide a common and repeatable mechanism to maintain controls and boundaries around workloads. Instead of application teams relying on run-book, process documentation, or lengthy review processes, cloud platform teams can publish ready to deploy patterns which include common resources along with included control guardrails. For example, a 3-tier web app will include a typical set of compute instances placed within the appropriate public and private network segments to prevent accidental exposure to internal systems. # Decommission process for isolated resource environments Decommission process for isolated resource environments There are various situations when your organization may need to decommission one or more isolated resource environments. For example, you may have a resource environment exclusively designed for and used by a single application that is being decommissioned, you may be using sandbox (disposable) environments, or you might have misconfigured a resource environment during your testing or development phases and determine that the best path is to delete the entire environment. For any situation that requires the decommissioning of isolated resource environments you will want to ensure a consistent termination workflow is in place to prevent unintended charges for resources no longer needed. Additionally, you will want to disable access to the resource environment during any interim waiting period while your resource environment is being terminated. Similar to how you would approach provisioning isolated resource environments, you will want to have a request process in place for decommissioning isolated resource environments. You should ensure that any dependencies with other isolated resource environments are no longer needed before decommissioning. Internal policies and compliance needs should guide how persistent data within the environment is either deleted, or safely transitioned into a separate environment. We recommend that you carefully consider what assets from the environment should be retained, and how they should be retained. For example, consider retaining assets that could add value to your business in the future or that could augment future projects by transitioning them out of the resource environment prior to termination of the environment. The decommissioning process should be documented and include guidance on the required steps in the workflow. This might include: + A method for determining if any assets or data within the environment should be retained. + Applying restrictive controls on the isolated resource environment for a period of time to prevent the use of the resources but allow a recovery process, if necessary. + A process or automation for disabling resources or deleting data.