Manage Google Maps Platform costs

Google Maps Platform provides a range of options for controlling your consumption and ensuring that your usage aligns with your budget. Options include:

  • Stop charges by capping the number of billing events your app triggers.
  • Get notified when your usage approaches specific budget or API limits.
  • Build your apps more cost effectively.

The following table shows your options.

Stop Charges Get Notified Build for Lower Cost

Modify quota limits

Create budgets and budget alerts

Follow cost-efficient implementation strategies

Quotas

Quotas restrict how much of a Google Maps Platform service can be used by your Google Cloud project. Quotas are intended to ensure fairness and reduce spikes in resource use and availability. For more information, see Cloud Quotas overview.

The following count against quota:

  • Successful requests
  • Requests that cause server errors

The following don't count against quota:

  • Requests that fail authentication

You can set up quota alerts to be notified when your API usage is approaching the limit. For more information, see Set up quota alerts and monitoring.

Quota limits help you control your API usage and prevent unexpected charges by capping the number of requests your project can make. While quota limits are set by default, they can be increased or decreased by submitting an adjustment request. For more information on managing quotas, see View and manage quotas.

A quota sets the most your project can use an API, so it also sets the most you can be charged for that API. Lowering a quota lowers that ceiling. Raising a quota raises it, which means your project can make more billable requests before the API stops responding. A quota increase doesn't cap your spending or protect you from unexpected charges.

For example, suppose a bug in your pagination code keeps requesting the next page of results with no stop condition. With a quota of 10,000 requests per day, the API rejects the loop's requests after the first 10,000. If you raise the quota to 100,000 requests per day, the same loop can make 10 times as many billable requests before the API rejects them.

A quota also limits the cost of unwanted traffic, such as requests from automated crawlers or from someone else using your API key, but it isn't your main protection against that traffic. To block unwanted traffic, restrict your API keys to your apps and to the APIs they use. Use quotas as a backstop.

Request a quota increase only when your app needs more capacity for expected traffic, such as a product launch or a seasonal peak.

Set quota limits

To put a hard cap on usage of an API, lower its per-day quota. When your project reaches the limit, requests to that API fail for the rest of the day. The limit applies again each day, because daily quotas reset at midnight Pacific time. Set the limit high enough for your app's normal traffic. For example, if your app usually makes about 2,000 requests per day and up to 3,000 on busy days, a limit of 4,000 requests per day covers your busiest days and stops a runaway loop at 4,000 requests.

To change a limit, open the Quotas page in the Cloud console, select the API, and edit the quota. For detailed steps, see View and manage quotas.

To stay within a SKU's monthly free usage cap, divide the free usage cap by 31 (the most days in a month) and round down. Set the result as the daily limit on the quota that counts what the SKU bills for. For example, if a SKU has a free usage cap of 1,000 billable events per month, divide 1,000 by 31 to get about 32.3. A daily limit of 32 keeps usage at or below 992 in any month. Free usage caps can change, so check the current cap for each SKU before you set a limit.

Before you set a daily limit, check how the SKU is billed:

  • Billing unit: Some SKUs bill per element or per map load, not per request. For example, computeRouteMatrix requests are billed per element, which is the number of origins multiplied by the number of destinations. A request with 5 origins and 10 destinations is billed for 50 elements. If you set a limit of 32 requests per day, your app can still use 1,600 elements per day. For these SKUs, lower the per-day quota that counts the same unit, such as elements per day, not requests per day.
  • No matching quota: Some billing units, such as sessions, don't have a matching quota. A requests quota still caps that usage, because each session includes at least one request, but it can block traffic before you reach the free usage cap.
  • More than one SKU per API: If requests to an API can trigger more than one SKU, base the limit on the SKU with the lowest free usage cap.
  • More than one API per SKU: If more than one API in your project bills to the same SKU, split the daily limit across those APIs.

Adjust quota as needed

Regularly review and adjust your API quotas to optimize usage and costs while finding a balance between preventing excessive spending and ensuring your application functions properly.

  • Monitor your API usage patterns in the Google Cloud Console. Set quotas that align with your budget and prevent overspending.
  • Ensure quotas can handle peak usage periods.
  • Make gradual adjustments and test your application thoroughly after each change to avoid disruptions.

Budgets and alerts

If you have a specific budget for your Google Maps Platform use, you can avoid surprises in your bill by creating Cloud Billing budgets and alerts.

You can set budget alerts to notify you when you've reached a certain percentage of your total budget, so that you can see how your usage costs are trending over time.

For more information, see Create, edit, or delete a budget alert.

Strategic cost management

Effective budgeting involves using free or lower-cost options whenever possible. This section explores various strategies for minimizing costs.

Use Maps Static API whenever possible

The following situations work well with static maps, which support simple map displays that only need a single marker:

  • You are starting with a prototype that doesn't yet have a lot of features.
  • You don't have any map customizations.
  • You use at most one marker.
  • You don't need to support user interaction using dynamic maps or dynamic street view.

Lazy-load using thumbnails

Thumbnails (small map images) are a good use for the Maps Static API. These items are billed at a lower rate than dynamic map loads and upon user interaction can take users to a dynamic version of Google Maps on-click, so that you only pay for dynamic map loads for engaged users.

Use cheaper pricing categories

Google provides a different number of free usage events for each pricing category. You can optimize your application to use capabilities in the "Essentials" or "Pro" categories, where you have more free monthly usage events. Learn more about pricing categories.

Consolidate multiple maps

If you have an implementation that displays multiple maps, follow these guidelines:

  • Load maps only when necessary, minimizing unnecessary resources.
  • Reuse a single map by updating its viewport, zoom, and markers as needed.
  • Use the Store Locator Plus solution if you're displaying multiple maps to show store locations.
  • Use a single map per user-interface screen, as users generally only interact with one map at a time.

Cache content when permitted

Most Google Maps Platform products prohibit caching content. However, some exceptions allow you to cache their results for up to 30 days. See the Google Maps Platform terms for details.