Skip to main content

Amazon Nova: Bedrock Deployment, Speech-to-Speech and Browser Agents

Amazon Nova is AWS's closed-weight model family, distinguished from the other models in this section by its deployment model: rather than a standalone consumer API, Nova is delivered through Amazon Bedrock, AWS's managed foundation-model service, alongside models from other providers. The family spans text and multimodal understanding, reasoning-focused models (including Nova 2 Lite), speech-to-speech interaction (Nova Sonic), embeddings, and browser-operating agents (Nova Act).

How to read this guide​

PartSectionsFocus
A · Identity1–2Closed model, Bedrock delivery, tier lineup
B · Study map3Priorities for engineers
C · Architecture4Disclosed design signals, Bedrock integration
D · Evaluation5Model cards, Bedrock evaluation tooling
E · Production6–7Bedrock API patterns, Guardrails, cost
F · Assessment8–ConclusionChecklist, reading list, takeaways

Introduction​

Unlike OpenAI, Anthropic, Google and xAI — each of which ships a direct-to-developer API as the primary access path — Amazon's Nova models are designed and marketed as Bedrock-native. This means much of what an AI engineer needs to master is not solely about Nova's model behaviour, but about the surrounding AWS platform primitives: Bedrock's unified API surface across multiple model providers, Guardrails for policy enforcement, provisioned throughput and inference profiles for capacity and latency management, and SageMaker for customisation workflows that go beyond simple prompting.

As with every other model family in this section, Nova's weights, exact parameter counts and full training methodology are not published. AWS documentation and blog posts describe capability and deployment patterns at a product level.

1. What kind of model is Amazon Nova?​

1.1 Closed, Bedrock-delivered​

Nova models are accessed through Amazon Bedrock — AWS's managed service exposing a common API surface across multiple foundation-model providers (including Amazon's own Nova family, Anthropic, Meta and others). There is no standalone Nova API separate from Bedrock, and no open-weight Nova release.

1.2 A multi-purpose family, not one model​

Nova spans several distinct capability categories rather than a single text-chat lineage:

  • Text and multimodal understanding models for general reasoning and document/image analysis.
  • Reasoning-focused models (Nova 2 Lite) tuned for deeper, more deliberate reasoning at efficient cost.
  • Speech-to-speech (Nova Sonic) for natural, low-latency voice interaction.
  • Embeddings for retrieval and semantic search.
  • Browser-action agents (Nova Act) for automating tasks within a web browser.

1.3 Deeply embedded in the AWS operational stack​

Nova is designed to be consumed alongside AWS's broader AI/ML operational tooling: Bedrock Guardrails for safety and compliance policy enforcement, Bedrock Agents for tool-orchestration, SageMaker for customisation, CloudWatch for monitoring, and IAM for access control. This is Nova's core differentiator versus a standalone-API competitor: operational integration, not necessarily raw leaderboard capability.

1.4 Customisable through SageMaker​

Unlike a purely prompt-only closed model, Nova explicitly supports several tiers of customisation through SageMaker: continued pretraining on domain-specific corpora, supervised fine-tuning (SFT) on labelled examples, and reinforcement fine-tuning (RFT) using reward signals — a materially deeper customisation surface than most closed competitors expose directly to customers.

2. Family lineup and tiers​

ModelCategoryPosition
Nova Micro / Lite / Pro (text/multimodal tiers)General-purposeCost/latency/capability ladder for text and multimodal understanding tasks
Nova 2 LiteReasoningEfficient, reasoning-focused model with deeper deliberation at lower cost than a full reasoning-flagship tier
Nova SonicSpeech-to-speechNatural, low-latency bidirectional voice interaction
Nova embeddingsEmbeddingsVector representations for retrieval, semantic search and RAG pipelines
Nova ActBrowser-action agentAutomates tasks by operating a web browser directly

2.1 Choosing a text/multimodal tier​

SignalLean toward
High-volume, simple classification/extractionLower-cost general-purpose tier
Standard production assistant and document-analysis workloadsMid-tier general-purpose model
Deeper, multi-step reasoning at efficient costNova 2 Lite

