[Azure/MongoDB] Creating Azure Cosmos DB for MongoDB (RU)

Contents

1)Install the Azure Cosmos DB for MongoDB (RU)

1.1) Basic Tap

1.1.1) Project Details – Thông tin dự án

Workload Type*
→ Lựa chọn loại khối lượng công việc bạn muốn chạy:
– Learning
– Devlopment/Testing
– Production
Dựa vào đó, Azure sẽ đề xuất thiết lập tối ưu, nhưng bạn vẫn có thể điều chỉnh theo nhu cầu.

Nếu bạn chọn Production thì cấu hình sẽ chọn sẵn cho bạn là: Enable Availability Zones, Capacity là Provisioned throughput, Disable free tier.

Subscription*
→ Chọn gói đăng ký bạn đang sử dụng (mỗi subscription gắn liền với tài khoản thanh toán).

Resource Group*
→ Nhóm tài nguyên (Resource Group) giúp bạn quản lý các tài nguyên Azure như cơ sở dữ liệu, máy chủ, mạng… Bạn có thể chọn nhóm có sẵn hoặc nhấn Create new để tạo mới.

1.1.2) Instance Details – Chi tiết cấu hình cơ sở dữ liệu

Account Name*
→ Tên định danh duy nhất cho tài khoản Cosmos DB của bạn.
Availability Zones
- Enable: Bật các vùng khả dụng giúp tăng tính sẵn sàng bằng cách phân tán dữ liệu qua các trung tâm dữ liệu khác nhau.
- Disable: Không sử dụng vùng khả dụng.
Location
→ Chọn khu vực địa lý để đặt dữ liệu. Ảnh bạn chọn là: (South America) Chile Central.
⚠ Lưu ý: Một số vùng yêu cầu thiết lập đặc biệt về backup, bạn sẽ được hướng dẫn ở tab Backup Policy.

1.1.3) Capacity Mode – Chế độ dung lượng (hiệu suất)

Azure Cosmos DB có 2 chế độ:

Provisioned Throughput
→ Bạn định nghĩa trước số lượng RU/s (Request Units per second). Có 2 cách:
- Autoscale: Azure tự động tăng/giảm từ 1–10 lần tùy vào lưu lượng.
- Manual: Bạn đặt cố định số RU/s, thích hợp cho lưu lượng ổn định.
💡 Thích hợp nếu bạn biết rõ lưu lượng truy cập.
Serverless (Đang được chọn trong ảnh)
→ Bạn không cần cấu hình trước. Azure chỉ tính tiền theo lượng RU/s đã sử dụng.
⚡ Phù hợp cho các ứng dụng khởi đầu, lưu lượng không ổn định.

1.1.4) Version – Phiên bản MongoDB

Ví dụ: 7.0
→ Chọn phiên bản MongoDB mà bạn muốn Cosmos DB tương thích.

1.2) Global Distribution

Cho phép bạn cấu hình cách phân phối dữ liệu giữa các vùng (regions) để tăng độ sẵn sàng, khả năng phục hồi và hiệu suất truy cập dữ liệu từ nhiều quốc gia.

1.2.1) Geo-Redundancy (Dự phòng theo vùng địa lý)

Enable:
→ Dữ liệu của bạn sẽ được sao chép sang một khu vực khác (geo-paired region) do Azure chỉ định.
✅ Lợi ích:
- Tăng độ bền dữ liệu và khả năng phục hồi khi khu vực chính gặp sự cố.
- Tự động chuyển sang vùng dự phòng nếu có thiên tai hoặc lỗi trung tâm dữ liệu.
Disable (mặc định):
→ Dữ liệu chỉ tồn tại tại 1 vùng chính (primary region) bạn chọn trong tab “Basics”.

🔎 Khi nào bật?

Nếu ứng dụng bạn yêu cầu khả năng phục hồi cao (high availability) trên toàn cầu hoặc tuân thủ các quy định về bảo vệ dữ liệu.

1.2.2) Multi-region Writes (Ghi dữ liệu từ nhiều vùng)

