Azure
Why I recommend it as the lowest-friction cloud entry for Microsoft-aligned shops
I’ve worked across AWS, Azure, and GCP at multi-cloud working-knowledge depth, not as a pure-Azure specialist, but enough across real deployments to know where the platform earns its keep and where the rename cadence punishes anyone trying to keep documentation current. This is the case I make to clients already running M365 who are evaluating cloud workloads, and the portal sprawl no one in marketing prints.
Why Azure works
Four reasons hold up across deployments.
Entra ID is the cloud's identity layer
One IDP for Azure resources, M365, third-party SaaS (via SCIM, SAML, and OIDC), and on-prem (via Entra Connect or Cloud Sync). Conditional access at the platform level applies the same way to Azure resource access as it does to M365 app access, which means one policy model, not two.
The painful "every workload owns its own identity store" anti-pattern dissolves once Entra is the source of truth. One join in HR, one offboard, every plane affected.
Defender for Cloud and Sentinel as integrated security
Defender for Cloud carries CSPM plus runtime threat detection across VMs, containers, and databases, priced by resource tier so you pay for what you actually protect. Sentinel runs as the cloud-native SIEM with Azure Monitor and Log Analytics as the backbone, and native KQL queries beat raw log greps by a wide margin.
Handing an auditor a Defender for Cloud secure score plus a Sentinel incident log plus Entra sign-in logs covers most of a SOC 2 control set without a third-party SIEM. The platform is doing audit work you used to pay separately for.
Hybrid that actually ships (Azure Arc)
Arc-enabled servers and Kubernetes mean on-prem and other-cloud resources show up in Azure RBAC, Policy, and Monitor as if they were native. Defender for Cloud extends to Arc-managed resources, so the security posture view stays unified across hybrid rather than fragmenting per environment.
Managing on-prem VMs plus AWS EC2 instances plus Azure VMs from one Azure Policy view is the closest thing to actually unified hybrid I've seen ship. The other clouds talk about hybrid; Arc does it.
Compliance baseline for regulated industries
Azure Government and Azure China cover sovereign-cloud requirements. FedRAMP High, HIPAA, PCI, and GDPR baselines are extensive. Microsoft Purview handles data classification, DLP, and retention across M365 and Azure from one admin surface.
For regulated mid-market in healthcare, finance, and government-adjacent verticals, Azure's compliance baseline is the lowest-effort path to audit-ready. The auditor has seen the Microsoft evidence packages before.
Where it fits best
Not every shop. The fit is sharpest when one of these describes you:
Extending to cloud workloads when identity, billing, and support are already wired through your existing Microsoft tenant. Adding Azure subscriptions on top of an existing M365 footprint is incremental work, not a migration.
Arc handles on-prem and multi-cloud in a way AWS doesn't currently try to match. If your reality is "we're keeping the on-prem footprint for years and adding cloud on top," Azure's hybrid story is the most honest.
Healthcare, finance, and government-adjacent shops where the compliance baseline carries real weight. Purview plus Defender for Cloud plus Compliance Manager covers a meaningful chunk of audit evidence out of the box.
The labor market for Azure-skilled admins is deep wherever M365 admins already exist. Hiring an AZ-104 in LATAM is a different conversation than hiring a Google Cloud specialist of comparable depth.
If you’re not on M365 and don’t need Microsoft-stack integration, AWS is the more defensible default cloud. If you’re not sure whether M365 itself is the right baseline, start with the Microsoft evaluation first.
The honest tradeoffs
Marketing won’t print these. I have, in production. Tap to expand.
Portal sprawlFive portals, one tenant, no muscle memory transfers
Azure portal, Entra portal, Defender portal, Intune portal, Purview portal. Different teams live in different blades, search behaves differently in each one, and the URLs change roughly every 18 months as Microsoft repositions services. Bookmark the actual blade URLs your team uses, document the path in your runbooks, and budget time for the next reshuffle. The portals are approachable individually; switching between them is the friction.
Renames"Azure AD" → "Entra ID" → next name, and the docs lag
Azure AD became Entra ID. AAD Connect became Entra Connect, then Cloud Sync for newer deployments. Azure Sentinel became Microsoft Sentinel. The rename cadence isn't about confusion for its own sake; it reflects Microsoft repositioning identity and security as platform-wide capabilities rather than Azure-specific products. Keeping the current canonical name straight is admin overhead, and third-party documentation always trails the rename by months.
Cost observabilityCost Management improved but still trails AWS Cost Explorer
Reserved Instances vs Savings Plans vs Spot vs Pay-as-you-go vs Azure Hybrid Benefit math is non-trivial, and the right mix depends on workload predictability. Subscription-level vs management-group-level cost rollup is a learning curve in itself, and Cost Management views feel one generation behind what AWS shipped years ago. Set Budgets alerts at 50%, 80%, and 100% before the first workload lands, and treat the first quarterly bill review as mandatory, not optional.
Platform lock-inIdentity, security, and cloud concentrated under one vendor
Once Entra ID is your identity backbone and Defender for Cloud is your CSPM, peeling out is a multi-quarter project. The same calculus applies to AWS lock-in, but with the additional dimension that Microsoft owns identity, productivity, AND cloud in the same tenant. Vendor bargaining power is concentrated in a way that's worth entering eyes-open, not a reason to avoid Azure but a reason to design exit-cost into the architecture review rather than discovering it three years in.
Azure's strength is the platform fabric. The tradeoff is that the same fabric makes it hard to leave once you're inside.
Is it right for your company?
Four dimensions to check before you commit:
- Size: 50–10,000+ employees. Below 50, the Azure overhead beyond what a Business Premium M365 tenant already gives you is usually not worth the admin lift. Above 10,000, the conversation needs a Microsoft Partner with real Azure Landing Zone delivery muscle, not a solo consultant.
- IT maturity: At least one admin with AZ-104 (Azure Administrator Associate) baseline or willing to invest in it. The lead architect on a first landing zone should be on the AZ-305 path; the design decisions made in week one are expensive to refactor once production subscriptions are in use.
- Existing stack: Microsoft 365 plus Entra ID is the best fit. AWS-first or GCP-first orgs face higher friction adding Azure as a secondary cloud, and the integration story isn’t compelling enough on its own to justify the second tenant unless there’s a specific workload reason.
- Geography: Global. LATAM has Brazil South as the regional anchor plus smaller edge presence; Mexico Central is on the published roadmap but not yet GA at this writing. US Gov and Germany sovereign clouds matter for specific regulated workloads.
If three of the four match, Azure is on the shortlist. If all four match, it’s probably the right answer.
Who implements it
Internally, the lead implementer should be a cloud architect or senior systems engineer with real Azure exposure. AZ-104 is the practical baseline for the team; AZ-305 (Azure Solutions Architect Expert) for the lead on landing zone or Arc work. Tenant-level and subscription-structure decisions made in week one (management group hierarchy, RBAC model, network topology, baseline policies) are expensive to refactor once production workloads depend on them.
External help is worth it for the first landing zone build. A Microsoft Partner who has shipped Azure Landing Zone accelerator deployments, governance baselines, and Defender for Cloud rollouts several times will save you the discovery cost on the parts that look simple in the docs and aren’t in practice. CSP partners handle the billing and procurement side, which matters in LATAM where local-currency invoicing and channel margin negotiation are part of the conversation.
If you’re standing up your first Azure landing zone or extending an existing M365 tenant into cloud workloads, let’s talk. Start with a 30-minute scoping call; if it’s a fit, we’ll spec the engagement from there.
First steps
- Read the Microsoft 365 + Entra ID + Intune evaluation first. Azure on top of M365 is incremental; Azure without M365 is a harder sell against AWS. The identity broker, the billing relationship, and the admin skill set are already in place if M365 is running. If they aren't, the foundation question comes first.
- Pick the entry workload and start with the foundation. My recommended sequence:
- VNets plus Hub-Spoke topology. Networking baseline before workloads land. Topology decisions are expensive to undo.
- Entra ID plus Entra Connect. Identity baseline, likely already in place from M365. Confirm the sync scope and conditional access posture before adding Azure resources.
- Defender for Cloud plus Sentinel. Security baseline before scale. You want the secure score visible the day the first VM boots, not the day after the first incident.
- Cost Management plus Budgets. Financial baseline before the first big bill. Alerts at 50%, 80%, and 100% of monthly expectation are not optional.
- Use the Azure Landing Zone accelerator for the first deployment. Don't hand-craft the foundation. The accelerator captures years of Microsoft plus community guidance on management groups, policy assignments, and network topology that you'd otherwise rediscover the hard way in production.
Beyond first steps: I take on Azure network, identity, and security work for SMB and mid-market clients in LATAM and remote globally. Talk to me about your cloud roadmap. I’ll tell you in 30 minutes whether it’s an Azure job, an AWS job, or a “fix what you already have” job.