Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Workloads are logical groups of Azure resources that you define inside an Azure Enclave. You link Azure resource groups to a workload resource to bring those resource groups into the security and control boundary of the enclave. For an illustration, see the architecture diagram.
Community and enclave owners can create isolated mission-critical workloads, and then allow specific access as needed. When you deploy Azure resources and services into workloads, each workload automatically inherits the enclave's security posture and policies.
You create your own Azure services in your workload resource groups and maintain those resources under the shared responsibility model in the cloud. Workloads can also reach community services through the enclave connections that are configured for their enclave.
Why use a workload?
Workloads are a logical way to organize your Azure resource groups and create a link to your Azure Enclave environment. Policy assignments are applied at the scope of each linked workload resource group, so the resources you deploy there must comply. The policy set itself comes from the enclave's governed service list, or from the community's list when the enclave doesn't define one, and every workload in the enclave inherits it. Workload resource groups have some restrictions, which are described in Best practices for Azure Enclave.
The alternative is to deploy an Azure resource group through the portal that isn't linked to a workload. Workload resource groups are equivalent to normal Azure resource groups with the added benefit of keeping the resources secured within the enclave boundary. Deploying a normal Azure resource group through the portal is still an option, but a normal Azure resource group wouldn't be secured within the enclave boundary.
Architecture of a workload
Workloads are child resources of enclaves. Each workload references its workload resource groups by resource ID in the workload's resourceGroupCollection property. Those resource groups remain standard Azure resource groups, so they aren't Azure Resource Manager child resources of the workload.
This diagram shows two example workloads. The Shared Workload is linked to three workload resource groups and the AKS Workload is linked to one workload resource group. Resource groups are highlighted in green and Azure resources are highlighted in dark blue.
Workload resource group
When you create a workload in your enclave, specify the workload resource groups to link to it. Azure Enclave creates the resource groups that don't exist yet and links the existing resource groups. An existing resource group must be empty, must be in the same subscription as the workload, and can't already be linked to another workload.
For more details regarding workload resource group best practices and guidelines, learn more about Best practices of workload resource groups.
What can I add to my workload?
The workload resource groups function like an Azure resource group. You can deploy Azure resources that comply with the policies assigned to the workload resource groups. Create new resources by using the methods you're familiar with for your Azure resources. You can also create resources from the Azure portal through the service catalog. For more information, see What is the service catalog?
Next steps
- Tutorial: Create a workload
- Tutorial: Workloads in Azure Enclave
- What is the service catalog?
- What is an enclave?
- What is a community?
- What is Azure Enclave?
- Azure Enclave governance
- Best practices
- Shared responsibility model in the cloud
- Well-Architected Framework workload guidance
- Well-Architected Framework service guides