Draft for review. This page is under review before the Operational Readiness Review. Panels marked as open questions are still waiting for an answer. Send corrections to the Research Platform team.
Read time: 4 minutes. Short version: your project pays with its own funding. You pay for the time your machines run, and for the storage you use. Nothing else. Nothing stops you automatically yet — watch your budget.
Who pays
The project pays, from its own funding. The Research Platform does not give you a separate pot of money. Your project brings its funding, and its members spend against it.
The project admin shares that money out across the team. See RPAdmin — the admin console.
What you pay for
Compute — you pay for running time only
All work on the platform runs in containers. (A container is a packaged, running copy of your workspace software.) You pay for the time a container is running. Nothing more.
This covers:
| What you start | You pay while… |
|---|---|
| Your notebook workspace | the notebook is running |
| A Dask cluster (many machines for one job) | the cluster is up |
| A background job (a notebook that runs on its own) | the job is running |
When the container stops, the charge stops. So: stop your notebook when you finish for the day. Shut down a Dask cluster as soon as the job is done. This is the single biggest thing you can do to control your cost.
Storage — you pay for what you use
You pay for the space you actually hold in three places:
| Storage | What it is |
|---|---|
| EFS | The shared filesystem for your project |
| EBS | Your own private workspace disk |
| S3 | Cloud object storage for large data |
One important exception: if the S3 storage sits in a remote AWS account — your institution's account, or a mission's account — the Research Platform does not charge you for it. That account's owner pays for it, the same as before.
Platform or support fee
There is no platform fee and no support fee today. The team is evaluating whether to add one. This page will say so if that changes.
Free trial
There is a small free allocation for a new project, so you can try the platform. The exact amount is still to be defined. Ask the Science Cloud team for the current figure.
What happens when the money runs out
Today the platform does not stop you. Budgets are tracked and shown, but a workspace still starts when the money is spent. So watch the numbers.
What the platform does do today:
- A platform admin sets the project's total budget, once the Science Cloud has received the funds.
- Your project admin then shares that total out, as a spending limit for each member.
- The platform blocks giving out more than the project holds. A project admin cannot promise money the project does not have.
- Every member sees their own usage and what is left, inside JupyterLab.
- A project admin sees the whole project's spend against budget in RPAdmin.
What is coming
A hard stop at launch is planned work, not live yet:
- When the project's funds are used up, new workspaces will not start.
- For each member's allocation, the project admin will choose the behaviour: block the member from launching, or let them keep working and watch the number.
Until that ships, budget control is by watching and talking, not by the system saying no.
How the money gets into the system
OPEN — Danl to answer. The question for him is: "How does funding actually reach a project's budget in RPAdmin? Who enters the dollar amount, and what is it based on — a WBS number, a purchase, a funds transfer, or something else? What paperwork does a project admin need before the number can be entered, and how does the project admin add more money later?" Do not publish this section until Danl answers.
How to keep your cost down
- Stop what you are not using. Notebooks, Dask clusters, and background jobs.
- Pick the right size. Do not take a 64 GB machine for a small job.
- Watch your own number. Your usage and remaining budget are shown in JupyterLab.
- Clean up storage. Old files keep costing money every month.
- Use a background job for long runs. You do not need to keep an interactive session alive.