Azure Postpaid Account Azure Cloud Onboarding and Technical Setup

So You’re Going to Azure. Congrats. Now Breathe.

Let’s get one thing straight: Azure onboarding isn’t a checkbox exercise—it’s your organization’s first real conversation with the cloud. It’s where policy meets panic, where naming conventions go to die, and where someone inevitably creates a resource group called TestStuff2 at 4:57 p.m. on a Friday. This guide won’t drown you in Microsoft docs or recite the Shared Responsibility Model like a mantra. Instead, it’s your field manual—tested in production, annotated with coffee-stained lessons, and written by people who once spent 14 hours debugging why az login worked locally but failed in CI/CD (spoiler: it was an expired MFA token cached in a Docker layer).

Phase 1: The Tenant Tango (Yes, It’s a Dance)

Your Azure AD Tenant Is Not Your Company Directory—It’s Your Cloud Nation

You don’t ‘create’ an Azure tenant—you declare sovereignty. If your org uses Microsoft 365, you likely already have one. Don’t spin up a new tenant unless you’re doing a true greenfield acquisition or need strict logical isolation (e.g., regulated subsidiaries). Duplicate tenants = duplicate identity chaos, broken SSO, and frantic calls from HR about why their new hire can’t access Teams or the payroll app.

Before typing New-AzureADTenant (which doesn’t exist—yes, that’s a trap), verify:

• Who owns the verified domain (e.g., @yourcompany.com) in Azure AD? Spoiler: It’s probably not the cloud team—it’s the email admin who hasn’t logged into the Azure portal since 2021.
• Is your custom domain federated (with ADFS or Entra ID Connect) or managed? Federated = tighter control, steeper ops overhead. Managed = simpler, but password hashes sync via secure channel—not magic.
• Are guest users enabled? (They should be—but only with external collaboration settings locked down tighter than your ex’s Instagram DMs.)

Admin Roles: Please, For the Love of All That Is Holy, Don’t Make Everyone a Global Admin

We’ve seen it: 47 Global Admins, including Karen from Finance who last used PowerShell to rename an Excel tab. Azure AD Global Admin is the ‘nuclear launch code’ role—broad, dangerous, and rarely needed day-to-day. Instead:

• Create Privileged Role Administrator accounts for break-glass scenarios (store them offline, rotate quarterly).
• Assign Cloud Device Administrator to endpoint teams.
• Use Application Administrator for dev leads managing service principals—not the whole engineering org.

Pro tip: Enable Privileged Identity Management (PIM) before onboarding starts. Not ‘somewhere in Phase 3’. Before. Because ‘just-in-time’ access sounds fancy until you realize your CI/CD pipeline needs 2-hour elevated rights to deploy ARM templates—and no one remembered to pre-approve it.

Phase 2: Subscriptions—Not Just Billing Buckets, But Governance Boundaries

One Subscription ≠ One Project. Repeat After Me.

Azure subscriptions are your foundational governance unit—not billing containers, not ‘where VMs live’. They carry quotas, policies, RBAC scopes, and cost centers. Treat them like corporate subsidiaries: each needs purpose, budget guardrails, and clear ownership.

Start with this lean, battle-tested structure:

• Management Subscription: Houses landing zone resources (Log Analytics, Key Vault, Azure Policy definitions). No workloads here—just governance plumbing.
• Connectivity Subscription: VNETs, ExpressRoute gateways, private DNS zones. Network folks own this. Devs don’t touch it—even with gloves on.
• Platform Subscription(s): Shared services (AKS clusters, API Management, shared databases). Tagged with env=platform, audited monthly.
• Workload Subscriptions: One per major app or business unit (prod-finance-app, nonprod-hr-system). Isolated, budget-capped, and deleted automatically after 90 days of inactivity (yes, automate that).

Resist the ‘one sub for everything’ urge. We watched a startup do it. Their dev-test-prod tags were ignored. Their $8K/month bill included three orphaned SQL DBs named temp_db_v2_final_really.

Phase 3: Landing Zone—Your Cloud Neighborhood Watch

Azure Postpaid Account Forget ‘Well-Architected’. Start With ‘Not On Fire’.

A landing zone isn’t a reference architecture PDF—it’s the minimum viable environment that stops your first production deployment from becoming a ransomware headline. At bare minimum, your LZ must include:

• Centralized logging: Send all Activity Logs + diagnostic settings to a Log Analytics workspace in the Management sub. Not ‘maybe later’. Day one.
• Mandatory tagging: Enforce Owner, Environment, CostCenter via Azure Policy. Reject resources missing tags. Yes, even if Dev says ‘but my test VM is temporary!’ (Hint: nothing is temporary. Everything costs money. Especially that VM with 128 vCPUs running Ubuntu and a single curl command.)
• Key Vault as the source of truth: No hardcoded secrets in ARM templates, GitHub repos, or sticky notes on monitors. Integrate with Azure Pipelines using get-secrets tasks—not echo $PASSWORD.

Bonus move: Deploy a shared-services resource group with pre-approved NSGs, UDRs, and private endpoints. Save your network team from writing firewall rules in YAML at midnight.

Phase 4: Your First Deployment—And Why It Will Fail Spectacularly

The Three Most Common ‘First Deployment’ Disasters (and How to Dodge Them)

1. The ‘I Ran az login —tenant’ Disaster: You authenticated to the wrong tenant, deployed resources to a dev tenant, then realized 3 days later when Finance asked why there’s a $2,300 charge on the acme-corp-prod credit card. Fix: Always use az account set --subscription "SUB_NAME" immediately after login—and alias it to azsub in your shell.
2. The ‘I Used Default VNet’ Disaster: You accepted the default VNet name, address space, and subnet. Later, you try peering it to on-prem—and discover overlapping CIDRs, or worse, that someone else already used 10.0.0.0/16 for their IoT sandbox. Fix: Standardize VNet names (vnet-<env>-<region>) and use /22s with documented gaps.
3. The ‘I Didn’t Check Quotas’ Disaster: Your AKS cluster fails because the region has zero remaining Standard_D8as_v4 cores. Azure won’t tell you ‘sorry, quota exhausted’—it’ll just hang for 45 minutes then time out. Fix: Run az vm list-usage --location eastus before provisioning anything compute-heavy. And yes—request quota increases before go-live, not during the war room.

Phase 5: The ‘Done’ Checklist (Spoiler: There Is No Done)

Onboarding isn’t a project—it’s a habit. Your checklist should include:

• ✅ Monthly subscription health check (orphaned resources, untagged resources, unused public IPs)
• ✅ Quarterly PIM access review (remove stale approvals, audit who can reset passwords)
• ✅ Biannual policy review (update allowed SKUs, block legacy TLS, retire deprecated regions)
• ✅ ‘Chaos Friday’ drill: Pick one non-critical resource, delete it, and validate backup/recovery in under 20 minutes

Final truth bomb: Azure onboarding succeeds not when everything is configured—but when your finance team can trace every dollar to a tagged workload, your security team can prove least-privilege enforcement, and your developers stop asking ‘How do I get admin access?’ and start asking ‘Where’s the self-service portal for dev environments?’

That’s not infrastructure. That’s culture. And culture doesn’t deploy via ARM template. It ships with coffee, empathy, and one very well-documented Confluence page titled ‘No, Karen, You Still Can’t Be a Global Admin.’