2.2 Choosing a modality-specific model​

RequirementModel
Natural real-time voice conversationNova Sonic
Semantic search / retrieval for RAGNova embeddings
Automating a task inside a web browser (form filling, navigation, data extraction from web UIs)Nova Act

2.3 Nova 2 Lite: reasoning at efficient cost​

AWS positions Nova 2 Lite specifically to close the gap between "fast but shallow" and "deep but expensive" reasoning, aimed at workloads that need multi-step deliberation (planning, analysis, structured problem-solving) without the cost profile of a full frontier reasoning flagship. This mirrors the broader 2026 industry pattern of reasoning-effort tiers, but packaged as a distinct model in Nova's naming rather than a single model with an effort parameter.

2.4 Nova Act: browser-operating agents​

Nova Act is designed to operate a browser directly — navigating pages, filling forms, clicking elements and extracting data — as an alternative or complement to purpose-built API integrations for web-only systems. This is architecturally comparable in purpose to Claude's computer use, but scoped specifically to browser automation rather than full desktop GUI control, and delivered as a distinct product (nova.amazon.com/act) with its own SDK.

3. What an AI engineer should study​

  1. Bedrock deployment model — the unified API surface, model IDs, versioning, and how Bedrock differs operationally from a direct-to-vendor API.
  2. Bedrock Guardrails — configurable content-safety policies (denied topics, PII redaction, word filters, contextual grounding checks) applied independently of the underlying model's own safety training.
  3. Provisioned throughput — reserving dedicated model capacity for predictable latency and throughput, versus on-demand invocation with variable latency under load.
  4. Inference profiles — cross-region routing configurations that can improve availability and, in some cases, cost, by directing requests across AWS regions.
  5. SageMaker customisation — continued pretraining, SFT and RFT workflows, and when each is appropriate versus prompt engineering or retrieval augmentation alone.
  6. Nova Sonic's speech-to-speech design — bidirectional, low-latency voice interaction patterns and how they differ operationally from a speech-to-text-then-LLM-then-text-to-speech pipeline.
  7. Nova Act's browser-agent model — designing safe, scoped browser automation with explicit action boundaries.
  8. Reasoning-depth selection — choosing between general-purpose tiers and Nova 2 Lite based on task complexity rather than defaulting to the most capable (and most expensive) option.
  9. AWS-native monitoring and governance — CloudWatch metrics, IAM-scoped access control, and how Bedrock's audit logging integrates with broader AWS compliance tooling.

4. Architecture and system design (as publicly disclosed)​

This section is limited to what AWS has publicly described. Parameter counts, layer structure, attention mechanism details and full training data composition for Nova models are not published.

4.1 A family, not a single architecture​

AWS documentation describes Nova as a family of models purpose-built for different modalities and tasks rather than a single architecture scaled to different sizes. Text/multimodal understanding models, the reasoning-focused Nova 2 Lite, the speech-to-speech Nova Sonic, embeddings, and the browser-agent Nova Act are presented as distinct products serving distinct workload categories, each documented separately under docs.aws.amazon.com/nova.

4.2 What is explicitly not disclosed​

  • Total or active parameter counts for any Nova model.
  • Exact attention mechanism, layer structure, or whether any Nova model uses a dense or Mixture-of-Experts design.
  • Full training data composition and filtering methodology.
  • The detailed internal architecture distinguishing Nova 2 Lite's reasoning approach from the general-purpose tiers beyond high-level product positioning.

4.3 Speech-to-speech design (Nova Sonic)​

Nova Sonic is described as a model purpose-built for speech-to-speech interaction — processing spoken input and producing spoken output within a unified model, rather than chaining separate speech-recognition, language-model and speech-synthesis components. AWS's stated goal is more natural conversational dynamics (interruption handling, natural pacing, tone) than a chained pipeline typically achieves, at lower end-to-end latency.

Traditional chained pipeline:
Speech → ASR (speech-to-text) → LLM (text reasoning) → TTS (text-to-speech) → Speech

Nova Sonic (speech-to-speech):
Speech ─────────────────────────────────────────────────────────→ Speech
                (unified model, single latency budget)

