Microsoft Azure — Getting Started with Azure

Azure is Microsoft's cloud computing platform offering over 200 services. This article covers getting started with azure with production-ready configurations, best practices, and hands-on examples.

Why Azure? The Cloud That Runs Your Enterprise

Microsoft Azure is not just another cloud provider—it's the backbone of enterprise IT for thousands of organizations. With over 200 services spanning compute, storage, networking, AI, and DevOps, Azure offers unmatched integration with Microsoft products like Active Directory, Visual Studio, and Office 365. For DevOps teams, Azure provides a unified platform for building, deploying, and managing applications at scale. Its global footprint of 60+ regions ensures low latency and compliance with data residency requirements. If your organization already uses Microsoft tools, Azure reduces friction and accelerates time-to-market. This guide walks you through the fundamentals: setting up an account, understanding core services, deploying your first application, and implementing cost controls. By the end, you'll have a production-ready foundation.

#!/bin/bash
# Verify Azure CLI installation and login
az version --output table
az account show --output table || az login

Setting Up Your Azure Environment

Before deploying anything, you need a structured environment. Start by creating an Azure subscription (use a Pay-As-You-Go plan to avoid surprises). Then, install the Azure CLI locally—it's the primary tool for managing resources from the command line. Next, organize resources using Management Groups, Subscriptions, and Resource Groups. A common pattern is to have separate resource groups per environment (dev, test, prod) and per application. Use tags (e.g., Environment, CostCenter, Owner) to track costs and ownership. Finally, set up Azure Policy to enforce compliance (e.g., restrict VM sizes, require tags). This foundation prevents configuration drift and runaway costs.

#!/bin/bash
# Create resource group and set tags
az group create --name prod-rg --location eastus --tags Environment=Prod CostCenter=Engineering Owner=DevOps

# Apply a policy to require tags
az policy assignment create --name 'require-tags' --policy '2a0e14d6-1a6b-4f5e-8f6d-3f4e5d6c7b8a' --params '{"tagName":{"value":"Environment"}}'

Core Compute: Virtual Machines vs. App Service

Azure offers multiple compute options. For full control, use Virtual Machines (VMs). They're ideal for legacy apps, custom OS configurations, or workloads requiring dedicated resources. For modern web apps and APIs, App Service is the better choice—it handles patching, scaling, and load balancing automatically. App Service supports Windows and Linux, containers, and auto-scaling based on metrics. For containerized workloads, consider Azure Kubernetes Service (AKS) or Container Instances. The rule of thumb: if you can containerize it, do it. VMs should be your last resort due to higher operational overhead. Always use managed disks and availability sets/zones for production VMs.

#!/bin/bash
# Create a Linux VM with managed disk and availability set
az vm create \
  --resource-group prod-rg \
  --name web-vm \
  --image UbuntuLTS \
  --admin-username azureuser \
  --generate-ssh-keys \
  --size Standard_DS2_v2 \
  --availability-set web-avset \
  --os-disk-size-gb 128

Storage: Blobs, Files, and Disks

Azure Storage is the foundation for data persistence. Blob storage is for unstructured data (images, backups, logs). File storage provides SMB shares for legacy apps. Disk storage is for VM disks. For production, use geo-redundant storage (GRS) for blobs to survive regional outages. Implement lifecycle management to tier blobs from hot to cool to archive, reducing costs. For VM disks, use Premium SSDs for production workloads. Always enable soft delete for blobs to recover from accidental deletion. Access control is via shared access signatures (SAS) or Azure AD authentication. Never use storage account keys in code—use managed identities.

#!/bin/bash
# Create storage account with GRS and blob soft delete
az storage account create \
  --name prodstorage123 \
  --resource-group prod-rg \
  --location eastus \
  --sku Standard_GRS \
  --kind StorageV2 \
  --enable-hierarchical-namespace false

# Enable blob soft delete
az storage blob service-properties delete-policy update \
  --account-name prodstorage123 \
  --enable true \
  --days-retained 7

Networking: VNets, Subnets, and Security Groups

