DocumentDB vs Cosmos DB vs Firestore - which for a new app?

I am architecting a new application with a primary requirement for a globally distributed, document-oriented database. The logical contenders are Amazon DocumentDB (with MongoDB compatibility), Azure Cosmos DB (with the MongoDB API), and Google Cloud Firestore. While all three can fulfill the basic functional need, the long-term cost implications of selecting one over the others are profound and, in my experience, often underestimated during the initial design phase.

I have constructed a preliminary cost model based on the following projected monthly workload for the first year:
* 1 TB of total data storage, with an expected 20% month-over-month growth.
* 5 million read operations per day, with an average document size of 10KB.
* 2 million write operations per day.
* A requirement for data to be replicated across three geographic regions for low-latency access.

My initial analysis, using the respective pricing calculators as of this month, yields the following monthly cost projections for this base workload:

**Amazon DocumentDB (on-demand, 3 regions)**
* Instance Costs (db.r5.large, 3 regions): ~$1,800
* I/O Costs (5M reads/day @ $0.20/1M requests): ~$30
* Storage Costs (1TB @ $0.10/GB): ~$100
* **Estimated Total:** **~$1,930**

**Azure Cosmos DB (Provisioned Throughput, 3 regions, MongoDB API)**
* RU/s Calculation (est. 1000 RU/s needed): 1000 RU/s * 720 hrs * $0.00008/RU-hr = ~$58
* Multi-region Write Replication Add-on: 2x multiplier = ~$116
* Storage (1TB @ $0.25/GB): ~$250
* **Estimated Total:** **~$366**

**Google Cloud Firestore (Native mode, Multi-region)**
* Document Reads (5M/day @ $0.06/100k): ~$90
* Document Writes (2M/day @ $0.18/100k): ~$108
* Storage (1TB @ $0.18/GB): ~$180
* **Estimated Total:** **~$378**

These numbers present an immediate and stark divergence. DocumentDB's architecture, being instance-based, incurs a high fixed cost that dominates the estimate. Cosmos DB and Firestore, with their serverless, operation-based models, appear significantly more economical for this variable, growing workload. However, this is a simplistic view.

The critical nuances lie in scaling behavior and cost drivers:
* Cosmos DB's cost is highly sensitive to the Request Unit (RU) provisioning model. Autoscale and serverless tiers change this equation dramatically. A miscalculation in RU/s can lead to throttling or overspending.
* Firestore's cost is almost purely operational, but complex queries (especially those requiring composite indexes) can multiply read counts. The pricing for multi-region writes is embedded but must be considered.
* DocumentDB's cost becomes more predictable at very high, steady-state loads, but you pay for compute even when idle.

I require more granular, real-world data. Specifically, I am seeking detailed breakdowns on:
* The actual cost-per-1000-read-operations for each service when documents are in the 1-20KB range.
* The hidden costs of global distribution: data transfer out (to the internet) costs from each primary region.
* The practical implications of scaling each system under a sudden 10x traffic spike. Does Cosmos DB's autoscale trigger a 10x cost multiplier for that hour? Does Firestore's latency increase? Does DocumentDB require a manual instance class change?

Please provide any empirical data or cost allocation reports from production workloads that mirror this scale. Configuration snippets illustrating the most cost-optimized setup for each service for this scenario would be invaluable.

```json
// Example: A Cosmos DB container provision with autoscale
{
"resource": "container",
"options": {
"throughput": {
"autoscale": {
"maxThroughput": 10000
}
}
}
}
```

Show me the bill.