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.
Related
As an MSP, we manage multiple customer subscriptions through Azure Lighthouse.
Historically we've used a single Automation Account per subscription to contain solutions such as runbooks related to the Start/Stop v1 solution, Automation-based Update Management, Inventory, and Change Tracking. This Automation Account is also linked to a single Log Analytics workspace per subscription.
We've since deployed Start/Stop v2, which uses LogicApps and Azure Functions. We now have a requirement to, as part of stopping and starting some VMs, stop and start some services on the machines itself. I plan on doing this through (PowerShell) Azure Automation Runbooks, which would only stop a VM if the runbook has successfully stopped a service on it.
My question relates to whether a single monolithic Automation Account is the way to go, or whether there are any considerations to be taken if we were to implement multiple Automation Accounts.
(I've noticed Best practice to deploy Azure Automation Account Runbooks, but that's over a year ago. Things might have changed in the mean time)
The best practice related question which you have mentioned still holds good i.e., 2 major attributes to consider are pricing and logical resource allocation. One other attribute to keep in mind while deciding whether to go with single or multiple automation accounts is the limits i.e., if you go with single automation account then does the traffic in your environment or the activities that your automation account does reach the limits mentioned here? If yes, then go for multiple automation accounts approach.
Issue: I am planning to move my Azure Resources to another subscription but as an impact analysis I want to know if Access Keys to a resource such as Storage, Batch Services will be affected.
I have more than 30 services which are currently in use. I am looking forward to having least possible downtime and so I need to analyze what all services will be impacted.
I am aware of the resources which are possible to migrate from the Microsoft page: https://learn.microsoft.com/en-us/azure/azure-resource-manager/resource-group-move-resources.
Here are my few questions, I would like to know the answers in all possible cases such as migration to different directory/Azure Active directory or common Azure Active directory.
Will the Access Keys to a resource such as Storage, Batch Services etc.. will be affected after I migrate my resource to another subscription?
Do I need to reconfigure the Service Endpoints?
Thanks.
They wont change
No, storage account endpoints are not tied to resourceId
We are looking to move/create 3 websites with Azure Web Apps, and would like to determine the best design for Resource Groups to use with this.
These 3 websites (website1, website2, and website3) would all point to the same database.
We would like to have a deployment cycle like this:
Azure Web App (AWA1) – website1-dev (DB: CompanyDb-dev; File Storage: CompanyFiles-dev) (Service Plan F1 (Free))
AWA2 – website1-qa (DB: CompanyDb-dev; File Storage: CompanyFiles-dev) (Service Plan F1 (Free))
AWA3 – website1 & website1-staging (slot) (DB: CompanyDb; File Storage: CompanyFiles) (Service Plan S1, S2, or S3)
So, for website1 we could Publish to –dev, -qa, or –staging, and –dev and –qa would use the –dev database and file storage, while –staging and prod would use the prod database and file storage.
So, my question(s), would it make sense to have the 3 Azure Web Apps, the 2 databases, and the 2 file stores in the same Resource group?
If our other two websites will also make use of CompanyDb, should they (and their related development Azure Web Apps) be in the same resource group? Or their own resource group?
According to the Azure Resource Manager overview documentation page.
All of the resources in your group should share the same lifecycle. You will deploy, update and delete them together. If one resource, such as a database server, needs to exist on a different deployment cycle it should be in another resource group.
From that you should consider which pieces can be grouped together as a lifecycle. What group could you safely delete and recreate without affecting the other groups.
From that, it probably safest to have a DB resource group, and each Website in its own group. That way you could probably just have two templates (a db and a website) and deploy those as much as you need.
This is more of a personal preference question. Resource Groups are just for logical grouping of your resources, it doesn't actually affect much implementation wise.
So go with whatever you think is most convenient.
As a side note: instead of creating three different web sites, have you guys considered using Site Slots?
I just read a small post of #pierreroman with the title Azure Cloud Service VS Azure Resource Manager. Unfortunately I was not able to comment his post (There was an error saving your comment. (Cannot create comment - access denied.)). Therefore and because I think this topic is interesting for many folks who are using azure cloud services right now, I write my "comment" here and send him a tweet. Maybe he or someone else can answer my questions.
I think that more interesting than the "what is the difference between cloud services and resource groups" is the question "should we plan to move from cloud services to azure resource groups?". Is it even possible? Or are we comparing apples to oranges?
What about scaling (for example adding new instances of a worker role with a simple slider or with auto scaling)?
The comparison is kind of apples(Cloud Service) and grocery(ARM) where can manage fruits, meats, and fishes.
But, very first concept of Cloud Service was similar to the ARM. That's why sometimes confusing.
Below quote is from free ebook Azure Web Apps for Developers (download), page 12 and 13.
An Azure Resource Group is a logical container for grouping Azure resources.
Grouping resources this way helps simplify the implementation, deployment, management, and monitoring of resources in the resource group. From a billing perspective, it gives you a way to view costs for the resource group rather than for individual resources, eliminating the need to figure out which resources are related. You can think of an Azure Resource Group as a unit of management.
The last line helps to understand clearly, Azure Resource Group is a unit of management.
I've created a Hosted Service that talks to a Storage Account in Azure. Both have their regions set to Anywhere US but looking at the bills for the last couple of months I've found that I'm being charged for communication between the two as one is in North-Central US and the other South-Central US.
Am I correct in thinking there would be no charge if they were both hosted in the same sub-region?
If so, is it possible to move one of them and how do I go about doing it? I can't see anywhere in the Management Portal that allows me to do this.
Thanks in advance.
Adding to what astaykov said: My advice is to always select a specific region, even if you don't use affinity groups. You'll now be assured that your storage and services are in the same data center and you won't incur outbound bandwidth charges.
There isn't a way to move a storage account; you'll need to either transfer your data (and incur bandwidth costs), or re-deploy your hosted service to the region currently hosting your data (no bandwidth costs). To minimize downtime if your site is live, you can push your new hosted service up (to a new .cloudapp.net name), then change your DNS information to point to the new hosted service.
EDIT 5/23/2012 - If you re-visit the portal and create a new storage account or hosted service, you'll notice that the Anywhere options are no longer available. This doesn't impact existing accounts (although they'll now be shown at their current subregion).
In order to avoid such charges the best guideline is to use Affinity Groups. You define affinity group once, and then choose it when creating new storage account or hosted service. You can still have the Affinity Group in "Anywhere US", but as long as both the storage account and the hosted service are in the same affinity group, they will be placed in one DataCenter.
As for moving account from one region to another - I don't think it is possible. You might have to create a new account and migrate the data if required. You can use some 3rd party tool as Cerebrata's Cloud Storage Studio to first export your data and then import it into the new account.
Don't forget - use affinity groups! This is the way to make 100% sure there will no be traffic charges between Compute, Storage, SQL Azure.