Top Azure Services

What This Chapter Is About

Help readers revise important Azure services by remembering each service's architectural job, common use cases, trade-offs, and decision prompts.

This chapter is practical rather than encyclopedic. The goal is not to memorize every Azure feature. The goal is to recognize which responsibility a service usually owns in an architecture and what question should be asked before choosing it.

Keep one durable idea in view:

Service reference is useful when it connects product names to architecture responsibilities and trade-offs.

Sections

1. How to Use the Service Guide

2. Identity, Governance, and Security Services

3. Networking and Edge Services

4. Compute and Container Services

5. Integration and Messaging Services

6. Data and Analytics Services

7. AI and Agentic Services

8. Observability, Operations, and Cost Services

9. Service Selection Comparison Prompts

10. Architecture Review and Conversation Prompts

How the Chapter Develops

The chapter develops in this order:

1. Explain how to use the service guide as a decision aid, not a memorization list.

2. Group services by architecture responsibility: identity, governance, security, networking, compute, integration, data, analytics, AI, operations, and cost.

3. Give each service entry a compact structure: purpose, when to use, when not to use, architecture patterns, cloud comparison where useful, and common design prompt.

4. End with comparison prompts and review questions that help readers explain service choices clearly.

Together, these sections show that service names are easier to remember when they are tied to recurring architecture decisions.

What You Will Be Able to Do

By the end of this chapter, the reader should be able to:

• Explain the architectural job of important Azure services.

• Recognize when a service is a strong fit and when it is not.

• Compare similar services without treating names as direct equivalents.

• Connect services to architecture patterns from earlier chapters.

• Answer common service-selection questions in a clear, practical way.

Key Ideas

• Start from the responsibility, then name the service.

• A service entry should explain purpose, fit, limits, patterns, comparisons, and prompts.

• Service mappings to AWS or GCP are vocabulary bridges, not complete design answers.

• Similar services often differ by ownership, durability, scale, control, or operating model.

• The best short answer usually names the trade-off, not only the product.