I have a old vm on microsoft azure, that I need to delete. There are a bunch of resources over that vm (vnet, public ip, disk, ...)
As I don't want to have unused resources, is it possibile to list all resources linked to another?
thank so much!
N.
there is nothing built-in in Azure to achieve this, kinda. One way of doing this (if you are not using shared virtual networks, backups, etc) is to put all the resources that logically relate to the vm in the same resource group and just delete the resource group.
an alternative would be to create a script to delete all the related resources along with the vm
I want to deploy multiple machines across various geographical regions to serve my application in a Development and Production environment; I'm coming from Google Cloud Platform where my solution would be to create 2 projects:
project-dev
project-prod
With that I have complete freedom of creating resources in any region/zone in either project/environment.
The closest thing to this I have found on Azure is Resource Groups, but those are tied to a specified region, which is not ideal for me. Is there a better way, rather than creating a resource group in EACH region I choose to deploy resources for both environments as follows:
project-dev-east-us
project-dev-west-us
project-dev-west-eu
project-dev-east-as
project-prod-east-us
project-prod-west-us
project-prod-west-eu
project-prod-east-as
Resource groups are tied to regions, but resource inside are not, so you can have resources from multiple regions in a single resource group. but resource group is like a folder on a hard drive. its just a way to logically organize things, nothing more.
Can we use same subscription in different Azure region. I want to create different Virtual Networks in different region and design protocol to communicate these regions.
Regards
Abdul
Yes, you can easily use the same subscription to spin up resources in other regions in Azure.
What regions you can use depends on your subscription type though. If you use any of the Azure credit offers you will find that certain offers has limits on the regions they can activate resources in.
I would recommend that you simply test by making a resource group in Azure in the region you want to test with, then create a new Azure Virtual Network in that resource group (which will per default have the same region).
This shows you the regions available to you. Repeat for each region you want a network in.
If you wish to connect the Azure Virtual Networks in different regions with each other you can setup Azure Virtual Network Peering
A little side note.
Not all types of resources are available in all regions. I would recommend checking what regions are available in the Azure Region Map, then check the Offers by Region page to see if the product you want to use is available in your chosen region.
I have created few virtual machines with same ResourceGroup and NetworkSecurityGroup. I am not using custom DNS but default one.
Now, I want these machines to talk each other, can use shared folders of each others and so on.
For example: VM named Machine-2 can access shared folder of another VM Machine-1 like: \\\Machine-1\SharedFolder
I have gone through some similar threads like below:
Azure VMs Virtual Network inter-communication
https://azure.microsoft.com/en-us/documentation/articles/virtual-networks-name-resolution-for-vms-and-role-instances/
Right now, these VMs are even not ping-able from others.
You should look at Azure Files. It exploits your existing storage account and it is very easy to use.
I'm new to Azure architecture and am trying to understand why Azure Resource Groups, which are logical deployment buckets for applications built on Azure, are associated with a region when they are defined.
At first I thought it was to provide global distribution for disaster recovery or geographic redundancy, but then I realized that a single Resource Group can contain web apps in different regions, which can provide those features via Traffic Manager. I suppose that using separate Resource Groups would help better identify which resources are in which region, but other than for organizational purposes, I can't understand what the region definition for Resource Groups implies.
(edit: removed general advice query to be more focused)
The main reason for specifying the location of a resource group is to specify a location for data/metadata for the deployment to be stored in... It also makes the API consistent (think of the paths in REST API calls) but the primary reason is storage during deployment.
The location of the resources in the group is independent/not related to the location of the group itself.
When creating a resource group, you need to provide a location for that resource group. You may be wondering, "Why does a resource group need a location? And, if the resources can have different locations than the resource group, why does the resource group location matter at all?" The resource group stores metadata about the resources. Therefore, when you specify a location for the resource group, you are specifying where that metadata is stored. For compliance reasons, you may need to ensure that your data is stored in a particular region.
https://learn.microsoft.com/en-us/azure/azure-resource-manager/resource-group-overview
The meta data (definition) of the Azure resource group needs to be stored somewhere. hence the location. However, resources inside a resource group are location independent and can be placed in a different region\location.
Do note that dependencies between resources can exist. A Virtual machine in West Europe obviously needs a storage account in West Europe as well, but a SQL database in the same resource group can exist in West US.
Resource groups are basically for you to decide which resources in your application you want to manage together and by manage I mean you want to deploy, manage, and monitor them as a group so at a high level you do not see them as separate components.
In general in a big ecosystem, Azure resource groups are the ones that you do not see those components(resources) in them as separate entities, instead you see them as related and interdependent parts of a single entity so you put them in one Resource Group so that using the Azure Resource Group Manager tool You can deploy, update or delete all of the resources for your application in a single, coordinated operation.
You use a template for deployment and that template can work for different environments such as testing, staging and production. You can clarify billing for your organization by viewing the rolled-up costs for the entire group.
You can find more details on Azure Resource Manager here which I believe will help you better understand the idea behind the Azure Resource Groups:
https://azure.microsoft.com/en-us/documentation/articles/resource-group-overview/
Everything in Azure relates to a physical location/Datacenter, and ARM is no different. A little while ago, not every Datacenter supported ARM, so the reason for choosing made even more sense. Now, like any other Azure resource, the decision is for the user to make, often based on their required proximity to the end user and/or legal geographic requirements.
It appears there is no obvious way to determine what region a resource group is in after it has been created. This has caused me grief per the discussion here, when I ran into problems with CDN metadata conflicts. I had to start over. Now I name my resource groups with the region. e.g.: my-resourcegroup-westus