Amazon Bedrock Custom Model
Does ZopNight manage Amazon Bedrock Custom Model?
Bedrock custom models bill in three phases: a training charge when fine-tuning runs, a monthly storage fee for every model version kept, and provisioned throughput hours when the model is served. Unserved models still pay storage monthly. ZopNight discovers custom models on the 6-hour cycle and flags the ones nothing invokes.
Rules that fire on Amazon Bedrock Custom Model
At a glance
| Field | Value |
|---|---|
| Scheduling notes | discovery and cost tracking only. |
A Bedrock custom model is a foundation model fine-tuned or continued-pretrained on your data, billed for training, monthly storage, and provisioned throughput required for inference. Custom models that are no longer served still accrue storage charges.
Three phases, three meters
Custom model cost arrives in sequence. Training bills once per customization run, metered on the tokens processed. Storage bills monthly per model version for as long as the artifact exists. Individually small, it is cumulative across the versions that fine-tuning iterations produce. Serving is the large phase: inference on a custom model requires purchasing provisioned throughput, which bills per model unit per hour continuously while the capacity exists. The phases decouple in practice: a model can finish its expensive training, never get served, and settle into paying storage forever. Worse, it can hold provisioned capacity for an application that quietly stopped calling it.
Custom models, matched to their traffic
ZopNight’s Bedrock provider discovers custom models on the 6-hour cycle, with training and storage cost from Cost Explorer or CUR 2.0. Hygiene recommendations target the unused: model versions that no provisioned throughput serves and no batch job references, accruing monthly storage as fine-tuning archaeology. Where a custom model does hold provisioned capacity, the throughput’s own utilization analysis applies, and the two findings together answer the lifecycle question: is this model an asset in service, an artifact worth archiving, or a bill with no beneficiary?
Fine-tuning residue
Iteration is the source: reaching a production-worthy custom model typically takes many training runs, each producing a stored version, and nobody deletes the failed candidates. Data refreshes compound it, since quarterly re-fine-tuning strands the previous generation. And organizational churn finishes the job, leaving models whose training data, evaluation results, and owning team have all moved on.
Version housekeeping in Bedrock
The Bedrock console’s Custom models view lists versions with creation dates and customization details. The audit walks each version against serving reality: anything unserved and superseded is a deletion candidate, remembering that the training investment is already spent either way. Storage is the only meter still running.