Azure Virtual Network (VNet) is the foundation of your network topology. Always create a VNet with at least two subnets: one for public-facing resources (e.g., load balancers) and one for private resources (e.g., databases). Use Network Security Groups (NSGs) to filter traffic at the subnet or NIC level. For production, implement a hub-and-spoke topology with Azure Firewall or a Network Virtual Appliance (NVA) for centralized inspection. Never expose VMs directly to the internet—use Azure Load Balancer or Application Gateway. Enable DDoS Protection Standard on your VNet for production workloads. Use Private Link to access PaaS services privately.

#!/bin/bash
# Create VNet with two subnets and NSG
az network vnet create \
  --name prod-vnet \
  --resource-group prod-rg \
  --address-prefix 10.0.0.0/16 \
  --subnet-name public-subnet \
  --subnet-prefix 10.0.1.0/24

az network vnet subnet create \
  --name private-subnet \
  --resource-group prod-rg \
  --vnet-name prod-vnet \
  --address-prefix 10.0.2.0/24

# Create NSG and allow HTTP/HTTPS
az network nsg create --name public-nsg --resource-group prod-rg
az network nsg rule create --nsg-name public-nsg --resource-group prod-rg --name AllowHTTP --priority 100 --destination-port-ranges 80 443 --access Allow --protocol Tcp

Deploying Your First App with Azure App Service

Azure App Service is a fully managed platform for web apps and APIs. To deploy, create an App Service plan (defines region, VM size, and scaling) and then the web app. For production, use a Standard or Premium plan to get auto-scaling, staging slots, and custom domains. Deploy via Git, GitHub Actions, Azure DevOps, or FTP. Always use deployment slots (e.g., staging) to swap traffic after validation. Enable Application Insights for monitoring. Configure auto-scaling based on CPU or memory. Set up a custom domain and SSL certificate (Azure provides free managed certificates). Finally, enable logging and diagnostics.

#!/bin/bash
# Create App Service plan and web app
az appservice plan create \
  --name prod-plan \
  --resource-group prod-rg \
  --sku S1 \
  --is-linux

az webapp create \
  --name myprodapp \
  --resource-group prod-rg \
  --plan prod-plan \
  --runtime "NODE|18-lts"

# Deploy from GitHub
az webapp deployment source config --name myprodapp --resource-group prod-rg --repo-url https://github.com/myorg/myapp --branch main --manual-integration

Identity and Access Management with Azure AD

Azure Active Directory (Azure AD) is the identity backbone. For production, never use local user accounts—always use Azure AD identities. Create service principals for automated tools (e.g., CI/CD pipelines). Use Managed Identities for Azure resources (e.g., VMs, App Service) to access other Azure services without storing credentials. Implement Role-Based Access Control (RBAC) with least privilege: assign roles at resource group scope, not subscription. Use Privileged Identity Management (PIM) for just-in-time admin access. Enable Conditional Access policies (e.g., require MFA for production). Audit sign-in logs regularly.

#!/bin/bash
# Create a service principal with Contributor role at resource group scope
az ad sp create-for-rbac \
  --name "prod-deploy-sp" \
  --role Contributor \
  --scopes /subscriptions/.../resourceGroups/prod-rg

# Output credentials (save securely!)
echo "Client ID: $appId"
echo "Client Secret: $password"
echo "Tenant ID: $tenant"

Monitoring and Logging with Azure Monitor

You can't fix what you can't see. Azure Monitor collects metrics, logs, and traces from all Azure resources. For production, enable diagnostic settings on every resource to send logs to a Log Analytics workspace. Create dashboards for key metrics (CPU, memory, request count, error rate). Set up alerts for critical conditions (e.g., CPU > 90%, HTTP 5xx errors). Use Application Insights for application-level monitoring (dependencies, exceptions, performance). Implement log queries to troubleshoot issues. For compliance, archive logs to Azure Storage or send to a SIEM. Use Azure Workbooks for custom reporting.

#!/bin/bash
# Create Log Analytics workspace
az monitor log-analytics workspace create \
  --resource-group prod-rg \
  --workspace-name prod-logs \
  --location eastus

