Azure Sandbox is a collection of interdependent cloud computing configurations for implementing common Azure services on a single subscription. This collection provides a flexible and cost effective sandbox environment for experimenting with Azure services and capabilities.
Depending on your Azure offer type and region, a fully provisioned Azure Sandbox environment can be expensive to run. You can reduce costs by stopping or deallocating virtual machines (VMs) when not in use or by skipping optional configurations that you don't plan to use.
Architecture
Download a Visio file of this architecture.
Components
You can deploy each of the following sandbox configurations or only the ones that you need:
- Shared services virtual network, Azure Bastion, and Active Directory domain controller
- Application virtual network, Windows Server jump box, Linux jump box, and Azure Files share
- SQL Server on Azure Virtual Machines (VMs)
- Azure SQL Database
- Azure Database for MySQL Flexible Server
- Azure Virtual WAN and point-to-site VPN
Deploy the sandbox
The Azure Sandbox environment requires the following prerequisites:
- A Microsoft Entra ID tenant
- An Azure subscription
- The appropriate Azure role-based access control (RBAC) role assignments
- A service principal
- A configured client environment
For more information about how to prepare for a sandbox deployment, see Prerequisites.
To integrate AzureSandbox with an Azure landing zone, consider the following strategies:
- Place the sandbox subscription in the Sandboxes management group.
- Keep the sandbox isolated from your private network.
- Audit sandbox subscription activity.
- Limit sandbox access, and remove access when it's no longer required.
- Decommission sandboxes after an expiration period to control costs.
- Create a budget on sandbox subscriptions to control costs.
For more information, see Landing zone sandbox environments.
To deploy Azure Sandbox, go to the AzureSandbox GitHub repository and begin with Getting started. For more information about how to deploy your sandbox environment, see Default Sandbox Deployment and known issues.
Use cases
A sandbox is ideal for accelerating Azure projects. After you deploy your sandbox environment, you can add services and capabilities. You can use the sandbox for activities like:
- Self-learning
- Hackathons
- Testing
- Development
- Tabletop exercises
- Red team/blue team simulations
- Incident response drills
Important
Azure Sandbox isn't intended for production use. The deployment uses some best practices, but others intentionally aren't used in favor of simplicity and cost.
Capabilities
Foundational prerequisites can block experimentation with certain Azure services or capabilities. A sandbox environment can accelerate your project by provisioning many of the mundane core infrastructure components. You can focus on the services or capabilities that you need to work with.
For example, you can use the following capabilities and configurations that the Azure Sandbox environment provides.
Connect to a Windows jump box VM from the internet.
- Option 1: Internet-facing access by using a web browser and Azure Bastion
- Option 2: Point-to-site VPN connectivity through Virtual WAN
Use a preconfigured Active Directory Domain Services local domain as a domain administrator.
- Preconfigured integrated DNS server
- Preconfigured integration with Azure private DNS zones
- Preconfigured integration with Azure Private Link private endpoints
Use an Azure Files preconfigured file share.
Use a Windows jumpbox VM as a developer workstation.
- Domain joined to local domain
- Administer Active Directory and DNS with preinstalled Windows Server Remote Server Administration Tools (RSAT)
- Visual Studio Code preinstalled with Remote-SSH into a Linux jump box
- Azure Storage Explorer, AzCopy, and Azure Data Studio preinstalled
- SQL Server Management Studio preinstalled
- MySQL Workbench preinstalled
Use a Linux jump box VM as a DevOps agent.
- Domain joined to local domain using Winbind
- Azure CLI, PowerShell, and Terraform preinstalled
- Dynamic CIFS mount to Azure Files preconfigured file share
Use a preconfigured SQL Server VM.
- Domain joined to local domain
Use a preconfigured SQL database or Azure Database for MySQL Flexible Server through private endpoints.
Security
Security provides assurances against deliberate attacks and the abuse of your valuable data and systems. For more information, see Design review checklist for Security.
Important
Sandbox environments represent an attack surface that can be exploited. To reduce risk, consider the following security best practices.
Implement strong authentication in the Microsoft Entra ID tenant associated with Azure subscriptions used to provision sandbox environments. Follow the recommendations in SE:05 - Recommendations for identity and access management.
- Use multifactor authentication (MFA) for all users.
- Use conditional access policies to restrict access to sandbox environments.
- Use integrated Microsoft Entra authentication to authorize access to Azure platform as a service (PaaS) services like SQL Database and Azure Storage.
Start with a least privilege approach to authorize sandbox use.
- Limit
OwnerAzure RBAC role assignments to sandbox subscription owners. - Limit
ContributorAzure RBAC role assignments to sandbox subscription users. - Use Microsoft Entra Privileged Identity Management (PIM) to manage privileged Azure RBAC role assignments scoped to sandbox subscriptions, such as
Owner,Contributor, andUser Access Administrator.
- Limit
Maintain your data classification compliance. For example, avoid hosting personally identifiable information (PII) or other sensitive data in a sandbox environment. If you must use sensitive data, use synthetic data or deidentified data.
Also, consider the Secure Futures Initiative principles when you're designing and implementing sandbox environments. The AzureSandbox implementation on GitHub showcases many of these principles.
Secure by design
Limit the use of shared secrets and use Azure Key Vault to secure them when required. When you have to use shared secrets, use managed identities at run time to retrieve from Key Vault. If secrets must be persisted, ensure that they're encrypted and not stored in plain text. Never echo secrets to the console or to log files, and never check secrets into source control.
Set an expiration date for Key Vault secrets.
When you select a guest operating system (OS) for VMs, only use OSs that are currently supported and eligible to receive security updates.
Secure by default
- Use encryption as recommended by SE:07 - Recommendations for data encryption.
- Ensure that cryptographic protocols and algorithms, such as TLS 1.2 or higher and SHA-256 or higher, are up to date.
- Consider using host encryption or Azure Disk Encryption for encryption of data in transit. For managed disks attached to VMs, data is encrypted at rest by default.
- Avoid the use of public IP addresses. Use Azure Bastion for secure remote access to VMs.
- Use private endpoints to communicate with Azure services.
- Disable public network access to Azure services like Storage and SQL Database.
Secure operations
Enable Microsoft Defender for Cloud CSPM on sandbox subscriptions.
Enable Azure Update Manager on all VMs that are used in sandbox environments. Set a regular patching schedule.
- For SQL Server VMs, enable first-party updates in Windows Update to ensure that SQL Server is patched.
Monitor activity and diagnostic logs with Azure Monitor and Microsoft Sentinel.
Decommission individual sandbox resources and whole sandboxes that are no longer in use.
Contributors
This article is maintained by Microsoft. It was originally written by the following contributor.
Principal author:
To see non-public LinkedIn profiles, sign in to LinkedIn.
Next steps
- Develop and test on Azure
- Microsoft Cloud Adoption Framework
- Cloud Adoption Framework Azure setup guide
- Microsoft Azure Well-Architected Framework
- Technology choices for Azure solutions
- Best practices for cloud applications
- Build applications on the Microsoft Cloud