4.4 Browser-action design (Nova Act)​

Nova Act is documented as a model and SDK for operating a browser: interpreting page state and issuing browser actions (navigation, clicks, form input, data extraction) to complete a described task. This is a specialised agentic modality — similar in category to Claude's computer use, but purpose-built and scoped to browser automation rather than general desktop control — with its own product surface at nova.amazon.com/act.

4.5 Reasoning depth in Nova 2 Lite​

AWS's public positioning for Nova 2 Lite emphasises reasoning depth at efficient cost, implying additional test-time deliberation relative to the standard general-purpose tiers, though the specific mechanism (explicit chain-of-thought, internal search, or another approach) is not disclosed in architectural detail comparable to, for example, Kimi K3's published reasoning-effort training methodology.

4.6 Bedrock as the architectural integration layer​

From an AWS-platform perspective, Bedrock itself is an important part of "Nova's architecture" from a deployment standpoint: it provides the routing, versioning, Guardrails enforcement, and capacity-management layer that sits between an application and the underlying Nova model, and this layer is documented in far more operational depth than the model internals themselves.

5. Evaluation and system cards​

5.1 AWS model documentation as the primary disclosure​

AWS publishes Nova capability descriptions and supported-model documentation under docs.aws.amazon.com/nova and the Bedrock "models supported" reference, alongside blog posts in AWS's Nova blog category announcing specific capability updates (Nova 2 Lite, Nova Sonic, and others). This plays a similar disclosure role to a system card but is generally organised around product documentation rather than a single consolidated safety/capability report.

5.2 Guardrails as an evaluable, configurable safety layer​

A distinguishing feature of the Bedrock delivery model is that safety enforcement is partly configurable by the customer through Bedrock Guardrails — denied topics, PII redaction rules, word filters, and contextual grounding checks can be defined per application rather than relying solely on the base model's trained refusal behaviour. This shifts some safety-evaluation responsibility onto the deploying organisation: a Guardrails policy must be evaluated and tuned for your specific use case, not assumed correct out of the box.

5.3 Model-level vs system-level evaluation​

As with every model in this section, a published Nova benchmark reflects a specific model tier, Guardrails configuration (or lack thereof), and inference-profile routing at a point in time. Since Guardrails policies are customer-configurable, two organisations running "the same" Nova model can observe materially different safety and refusal behaviour depending on their Guardrails setup — benchmark comparisons across organisations should account for this explicitly.

5.4 SageMaker customisation and evaluation implications​

Because Nova supports continued pretraining, SFT and RFT through SageMaker, a customised Nova deployment may diverge meaningfully from the base model's published evaluation numbers. Any organisation performing customisation should re-run evaluation on the customised model, not rely on base-model benchmark claims.

5.5 What remains unverifiable externally​

Training data composition, the precise reasoning mechanism behind Nova 2 Lite, and Nova Sonic's internal speech-processing architecture are not independently auditable without weight access. Treat AWS's product documentation as informative for deployment planning, not as a substitute for your own workload-specific evaluation.

6. Production engineering: API patterns​

6.1 Basic invocation via Bedrock Runtime​

from __future__ import annotations

import json

import boto3

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

response = bedrock_runtime.converse(
    modelId="amazon.nova-pro-v1:0",
    messages=[
        {
            "role": "user",
            "content": [{"text": "Summarise the trade-offs between provisioned and on-demand throughput."}],
        }
    ],
    inferenceConfig={"maxTokens": 1024, "temperature": 0.3},
)

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

The Bedrock converse API provides a unified message format across supported model providers, reducing per-vendor integration code when an application needs to support multiple Bedrock-hosted models behind one internal interface.

6.2 Applying Guardrails​

response = bedrock_runtime.converse(
    modelId="amazon.nova-pro-v1:0",
    messages=[
        {"role": "user", "content": [{"text": "Draft a customer response about a delayed refund."}]}
    ],
    guardrailConfig={
        "guardrailIdentifier": "customer-support-guardrail",
        "guardrailVersion": "3",
        "trace": "enabled",
    },
)