# Enable diagnostics for App Service
az webapp log config \
  --name myprodapp \
  --resource-group prod-rg \
  --application-logging filesystem \
  --detailed-error-messages true \
  --failed-request-tracing true \
  --web-server-logging filesystem

Cost Management and Optimization

Cloud costs can spiral without governance. Start by setting budgets and alerts in Azure Cost Management. Use tags to track costs by team, project, or environment. Right-size resources: use Azure Advisor recommendations to downsize underutilized VMs. For non-production, shut down resources on a schedule (e.g., dev VMs off nights and weekends). Use Reserved Instances or Azure Savings Plan for predictable workloads (up to 72% savings). For storage, use lifecycle management to move blobs to cooler tiers. Review cost reports weekly. Implement a chargeback model to make teams accountable.

#!/bin/bash
# Create a budget with alert at 80% and 100%
az consumption budget create \
  --budget-name prod-budget \
  --amount 10000 \
  --time-grain monthly \
  --start-date 2026-01-01 \
  --end-date 2026-12-31 \
  --category cost \
  --scope /subscriptions/... \
  --notification-group '{"enabled":true,"operator":"GreaterThan","threshold":80,"contactEmails":["team@example.com"]}'

Security Best Practices for Production

Security is not optional. Start with Azure Security Center (now Microsoft Defender for Cloud) to assess your security posture. Enable just-in-time VM access to reduce attack surface. Use Azure Key Vault to store secrets, certificates, and connection strings. Encrypt data at rest (Azure Storage Service Encryption) and in transit (TLS). Implement network segmentation with VNets and NSGs. Use Azure Policy to enforce security rules (e.g., require encryption). Enable audit logging for all critical resources. Regularly review security recommendations and remediate high-severity issues. Conduct penetration testing (with approval) and use Azure Sentinel for SIEM.

#!/bin/bash
# Enable Just-In-Time VM access policy
az vm jit-policy create \
  --resource-group prod-rg \
  --vm web-vm \
  --port 22 \
  --allowed-source-addresses "192.168.1.0/24" \
  --max-request-access-duration 3h

Automating Infrastructure with ARM and Bicep

Manual infrastructure is fragile. Use Infrastructure as Code (IaC) to define Azure resources declaratively. Azure Resource Manager (ARM) templates are JSON-based and idempotent. Bicep is a simpler DSL that compiles to ARM. For production, store templates in Git, use parameter files for environment-specific values, and deploy via CI/CD pipelines. Use what-if operations to preview changes before applying. Implement modular templates for reusable components (e.g., network, database). Always validate templates with ARM-TTK (Template Test Toolkit). Avoid hardcoding secrets—use Key Vault references.

param location string = resourceGroup().location
param appName string = 'myprodapp'
param sku string = 'S1'

resource appServicePlan 'Microsoft.Web/serverfarms@2021-02-01' = {
  name: '${appName}-plan'
  location: location
  sku: {
    name: sku
  }
}

resource webApp 'Microsoft.Web/sites@2021-02-01' = {
  name: appName
  location: location
  properties: {
    serverFarmId: appServicePlan.id
  }
}

output webAppUrl string = 'https://${webApp.properties.defaultHostName}'

Next Steps: CI/CD with Azure DevOps

Automation doesn't stop at infrastructure. Use Azure DevOps to build, test, and deploy your applications. Create a pipeline that runs on every commit: lint, test, build, and deploy to a staging slot. Use multi-stage YAML pipelines for clarity. Integrate with Azure Policy for gating (e.g., require security scans). Use Azure Test Plans for manual testing. Store pipeline variables in Azure Key Vault. Implement approval gates for production deployments. Monitor pipeline runs and set up alerts for failures. This end-to-end automation reduces human error and accelerates delivery.

trigger:
- main

variables:
  azureSubscription: 'prod-service-connection'
  appName: 'myprodapp'

stages:
- stage: Build
  jobs:
  - job: BuildJob
    steps:
    - script: npm install && npm run build
    - task: PublishBuildArtifacts@1

