If a Launch Is Refused
Last updated on 2026-10-28 | Edit this page
Every launch from a notebook instance on the workshop account is
checked against a short list of rules before it costs anything. (The
console and a laptop run under your sign-in’s permission set, which does
not carry the rules yet.) When a job breaks one, AWS refuses it with an
AccessDeniedException whose message ends in
with an explicit deny in an identity-based policy, and says
nothing else: an IAM refusal cannot carry a custom message, so the error
names neither the rule nor the fix. This page is the fix. It applies to
any job you launch from this account, during the lesson or in your own
notebooks afterwards.
The rules, and what to change
| The refusal means | What to change |
|---|---|
| A tag is missing | Every job needs the three tags Name,
Project and Purpose, passed as
tags= on the estimator, processor or tuner, with those
exact keys. |
Name is blank |
Your last and first name run together,
e.g. DoeJohn. |
Project is not on the list |
One of SinkOrSwim, WattBot2026,
BadgerScribe, BadgerCode,
BrainDecoding, PoisonedWell,
SnapshotWI, spelled exactly, capitals included. |
Purpose is not on the list |
One of Storage, Notebook,
Training, Tuning, Inference. |
| The instance type is not one the lesson uses |
ml.t3.medium, ml.m5.large,
ml.m5.xlarge, ml.g4dn.xlarge,
ml.g5.xlarge, ml.g6.xlarge,
ml.g6e.xlarge, ml.g6e.2xlarge: single-GPU
types only, so that one hung job under the 48-hour cap stays at about
$125 at most. Ask the instructor if your work needs
another. |
| The runtime cap is over 48 hours |
max_run (training and tuning jobs) or
max_runtime_in_seconds (Processing jobs) of at most
172800. Set it a little above your estimate. |
| A Processing job has no cap | Processing jobs do not get a default cap; pass
max_runtime_in_seconds=. |
| It is an endpoint or an EC2 instance | Nothing that runs until deleted can be created on this account. Use a job, or Bedrock. |
The message is the same for every row, so check them in order. A
launch that passes every row and is still refused is usually the
tags= argument left off the estimator.
Checking from the notebook
The lesson’s helper module applies the same rules before the request is sent, and its message names the problem. It works in any notebook on your instance, since the lesson repository is cloned there:
PYTHON
import sys
sys.path.insert(0, "/home/ec2-user/SageMaker/ML_with_AWS_SageMaker/scripts")
import helpers
job_tags = [
{"Key": "Name", "Value": "DoeJohn"},
{"Key": "Project", "Value": "WattBot2026"},
{"Key": "Purpose", "Value": "Training"},
]
helpers.check_launch(job_tags, instance_type="ml.g5.xlarge", max_run=2 * 60 * 60) # raises ValueError naming each problem; returns the tags when all is well
The fine-tuning episode uses
helpers.check_finetune_launch, which runs the same check
and then this lesson’s own rules for a fine-tune: LoRA, not a full
fine-tune, a model of at most 7B, a cap between the estimate and four
times it, checkpoints on any run that may pass an hour, a fixed job
name, and sane values for the passes and the pixel budget.
A failing check looks like this:
OUTPUT
ValueError: this launch would be refused by the account:
- Project 'MLMarathon' is not on the account's list: use one of SinkOrSwim, WattBot2026, BadgerScribe, BadgerCode, BrainDecoding, PoisonedWell, SnapshotWI, spelled exactly
- Purpose 'Testing' is not on the list: use one of Storage, Notebook, Training, Tuning, Inference
The helper reads its lists from scripts/guardrails.json,
a copy of the policy on the account, so a git pull in the
lesson folder keeps it current when the list changes. Run it in a cell
before the launch cell. Two companions:
PYTHON
helpers.rules() # prints the current rules
helpers.explain_refusal() # after a refusal: reads the refused requests of the last hour from CloudTrail and names the rule each one broke
explain_refusal works after the fact, on launches made
from any code, because AWS logs every API call on the account in
CloudTrail, including the refused ones, with the request exactly as it
was sent: tags, instance type and cap. The log is 5 to 15 minutes
behind, so a refusal made a moment ago may not be there yet. The output
lists each refused launch with its job name, so pick out yours by the
job name. The workshop role has the CloudTrail permission this needs; a
role on another account may not, and the helper says so if not.
Why the rules exist
They are the account administrator’s rules, written as an IAM policy on the role every notebook runs as; the cleanup episode lists the rules, and the Account preparation checklist instructor page has the policy to copy to an account of your own. The three tags are how the bill is split by person and project; the instance list and the cap bound what any one job can cost; the endpoint rule keeps anything from running unnoticed for a month.