Azure: Services & Architecture

Welcome

A practical guide to 65 core Azure services — what they do, how they work, when to use them, and when not to.

10 chapters 65 services covered 5 case studies Knowledge check on every service 6 hours audio

About This Guide

Azure has more than two hundred services and a portal that rearranges itself faster than anyone can memorize. Most engineers work with a few dozen and need real fluency in perhaps sixty. This guide covers sixty-five — the services that carry production workloads, anchor real architectures, and cause the most damage when chosen wrong.

Microsoft Learn is thorough and current, but it does not tell you when not to use a service, how to pick between the three things that look like they do the same job, or what the failure modes look like at 2 a.m. Azure also renames services often — Azure AD became Entra ID, Cognitive Services became Azure AI — and the old names linger everywhere. This guide uses plain engineering language and the current names.

Each service is covered with the same structure: what it is, how it works, when to use it, when not to, common mistakes, and best practices. Where services overlap — and on Azure they overlap constantly — the guide gives a direct decision rather than handing you a feature matrix.

Who This Is For

Software engineers, DevOps and platform engineers, and cloud architects working with Azure or moving to it. The material assumes you can read code, understand how web applications are built, and are comfortable with the basics of Linux, networking, and relational databases. No prior Azure experience is required. Engineers coming from AWS or Google Cloud will find the comparable-services sections a fast translation layer.

Prerequisites

  • Basic Linux operations — files, processes, permissions, SSH, reading a stack trace
  • Any modern programming language well enough to read short Python or JSON examples
  • HTTP and TLS fundamentals — the shape of a web request, transit encryption
  • Networking basics — IP addresses, ports, subnets, public vs private networks
  • No prior Azure experience required

The Azure Landscape

Azure grew out of Windows-era enterprise software, and its center of gravity shows: deep Active Directory roots (now Entra ID), first-class hybrid and on-premises integration, and a portal built for organizations with many subscriptions and strict governance. Identity and management sit at the core in a way they do not on other clouds. The cost of that heritage is a catalog full of renamed services and overlapping options layered over fifteen years.

Azure Global Infrastructure — Regions and Availability Zones
Region · example: East US
Zone 1independent datacenter(s)
Zone 2independent datacenter(s)
Zone 3independent datacenter(s)
A Region is a geographic area; most hold three Availability Zones with independent power, cooling, and networking. Spreading across zones survives a single-datacenter failure; pairing with a second Region survives a Region-wide outage. Not every Region has zones — confirm before you design for them.

The upside is reach and integration. Azure spans more than sixty Regions, most with multiple Availability Zones, and the identity, governance, and hybrid story is the strongest of the major clouds for enterprises already running Microsoft software. Engineers who know AWS or Google Cloud will find the primitives familiar; the differences are naming, the central role of identity, and the subscription-and-resource-group model for organizing everything.

Architecture Philosophy

One theme runs through every chapter: the best architecture is the simplest one that meets the requirements. That runs against the instinct to reach for sophisticated services because they feel safer or more impressive. Complexity is a real cost, and operational burden — patching, upgrades, incident response, capacity planning — is as real as the compute bill even when it never appears on the invoice.

Start simple
Operational complexity is a cost. A managed service that needs less maintenance earns its place even when it is less configurable than the alternative.
Identity is the perimeter
On Azure, most breaches are identity failures, not network ones. Get Entra ID, RBAC, and managed identities right before anything else.
Match tool to workload
Azure has many services that look alike. Each has a specific envelope. The wrong one does not just cost more — it creates problems that are hard to undo.
Operational burden is cost
Every self-managed component carries maintenance cost. Managed services delegate that work. Treat the trade-off explicitly, not as a default.

Chapter Map

Chapter 1
Compute
Virtual Machines, scale sets, Functions, App Service, and containers on ACI, AKS, and Container Apps — eight services across the full control spectrum.
Chapter 2
Storage
Object, block, and file storage — Blob, Disks, Files, NetApp, Data Lake — under one account model, plus Azure Backup. Shapes that are not interchangeable.
Chapter 3
Databases
Eight data stores spanning relational, document, key-value, in-memory, and analytical models — with Azure's unusually layered SQL lineup.
Chapter 4
Networking & Content Delivery
Virtual Network, load balancers, Application Gateway, DNS, Front Door, ExpressRoute, VPN Gateway, and Traffic Manager — connectivity, traffic, and edge.
Chapter 5
Security & Identity
Entra ID, External ID, Key Vault, managed identities, WAF, DDoS Protection, Defender for Cloud, and Sentinel — the tenant's security posture.
Chapter 6
Monitoring & Management
Azure Monitor, Log Analytics, Application Insights, Policy, Resource Manager, and Arc — six services for visibility, governance, and control.
Chapter 7
Developer Tools & Integration
Azure DevOps, Pipelines, Container Registry, Service Bus, Event Grid, Event Hubs, and Logic Apps — delivery and decoupled, event-driven integration.
Chapter 8
AI & Machine Learning
Azure Machine Learning, OpenAI Service, and the pre-trained AI APIs — Vision, Language, Speech, and Document Intelligence — the AI surface of Azure.
Chapter 9
Architecting on Azure
The Well-Architected Framework, landing zones, network topology, resilience, cost, security baseline, and multi-Region design.
Chapter 10
Case Studies
Five workload shapes — serverless SaaS, fintech, e-commerce, analytics, and enterprise migration — and the architectures they produce from the same catalog.

Disclaimer

This course is an independent educational project created and maintained by Sergey Okinchuk. It is provided for learning and reference purposes only.

No affiliation with Microsoft. This course is not affiliated with, sponsored by, endorsed by, commissioned by, or in any way officially connected to Microsoft Corporation or any of its subsidiaries or affiliates. All opinions, interpretations, and recommendations expressed are those of the author.

Trademarks. "Microsoft", "Azure", "Microsoft Azure", "Entra", and all Azure service names and logos are trademarks of Microsoft Corporation. All other product names, service names, and logos referenced throughout this course are trademarks or registered trademarks of their respective owners. Use of these names and marks is for identification and educational purposes only and does not imply any endorsement, sponsorship, or partnership.

Logo and icon attribution. The Azure logo and the per-service product icons used throughout this course are reproduced from the official Azure architecture icons set under nominative fair use for educational and editorial purposes. No modifications have been made to the official marks beyond resizing and standard rendering.

Accuracy and currency. Cloud platforms evolve rapidly. Features, pricing, regional availability, quotas, default behavior, and best practices described in this course reflect the author's understanding at the time of writing and may not be current. Always consult the official Microsoft Azure documentation as the authoritative source before making architectural, operational, or financial decisions.

No warranty. This material is provided "as is" without warranty of any kind, express or implied, including but not limited to warranties of accuracy, completeness, merchantability, or fitness for a particular purpose. The author makes no representations regarding the suitability of this material for any specific use, and accepts no liability for any loss, damage, cost, or claim arising from reliance on the content in production systems or otherwise.

Third-party content. Where this course references documentation, blog posts, conference talks, or other external sources, attribution is provided to the original authors. All quoted material remains the property of its respective rights-holders.