A Dev/Test Lab normally doesn't exists out of one VM. Probably it will have multiple VM's, some are Azure default Images some are custom made images. Also a Dev/Test Lab won't be used by a single team, but more teams will probably use and reuse the Dev/Test Lab artifacts.
A Dev/Test Lab will probably not exist in on Azure Subscription, certainly not a MSDN subscription. But, will be exist out off multiple subscripting in an Azure Enterprise Enrolment.
This all needs to be controlled, managed so teams can work fast and flexible, reuse each others work without loose control of the moving artifacts and, for certain, without loosing grip of the costs. (see image: Azure Dev/Test costs almost out of control)
A good practice is to have an Azure subscription per project.
A subscription per project gives a clear separation of costs and clear rights management. Via network configuration a separation can be made between Development, Test, Staging and Production.
Another way for Azure Subscription organization, is to create a subscription per environment type (develop, test, staging, production). Mainly done for security reasons (not really relevant reason anymore with the current RBAC capabilities of the new Azure). The cost separation and control can also be a reason for this separation, you get a bill per environment and it easy to see what the costs are for these environments. Also this reasons isn’t very relevant any more when using Resource Groups and tags (although only usages is available in the new API’s for this not in the billing API).
With multiple Azure Subscriptions comes additional costs when there is a need for a network in the Dev/Test lab (which in most situations is). It isn’t possible to share a network with other subscriptions, so every subscription needs there own network configuration.
Conclusion, an Azure subscription in the Azure Enterprise Enrolment per project is a good practice.
These projects with there own subscription probably will reuse artifacts from each other. For example a development machine with the same Visual Studio 2015 Enterprise configuration or a Database Server configuration for testing. See Versioning : Dev/Test Lab Management in the Cloud.
Using Azure Custom Images, with preinstalled software and configuration, can be reused between projects. From a ‘Golden’ Image Repository (an Azure subscriptions storage account) can images been copied to other Azure subscriptions where they can be used to create develop, test, staging or production environments.
Copying the image from one subscription to an other can be done via PowerShell, there are many examples to find on Internet (list below). It is good to be aware where you are going to use the Image, for an ‘old’ V1 Azure Virtual Machine or for ‘the new’ V2 Azure Resource Manager provisioning. The used storage must be the same version.
It is a harder job to manage all golden images and images which are copied to the subscriptions. A fire and forget deal, the golden image is copied to the subscription but from that moment it is the responsibility of the project, is an easy solution. When you want to make sure all use the same image some update process needs to be in place.
Sogeti OneShare Image Management.
For controlling the use of images within the Sogeti OneShare solution for different Azure subscriptions we made a small tool (see video). It makes the maintenance of images and updating of subscriptions easier.
A nice site note, it is written with AngularJS, Typescript, WebAPI, SignalR, Bootstrap and EF technologies and for sure hosted on a WebApp with a WebJob and SQL Azure. The App is for internal Sogeti use only, but if you are interested mail me.
See also this deck from slide 34: