{"id":78664,"date":"2026-04-20T00:36:42","date_gmt":"2026-04-19T19:06:42","guid":{"rendered":"https:\/\/www.tothenew.com\/blog\/?p=78664"},"modified":"2026-04-22T11:22:02","modified_gmt":"2026-04-22T05:52:02","slug":"understanding-azure-cloud-fundamentals-for-devops-engineers","status":"publish","type":"post","link":"https:\/\/www.tothenew.com\/blog\/understanding-azure-cloud-fundamentals-for-devops-engineers\/","title":{"rendered":"Understanding Azure Cloud Fundamentals for DevOps Engineers"},"content":{"rendered":"

What is Microsoft Azure<\/h2>\n

Azure is Microsoft’s cloud computing platform. And it does a lot \u2014 virtual machines, storage, networking, monitoring, identity management, databases, you name it. The idea is actually pretty simple. Instead of buying physical servers, setting them up in an office or data center, and then maintaining them yourself, organizations just use Azure to create and manage all of that online.<\/p>\n

Understanding the Basic Azure Hierarchy<\/h2>\n

Before jumping into services like virtual machines or storage accounts, understand how Azure is actually structured. This part matters more than people think it gives context to everything else.<\/p>\n

The basic hierarchy looks like this:<\/p>\n

 <\/p>\n

\"Azure

Azure Scopes<\/p><\/div>\n

Let\u2019s go through it one by one.<\/p>\n

Tenant – Your Organisation’s Identity Home<\/strong><\/h2>\n

A tenant is the highest level identity boundary in Azure. It basically represents your organization in Microsoft Entra ID, which was previously known as Azure Active Directory. This is where users, groups, applications, and identity-related settings are managed. Simply put, the tenant is your organization’s own dedicated space in Azure.<\/p>\n

If a company is using Azure, it will usually have one tenant where all the employee identities, access controls, and authentication are connected. So before even thinking about resources, there is usually a tenant behind it.<\/p>\n

This part can feel a little abstract in the beginning, which is normal. But later, when working with users, roles, or permissions, it starts making more sense.<\/p>\n

Management Group – The Thing Nobody Tells You About<\/strong><\/h2>\n

Management Groups are used to organize multiple subscriptions under a common structure.<\/p>\n

This becomes useful in larger organizations where there may be many subscriptions for different teams, departments, business units, or environments. Instead of applying governance separately everywhere, management groups help apply policies and permissions at a higher level.<\/p>\n

For example, if a company has separate subscriptions for development, testing, and production across multiple departments, management groups help bring some structure to that setup.<\/p>\n

You may not use management groups daily as a beginner, but it is still good to know where they fit in the hierarchy.<\/p>\n

Subscription – Billing and Access Boundary<\/h2>\n

An Azure subscription is one of the main billing and management boundaries in Azure. Resources are created inside subscriptions, and access control is also often managed at this level.\u00a0 A company may have one subscription, or it may have many. For example:<\/p>\n

    \n
  • one for development<\/li>\n
  • one for testing<\/li>\n
  • one for production<\/li>\n<\/ul>\n

    This separation helps with cost tracking, access management, and overall organization. It also reduces confusion, which matters more than people think.<\/p>\n

    A lot of practical Azure work starts from the subscription level.<\/p>\n

    Resource Group – Your Daily Driver<\/h2>\n

    A resource group is basically just a logical container for related Azure resources. Say you’re deploying an application , you’d keep its virtual machine, storage account, virtual network, and public IP all inside the same resource group. Keeps things together.<\/p>\n

    Resource groups are very important in day-to-day Azure work. They help in organizing resources based on application, environment, or project.<\/p>\n

    Resource Group: rg-ecommerce-prod
    \n\u251c\u2500\u2500 App Service: ecommerce-api
    \n\u251c\u2500\u2500 Azure SQL: ecommerce-db
    \n\u251c\u2500\u2500 Storage Account: ecommercestorage
    \n\u2514\u2500\u2500 Key Vault: ecommerce-kv<\/p>\n

    Resources – The Actual Stuff You Build With<\/strong><\/h2>\n

    Resources are the actual services you create and use in Azure. This includes things like:<\/p>\n

      \n
    • virtual machines<\/li>\n
    • storage accounts<\/li>\n
    • virtual networks<\/li>\n
    • load balancers<\/li>\n
    • app services<\/li>\n<\/ul>\n

      These are the building blocks of your environment. Once the hierarchy above is clear, understanding where these resources belong becomes much easier.<\/p>\n

      Core Azure Services Every DevOps Engineer Should Know<\/span><\/h2>\n

       <\/p>\n

      1. Virtual Machines<\/h2>\n

      Azure Virtual Machines are cloud-based servers. They’re one of the most basic and widely used services in Azure. A VM can host applications, run services, create test environments, or even act as a self-hosted agent for CI\/CD pipelines.<\/p>\n

      For someone learning DevOps, VMs are useful because they make cloud infrastructure feel real. You can log in, configure software, check logs, manage services. It stops being just theory at that point.<\/p>\n

      2. Storage Accounts<\/h2>\n

      Azure Storage is used to store data in different forms. Depending on the need, Azure provides different storage options such as –<\/p>\n

        \n
      • Blob Storage \u2014 unstructured files. Logs, images, backups, Terraform state files. This is what you’ll use the most.<\/li>\n
      • File Storage \u2014 managed file shares over SMB. Useful when apps need shared network storage.<\/li>\n
      • Queue Storage \u2014 simple message queuing.<\/li>\n
      • Table Storage \u2014 lightweight key-value NoSQL.<\/li>\n<\/ul>\n

        In DevOps work, storage often comes into use for logs, backups, deployment packages, application files, or VM disks. It is one of those services that quietly shows up everywhere.<\/p>\n

        3. Virtual Network – your private network inside Azure. Resources inside<\/h2>\n

        A Virtual Network, or VNet, lets Azure resources communicate with each other securely.<\/p>\n

        This matters because not every resource should be exposed to the public internet. Some should stay internal. Some should only talk to specific services.<\/p>\n

        With VNets, you can define IP ranges, create subnets, and set up isolated communication between resources. If an application has frontend, backend, and database layers, networking becomes very important very quickly.<\/p>\n

        4. Network Security Group – inbound and outbound traffic rules. Your firewall.<\/h2>\n

        A Network Security Group, or NSG, controls inbound and outbound network traffic. You can create rules like:<\/p>\n

          \n
        • allow SSH from a trusted IP<\/li>\n
        • allow HTTP and HTTPS traffic<\/li>\n
        • deny other unnecessary access<\/li>\n<\/ul>\n

          This is a key security concept in Azure. Even if someone is just starting, NSGs are worth understanding early because they directly affect how secure a resource is.<\/p>\n

          5. Application Security Group<\/h2>\n

          An Application Security Group, or ASG, helps group virtual machines based on their role, so security rules become easier to manage.<\/p>\n

          This is where it differs from NSG.<\/p>\n

          An NSG is used to define the actual traffic rules.
          \nAn ASG is used to group resources logically inside those rules.<\/p>\n

          \"ASG\"

          ASG<\/p><\/div>\n

          Suppose you have: 2 web servers ( VM1 , VM2 ) and 1 application servers (VM3)<\/p>\n

          Instead of creating NSG rules using private IP addresses for each server, you can put the web servers in one ASG and the application servers in another ASG.<\/p>\n

          Then the NSG rule can simply say:<\/p>\n

          Allow traffic from AsgWeb<\/strong> to AsgLogic<\/strong> on port 8080<\/p>\n

          So in simple words:<\/p>\n

            \n
          • NSG decides what traffic is allowed or denied<\/li>\n
          • ASG helps apply those rules in a smarter and more organized way<\/li>\n<\/ul>\n

            6. Load Balancer<\/h2>\n

            Azure Load Balancer distributes incoming traffic across multiple backend resources.<\/p>\n

            Why does this matter? Because depending on one server is risky. If traffic spikes or a server goes down, a load balancer is what keeps the application running.<\/p>\n

            In production environments, this becomes very important. Maybe not on day one of learning, but definitely later.<\/p>\n

            7. Azure App Service<\/h2>\n

            Azure App Service is a managed platform for hosting web apps and APIs. It’s useful when teams want to deploy applications without dealing with the underlying server directly. Azure handles most of the infrastructure side, so teams can focus more on the application and the deployment process.<\/p>\n

            For DevOps engineers, it’s good to understand both sides \u2014 server-based hosting like VMs, and platform-based hosting like App Service.<\/p>\n

            8. Azure Monitor<\/h2>\n

            Monitoring is a huge part of DevOps work. Deploying is only half of it. Once something’s live, you need to actually know if it’s behaving, is the app healthy, is the server holding up, are errors quietly piling up somewhere.<\/p>\n

            Azure Monitor pulls in metrics, logs, and alerts from your resources and applications. CPU running hot? App throwing errors every few minutes? Azure Monitor catches it. Faster troubleshooting, less guesswork.<\/p>\n

            For example, if CPU usage shoots too high or an app starts failing repeatedly, Azure Monitor can help catch and report that. Makes troubleshooting easier \u2014 and sometimes a lot faster.<\/p>\n

            9. Identity and Access Management<\/h2>\n

            Azure uses Microsoft Entra ID for identity and access management. This is what handles users, groups, roles, and permissions. In cloud environments, not everyone should have full access to everything.<\/p>\n

            That’d be messy and honestly a security disaster. For DevOps engineers, understanding role-based access matters because environments need to stay secure while still letting teams actually get their work done.<\/p>\n

            10. Azure and Automation<\/strong><\/h2>\n

            One of the biggest reasons Azure matters in DevOps is automation. Doing everything manually might work in very small setups, but it falls apart quickly. Manual work leads to inconsistency, repeated effort, and mistakes that are hard to trace back.<\/p>\n

            That’s why Azure environments are usually managed using tools such as:<\/p>\n

              \n
            • Azure CLI<\/li>\n
            • PowerShell<\/li>\n
            • ARM templates<\/li>\n
            • Bicep<\/li>\n
            • Terraform<\/li>\n<\/ul>\n

              With these tools, infrastructure and deployments can be repeated the exact same way every single time. And that repeatability \u2014 that’s really what DevOps is about.<\/p>\n

              Conclusion<\/h2>\n

              It’s really not about memorizing every service Azure has. The structure matters more understanding the building blocks and how they actually fit together in a real setup.<\/p>\n

              Get the hierarchy straight first:<\/p>\n

               <\/p>\n

              Tenant \u2192 Management Group \u2192 Subscription \u2192 Resource Group \u2192 Resources<\/h6>\n

               <\/p>\n

              Once that’s clear in your head, picking up virtual machines, storage, networking, monitoring, access management all of it starts clicking into place much faster.<\/p>\n","protected":false},"excerpt":{"rendered":"

              What is Microsoft Azure Azure is Microsoft’s cloud computing platform. And it does a lot \u2014 virtual machines, storage, networking, monitoring, identity management, databases, you name it. The idea is actually pretty simple. Instead of buying physical servers, setting them up in an office or data center, and then maintaining them yourself, organizations just use […]<\/p>\n","protected":false},"author":1950,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"iawp_total_views":8},"categories":[2348],"tags":[3457,1916,1892],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts\/78664"}],"collection":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/users\/1950"}],"replies":[{"embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/comments?post=78664"}],"version-history":[{"count":13,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts\/78664\/revisions"}],"predecessor-version":[{"id":79663,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts\/78664\/revisions\/79663"}],"wp:attachment":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/media?parent=78664"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/categories?post=78664"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/tags?post=78664"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}