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.
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.
I've been reading through the Microsoft Cloud Adoption Framework for some time now. In our company, we have a similar implementation (hub-spoke), but a lot less modular like it is depicted in the docs. We don't have an identity or management subscription for example.
When looking at our own hub-spoke architecture, we basically only have 2 spokes: non-prod and prod in which we deploy all applications (VMs) inside one big VNet (one per spoke). Since we have hundreds of VMs ranging from very small tools on a single VM up to large complex setups with dozens of VMs, we would eventually also have many landing zones (and therefor VNets) I suppose? Our hub contains central shared services like the firewall, domain controllers etc.
Important to know is that we don't do any in-house application development or let other departments like marketing deploy Azure resources themselves. We basically setup Azure infrastructure into the spokes from within our central IT infrastructure department and give external partners access to deploy their applications into it.
What I'm particularly curious about is when you would decide to create a new landing zone in this architecture? Would you have a landing zone for each application? One for each department to enable self-service? Is our approach a good idea?
Very interested to learn how other companies are implementing this architecture.
The big part of enterprise scale landing zone is probably the modules you mentioned that are missing in your implementation.(Or any start small type of land zone)
Enroll in EA so you have an account to manage multiple subscriptions
Have the proper resource organization in place(management groups and
subscriptions).This ensures that you can deploy policies and RBAC
etc at the proper level.
Landing Zone sits on much high level than the applications(resource groups). There is no need for more than 1 Landing Zone. You maybe need to extended it, by either creating new Spoke, and/or in some case new subscription.
We had a legacy monolith website application that is hosted on Azure windows server and had 10 customers using it, now as the application data grows the bandwidth of the application is affecting each customer because they were hosted in single server as a single website. Now the client wants to split the database as per customer separately to reduce the database load, so we divided the databases as per customer.
Regarding the website, we still had a dilemma on how to proceed, so we already divide the databases so we are thinking as
it is better to host each customer website on separate servers?
create a different website on a single server for each and every customer?.
Because the clients want this to be scalable and 100%, that one client’s activities and usage will not affect another, as well as be able to easily distinguish cost.
The client also asked to differentiate how much cost occurring for each customer on the resource groups,
previously we had a shared resource group.
Could anyone suggest how to solve this problem?
If your requirement fits you could leverage Azure App Service WebApps (PAAS solution).
You can host apps in the same App Service Plan or isolate your app into new App Service plan (as per your requirement) by having tradeoff between level-of control and costs.
Or to have greater control on the underlying VMs you could leverage Azure VMs (IAAS solution).
To start with, kindly take a look at this approach - Common web application architectures – monolithic application design using Azure App Service.
You could create the web application as separate App Service apps. This design lets you run them in separate App Service plans so they can be scaled independently. If you don't need that level of scalability initially, you can deploy the apps into the same plan and move them into separate plans later if necessary.
The pricing tier of an App Service plan determines what App Service features you get and how much you pay for the plan.
Azure App Service plan overview
App Service plans pricing
Azure offers a number of ways to host your application code.
Kindly checkout this architecture guide on compute decision choice
Resource Group is a just a container that holds related resources for an Azure solution. The resource group can include all the resources for the solution, or only those resources that you want to manage as a group. It doesn't have direct cost implications, but the resources/services (in this case App Service) under it does.
You may wish to know:
Explore and analyze costs with cost analysis
Prevent unexpected charges with Azure billing and cost management
I want know is there any need to have backup plan? I am just curious about if azure have its policy that they can maintain backup of all application they have installed on there server so is there any need to take extra plan to have separate backup of our own code and database ? Please guide me ?
This purely depends upon the product which you are going to develop/host within Azure. There are several factors like SLA(Service Level Agreements), Compliances, Audit/Policies etc.,
Let say if your product related to healthcare/financial domain. In such a case, you need to follow certain policies, compliances.
Healthcare related products should be HIPAA compliances
Financial/Cards products should be PCI DSS
You can find all the list of compliance with Azure here
The Answer may be not be needed. Azure has a lot of services for managing backups. If your project/product is compliance, Audit, and policies approved by Azure. Then you don't really need a separate backup from your side.
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