I was wondering if someone could help. Is it possible to share resource groups between azure subscriptions;
A little bit of background, I have two subscriptions in azure under one tenant, I am after setting up a VPN between each of the subscriptions, however I am yet to find a solution that doesn't involve sharing a resource group to allow connections.
With this in mind, is it possible to share resource groups between subscriptions or does it have to be in the same subscription?
If this is the case, how would I go about setting up a VPN between subscriptions.
Resource groups have nothing to do with using or connecting services. They're just an organizational (and security) boundary for viewing/configuring/changing resource settings, deleting resources, etc. Resource Groups are specific to a given subscription.
There's absolutely nothing stopping you from connecting services across subscriptions, as long as you know the passwords/access tokens/certificates/etc.
No, you cannot share resource groups across subscriptions (not that it makes sense in the first place). You can either create a site-to-site VPN or (better) create a peering between virtual networks across the subscriptions.
Peerings are free, easy to setup and don't require any management. Peerings work cross subscriptions and cross tenants (as of november 2019 afaik).
Related
Currently, we have our own Azure active directory and azure subscription for our organization. Now I want to On-Board different organizations and users in different organizations into our Azure. infrastructure. I want to manage resources for all the organizations and want to get billing details of each organization.
There are two ways to On-Board different organizations
Create separate AAD and Subscription for each organization - Clear separation between organizations makes it easier to get billing details for each resource group. But this option could not be cost-effective as we need to create the same resource for each organization
Create an AAD group for each organization in our Azure active directory and use our main subscription for all organizations - We need to add resource tagging to each Azure resource to get the usage details and billing for each organization. This could be cost-effective but will not get the all the features of azure cost management like alerts, budget, etc.
Please let me know which option should be used in this scenario while On-Boarding a large number of organizations and users?
Let me know other Pros and Cons of each option.
I recommend to go with the separate Azure Active Directory along with separate subscriptions so that you can track the billing details for each organization.
We cannot track the billing details with single subscriptions for each organization separately. You can have one billing for 2 subscriptions and you cannot have more than billing for 2 subscriptions. Kindly check this link to get more information and see if it helps. If you have any further queries kindly let me know
Today I am noticing that the Azure Group, I dont know when Azure created the
"DefaultResourceGroup-EAU" resource group, and in this group two item is placed
I am not using any Azure Container Registry service and AKS, should I remove this group because it paying in my invoice, I just only have Azure Web Apps and Azure SQL databases and one VM only, should its impact on my above mentioned services after deletion?
certainly not in terms of how those services function, but monitoring might be impaired if you delete those.
Those resources look like they were created alongside AKS cluster. Doesn't mean that they were only being used for that, but highly likely.
I have an Azure subscription and there are a number of services available.
If I configure VM, web apps, application. etc.,
there are few high-end resources which are very expensive.
In order to avoid unwanted billing,
I want to create a policy that allows only a few services and lower configuration resources.
Is there an Azure policy that can do that?
If I configure VM, web apps, application.. etc there are few high-end
resources which prices are high. In order to avoid unwanted billing, I
want to create policy there allow only a few services and lower
configuration resources
Do take a look at Azure Policy. In short, Azure Policies enables Cloud Governance and by defining proper policies, you can restrict creation of certain kinds of resources, disallow certain SKUs for resources and more.
However, as a good practice, you should have only few people in your organization who have the capability to provision resources and there should be a formal procedure for provisioning resources. One of my friend burned $180,000 in Azure in just 3 months because every developer in his team has the capability to create resources in the company's Azure Subscription. The developers in the team created resources as they pleased without thinking about pricing implication.
I have been tasked with building a PoC in Azure to "simulate" a future global deployment where data transfer time is important factor. The actual deployment will be using fully on-prem resources. So, as odd as it sounds, I am looking for the worse performance possible between the two options.
Architecture A (single tenant):
Create a single Azure tenant in the US region
Create a Resource Group with a US-based location
Create another Resource Group with an EU-based location
Architecture B (dual tenant):
Create an Azure tenant in the US region with a US-based RG
Create an entirely separate Azure tenant in an EU region with a EU-based RG
Would the dual-tenant structure above make any measurable difference one way or the other from the single-tenant (assuming all vNetwork, VMs, etc are identical)? I am thinking the single-tenant setup would be faster since (presumably) the traffic never leaves the Azure Service Fabric. But that's just speculation.
Here is what I got back from a colleague. She is (obviously) far more versed in Azure IaaS than I am. Answer #3 below indicates that the closest analog to the client MPLS connection is via VPN/ER. Not really worth the cost but still good to know.
Can a single subscription be used to provision US and European region located resources? Yes
Can resources in US and European located regions be managed from a US based portal? Yes
When allowing resources in US and European located regions communicate with one another what are our options? A couple primary ways...
Intra-regional (tenant to tenant:region to region)
Communications can be provisioned to travel across the Microsoft Azure
backbone. It never hits the open Internet.
VPN or Express Route:
Travels either the open internet or a private in TLS like route from
one region to another. However express route, the mpls like option,
does require advanced routing (BGP) and dedicated circuits at I other
point from different connectivity providers. Also, expensive.
I'm new to Azure and am working on some basics that I can't find any consistent information on at the Microsoft Azure site.
My understanding is that the use of Affinity Groups makes sure your virtual resources are very close to each other. So I created an affinity group for West-US. Then I created a cloud service which I'm going to use for my AD controllers. I assigned my affinity group to it. When I created my VM and selected my ad cloud service, I could not select the local network I had created. I could only place a VM in my local network only if a region was assigned during the creation of a cloud service as opposed to using an affinity group.
Can someone please shed some light on the practical use of when and where I create affinity groups, if at all?
Thank you.
Affinity groups were historically a way to ensure proximity between Azure compute and Azure Storage. Until about three months ago a VNET also had to be created in an affinity group. One of the problems with this is that an affinity group is tied to physical hardware in a datacenter so that when new hardware came along (such as high-memory SKUs) a cloud service or VNET hosted in an existing affinity group could not get access to it. This led to some frustration.
Any VNET created now should be a regional VNET NOT an affinity-group VNET - i.e., one hosted in a region not an affinity group. In fact, you can only do the former in the Azure portal. I suspect that much of the motivation for using an affinity group disappeared when Azure migrated to a flat high-speed network a couple of years ago.
I recently blogged a more extended discussion of affinity groups.