Enable:
→ Cho phép ghi dữ liệu đồng thời từ nhiều khu vực trên toàn cầu (ví dụ: từ US, Europe, Asia…).
✅ Lợi ích:
- Tăng tốc độ ghi dữ liệu ở các khu vực gần người dùng.
- Giảm độ trễ (latency).
- Hạn chế lỗi khi 1 vùng ghi bị quá tải.
Disable (mặc định):
→ Chỉ một vùng có thể ghi (write region), các vùng khác chỉ có thể đọc (read-only).

🔎 Khi nào bật?

Khi bạn cần ứng dụng phân tán toàn cầu có khả năng ghi dữ liệu từ nhiều khu vực.

1.3) Network tab

Giúp bạn kiểm soát ai và mạng nào có thể truy cập vào cơ sở dữ liệu Cosmos DB. Điều này ảnh hưởng trực tiếp đến bảo mật, hiệu suất, và chi phí kết nối mạng.

1.3.1) Connectivity method (Phương thức kết nối)

a. All networks (Mặc định)

Cho phép mọi địa chỉ IP hoặc dịch vụ có thể truy cập cơ sở dữ liệu này.
🔓 Dễ sử dụng nhưng ít an toàn hơn nếu không cấu hình tường lửa kỹ.

b. Public endpoint (selected networks)

Chỉ cho phép một số IP cụ thể hoặc VNet (Virtual Network) truy cập qua địa chỉ công khai.
✅ Khuyến nghị cho môi trường production để giới hạn truy cập không mong muốn.

c. Private endpoint

Kết nối Cosmos DB qua mạng riêng Azure (VNet) bằng một Private IP, không thông qua internet công cộng.
🔐 Tùy chọn an toàn nhất. Phù hợp với các hệ thống nội bộ hoặc yêu cầu tuân thủ bảo mật cao.

📌 Gợi ý sử dụng:

Môi trường	Khuyến nghị kết nối
Dev/Test	All networks hoặc Public endpoint
Production bảo mật cao	Private endpoint

1.4) Backup Policy:

Cho phép bạn lựa chọn cách Cosmos DB thực hiện backup dữ liệu để phục hồi trong trường hợp mất mát, lỗi hệ thống hoặc rollback.

1.4.1) Backup policy (Chính sách sao lưu)

🔘 Periodic (Định kỳ) – (Đang được chọn)

Cosmos DB tự động backup dữ liệu sau mỗi khoảng thời gian định kỳ.
Bạn cấu hình thời gian backup và thời gian giữ backup.
👉 Phù hợp nếu bạn không cần khôi phục từng thời điểm cụ thể, chỉ cần các bản backup theo chu kỳ.

🔘 Continuous (7 days) – (Miễn phí)

Cosmos DB liên tục sao lưu trong cửa sổ 7 ngày (168 giờ).
Bạn có thể khôi phục lại bất kỳ thời điểm nào trong 7 ngày vừa qua.
👉 Phù hợp cho các app cần khả năng rollback gần như tức thời trong tuần vừa qua.

🔘 Continuous (30 days) – (Mất phí cao hơn)

Giống Continuous 7 days, nhưng cửa sổ sao lưu là 30 ngày (720 giờ).
👉 Phù hợp cho các hệ thống tài chính, giao dịch… yêu cầu khôi phục dữ liệu cũ hơn.

⚠️ Lưu ý: Sau khi chọn Continuous, bạn không thể chuyển lại về Periodic.

1.4.2) Backup interval (Chu kỳ sao lưu)

Thời gian giữa các bản backup.
➤ Giá trị từ 60 đến 1440 phút (tức từ 1 giờ đến 24 giờ).
➤ Ví dụ: 240 phút → backup mỗi 4 tiếng.

1.4.3) Backup retention (Thời gian giữ backup)

Khoảng thời gian giữ mỗi bản sao lưu trước khi nó bị xóa tự động.
➤ Có thể từ 8 đến 720 giờ (~8 giờ đến 30 ngày).
➤ Ví dụ: 8 giờ → mỗi bản backup sẽ tồn tại trong 8 tiếng.

1.4.4) Copies of data retained (Số bản sao lưu giữ lại)

