Why Amazon Nova's Pricing Should Drive Product Decisions

A PM specs a new feature, an engineer wires it to whatever model the team already uses, and nobody revisits that choice until finance asks why the AI line item tripled. That's backwards. For a huge slice of product features, the model choice should start with Amazon Nova pricing, not end with it as an afterthought once the feature is built.

Nova is Amazon's own family of foundation models, and it only runs on Amazon Bedrock. That exclusivity is usually framed as a lock-in risk. It's also why Nova Micro and Nova Lite are priced the way they are: Amazon controls the whole stack, so it can undercut third-party models it also resells through the same service.

Amazon Nova pricing, in plain numbers

On Bedrock's on-demand tier, per million tokens:

| Model | Input | Output | |---|---|---| | Nova Micro | $0.035 | $0.14 | | Nova Lite | $0.06 | $0.24 | | Nova Pro | $0.80 | $2.40 | | GPT-4o mini (for reference) | $0.15 | $0.60 |

Nova Lite runs about 60% cheaper than GPT-4o mini on both input and output tokens. Nova Micro is cheaper again, though it's text-only: no image or video input, which Lite and Pro both support. For a lot of product surfaces, that's a fine trade.

Why this changes what you build, not just what you pay

Cost per call feels abstract until you multiply it by product scale. Take a support-ticket triage feature classifying intent and urgency: 10 million tokens a day, roughly 300 million a month, mostly short inputs with short outputs.

At GPT-4o mini rates that's around $135/month in blended token cost. At Nova Lite rates it's closer to $54. At Nova Micro, if the task doesn't need multimodal input, it drops further still. That gap doesn't just save budget, it changes what you're willing to greenlight. A feature that looked marginal at one price point becomes an easy yes at another, and a feature you'd have gated behind an enterprise tier can now ship to every user.

That's the real argument: pricing this low means classification, summarization, tagging, and routing tasks that used to get bundled into one expensive model call can each get their own cheap, dedicated one. You stop rationing intelligence and start using it wherever it's marginally useful.

The honest objection: is Nova actually good enough?

Nova Micro and Lite are not frontier models, and Amazon doesn't market them as such. They're built for high-volume, latency-sensitive, lower-complexity tasks: classification, extraction, short-form generation, simple agentic tool calls. Push them into multi-step reasoning or nuanced writing and you'll see the gap versus GPT-4o or Claude widen fast.

The Bedrock lock-in is real too. If your product needs to be cloud-portable, or you're already committed to Azure OpenAI or Vertex AI for other reasons, adding Bedrock as a third integration surface has its own operational cost that doesn't show up on the per-token bill.

So the right read isn't "replace your main model with Nova." It's "stop assuming one model has to handle every call." Route the cheap, high-volume, low-complexity work to Nova Micro or Lite, and keep the expensive model for the calls that actually need it.

Test it before you decide

Before locking in a model for a new feature, run the actual task against Nova Micro and Nova Lite with the Bedrock Converse API:

import boto3

client = boto3.client("bedrock-runtime", region_name="us-east-1")

response = client.converse(
    modelId="amazon.nova-lite-v1:0",
    messages=[
        {
            "role": "user",
            "content": [{"text": "Classify this support ticket's urgency as low, medium, or high: <ticket-text>"}],
        }
    ],
    inferenceConfig={"maxTokens": 50, "temperature": 0},
)

print(response["output"]["message"]["content"][0]["text"])

Swap modelId to amazon.nova-micro-v1:0 to compare, and check both against your current default on the same eval set: accuracy, latency, and cost per 1,000 calls side by side. No commitment required, since Bedrock's on-demand tier bills per token with no minimum.

If Nova clears your accuracy bar, you've just cut a real cost line and can afford to ship the feature to more users. If it doesn't, you've spent an afternoon confirming the pricier model earns its keep, which is a better position than never having asked.

Every model choice a PM signs off on is a recurring cost decision at production scale, and starting from the cheapest model that clears the bar, rather than the most familiar one, is what keeps an AI feature from becoming the reason a rollout gets paused.