CosmosDB Setup
Goal: Provision a CosmosDB account your workspace owns, so you can manage databases, containers and documents.
Prerequisites
- A connected Azure cloud on this workspace
- A provisioned landing zone — Environment → Manage Private CALZ
- Workspace admin permissions
If Databases is not in your Environment menu, one of the two above is missing. The item appears once a landing zone exists, because an account has to be provisioned into something.
Create an account
Step 1: Environment → Databases
Open Environment in the workspace toolbar and choose Databases. If your Azure session has expired, sign in inside this modal — you do not leave the page.
Step 2: Name it and choose how it should scale
| Field | What it does |
|---|---|
| Name | How the account appears in your workspace |
| Description | Optional |
| Scaling profile | Serverless, Standard or High volume |
The scaling profile is a named intent, not a number of request units. You are saying how the account will be used; the platform owns the Azure expansion of that.
Step 3: Save & Provision
Choose Save & Provision.
Saved. Provisioning runs in the background and this list updates as it completes.
Each account appears as a row showing its region, scaling profile, and state:
| State | Means |
|---|---|
| Not started | The record exists; provisioning has not begun |
| Provisioning | In flight |
| Live | Ready to use |
| Needs attention | Provisioning reported an error |
| Unknown | The record could not be read — this is "we cannot tell", not "not yet" |
Which region your data is in
The region is fixed when the account is created and cannot be changed afterwards.
Where it comes from depends on which account you are creating:
| Account | Region |
|---|---|
| Your first account | This account is created in your workspace landing zone region. It is not a choice made here. |
| Any additional account | An additional account must state its own region. It is not inherited from your landing zone. |
An additional account refuses to save without a region. That is deliberate: inheriting one would be choosing a region for you, and where data sits is not a decision the platform makes on your behalf.
Each region is a separate CosmosDB account with its own cost floor.
There is nothing to paste
There is no endpoint field, no account key, and no Test Connection button on this form — and their absence is the design, not an omission.
The account is provisioned into the Azure cloud your workspace is already connected to, and every call the platform makes to it resolves credentials server-side. A key you never collect is a key that cannot be stored, leaked, or left in a browser.
What this account does not give you
A CosmosDB container is a working store. It is not an evidence store.
Documents here can be updated and deleted. There is no write-once mode, no retention lock, and no immutability guarantee — CosmosDB does not offer one, so neither can we. Records you need to keep as proof of what happened belong in a store built for that, and a table you declare as holding evidence is refused at provisioning for exactly this reason.
Reads and writes through the table APIs are governed by which operations the container switches on — an operation left off is not published at all. That is an exposure decision, and it is not the same thing as an audit trail.
Next Steps
| If you want to... | Go to... |
|---|---|
| Manage databases and containers | Database Management → |
| Publish a container's documents over HTTP | Database Tables → |
| Build queries on database data | Warm Queries → |