Số lượng bản backup được lưu trữ cùng lúc.
➤ Ví dụ: giữ lại 2 bản backup gần nhất.
(Mục này hiển thị mặc định là 2, bạn không chỉnh được tại đây).

1.4.5) Backup storage redundancy (Dự phòng lưu trữ sao lưu)

Tùy chọn nơi và cách Azure lưu bản backup của bạn:

✅ Geo-redundant backup storage (GRS) (Khuyến nghị – đang chọn)

Sao lưu được lưu ở nhiều vùng địa lý khác nhau.
✅ An toàn cao nhất, bảo vệ trong trường hợp toàn vùng trung tâm dữ liệu bị lỗi.

⚙️ Zone-redundant backup storage (ZRS)

Sao lưu ở nhiều vùng (zone) trong cùng một khu vực (region).
⚖️ Cân bằng giữa an toàn và chi phí.

💾 Locally-redundant backup storage (LRS)

Sao lưu trong cùng một vùng, nhiều bản sao trong một trung tâm dữ liệu.
📉 Chi phí rẻ nhất nhưng không an toàn bằng GRS hoặc ZRS.

✅ Tóm tắt khuyến nghị theo mục tiêu:

Mục đích sử dụng	Nên chọn backup policy	Redundancy nên dùng
Web / App đơn giản	Periodic	LRS hoặc ZRS
Hệ thống quan trọng	Continuous (7d)	ZRS
Tài chính / pháp lý	Continuous (30d)	GRS

1.5) Security Tab

Thiết lập cách thức mã hóa dữ liệu (encryption at rest) – tức là dữ liệu được bảo vệ trong quá trình lưu trữ tại trung tâm dữ liệu Azure.

1.5.1) Data Encryption – Mã hóa dữ liệu

Azure Cosmos DB sẽ mã hóa toàn bộ dữ liệu tự động khi lưu trữ trong trung tâm dữ liệu, và tự giải mã khi người dùng truy cập, đảm bảo an toàn cho dữ liệu.

Bạn có 2 lựa chọn để kiểm soát khóa mã hóa (encryption key):

🔘 Service-managed key (Mặc định – đang chọn)

Azure tự động tạo, quản lý và xoay vòng khóa mã hóa.
Bạn không cần phải làm gì thêm.
✅ Dễ sử dụng, ít phức tạp, phù hợp với hầu hết nhu cầu thông thường.

🔘 Customer-managed key (CMK)

Bạn tự quản lý khóa mã hóa bằng cách sử dụng Azure Key Vault.
Bạn có toàn quyền kiểm soát:
- Tạo khóa.
- Xoay vòng (rotate).
- Hủy kích hoạt hoặc thu hồi quyền.
✅ Phù hợp cho tổ chức có yêu cầu bảo mật cao, cần tuân thủ quy định (như ISO, GDPR…).

⚠️ Lưu ý quan trọng:

Nếu bạn đã chọn CMK, bạn không thể chuyển lại sang Service-managed key sau này.
Bạn cần cấu hình trước Azure Key Vault và cấp quyền cho Cosmos DB sử dụng.

🔍 Tóm tắt so sánh:

Tùy chọn	Ai quản lý khóa	Phù hợp với ai	Ưu điểm
Service-managed key	Azure	Người dùng thông thường, startup	Dễ dùng, không cần thiết lập thêm
Customer-managed key (CMK)	Bạn (qua Azure Key Vault)	Doanh nghiệp, tổ chức bảo mật cao	Kiểm soát toàn diện khóa mã hóa

2) Terraform

2.1) Using Terraform to provision the Azure Cosmos DB for MongoDB (Request unit (RU) database account)

resource "azurerm_cosmosdb_account" "mongo" {
 name                = "example-mongo-cosmos"
 location            = var.resource_group_location
 resource_group_name = var.resource_group_name
 offer_type          = "Standard"
 kind                = "MongoDB"

 geo_location {
   location          = var.resource_group_location
   failover_priority = 0
 }
 consistency_policy {
   consistency_level       = "Session"
 }
 mongo_server_version = "7.0"
}

offer_type = "Standard": Luôn là "Standard" đối với tài khoản Cosmos DB mớ. Bạn không thể chỉnh sửa ở chỗ này.

