Is there an absolute maximum length of Azure Resource IDs, independent of the resource type?
Some parts of the structure are fixed (like subscription id) and others like group and resource name have documented limits. But RP namespace and resource types seem to add some unknown into the mix.
/subscriptions/{subscription-id}/resourceGroups/{resource-group-name}/providers/{resource-provider-namespace}/{resource-type}/{resource-name}
Related
This is probably an elemental question, but why would you want to ensure that resources are deployed to the same locations as their resource groups? I'm getting out of compliance issues with HIPPA and from CloudSploit about this and I'd like to get some more details around it as I know it deals with meta data but I'm not crystal clear.
Thanks in advance
Resources within a resource group need not always be deployed in the same location as the resource group. But there is a built-in Azure Policy available to audit this condition that one may choose to enable.
The resource group location serves two purposes:
First: The resource group stores metadata about the resources. When you specify a location for the resource group, you're specifying where that metadata is stored. Now, for compliance reasons, you may need to ensure that your data is stored within a particular region.
Second: If the resource group's region is temporarily unavailable, you can't update resources in the resource group because the metadata is unavailable. The resources in other regions will still function as expected, but you can't update them.
For knowing more about the factors to consider while defining your resrouce groups, check the Azure Resource Manager documentation.
my goal is to limit the creation of resource type per owner/collaborator of a specific Resource Group.
Example:
User_Group_XXX accessed by account YYY:
MAX 2 VM - Standard D2s v3
MAX 1 Kubernetes Cluster with 2 node - Standard DS2 v2
NO more than that and NO other type of resources.
How can I include those limits?
this is not possible by definition. Azure Policy looks at individual resource properties, so there is no way to have it do something like that (so check other resources and apply policy based on those resource to a the resource in question).
although, you could easily create a policy to only allow virtual machines\aks clusters.
again, policies cannot be scoped to users
I am preparing a script, and I need the get a specific ID of a resources, I tried to use get-azurermresource but it gives me only value like - ResourceId. For me this is not an unique ID of this resorce because when we remove resource and re-create it with the same name mentioned ResourceId will be the same. I am able to get this unique ID in case of Azure VM, using cmd-let --> GetAzVM, I got --> VmId : 604f7764-7ffe-4be0-b313-81ca9deda5ad. But what about the rest of the resources? is there any method to get mentioned "unique ID" for other resources?
As far as the Azure platform is concerned, the ResourceID is the uniqueID. It contains the subscriptionId, and the name of the resource. While you are correct, if you delete a resource and create another of the same name in the same subscription it will have the same ResourceID, it still uniquely identifies that created resource at that time.
The VmId is an outlier that is used to uniquely identify not only that VM, but that VM across other VM deployments that might be created, deleted, and recreated. This is useful for things like licensing because it's set at the SMBIOS level and can't be changed. Most, if not all, other resource types don't have this type of identifier.
If you want something that will identify a resource across different deployment instances, that may be harder to do with information direct from the platform. You might have to handle that on your own. Tags might be an option depending on what you are trying to accomplish.
To get a truly unique ID you will need to incorporate your subscriptionID along with ResourceGroupName and Provider. That is how we do it on our backend. For example, a VM disk's ResourceID for the service fabric would look something like this (get-azurermresource will show this):
/subscriptions/a4cd20a0-af7c-4278-8875-dc54076450f8/resourceGroups/MY-ResourceGroup/providers/Microsoft.Compute/disks/my_dev_disk00455
I am new to Terraform and trying to create some resources on Azure. To me it looks like there is some unnecessary duplication between the resource name and the attribute name in the definitions.
resource "azurerm_resource_group" "group_name" {
name = "group_name" # <-- repeated!
location = "${local.location}"
}
Is there a difference? Can I somehow set them to be the same in the spirit of this:
resource "azurerm_resource_group" "group_name" {
name = "${name}"
location = "${local.location}"
}
The two names here serve different purposes and have different scopes.
The name that appears in the block header is a local name used within a single Terraform module. It is useful when interpolating results from one resource into another, like ${azurerm_resource_group.group_name}. The remote API never sees this name; it is used only for internal references.
The name within the block is an attribute specific to the resource type itself -- azurerm_resource_group in this case. This name will be sent to the remote API and will be how the object is described within the AzureRM system itself.
In simple configurations within small organizations it is indeed possible that both of these names could match. In practice, the difference in scope between these names causes them to often vary. For example:
If there are multiple separate teams or applications sharing an AzureRM account, the name used with the API may need to be prefixed to avoid collisions with names created by other teams or applications, while the local name needs to be unique only within the module where it's defined.
In more complex usage with child modules, it's common to instantiate the same child module multiple times. In this case, the local name will be the same between all of the instances (because it's significant only within that instance) but the name used with the API will need to be adjusted for each instances so that they don't collide.
The resource name is the name you use to refer to the resource in Terraform context. The name parameter is the name given to the resource inside your provider's context. Resource don't have to have a name parameter, for example AWS Elastic IP resource doesn't have a name because AWS doesn't allow you to name them. Some of the resource like AWS Security group rule don't even translate one to one to resources you can name.
I understand that resources from different locations can all reside within one resource group. But when creating a new Resource Group, what is the purpose of choosing a location? Does it have any meaning?
Thanks
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
Actually it does matter:
Azure Resource Manager overview:
If the resource group's region is temporarily unavailable, you can't update resources in the resource group because the metadata is unavailable. The resources in other regions will still function as expected, but you can't update them.
For more information about building reliable applications, see Designing reliable Azure applications.
So we could imagine a situation where resource group is defined in LocationA, and all resources in that group are located in different region. When resource group region is unavailble then they may be issues when accessing metadata. Without metadata, it may not be able to failover.
Most templates in Azure ask you to specify a location(which is Azure Data Center Location) for each of the resources in a resource group.
Every resource is located in an Azure data center, but not every Azure data center supports every resource type.
Select any location that supports the resource type. You do not have to create all of the resources in a resource group in the same location;
However, whenever possible, you will want to create resources in the same location to optimize performance.
In particular, you will want to make sure that your database is in the same location as the app accessing it.
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