How to share a SageMaker notebook
Everything in SageMaker is governed by IAM, which is correct and which makes sharing a specific problem: the unit of access is a role in your AWS account, and the people who need to read a model evaluation frequently should not have one.
What SageMaker gives you
Studio's share feature. It snapshots the notebook to the domain's S3 bucket and produces a link. That link works for another Studio user in the same domain with permission on the bucket. It is a good collaboration feature between data scientists and it does not reach outside the account.
S3 static hosting. Write the HTML to a bucket and serve it. This works, and it is the pattern that produces the recurring incident: a bucket policy loosened to make one report readable, never tightened again. See S3 static hosting alternatives for the shape of that trade.
Presigned URLs. Better than a public bucket — time-limited, no policy change. Also single-use in practice, since the link expires and the next request starts the whole cycle again. And a presigned URL to an HTML file that references other files in the bucket breaks, because only the one object is signed.
Download the .ipynb and email it. Requires the recipient to have Jupyter, which for a product manager or a compliance reviewer they do not.
What the audience actually needs
Model evaluations get read by people who are not going to open a notebook: the product owner deciding whether to ship, the risk reviewer signing off, the customer's data science contact. They need the metrics and the plots at a URL, as text they can quote, with somewhere to ask about the fairness slice.
Render and publish from the pipeline
The best place to put this is not a human's laptop, it is the last step of the job that produced the numbers.
In a notebook or a Processing step:
jupyter nbconvert --to html --execute --no-input evaluation.ipynb --output report.html
Then push it, PATCHing the same report id so every run stacks a revision at one URL:
import os, requests
html = open("report.html").read()
requests.patch(
f"https://commareports.com/api/v1/reports/{os.environ['REPORT_ID']}",
headers={"Authorization": f"Bearer {os.environ['COMMA_API_TOKEN']}"},
json={"title": f"Churn model — eval {os.environ['TRAINING_JOB_NAME']}", "html": html},
timeout=30,
).raise_for_status()
Keep the token in Secrets Manager or SSM Parameter Store and read it in the step, not in the notebook body — notebooks get committed. A scoped token bounds what a leaked credential can reach.
Matplotlib and seaborn plots embed as base64 images through nbconvert automatically, so the file stays self-contained. Plotly and Altair charts stay interactive as long as the library is inlined rather than linked to a CDN.
What changes
No IAM for readers. Access is a setting on the report — private, team, domain-gated or link — so a reviewer with no AWS presence opens the evaluation, and nobody loosens a bucket policy to make it happen.
A run history that matches the model history. Every training run PATCHes a revision, so the metrics for v11 sit next to v10 at the same URL. That is exactly the artifact a model card wants to link to, and the link never rots.
Review that stays attached. A risk reviewer highlights the subgroup AUC and pins "below the threshold in the 65+ slice — blocking until re-weighted." That thread persists across revisions, so the next run's reader sees whether the objection was resolved rather than asking again.
And an agent attached through Comma's MCP server can read the review threads and act on them, which closes the loop between the reviewer's objection and the retraining job.
When to just share in Studio
Share the Studio snapshot when the other person is a data scientist in the same domain who will run cells. That is what it is for. Publish an executed render when the audience is reviewing, approving, or reading — which is the audience that decides whether the model ships.
Try it
Comma is free — unlimited reports, unlimited commenters, unlimited revision history.