if response.get("stopReason") == "guardrail_intervened":
    handle_guardrail_intervention(response)

Always enable Guardrails tracing in non-trivial deployments so intervention reasons are logged and auditable — a silent Guardrails block without visibility into why is a debugging and compliance liability.

6.3 Reasoning tier selection (Nova 2 Lite)​

response = bedrock_runtime.converse(
    modelId="amazon.nova-2-lite-v1:0",
    messages=[
        {
            "role": "user",
            "content": [
                {
                    "text": (
                        "Given these three vendor proposals, identify the two "
                        "most significant contractual risks in each."
                    )
                }
            ],
        }
    ],
    inferenceConfig={"maxTokens": 2048},
)

Reserve Nova 2 Lite (or an equivalent reasoning-focused tier) for tasks that genuinely require multi-step deliberation; route simple extraction and classification tasks to a lower-cost general-purpose tier instead.

6.4 Provisioned throughput for predictable latency​

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

provisioned_model = bedrock.create_provisioned_model_throughput(
    modelId="amazon.nova-pro-v1:0",
    provisionedModelName="customer-support-nova-pro",
    modelUnits=2,
)

Provisioned throughput trades a committed cost for predictable latency and guaranteed capacity — appropriate for latency-SLA-bound production workloads, and generally a poor fit for spiky, low-volume or experimental traffic where on-demand invocation is more cost-efficient.

6.5 Inference profiles for cross-region routing​

response = bedrock_runtime.converse(
    modelId="us.amazon.nova-pro-v1:0",  # cross-region inference profile ID
    messages=[{"role": "user", "content": [{"text": "Draft an incident summary."}]}],
)

Cross-region inference profiles can improve availability and help manage regional capacity limits, but introduce data-residency considerations that must be reviewed against your organisation's compliance requirements before enabling them for regulated workloads.

6.6 Nova Sonic speech-to-speech session​

async def run_sonic_session(audio_stream) -> None:
    async with bedrock_runtime.invoke_model_with_bidirectional_stream(
        modelId="amazon.nova-sonic-v1:0"
    ) as session:
        await session.send_audio_chunk(audio_stream)
        async for event in session.receive_events():
            if event.audio_output:
                play_audio_chunk(event.audio_output)

Design explicit interruption handling (the user speaking over the model) and session-timeout logic for speech-to-speech sessions — these are stateful, long-lived interactions, not simple request/response calls.

6.7 Nova Act browser automation​

from nova_act import NovaAct

with NovaAct(starting_page="https://internal-portal.example.com") as agent:
    result = agent.act("Find the latest invoice for account 4471 and download the PDF.")

Scope Nova Act sessions to an isolated browser profile with no access to unrelated authenticated sessions, restrict the domains it can navigate to, and require human review before any action with financial or irreversible consequences (submitting a form, confirming a payment).

6.8 Embeddings for retrieval​

response = bedrock_runtime.invoke_model(
    modelId="amazon.nova-embed-v1",
    body=json.dumps({"inputText": "AWS Bedrock provisioned throughput pricing model"}),
)
embedding_vector = json.loads(response["body"].read())["embedding"]

7. Latency, cost and reliability engineering​

7.1 Tier and product selection by workload​

WorkloadRecommended Nova product
High-volume simple text tasksLower-cost general-purpose tier (e.g., Micro/Lite)
Standard assistant and document workloadsMid-tier general-purpose model
Multi-step reasoning and analysisNova 2 Lite
Real-time voice interactionNova Sonic
Semantic search / RAG retrievalNova embeddings
Web-browser task automationNova Act

7.2 On-demand vs provisioned throughput​

ConsiderationOn-demandProvisioned throughput
Cost modelPay per request/tokenCommitted cost for reserved capacity
Latency predictabilityVariable under loadPredictable, guaranteed capacity
Best fitSpiky, experimental, low-volume trafficLatency-SLA-bound production workloads

7.3 Guardrails performance and cost trade-offs​

