Azure Maps

About Azure Maps

Azure Maps is Microsoft's managed geospatial platform for developers and organizations that need mapping, geocoding, routing, traffic, weather, time-zone and spatial capabilities inside applications. It combines REST APIs with web and mobile mapping tools so teams can add location context without building a mapping stack from scratch. The service is best evaluated as an application platform rather than a finished consumer map: buyers choose the APIs, SDKs, authentication method and transaction volume that fit their own product.

What does Azure Maps provide?

Azure Maps provides map rendering, address and place search, routing, traffic, weather, time-zone, geolocation and spatial services. Microsoft also exposes a Web SDK for interactive maps and REST APIs for language-agnostic application integration. Common use cases include logistics, fleet tracking, asset monitoring, store locators, delivery routing, mobility applications and location-aware dashboards.

The platform can render road, satellite, traffic and weather tiles, perform geocoding and reverse geocoding, calculate routes, work with travel-time or distance matrices, and add geographic context to operational applications. This breadth is useful when a team wants several mapping capabilities under one Azure resource and billing model rather than stitching together unrelated APIs.

How does Azure Maps pricing work?

Pricing was checked on August 27, 2026. Microsoft currently recommends the Gen2 pricing tier for new and existing Azure Maps customers. Gen2 is usage based and meters different services by transactions rather than charging one fixed monthly subscription price. Microsoft publishes free monthly allowances for several service categories and then applies paid transaction pricing according to the API or map capability used.

The transaction definition differs by service. Tile requests can be grouped into billing transactions, while route matrices, batch search, batch routing and autocomplete use their own counting rules. Teams should model the actual API mix, not just total HTTP requests, because two applications with the same request count can produce different bills. Regional agreement and currency also affect displayed rates, so BrandLigo does not present one universal dollar figure.

What is changing with Gen1 pricing and older APIs?

Azure Maps has important 2026 lifecycle changes that buyers should not miss. Microsoft states that the Gen1 pricing tier is deprecated and retires on September 15, 2026. Existing Gen1 S0 or S1 accounts should move to Gen2 before that date or Microsoft will update the account according to its retirement guidance.

Microsoft also states that Azure Maps Render v1 is deprecated and retires on September 17, 2026. Applications still calling the older Render v1 API should migrate to a current Render API before that date. These dates matter for existing applications because a mapping integration can keep working for years while quietly depending on an older endpoint or pricing model.

What are the current request-rate limits?

Azure Maps does not impose one universal daily request cap, but Microsoft publishes queries-per-second limits by service. Current Gen2 examples include up to 500 QPS for road map tiles, 250 QPS for satellite tiles, 500 QPS for single Search requests, 250 QPS for reverse search, 100 QPS for geocode autocomplete, and 50 QPS for single Route requests. Batch search and batch route operations have lower published QPS limits.

These limits should be considered before using Azure Maps for sudden high-volume consumer traffic or large batch workloads. Applications should cache where licensing permits, control retry behavior, spread large batch jobs and monitor throttling rather than assuming unlimited burst capacity.

How should applications authenticate to Azure Maps?

Azure Maps supports shared-key authentication, but Microsoft recommends Microsoft Entra ID for production scenarios. Entra-based access can use users, registered applications and managed identities, with Azure RBAC controlling access to the Maps account. Managed identities are especially useful when the calling application runs on Azure because they reduce the need to distribute or rotate long-lived application secrets.

Shared keys remain useful for simple development and some legacy integrations, but production teams should treat them as credentials that need protection and rotation. Authentication design also affects deployment architecture, CI/CD configuration and how safely multiple applications can share access to one Maps account.

What should buyers know about data, coverage and attribution?

Coverage differs by capability and geography, so buyers should verify the specific Search, Route, Traffic, Weather or Render coverage required by their application rather than assuming every feature is identical worldwide. Microsoft currently states that Azure Maps services are unavailable in China and Korea. Azure Maps also requires appropriate map copyright attribution when Microsoft map tiles or rendered basemaps are used.

Microsoft states that customer-provided address and location queries can be shared with TomTom for mapping functionality under Microsoft's subprocessor arrangements, without being linked to an identified customer or end user. Organizations with strict data-residency, privacy or procurement requirements should review Microsoft's current trust and subprocessor documentation before deploying location-sensitive workloads.

How does Azure Maps fit with Power BI and Microsoft Fabric?

Azure Maps is not limited to developer APIs. Microsoft also provides an Azure Maps visual for Power BI, and Maps in Microsoft Fabric is currently positioned as a geospatial visualization experience in Fabric Real-Time Intelligence. Those experiences can be useful when the requirement is analyst-facing visualization rather than building a custom application.

A development team should still choose the Azure Maps APIs or SDKs when it needs custom search, routing, geofencing, traffic or map interaction in its own software. A business-intelligence team may prefer the Power BI or Fabric experiences when the main goal is to analyze spatial data without maintaining a custom mapping front end.

What are the main limitations and operational tradeoffs?

Azure Maps removes the need to operate a map-data platform, but it does not remove application responsibility. Teams still need to design authentication, caching, request throttling, attribution, error handling, API-version upgrades and cost monitoring. High request rates can hit service-specific QPS limits, and older APIs or pricing tiers can create migration work when Microsoft retires them.

Mapping quality also depends on the exact geography and use case. Teams building regulated navigation, specialized indoor mapping, offline mapping or highly customized cartography should validate whether Azure Maps provides the needed data, controls and licensing before standardizing on it.

Who should choose something else?

Choose another option if the requirement is a finished consumer navigation application rather than embeddable geospatial services, if a specialized mapping vendor offers materially better data for the required region, or if the project needs offline-first maps with licensing and packaging that do not fit Azure Maps. Teams already standardized on another cloud mapping platform should also compare migration cost, SDK compatibility, map-data quality and operational complexity rather than moving only for vendor consolidation.

For basic location display inside analytics, Power BI or Microsoft Fabric may be simpler than building directly on the Azure Maps APIs. For applications that only need one small geocoding or static-map feature, a narrower service can also be easier to operate if Azure Maps' broader platform capabilities are unnecessary.