kind = “MongoDB”: Loại API được Cosmos DB sử dụng.

geo_location { ... }: Cấu hình vị trí địa lý và ưu tiên failover (dự phòng).

location = var.resource_group_location: Nơi dữ liệu chính được lưu.
failover_priority = 0
– Thiết lập thứ tự ưu tiên khi xảy ra lỗi vùng (failover).
– 0 là vùng chính (primary). Nếu có vùng phụ, đặt 1, 2,…

consistency_policy { ... }

Chỉ định mức độ nhất quán dữ liệu (Consistency Level).

▪ consistency_level = "Session"

“Session” consistency là mức nhất quán theo phiên, cân bằng giữa hiệu năng và độ chính xác dữ liệu:
- Đảm bảo người dùng luôn thấy phiên bản mới nhất của dữ liệu trong cùng một phiên.
- Mặc định trong Cosmos DB.

🧠 Các mức khác có thể chọn: Strong, BoundedStaleness, Eventual, ConsistentPrefix.

Đây là cách Azure Cosmos DB đảm bảo tính nhất quán của dữ liệu khi đọc từ nhiều vị trí/vùng (regions) — đặc biệt quan trọng trong môi trường phân tán toàn cầu.

Tưởng tượng có 2 người dùng: một ở Mỹ, một ở Việt Nam, truy cập cùng một DB được phân phối toàn cầu. Consistency Level quyết định liệu người ở Việt Nam có thấy được dữ liệu mới mà người ở Mỹ vừa cập nhật hay không — và thấy nhanh đến mức nào.

2.2) Các mức độ nhất quán (`consistency_level`)

Tên mức	Độ mạnh nhất quán	Đặc điểm chính	Khi nào dùng
Strong	🔒 Mạnh nhất	Mỗi lần đọc luôn trả về dữ liệu mới nhất (giống như trong SQL truyền thống).	Hệ thống tài chính, cần độ chính xác tuyệt đối.
BoundedStaleness	⚖️ Cân bằng	Cho phép chậm trễ dữ liệu tối đa `X` bản ghi hoặc `Y` giây.	Khi bạn chấp nhận một độ trễ nhẹ nhưng vẫn kiểm soát được.
Session (mặc định)	🧠 Theo phiên	Mỗi user/thao tác đọc luôn thấy dữ liệu mới nhất mà chính họ đã ghi trong phiên đó.	App thông thường, có người dùng cá nhân (web, mobile).
ConsistentPrefix	📚 Giữ thứ tự	Không thấy bản ghi mới nhất, nhưng luôn đúng thứ tự thời gian.	Chat, feed, log cần giữ đúng dòng thời gian.
Eventual	💨 Yếu nhất	Có thể thấy dữ liệu lỗi thời, nhưng cuối cùng sẽ đồng nhất.	Tối ưu hiệu suất, hệ thống không quan trọng độ chính xác tức thì.

Có 1 điều quan trong là:
Cụ thể, tài liệu Mapping consistency levels for Azure Cosmos DB for MongoDB nêu rõ:
Tuy nhiên, khi sử dụng API MongoDB, Azure Cosmos DB sẽ ánh xạ các mức độ nhất quán của MongoDB (như write concern và read concern) sang mức độ nhất quán đã được cấu hình mặc định trên tài khoản Azure Cosmos DB của bạn.
Cụ thể:
– read concern được Azure Cosmos DB ánh xạ động tới một trong các mức độ nhất quán đã được cấu hình trên tài khoản, tùy thuộc vào yêu cầu đọc cụ thể.
– write concern của MongoDB được ánh xạ tới mức độ nhất quán mặc định của tài khoản Azure Cosmos DB.

Bạn cũng không thấy có option consistency level trong Azure console web.
Nhưng Terraform configure yêu cầu khai báo trường này nên bạn cứ để là consistency_level = "Session" là ok (Yên tâm là nó không hiệu lực)

mongo_server_version = "7.0"

Xác định phiên bản MongoDB mà Cosmos DB sẽ mô phỏng.
Giúp bạn tương thích với các ứng dụng dùng MongoDB 7.0.