Guardrails add a policy-evaluation step to each request, contributing latency and (depending on configuration) additional cost. Scope Guardrails policies tightly to the actual risk surface of each application rather than applying an overly broad, generic policy everywhere — both for latency reasons and to reduce false-positive interventions on legitimate requests.

7.4 SageMaker customisation cost/benefit​

Customisation approachWhen to use
Prompt engineering / retrieval augmentationDefault starting point; cheapest, fastest to iterate
Supervised fine-tuning (SFT)Consistent, narrow task with abundant labelled examples where prompting alone underperforms
Reinforcement fine-tuning (RFT)Tasks with a clear, verifiable reward signal (e.g., passing tests, matching a structured schema) where SFT alone plateaus
Continued pretrainingDomain with substantial unlabelled corpus and a genuine need for deep domain adaptation beyond fine-tuning

Escalate through this list only when evidence from evaluation shows the cheaper approach is insufficient — customisation costs (data preparation, SageMaker compute, ongoing retraining/versioning burden) are non-trivial and should be justified by measured evaluation gaps.

7.5 Reliability patterns​

  • Apply exponential backoff with jitter on Bedrock throttling responses.
  • Monitor Guardrails intervention rate as a first-class metric, not an afterthought — a rising intervention rate can indicate either a genuine safety issue or an overly broad policy misfiring on legitimate traffic.
  • For Nova Act browser sessions, implement explicit step limits and anomaly detection (unexpected navigation, repeated failed actions) to prevent a stuck agent from looping indefinitely against a live web application.

7.6 Observability​

Track per application: model/tier selection distribution, Guardrails intervention rate and reason codes, provisioned-throughput utilisation versus on-demand overflow, cross-region inference-profile latency variance, Nova Sonic session interruption/error rates, and Nova Act task success/failure rates with human-review escalation counts.

8. Engineering assessment checklist​

Amazon Nova engineering assessment

  • Confirmed no self-hosting path exists; Nova access depends entirely on Amazon Bedrock availability, quotas and terms
  • Correct Nova product selected per workload (general-purpose tier, Nova 2 Lite, Nova Sonic, embeddings, or Nova Act) based on the actual task, not the most capable option by default
  • Bedrock Guardrails configured and scoped to the actual risk surface of each application, with tracing enabled for auditability
  • Provisioned throughput evaluated against on-demand cost/latency trade-offs for latency-SLA-bound workloads
  • Cross-region inference profiles reviewed against data-residency and compliance requirements before enabling
  • SageMaker customisation (continued pretraining, SFT, RFT) justified by measured evaluation gaps versus prompting/retrieval alone, and re-evaluated after customisation rather than relying on base-model benchmarks
  • Nova Sonic sessions have explicit interruption handling and session-timeout logic
  • Nova Act sessions scoped to isolated browser profiles, restricted domains, and human review for financial/irreversible actions
  • Guardrails intervention rate and reason codes monitored as a first-class production metric
  • Own golden evaluation set maintained per Nova product/tier, independent of AWS-published capability claims
  • IAM access scoped tightly per Bedrock model and Guardrails resource, following least-privilege principles
  • CloudWatch monitoring and alerting configured for throttling, error rates and Guardrails interventions

Essential reading​

Conclusion​

Amazon Nova's engineering story is defined less by a single headline architectural breakthrough and more by deep operational integration with AWS: a unified Bedrock API surface, configurable Guardrails for safety policy, provisioned throughput and inference profiles for latency and capacity management, and a genuinely deep SageMaker customisation path (continued pretraining, SFT, RFT) that goes beyond what most closed competitors expose directly. Nova Sonic's unified speech-to-speech design and Nova Act's browser-operating agents extend the family into modalities that materially differ from a conventional text-chat API.

Correct interpretation: choosing Nova is substantially a choice about AWS platform fit — Bedrock's operational primitives, Guardrails governance and SageMaker customisation depth — as much as it is a choice about raw model capability compared against GPT-5.6, Claude, Gemini or Grok.

Last updated on

Discussion

Comments​

Share feedback or questions about this page. No account required.

Loading comments…

Occasional notes on AI delivery.

Unsubscribe anytimePrivacy