Structured Output on Amazon Bedrock: Schema-Compliant AI Responses

Today, we’re announcing Structured Output on Amazon Bedrock – a capability that fundamentally changes how you can get valid JSON responses from Foundation models through restricted decoding for schema compliance.

This represents a paradigm shift in AI application development. Instead of validating JSON responses and writing fallback logic if they fail, you can move straight to creation with the data. With structured output, you can create zero-validation data pipelines that trust model outputs, trusted agent systems that confidently call external functions, and simplified application architectures without retry logic.

In this post, we explore the challenges of traditional JSON generation and how structured output solves them. We cover the two main mechanisms—JSON schema output format and strict tool usage—with implementation details, best practices, and practical code examples. Whether you’re building data extraction pipelines, agentic workflows, or AI-powered APIs, you’ll learn how to use structured output to build reliable, production-ready applications. our partner jupyter notebook Provides practical examples for each feature included here.

Problem with traditional JSON generation

For years, getting structured data from a language model meant creating elaborate prompts, hoping for the best, and building elaborate error-handling systems. Even with careful prompting, developers routinely encounter:

• parsing failures:invalid JSON syntax that breaks json.loads() Call
• missing fields: Required data points are missing from the responses
• type mismatch:Strings where integers are expected break downstream processing
• schema violation: Responses that technically parse but don’t match your data model

In production systems, these failures become complex. A single malformed response can propagate through your pipeline, requiring retries, increasing latency and cost. For agentic workflows where models call tools, invalid parameters can completely break the function call.

Consider the need for a booking system passengers: int. Without schema enforcement, the model may return passengers: "two" Or passengers: "2"– Syntactically valid JSON, but semantically incorrect for your function signature.

What changes with structured output

Structured output on Amazon Bedrock is not an incremental improvement – ​​it is a fundamental shift in output formatting from probabilistic to deterministic. Through restricted decoding, Amazon Bedrock forces model responses to conform to your specified JSON schema. Two complementary mechanisms are available:

These features can be used independently or together, giving you precise control over both the model output and how it calls your functions.

What structured output provides:

• always valid:not anymore JSON.parse() errors or parsing exceptions
• type safe: Field types are enforced and required fields are always present
• reliable: Schema violation does not require retry
• production ready: Deploy with confidence at enterprise scale

How structured output works

Structured output uses restricted sampling with compiled grammar artifacts. What happens when you make a request:

1. schema validation: Amazon Bedrock validates your JSON schema against supported JSON Schema Draft 2020-12 subsets
2. grammar collection: For the new schema, Amazon Bedrock compiles a grammar (first request may take longer)
3. caching: Compiled grammars are cached for 24 hours, making subsequent requests faster
4. forced generation: Generates model tokens that generate valid JSON matching your schema

Performance Considerations:

• first request latency: Initial compilation may add latency to the new schema
• cached display: Subsequent requests with the same schema have minimal overhead
• cash range: Grammarly is cached per account for 24 hours from first access

Changing the JSON schema structure or the tool’s input schema invalidates the cache, but only changes name Or description There is no field.

Getting Started with Structured Output

The following example demonstrates structured output with the Converse API:

import boto3
import json
# Initialize the Bedrock Runtime client
bedrock_runtime = boto3.client(
    service_name="bedrock-runtime",
    region_name="us-east-1"  # Choose your preferred region
)
# Define your JSON schema
extraction_schema = {
    "type": "object",
    "properties": {
        "name": {"type": "string", "description": "Customer name"},
        "email": {"type": "string", "description": "Customer email address"},
        "plan_interest": {"type": "string", "description": "Product plan of interest"},
        "demo_requested": {"type": "boolean", "description": "Whether a demo was requested"}
    },
    "required": ("name", "email", "plan_interest", "demo_requested"),
    "additionalProperties": False
}
# Make the request with structured outputs
response = bedrock_runtime.converse(
    modelId="us.anthropic.claude-opus-4-5-20251101-v1:0",
    messages=(
        {
            "role": "user",
            "content": (
                {
                    "text": "Extract the key information from this email: John Smith (john@example.com) is interested in our Enterprise plan and wants to schedule a demo for next Tuesday at 2pm."
                }
            )
        }
    ),
    inferenceConfig={
        "maxTokens": 1024
    },
    outputConfig={
        "textFormat": {
            "type": "json_schema",
            "structure": {
                "jsonSchema": {
                    "schema": json.dumps(extraction_schema),
                    "name": "lead_extraction",
                    "description": "Extract lead information from customer emails"
                }
            }
        }
    }
)
# Parse the schema-compliant JSON response
result = json.loads(response("output")("message")("content")(0)("text"))
print(json.dumps(result, indent=2))

Output:

{
  "name": "John Smith",
  "email": "john@example.com",
  "plan_interest": "Enterprise",
  "demo_requested": true
}

The response conforms to your schema—no additional validation required.

Requirements and Best Practices

To use structured output effectively, follow these guidelines:

• set additionalProperties: false On all items. This is necessary for structured output to work. Without this, your scheme will not be accepted.

{
  "type": "object",
  "properties": {
    "name": {"type": "string"}
  },
  "required": ("name"),
  "additionalProperties": false
}

• Use descriptive field names and descriptions. Models use property names and descriptions to understand what data to extract. obvious names like customer_email outperform common names like field1.
• Use enum For restricted values. Use when a field has a limited set of valid values enum Limiting options. This improves accuracy and produces valid values.
• Start basic, then add complexity. Start with the minimum required fields and gradually add complexity. Basic schemas compile faster and are easier to maintain.
• Reuse schema to benefit from caching. Structure your application to reuse the schema across all requests. The 24-hour grammar cache significantly improves performance for frequently asked queries.
• check stopReason In every reaction. Two scenarios can generate non-conforming responses: denial (when the model is rejected for security reasons) and token limitation (when max_tokens is reached before completion). Handle both cases in your code.
• Test with realistic data before deployment. Validate your schema against production-representative input. Edge cases in real data often reveal schema design problems.