2.3) Enable Availability Zones for Azure Cosmos DB for MongoDB (Request Unit)

Để bật Availability Zones cho tài khoản Azure Cosmos DB sử dụng API MongoDB trong Terraform, bạn cần thêm thuộc tính zone_redundant = true vào khối geo_location. Thuộc tính này cho phép dữ liệu của bạn được phân phối qua nhiều vùng khả dụng trong một khu vực, tăng cường độ sẵn sàng và khả năng chịu lỗi.
https://github.com/terraform-providers/terraform-provider-azurerm/issues/8010

Lúc bạn chưa bật bận sẽ thấy:

resource "azurerm_cosmosdb_account" "mongo" {
  name                = "example-mongo-cosmos"
  location            = var.resource_group_location
  resource_group_name = var.resource_group_name
  offer_type          = "Standard"
  kind                = "MongoDB"

  geo_location {
    location          = var.resource_group_location
    failover_priority = 0
    zone_redundant    = true
  }

  consistency_policy {
    consistency_level = "Session"
  }

  mongo_server_version = "7.0"
}

2.4) Lưu ý quan trọng

Hỗ trợ vùng khả dụng: Không phải tất cả các khu vực Azure đều hỗ trợ Availability Zones. Trước khi bật zone_redundant, hãy đảm bảo rằng khu vực bạn chọn hỗ trợ tính năng này.
Chi phí: Việc bật Availability Zones có thể ảnh hưởng đến chi phí, vì dữ liệu được sao chép qua nhiều vùng khả dụng.
Không thể thay đổi sau khi tạo: Một khi tài khoản Cosmos DB được tạo với zone_redundant = true, bạn không thể thay đổi thuộc tính này sau đó. Nếu cần thay đổi, bạn sẽ phải tạo một tài khoản mới.GitHub

Sau khi destroy và chạy lại thì bạn thấy là đã active được Availability Zone

2.5) MongoDB performance capabilities.

2.5.1) Limit total RU/s for all databases MongoDB (CosmosDB)

capacity {
  total_throughput_limit = 4000
}

This sets a hard limit on the total RU/s that can be provisioned across all databases and containers in the account.

2.5.2) Configure Capacity Mode for Azure Cosmos DB for MongoDB

Database level

MongoDB with Autoscale

resource "azurerm_cosmosdb_account" "mongo" {
    name                = "example-mongo-cosmos"
    location            = var.resource_group_location
    resource_group_name = var.resource_group_name
    offer_type          = "Standard"
    kind                = "MongoDB"
    geo_location {
      location          = var.resource_group_location
      failover_priority = 0
      zone_redundant    = true
    }
     mongo_server_version = "7.0"
    consistency_policy {
     consistency_level       = "Session"
   }
  
  }
  
  resource "azurerm_cosmosdb_mongo_database" "autoscale_db" {
    name                = "autoscaledb"
    resource_group_name = var.resource_group_name
    account_name        = azurerm_cosmosdb_account.mongo.name
  
    autoscale_settings {
      max_throughput = 4000  # RU/s will scale from 400 to 4000
    }
  }

Sau khi apply lại bạn sẽ thấy ở Collections -> Scale

Chúng ta có thể monitor RU trong metrics

Mongo Database with Manual Provisioned Throughput

resource "azurerm_cosmosdb_account" "mongo" {
    name                = "example-mongo-cosmos"
    location            = var.resource_group_location
    resource_group_name = var.resource_group_name
    offer_type          = "Standard"
    kind                = "MongoDB"
    geo_location {
      location          = var.resource_group_location
      failover_priority = 0
      zone_redundant    = true
    }
     mongo_server_version = "7.0"
    consistency_policy {
     consistency_level       = "Session"
   }
  
  }
  
  resource "azurerm_cosmosdb_mongo_database" "autoscale_db" {
    name                = "autoscaledb"
    resource_group_name = var.resource_group_name
    account_name        = azurerm_cosmosdb_account.mongo.name
  
    throughput          = 400  # Fix RU/s for manual Capacity 
  }

Serverless Mode (Only at Account Level)

