Only one of AWS Bedrock’s 33 regions—us-west-2—lets you fine-tune the 70-billion-parameter Llama 3.3 model. Developers must either stitch together cross-region pipelines or endure a clunky workaround.
Why the discovery matters
AWS’s public pricing page still lists training costs for the older Llama 2 series. The newer Llama 3.1 and 3.3 families are missing entirely. Engineers are left guessing which regions actually support fine-tuning, how long jobs will sit in queues, and whether idle time will be billed.
The hard numbers
- us-west-2 – the only region where Llama 3.3 70B fine-tuning works.
- us-east-1 – only Amazon-built models; no Llama or Anthropic fine-tuning.
- eu-west-2 (London) – fine-tunes a single, non-Llama model.
- All other regions – return “model not available” errors for Llama 3.3 70B.
If you need a custom-tuned Llama 3.3 70B, run the job in us-west-2 and ship data across regions, or try the “Custom Model Import” route, which the author’s attempt blew up with a generic hardware error.
Custom Model Import: a risky detour
AWS docs claim “Custom Model Import” can bring weights under 200 GB into any region, including eu-central-1. In reality, attempts to import Llama 3.3 70B (well over that size) repeatedly hit a “hardware error.” For now, the safest bet stays the native us-west-2 fine-tuning endpoint.
Two tricks that save money (and sanity)
- Don’t trust the top-level “InProgress” flag. A job may sit in an AWS-managed queue for hours with that status while no compute runs. Billing starts only when the nested
trainingDetailsfield flips to “Running.” Check the inner flag to avoid paying for idle queue time. - Patience beats impatience. One test job lingered in the queue for 23 hours before training began and completed without issue. Killing it and relaunching shoved it to the back of the line, extending total wait time. Queue time is free; the cost kicks in once GPU instances spin up.
Other field lessons
- Model schemas differ. Llama 3.3 and Llama 3.1 use distinct configuration objects. Copy-pasting a JSON schema from one version to the other triggers validation errors, even though limits like token length match.
- Quota quirks. The limit on “Custom models with a creating status” is often far lower than the overall job quota. If you hit a “quota exceeded” error while a previous job still shows “creating,” delete the stale entry before launching a new one.
- Storage adds up. Each fine-tuned checkpoint consumes S3 storage billed at standard rates. Leaving old versions untouched inflates your monthly bill without delivering value.
Bottom line
If your project hinges on a fine-tuned Llama 3.3 70B model, plan to run that step in us-west-2, or brace for trial-and-error with custom imports. Verify queue status at the granular level, resist aborting long-waiting jobs, and monitor storage and quota usage closely.
