Azure Portal
The Azure Portal is where a deployed Azure environment either makes sense or doesn't. Teams who have configured it properly see cost trends, active alerts, resource health, and compliance gaps from one screen. Teams who haven't are navigating a list of resources with no context for what they're running or why.
We configure Azure Portal for development teams and agencies who need the portal to show them what matters — not just give access to everything at once.
Azure Portal as the Operational Control Plane for Your Azure Environment
Most Azure deployments treat the portal as the provisioning interface — the place you went to create a resource before Terraform or Bicep took over. That is a limited use of what the portal provides. A well-configured Azure Portal is the operational visibility layer for a running production environment: custom dashboards showing the metrics the team cares about, cost alerts that fire before a budget is exceeded, resource health monitoring that flags an impaired service component before support tickets arrive, and role-based access that gives each stakeholder exactly the view their role requires.
The portal does not configure itself. Default resource groups are not structured for cost reporting. Default access is broader than it needs to be. Default alerts are too noisy to be useful. We set up Azure Portal as a management tool, not just an access point to a list of resources the team navigates without context. See how Azure Portal configuration is applied across our Azure engagements.
Azure Portal Configuration Services
Six operational management services covering every layer of Azure Portal governance.
Azure Portal Dashboard Configuration
Custom Azure Portal dashboards pinned to the resources, metrics, and cost views that matter to each team role. One dashboard for the engineering lead showing service health and active alerts, another for the product owner showing deployment frequency and cost trend, another for the finance stakeholder showing month-to-date spend against budget. Shared dashboards accessible to every team member with the appropriate access role. White-label portal configuration available for agency clients who need a clean view of their own environment.
Azure Cost Management and Budgets
Azure Cost Management configured with resource group and tag-based cost allocation, monthly budgets with alert thresholds at 80% and 100% of spend, cost anomaly detection enabled, and cost analysis views saved for finance reporting. Azure Cost Management best practices followed throughout. Chargeback views for multi-product organisations or agencies billing Azure costs to individual clients. Forecast alerting so budget overruns are flagged before the invoice arrives, not after.
Azure Monitor Alerts and Action Groups
Metric alerts, log alerts, and activity log alerts configured for the resources that matter to the production environment — not every default alert that generates noise. Action groups routing alerts to the correct channel: email and SMS for severity 1 incidents, Teams webhook for warnings, Azure Automation runbook for self-healing responses where automatable. Alert rules reviewed against the team’s actual incident response process rather than configured in isolation from the people who will receive them.
Resource Governance and Tagging Strategy
Azure resource tags applied consistently across all resources — environment, product, cost centre, owner, deployment method — so cost reporting, access control, and operational filtering all work from a single tagging taxonomy. Resource locks on production resources prevent accidental deletion. Azure Policy assignments enforce tagging compliance on new resource creation. Resource group structure designed for the organisation’s cost allocation and access control requirements, not assembled arbitrarily during initial provisioning.
Azure Advisor and Security Recommendations
Azure Advisor analyses the running environment and produces recommendations across reliability, security, operational excellence, performance, and cost. We implement the high-impact recommendations — right-sizing undersized or oversized resources, enabling soft delete on storage accounts, upgrading deprecated runtimes, enabling backup on unprotected virtual machines — and configure Defender for Cloud to surface the security posture score in the portal. Recommendations are prioritised by impact and implementation effort, not applied wholesale.
Role-Based Access Control and PIM
RBAC assignments scoped to the level where they are needed — resource group, subscription, or management group — rather than granted at subscription scope where every permission applies to everything. Custom roles defined where built-in roles are too broad or too restrictive for the team structure. Privileged Identity Management for just-in-time elevated access to production resources. Access reviews scheduled so stale assignments are identified and revoked rather than accumulating. See how RBAC is structured across our Azure projects.
Structuring Azure Portal Access for Different Stakeholders
The engineering team needs write access to the resources they maintain. The DevOps lead needs visibility across the subscription’s deployment pipeline and alert status. The finance stakeholder needs read access to cost reports without being able to accidentally modify a production resource. The client contact needs a clean dashboard showing service health and spend without navigating the full portal interface.
Each of these is a different RBAC scope and a different portal dashboard. Setting them up correctly means auditing who actually needs what access, defining resource group boundaries that align with access requirements, and building dashboards that surface the right information for each role. The result is a portal that a junior developer can use without accidentally deleting a database, a CFO can use without a training session, and an auditor can access with a read-only account scoped exactly to what they need. Talk to us about the right portal structure for your team.
What We Configure in an Azure Portal Engagement
Four operational management capabilities that make the portal work for your team.
Cost Management Dashboards and Budget Alerts
Resource-level cost tagging implemented so every spend is attributable to a product, environment, or team. Budget alerts at 80% and 100% of spend routing to the relevant notification channel. Anomaly detection enabled so unexpected spending patterns surface before the end of the billing cycle. Shared cost analysis views saved for finance reporting — spend by resource group, by tag, and by service type — accessible without requiring finance to navigate the full portal. Request a cost management configuration walkthrough.
Resource Health and Service Health Monitoring
Azure Resource Health and Azure Service Health configured so production incidents — both Azure platform-level outages and individual resource health degradation — are visible before support tickets start arriving. Service Health alerts routed to the team’s communication channel for planned maintenance, service issues, and health advisories affecting the Azure regions and services in use. Resource Health history checked during post-mortems to distinguish platform failures from application failures. See how health monitoring is applied.
Azure Policy Compliance in the Portal
Azure Policy assignments enforcing governance rules — required tags on all new resources, allowed regions, allowed VM SKUs, mandatory diagnostic settings — visible in the portal’s compliance dashboard. Policy effect configured correctly: Audit for visibility, Deny for hard enforcement, DeployIfNotExists for automatic remediation. Non-compliant resources surfaced in the compliance report. Management gets a real-time view of governance adherence without needing to query the API directly or wait for a periodic audit.
Custom Client-Facing Portal Dashboards
For agencies running Azure infrastructure on behalf of clients, a read-only client-facing portal dashboard gives clients the service health, cost, and deployment activity view they ask for in status meetings — without giving them access to modify anything or see other clients’ resources. We design and publish shared dashboards scoped to the client’s resource group, with the metrics, alert counts, and cost tiles the client’s stakeholders need. Status meetings become shorter when the client already has live visibility before the call.
White-Label Azure Portal Configuration for Agency Partners
Your agency manages Azure infrastructure for clients. Clients ask about their environment in status meetings. You pull up the portal and navigate through resource groups to find the cost view. We configure Azure Portal so that question has a clean answer: a client-facing shared dashboard showing service health, spend against budget, and recent deployment activity, accessible to the client’s read-only account and no one else’s.
Agency partners receive Azure Portal configuration as part of every Azure engagement we deliver, or as a standalone engagement for existing environments that were never configured for operational visibility. Explore the agency partner programme or review the white-label development model for details.
What a Well-Configured Azure Portal Reveals That Most Teams Never See
The average Azure Portal for a production environment has a subscription view with forty resources listed alphabetically, no cost budgets set, default alerts either absent or firing on thresholds nobody calibrated, and access granted at the subscription level to everyone who ever needed to check something once. The portal works. The team logs in, finds what they need eventually, and logs out. It does not tell them anything they were not already looking for.
A configured Azure Portal is different. Cost anomaly detection fires before a spike reaches the invoice. Azure Advisor flags that a VM has been running at 2% CPU for six weeks and could save 70% of the compute cost at a smaller SKU. Resource Health shows a storage account has been in a degraded state for three days while the application silently swallows the errors. An access review surfaces a developer who left five months ago and still has Contributor access to the production subscription. These are not edge cases — they are the findings of every Azure portal audit we run. Book a consultation to see what a portal audit reveals about your environment.
Azure Portal Engagement Models
Four structures for Azure Portal configuration and operational governance.
Azure Portal Setup and Configuration
Complete Azure Portal configuration for a new or existing Azure environment — RBAC structure, custom dashboards for each stakeholder role, cost management with budgets and alerts, Azure Monitor alert rules and action groups, resource tagging strategy, and Azure Policy compliance configuration. Delivered as a standalone engagement or alongside a broader Azure software development project.
Azure Cost Management Engagement
Focused engagement on cost visibility and control: resource tagging implemented, budgets configured, cost analysis views built, chargeback reports set up for multi-product or multi-client environments, anomaly detection enabled. Fixed scope, typically one week from access grant to a configured cost management environment the finance team can use independently. Before-and-after cost visibility is documented for every engagement.
Azure Governance and Policy Configuration
Azure Policy assignments for the organisation’s governance requirements: tagging enforcement, allowed regions, mandatory diagnostic settings, security baselines. Compliance dashboard configured in the portal. Non-compliant resources remediated. RBAC reviewed and scoped to least privilege. PIM configured for just-in-time access to production. Talk to us about your governance requirements.
Azure Portal Audit
An independent review of an existing Azure Portal configuration: access control scope, cost management completeness, alert coverage, resource health setup, tag consistency, and Advisor recommendation status. Written report with prioritised findings and effort estimates per item. The highest-risk findings — overprivileged access, absent cost alerts, unmonitored production resources — are typically resolvable within a single remediation sprint.
How We Deliver an Azure Portal Configuration Engagement
01. Azure Portal Access Review and RBAC Audit
02. Resource Tagging and Governance Strategy
We review existing RBAC assignments across the subscription or management group — identifying overprivileged roles, stale access from departed team members, and access granted at subscription scope that should be scoped to a resource group. The audit output is a written access review with recommended changes ranked by risk level, completed before any configuration changes are made to the production environment.
03. Cost Management Configuration
A tagging taxonomy agreed before any tags are applied — environment, product name, cost centre, owner, and deployment method as a minimum. Tags applied to all existing resources via Azure Policy remediation tasks. New resource creation policy assignments enforce required tags going forward. Resource group restructuring documented where the current grouping does not support the intended cost allocation or access control model.
04. Azure Monitor and Alerts Setup
Monthly budgets created for each resource group or subscription scope relevant to the cost allocation model. Alert thresholds set at 80%, 100%, and forecast-to-exceed the budget. Cost anomaly detection enabled. Cost analysis views saved for the finance team’s monthly reporting and the engineering team’s sprint cost review. Chargeback views configured for agencies billing Azure costs to clients by resource group tag.
05. Dashboard Design and Stakeholder Views
Alert rules created for the metrics that matter to the production environment — availability, error rate, response time, resource saturation — with thresholds calibrated against the application’s baseline rather than generic defaults. Action groups configured for each alert severity. Alert rule names and descriptions written so the person receiving the alert understands what it means and what action to take, not just which resource triggered it.
06. Ongoing Governance and Advisor Review
Custom dashboards designed and published as shared dashboards accessible to the appropriate role. Each dashboard is built for a specific audience: the operations team dashboard shows alert status, resource health, and recent deployments; the product owner dashboard shows cost trend and availability; the client-facing dashboard shows service health and spend against budget in a clean layout. Every dashboard is reviewed with the intended audience before publishing.
Operational visibility. Cost control. Governance in place.
Monthly Azure Advisor review to surface new recommendations that have emerged since initial configuration — right-sizing opportunities, security posture improvements, reliability recommendations. RBAC access review on a defined cadence. Budget alerts reviewed quarterly against actual spend patterns. The Azure Portal configuration is not a one-time task — the recommendations, costs, and access requirements change as the application grows and the team evolves.
Azure Portal: Common Questions
Answered by engineers who configure and manage Azure Portal for production environments.
What is the Azure Portal and what is it used for in software development?
The Azure Portal at portal.azure.com is the web-based management console for Microsoft Azure — the interface where Azure resources are created, configured, monitored, and managed. For software development teams, it is the operational hub for a deployed Azure environment: the place where cost trends are reviewed, alerts are configured, access is managed, resource health is monitored, and the compliance posture of the Azure subscription is assessed. Most teams use the Azure Portal primarily for provisioning new resources, which is the least valuable use of what it provides. The cost management, monitoring, governance, and access control capabilities do more to protect a production environment than the provisioning interface does.
How do you control who can see and do what in the Azure Portal?
Through Azure Role-Based Access Control (RBAC), which assigns permissions at the management group, subscription, resource group, or individual resource scope. The principle of least privilege is applied by assigning built-in roles at the lowest scope necessary, or defining custom roles where built-in options are either too broad or too narrow for the specific team structure. Read-only stakeholder access for finance or client review uses the Reader built-in role scoped to the relevant resource group. Privileged Identity Management restricts permanent elevated access by requiring explicit activation of privileged roles with an approval workflow and time-limited assignment — so production access is granted when needed and revoked when it is not.
How do you set up cost alerts in the Azure Portal?
Through Azure Cost Management, accessible from the Azure Portal. Budgets are created at the subscription or resource group scope with alert thresholds — commonly 80% for an early warning and 100% when the budget is reached. Each budget sends alerts to email addresses or action groups, which can route notifications to Teams channels or trigger an automated response. Azure Cost Management also supports anomaly detection, which identifies unexpected changes in daily spend without requiring a budget threshold to be exceeded first. The alerts are only as useful as the budgets they are configured against, which requires resource tagging to be consistent enough to attribute costs to the right owner.
What is Azure Advisor and how does it benefit a running Azure environment?
Azure Advisor is a built-in portal service that analyses the running Azure environment and provides prioritised recommendations across five categories: reliability, security, operational excellence, performance, and cost. Cost recommendations identify resources that are consistently underutilised — a VM running at 2% CPU for weeks, an unattached managed disk, a reserved instance opportunity — and estimate the monthly saving from addressing them. Security recommendations surface configurations that fall below the Azure security baseline. Reliability recommendations flag single points of failure, missing backups, and resources without redundancy. The recommendations are updated continuously as the environment changes, making them useful for ongoing optimisation rather than just initial setup.
Can you give clients read-only access to their Azure resources through the portal?
Yes. A client stakeholder account can be given Reader access scoped to the resource group containing their application’s resources — enough to view resource status, review costs, and see alert history without the ability to modify anything. For a cleaner client experience, a shared custom dashboard can be published showing the specific metrics, cost tiles, and health indicators the client cares about, accessible from the shared dashboards section of the portal. This removes the need for status reports that are outdated by the time they are delivered — the client sees live data directly. For agencies managing multiple clients in the same subscription, resource group scoping ensures each client’s Reader account sees only their own resources.
How is the Azure Portal different from managing Azure through the CLI or Terraform?
Azure CLI and Terraform are the tools used to provision and configure Azure infrastructure — they define what resources exist and how they are configured, ideally managed as code in version control. The Azure Portal is the operational console — it surfaces the running state of those resources, their cost, their health, and their compliance with governance policies in a visual interface. The two are complementary rather than alternatives. Terraform defines a virtual network; the Azure Portal shows its traffic throughput, associated alert rules, and network topology. Azure CLI deploys an App Service; the Azure Portal shows its deployment history, current CPU and memory utilisation, and active connections. Teams that manage infrastructure as code but ignore the portal lose operational visibility. Teams that manage infrastructure through the portal instead of code have an environment they cannot reliably reproduce or audit.