resource "azurerm_cosmosdb_account" "mongo" {
  name                = "example-mongo-cosmos"
  location            = var.resource_group_location
  resource_group_name = var.resource_group_name
  offer_type          = "Standard"
  kind                = "MongoDB"
  geo_location {
    location          = var.resource_group_location
    failover_priority = 0
    zone_redundant    = true
  }
  mongo_server_version = "7.0"

  consistency_policy {
   consistency_level       = "Session"
  }

  ## Enable MongoDB and Serverless capabilities
  capabilities {
    name = "EnableMongo"
  }
  capabilities {
    name = "EnableServerless"
  }

}

Sau khi Run bạn có thể thấy capacity là Serverless

Terraform Resource Structure for Cosmos DB

Terraform Resource	Throughput Configuration Support?	Notes
`azurerm_cosmosdb_account`	✅ Capacity limit only	Supports capacity block with `total_throughput_limit` (RU/s). Does not configure actual throughput (manual/autoscale/serverless).
`azurerm_cosmosdb_mongo_database`	✅ Manual or Autoscale	You can set manual throughput using `throughput = ...`, or autoscale using `autoscale_settings`.
`azurerm_cosmosdb_mongo_collection`	✅ Manual or Autoscale	You can override or define throughput per collection. Follows the same pattern as the database level.

Dựa vào bẳng trên bạn cũng có thể thấy
Chúng ta có thể overwrite throughPut ở collection

Collect Level

Cũng như mục database, Chúng ta cũng có thể setup manual và auto scale:

OPTION 1: Manual Throughput at Collection Level

resource "azurerm_cosmosdb_account" "mongo" {
  name                = "example-mongo-cosmos"
  location            = var.resource_group_location
  resource_group_name = var.resource_group_name
  offer_type          = "Standard"
  kind                = "MongoDB"
  geo_location {
    location          = var.resource_group_location
    failover_priority = 0
    zone_redundant    = true
  }
  mongo_server_version = "7.0"
  consistency_policy {
   consistency_level       = "Session"
 }

  capabilities {
    name = "EnableMongo"
  }

}


resource "azurerm_cosmosdb_mongo_database" "example_db" {
  name                = "mydb"
  resource_group_name = var.resource_group_name
  account_name        = azurerm_cosmosdb_account.mongo.name

  # Option 1: Manual throughput at DB level
  # throughput = 1000

  # Option 2: Autoscale at DB level
  # autoscale_settings {
  #   max_throughput = 4000
  # }
}

resource "azurerm_cosmosdb_mongo_collection" "manual_collection" {
  name                = "manualCollection"
  resource_group_name = var.resource_group_name
  account_name        = azurerm_cosmosdb_account.mongo.name
  database_name       = azurerm_cosmosdb_mongo_database.example_db.name

  throughput = 1000

  shard_key = "userId"

  # ✅ Required _id index
  index {
    keys   = ["_id"]
    unique = true
  }

  # Optional: add your additional indexes
  index {
    keys   = ["userId"]
    unique = false
  }
}

Chúng ta cùng nhau kiểm tra trên azure console:

OPTION 2: Autoscale Throughput at Collection Level

resource "azurerm_cosmosdb_account" "mongo" {
  name                = "example-mongo-cosmos"
  location            = var.resource_group_location
  resource_group_name = var.resource_group_name
  offer_type          = "Standard"
  kind                = "MongoDB"
  geo_location {
    location          = var.resource_group_location
    failover_priority = 0
    zone_redundant    = true
  }
  mongo_server_version = "7.0"
  consistency_policy {
   consistency_level       = "Session"
 }

  capabilities {
    name = "EnableMongo"
  }

}


resource "azurerm_cosmosdb_mongo_database" "example_db" {
  name                = "mydb"
  resource_group_name = var.resource_group_name
  account_name        = azurerm_cosmosdb_account.mongo.name

  # Option 1: Manual throughput at DB level
  # throughput = 1000

  # Option 2: Autoscale at DB level
  # autoscale_settings {
  #   max_throughput = 4000
  # }
}