Supported JSON Schema Features:

• All basic types: object, array, string, integer, number, boolean, null
• enum (only strings, numbers, bools or nulls)
• const, anyOf, allOf (with limitations)
• $ref, $defAnd definitions (Internal reference only)
• String Format: date-time, time, date, duration, email, hostname, uri, ipv4, ipv6, uuid
• array minItems (only values ​​0 and 1)

not supported:

• recursive schema
• external $ref Give Feedback Reference
• numerical constraints (minimum, maximum, multipleOf)
• string constraints (minLength, maxLength)
• additionalProperties set to something other than false

Use of rigorous tools for agentic workflows

When creating an application, set where the model tool is called. strict: true Force the tool parameters in your tool definition to match your input schema exactly:

import boto3
import json
bedrock_runtime = boto3.client('bedrock-runtime', region_name="us-east-1")
response = bedrock_runtime.converse(
    modelId="us.anthropic.claude-opus-4-5-20251101-v1:0",
    messages=(
        {
            "role": "user",
            "content": ({"text": "What's the weather like in San Francisco?"})
        }
    ),
    inferenceConfig={"maxTokens": 1024},
    toolConfig={
        "tools": (
            {
                "toolSpec": {
                    "name": "get_weather",
                    "description": "Get the current weather for a specified location",
                    "strict": True,  # Enable strict mode
                    "inputSchema": {
                        "json": {
                            "type": "object",
                            "properties": {
                                "location": {
                                    "type": "string",
                                    "description": "The city and state, e.g., San Francisco, CA"
                                },
                                "unit": {
                                    "type": "string",
                                    "enum": ("celsius", "fahrenheit"),
                                    "description": "Temperature unit"
                                }
                            },
                            "required": ("location", "unit"),
                            "additionalProperties": False
                        }
                    }
                }
            }
        )
    }
)
# Tool inputs conform to the schema
for content_block in response("output")("message")("content"):
    if "toolUse" in content_block:
        tool_input = content_block("toolUse")("input")
        print(f"Tool: {content_block('toolUse')('name')}")
        print(f"Input: {json.dumps(tool_input, indent=2)}")

with strict: trueStructured output constrains the output so that:

• location field is always a string
• unit field is always either celsius Or fahrenheit
• No unexpected fields appear in input

Practical applications in industries

The notebook showcases use cases spanning industries:

• financial Services: Extract structured data from income reports, loan applications and compliance documents. With structured output, every required field is present and typed correctly for downstream processing.
• Health care: Parse clinical notes into structured, schema-conforming records. Extract patient information, diagnoses, and treatment plans in valid JSON for EHR integration.
• e-commerce: Build a reliable product catalog promotion pipeline. Extract specifications, categories, and features from product descriptions with consistent, reliable results.
• legal: Analyze contracts and extract key terms, parties, dates and obligations in structured formats suitable for contract management systems.
• customer service: Create intelligent ticket routing and response systems where extracted intents, sentiments, and entities match your application’s data model.

choosing the right approach

Our testing revealed clear patterns for when to use each feature:

Use JSON Schema output format when:

• You need the model’s response in a specific structure
• Building data extraction pipelines
• Generating API-ready responses
• Creating structured reports or summaries

Use hardening equipment when:

• Building agentic systems that call external functions
• Implementing multi-step workflows with toolchains
• Function call requires valid parameter type
• Connecting AI to databases, APIs or external services

Use both together when:

• Building complex agents that require valid tool calls and structured final responses
• Creating systems where results from intermediate tools feed into structured output
• Implementing enterprise workflows requiring end-to-end schema compliance

API comparison: Conversations compared to InvokeModel

The Converse API and InvokeModel API both support structured output with slightly different parameter formats:

Comment:The InvokeModel API uses different request field names depending on the model type. For anthropic cloud models, use output_config.format For JSON schema output. For open weight models, use response_format instead.

Choose Converse API for multi-turn conversations and InvokeModel API when you need direct model access with provider-specific request formats.

Supported models and availability

Structured output is generally available in all commercial AWS regions for select Amazon Bedrock model providers:

• anthropic
• deepseek
• Google
• minimal maximum
• Mistral AI
• Moonshot AI
• NVIDIA
• OpenAI
• quen

This feature works seamlessly with:

• cross-region estimation: Use structured output in AWS regions without additional setup
• batch estimation: Process large amounts with schema-conforming output
• streaming: Stream structured responses ConverseStream Or InvokeModelWithResponseStream

conclusion

In this post, you learned how structured outputs on Amazon Bedrock reduce the uncertainty of AI-generated JSON through valid, schema-conformant responses. Using the JSON Schema output format and strict tool usage, you can build reliable data extraction pipelines, robust agentic workflows, and production-ready AI applications – without custom parsing or validation logic. Whether you’re extracting data from documents, building intelligent automation, or building AI-powered APIs, structured outputs deliver the reliability your applications demand.

Structured output is now generally available on Amazon Bedrock. To use structured output with the Converse API, update to the latest AWS SDKs. To learn more, check out the Amazon Bedrock documentation and learn about us sample notebook.

Which workflows in your organization can unlock valid, schema-compliant JSON? The notebook provides everything you need to know.

About the authors