ARM Template deployment - CosmosDB provision fails with - Request rate is large. More Request Units may be needed, so no changes were made

Question

I tried deploying cosmosDB and when I first create it I get this error - "Request rate is large. More Request Units may be needed, so no changes were made"

After redeploying it works.

But the initial creation doesn't.

I extended the throughput to 50000 (autoscale) and 10000 with fixed size. Is there another option to extend the RUs?

"type": "Microsoft.DocumentDB/databaseAccounts/sqlDatabases/containers",
  "apiVersion": "2020-03-01",
  "name": "
  "dependsOn": 
    
  ],
  "properties": {
    "resource": {
      "id": "subscriptions",
      "indexingPolicy": {
        "indexingMode": "consistent",
        "automatic": true,
        "includedPaths": [
          {
            "path": "/*"
          }
        ],
        "excludedPaths": [
          {
            "path": "/\"_etag\"/?"
          }
        ],
        "spatialIndexes": [
          {
            "path": "/*",
            "types": ["Point", "LineString", "Polygon", "MultiPolygon"]
          }
        ]
      },
      "partitionKey": {
        "paths": ["/partitionKey"],
        "kind": "Hash"
      },
      "uniqueKeyPolicy": {
        "uniqueKeys": []
      },
      "conflictResolutionPolicy": {
        "mode": "LastWriterWins",
        "conflictResolutionPath": "/_ts"
      }
    },
    "options": {
      "autoscaleSettings": {
        "maxThroughput": 50000
      }
    }
  }

Answer 1

The error message indicates that there was a large number of requests hitting the master partition for your account. This can be caused by other clients querying the database resource to list containers or querying containers to get it's properties. It can also happen when you are deploying a large number of Cosmos resources at the same time. This is mostly a transient issue and is hard to reproduce.

Your arm template for this container looks correct. I'm guessing you've purposely removed the name and depends on parameters.

I would update the api-version to 2020-04-01 however. There are issues with 2020-03-01 with autoscale and that api-version is going to be deprecated in the future.