resource "azurerm_cosmosdb_mongo_collection" "autoscale_collection" {
  name                = "autoscaleCollection"
  resource_group_name = var.resource_group_name
  account_name        = azurerm_cosmosdb_account.mongo.name
  database_name       = azurerm_cosmosdb_mongo_database.example_db.name

  autoscale_settings {
    max_throughput = 4000
  }

  shard_key = "userId"

  # ✅ Required _id index
  index {
    keys   = ["_id"]
    unique = true
  }

  # Optional: add your additional indexes
  index {
    keys   = ["userId"]
    unique = false
  }
}

3) Insight

3.1) Understand Request Unit (RU/s) In Azure Cosmos DB

a Request Unit (RU) is a performance abstraction(trừu tượng) that measures the cost of database operations (read/write/query/etc)

3.1.1) RU/s – How You Can “Estimate” It from AWS Metrics

Although AWS doesn’t use RUs:

Monitor reads/writes per second
- Combine with average document size to get baseline throughput
Measure latency + CPU/memory usage per operation
- The higher the latency or CPU, the higher the “RU-equivalent”
Assume baseline RU cost:
- 1 KB read ≈ 1 RU
- 1 KB write ≈ 5 RUs
- Indexed queries or large filters can cost 10–1000 RUs

https://learn.microsoft.com/en-us/azure/cosmos-db/request-units
https://cosmos.azure.com/capacitycalculator/

Step 1: Extract Key Data from Your IOPS Chart

Max Write IOPS: ~5,860 (from legend)
Max Read IOPS: ~2,380
Average Write IOPS: ~53
Average Read IOPS: ~32

The “IOPS” here (from AWS DocumentDB) means how many write/read operations per second your cluster is handling.

Step 2: Map IOPS to Cosmos DB Operations

Assuming each IOPS ≈ 1 database operation (this is typical unless you use batch or bulk ops):

Write ops/sec (peak): 5,860
Read ops/sec (peak): 2,380
Write ops/sec (avg): 53
Read ops/sec (avg): 32

Step 3: RU Cost per Operation (Typical Estimates)

For 1 KB documents (standard):

Point read: 1 RU
Write (insert/update): 5 RUs

(If your docs are larger, multiply RUs by their KB size)

Step 4: RU Estimation (Peak and Average)

Peak Load RU Estimate

Reads: 2,380 ops/sec × 1 RU = 2,380 RU/s
Writes: 5,860 ops/sec × 5 RUs = 29,300 RU/s
Total (peak): ~31,680 RU/s

Average Load RU Estimate

Reads: 32 ops/sec × 1 RU = 32 RU/s
Writes: 53 ops/sec × 5 RUs = 265 RU/s
Total (avg): ~297 RU/s

3.1.2) Perdict the cost

Azure Cosmos DB Pricing (2024)

1. Manual Provisioned Throughput

Description: You provision a fixed number of Request Units per second (RU/s), paying for the allocated capacity regardless of actual usage.

Cost Calculation:

Formula: (Provisioned RU/s / 100) × $0.008 × Hours × Regions
Example: For 10,000 RU/s in a single region over 30 days:
- (10,000 / 100) × $0.008 × 24 × 30 = $576

Best For: Workloads with consistent and predictable traffic.

2. Autoscale Provisioned Throughput

Description: Automatically scales RU/s between 10% and 100% of a defined maximum based on workload demands.
Cost Calculation:
- Formula: (Max RU/s / 100) × $0.012 × Hours × Regions
- Billing: Charged based on the highest RU/s used each hour, with a minimum of 10% of the max RU/s.
- Example: For a max of 10,000 RU/s with average utilization at 40% over 30 days:
  - Assuming average billed RU/s is 4,000:
  - (4,000 / 100) × $0.012 × 24 × 30 = $345.60
Best For: Applications with variable or unpredictable traffic patterns.

3. Serverless

Description: No throughput provisioning; you pay per RU consumed, making it ideal for intermittent or low-traffic workloads.
Cost Calculation:
- Rate: $0.25 per 1 million RUs consumed.
- Example: If your application consumes 50 million RUs in a month:
  - (50 × $0.25) = $12.50
Best For: Development, testing, or applications with sporadic usage.