- stage: DeployStaging
  dependsOn: Build
  jobs:
  - deployment: Deploy
    environment: staging
    strategy:
      runOnce:
        deploy:
          steps:
          - task: AzureWebApp@1
            inputs:
              azureSubscription: $(azureSubscription)
              appName: $(appName)
              slotName: staging

- stage: DeployProd
  dependsOn: DeployStaging
  jobs:
  - deployment: Deploy
    environment: prod
    strategy:
      runOnce:
        deploy:
          steps:
          - task: AzureWebApp@1
            inputs:
              azureSubscription: $(azureSubscription)
              appName: $(appName)
              slotName: production

Azure Container Services: AKS, Container Instances, and Container Apps

Azure offers three main container orchestration options. Azure Kubernetes Service (AKS) is a managed Kubernetes cluster for complex microservices architectures with auto-scaling, service mesh integration, and GitOps-driven deployments via Flux. Azure Container Instances (ACI) is the fastest way to run a single container without managing servers — ideal for batch jobs, build agents, and event-driven processing. Azure Container Apps is a serverless platform built on Kubernetes that abstracts cluster management entirely; it supports KEDA-based auto-scaling (HTTP, queue, cron triggers), Dapr for microservice patterns, and revision-based deployments with blue-green traffic splitting. For production, choose AKS when you need full Kubernetes control (e.g., custom CNI, pod security policies), Container Apps when you want serverless Kubernetes without cluster management, and ACI for simple, ephemeral containers. Always use Azure Container Registry (ACR) to store and scan container images for vulnerabilities.

az container create \
  --resource-group myResourceGroup \
  --name mycontainerapp \
  --image mcr.microsoft.com/azuredocs/aci-helloworld \
  --dns-name-label mycontainerapp-${RANDOM} \
  --ports 80

Connecting Azure with DevOps and GitHub

Azure integrates deeply with GitHub and Azure DevOps for end-to-end CI/CD. Use GitHub Actions for lightweight CI/CD directly from your GitHub repository — deploy to Azure App Service, AKS, or Azure Functions using Azure publish profiles or OpenID Connect (OIDC) with managed identities. For larger teams, Azure DevOps provides Azure Boards (work tracking), Azure Repos (Git hosting), Azure Pipelines (CI/CD), Azure Test Plans (manual/exploratory testing), and Azure Artifacts (package feeds). Key best practices: use OIDC instead of client secrets for GitHub Actions — it eliminates static credentials and auto-rotates tokens. Set up branch protection rules requiring PR approvals and status checks. Use environment-based secrets and approval gates for production deployments. For infrastructure, deploy using multi-stage YAML pipelines that run linting, security scanning, and integration tests before promotion.

name: Deploy to Azure App Service

on:
  push:
    branches: [main]

permissions:
  id-token: write
  contents: read

jobs:
  build-and-deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: azure/login@v2
        with:
          client-id: ${{ secrets.AZURE_CLIENT_ID }}
          tenant-id: ${{ secrets.AZURE_TENANT_ID }}
          subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
      - run: |
          az webapp up --name myprodapp --resource-group prod-rg --plan prod-plan --runtime "NODE|18-lts" --sku S1

Exploring the Azure Marketplace and Partner Solutions

Azure Marketplace is an online store with thousands of pre-built solutions from Microsoft and third-party partners. You can deploy Linux/Windows VMs with pre-configured software (e.g., WordPress, Jenkins, Nginx), SaaS applications (e.g., Datadog, Elastic, MongoDB Atlas), and consulting services. Marketplace solutions are billed through your Azure subscription, consolidating costs. For development, use the Quickstart Center to find starter templates. For production, evaluate partner solutions carefully: check support SLAs, data residency, and integration with Azure Monitor. Use Azure Policy to restrict which Marketplace images can be deployed to prevent unapproved software. Many ISVs offer Azure-native integrations via Azure Resource Manager templates — these are the safest to deploy as they follow Azure's IaC model. Always review the publisher's Microsoft Partner Network (MPN) status and customer ratings before deploying.

az vm image list --all --publisher bitnami --offer wordpress --output table