Amazon Bedrock 全面支持 Anthropic Claude 模型结构化输出

在所有可用该模型的区域，Amazon Bedrock 现已在 bedrock-runtime 和 bedrock-mantle 两个端点上支持所有 Anthropic Claude 模型的结构化输出（Structured Outputs）。

无论你是通过 Boto3 和 bedrock-runtime API 调用 Claude，还是通过 Messages API 与 bedrock-mantle 端点调用，现在都能获得符合预定义结构的、合规的 JSON 响应。你不再需要编写自定义解析代码、重试逻辑或后处理步骤。

实际应用场景

借助 Amazon Bedrock 上 Claude 的结构化输出功能，你可以跨行业实现可靠、符合 Schema 规范的自动化任务。应用场景包括：从财务财报和合规文件中提取每一个所需字段、将临床病历解析到电子健康档案（EHR）中，以及利用一致且经过验证的结果丰富产品目录。你还可以分析合同中的关键条款、合同方与法律义务，或者构建智能客服工单路由系统，确保意图、情绪和实体提取始终与你的应用程序数据模型保持一致。

结构化输出为 Amazon Bedrock 带来了哪些改变

结构化输出使用受限解码（constrained decoding）技术在 Token 生成过程中（而非生成完成后）强制执行你的 JSON Schema。模型不会生成任何违反 Schema 的 Token。这使得输出格式化从“概率性（probabilistic）”转变为“确定性（deterministic）”。

两个 Amazon Bedrock 端点现均提供以下两项互补机制：

功能	目的	使用场景
JSON Schema 输出格式	控制模型的响应结构	数据提取、报告生成、API 响应
严格工具调用（Strict tool use）	根据 Schema 校验工具参数	Agent 工作流、函数调用（Function Calling）、多步自动化

这对开发者意味着什么

每个响应都是有效的 JSON，因此你不再会遇到 JSON.parse() 错误或解析异常。响应还具备类型安全性（type safe）：字段类型得到强制校验，且必填字段始终存在。由于输出始终符合你的 Schema，你不需要为了应对 Schema 违规而设置重试机制，从而让系统集成更加稳定可靠。结构化输出还将响应严格限制在你定义的字段内，这减少了输出 Token 的数量，并能在高吞吐量工作负载下降低推理成本。这些特性让结构化输出达到了生产可用级别（production ready），无需额外的 Schema 校验代码即可进行大规模部署。

支持的模型与可用性

结构化输出支持批处理推理（batch inference），因此你可以异步处理海量请求，同时依然能获取符合 Schema 规范的输出。在 bedrock-runtime 端点上，它还支持跨区域推理（cross-Region inference），无需额外设置即可跨 AWS 区域使用。如果你需要实时响应，还可以将结构化响应以类型化事件（typed events）的形式流式传输。

工作原理

当你发起包含 JSON Schema 的请求时，底层处理流程如下：

1. Schema 校验 – Amazon Bedrock 会根据支持的 JSON Schema Draft 2020-12 子集来校验你的 JSON Schema。
2. 语法编译 – 对于新的 Schema，Amazon Bedrock 会编译一个语法构件（grammar artifact，首次请求可能会稍长一些）。
3. 缓存 – 编译后的语法会被缓存 24 小时，从而加快后续请求的处理速度。
4. 受限生成 – 模型生成能够产生符合你 Schema 的有效 JSON Token。

性能考量

在性能方面，使用新 Schema 的首次请求耗时可能会更长，因为 Amazon Bedrock 需要在开始生成前编译语法构件。在首次编译完成后，使用相同 Schema 的后续请求将以极低的额外开销运行，因为编译后的语法已被缓存。该缓存的作用域绑定在你的账户内，并在首次访问后有效保留 24 小时。修改 JSON Schema 的结构会使缓存失效并触发重新编译；但如果仅修改名称（name）或描述（description）字段，则缓存的语法仍然有效。

入门指南：通过 InvokeModel API (bedrock-runtime) 使用结构化输出

InvokeModel API 接受 Anthropic 原生请求体，因此 Schema 作为 JSON 对象置于 output_config.format 中，而不是作为 JSON 字符串。以下示例演示了如何结合使用 boto3 与 Anthropic Claude 模型，从客户电子邮件中提取结构化的销售线索（Lead）数据：

Python

import boto3
import json

REGION = "us-east-1" # Choose your preferred region
bedrock_runtime = boto3.client(service_name="bedrock-runtime", region_name=REGION)

# Define the JSON schema for structured output
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 a request with structured outputs via the InvokeModel API
# (reusing the schema defined for the Converse example)
response = bedrock_runtime.invoke_model(
    modelId="global.anthropic.claude-sonnet-5-5",
    body=json.dumps({
        "anthropic_version": "bedrock-2023-05-31",
        "max_tokens": 512,
        "messages": [
            {"role": "user", "content": (
                "Paulo Santos (paulo@example.com) is interested in our Enterprise plan "
                "and wants to schedule a demo for next Tuesday at 2pm."
            )}
        ],
        "output_config": {"format": {"type": "json_schema", "schema": schema}}
    })
)

body = json.loads(response["body"].read())

# Check the stop reason before parsing
if body["stop_reason"] == "end_turn":
    result_text = next(b["text"] for b in body["content"] if b["type"] == "text")
    print(json.dumps(json.loads(result_text), indent=2))
elif body["stop_reason"] == "max_tokens":
    print("Response truncated: increase max_tokens and retry.")

JSON

{
    "name": "Paulo Santos",
    "email": "paulo@example.com",
    "plan_interest": "Enterprise",
    "demo_requested": true
}

响应完全符合你的 Schema。不需要额外的验证。

如需查看更多 API 使用示例（包括 Messages API），请参阅配套的示例 Notebook。

Amazon Bedrock Mantle 专为带有服务端工具、后台推理和有状态对话的 Agent 应用程序而设计。通过在 bedrock-mantle 端点上启用严格工具调用（strict tool use），你现在可以确保工具参数与输入 Schema 完全匹配。以下示例演示了如何定义具有严格 Schema 强制校验的工具：

Import json
from anthropic import AnthropicBedrockMantle

# Reusing the client created in the Messages API example
client = AnthropicBedrockMantle(aws_region="us-east-1")

message = client.messages.create(
    model="anthropic.claude-sonnet-5",
    max_tokens=512,
    messages=[{"role": "user", "content": "What's the weather like in San Francisco?"}],
    tools=[
        {
            "name": "get_weather",
            "description": "Get the current weather for a specified location",
            "strict": True,
            "input_schema": {
                "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 block in message.content:
    if block.type == "tool_use":
        print(f"Tool: {block.name}")
        print(f"Input: {json.dumps(block.input, indent=2)}")

将 strict: true 设置后，模型的工具输入将被限制为完全匹配你的 Schema。location 字段始终是字符串，unit 字段始终为 celsius 或 fahrenheit。模型无法添加 Schema 之外的字段，因此工具输入仅包含 Schema 所指定的内容。

这对于 Amazon Bedrock Mantle 上的 Agent 使用场景尤为宝贵，在这些场景中，模型会通过网络搜索和代码解释器等服务端工具来编排多步骤工作流。

Claude 结构化输出的核心用例

在以下三种常见模式中，结构化输出最大程度地减少了错误处理的复杂度：

• 数据提取： 从发票、合同、电子邮件和会议纪要中提取字段并生成始终符合 Schema 的 JSON，可直接加载到数据库或客户关系管理（CRM）系统中。
• 可靠的 Agent 工具调用： 在生成时针对 Schema 校验工具参数，使多步 Agent 工作流不会因格式错误的输入而执行失败。
• 大规模分类： 按意图、优先级和情绪对工单、销售线索或内容进行分类，用于路由、内容审核与评估。

Claude Haiku 5.5 能够稳定处理快速且重复的工作负载，例如摘要、压缩、数据库查询和分类请求。以下示例展示了如何使用 Invoke API 和 Haiku 5.5 对传入数据进行分类和路由：

import boto3
import json

REGION = "us-east-1" # Choose your preferred region
bedrock_runtime = boto3.client(service_name="bedrock-runtime", region_name=REGION)

# Classification schema: enums restrict output to a fixed set of labels
schema = {
    "type": "object",
    "properties": {
        "category": {
            "type": "string",
            "enum": ["billing", "technical", "account", "sales", "other"],
            "description": "Primary ticket category"
        },
        "priority": {
            "type": "string",
            "enum": ["low", "medium", "high", "urgent"],
            "description": "Urgency based on business impact"
        },
        "sentiment": {
            "type": "string",
            "enum": ["positive", "neutral", "negative"],
            "description": "Customer sentiment"
        },
        "escalate": {"type": "boolean", "description": "Whether a human should review immediately"},
        "reason": {"type": "string", "description": "One-sentence justification for the classification"}
    },
    "required": ["category", "priority", "sentiment", "escalate", "reason"],
    "additionalProperties": False
}

ticket = (
    "Our production API calls have been failing with 500 errors since this morning. "
    "We're losing orders every minute. This is the second outage this month!"
)

# Make a request with structured outputs via the InvokeModel API
response = bedrock_runtime.invoke_model(
    modelId="global.anthropic.claude-haiku-5-5",
    body=json.dumps({
        "anthropic_version": "bedrock-2023-05-31",
        "max_tokens": 512,
        "system": "You are a support ticket classifier. Classify the ticket accurately.",
        "messages": [
            {"role": "user", "content": f"Classify this support ticket:\n\n{ticket}"}
        ],
        "output_config": {"format": {"type": "json_schema", "schema": schema}}
    })
)

body = json.loads(response["body"].read())

# Check the stop reason before parsing
if body["stop_reason"] == "end_turn":
    result_text = next(b["text"] for b in body["content"] if b["type"] == "text")
    result = json.loads(result_text)
    print(json.dumps(result, indent=2))
    # Route the ticket based on the guaranteed-valid labels
    if result["escalate"]:
        print(f"Escalating to on-call: {result['category']} / {result['priority']}")
elif body["stop_reason"] == "max_tokens":
    print("Response truncated: increase max_tokens and retry.")

要求与最佳实践

要在 Amazon Bedrock 上高效使用结构化输出，请遵循以下准则：

1. 在所有对象上设置 additionalProperties: false：这是结构化输出生效的硬性要求。缺少此项，你的 Schema 将无法被接受。
2. 使用具描述性的字段名称与说明：模型依赖属性名和描述来理解需要提取哪些数据。像 customer_email 这样清晰的名称表现远优于像 field1 这样的通用名称。
3. 使用 enum 限制取值范围：当某个字段的有效值有限时，使用 enum 来约束可选范围。
4. 先从基础结构做起，再逐步增加复杂度：从最小必要字段开始，循序渐进地增加复杂度。基础 Schema 编译更快、更易调试，还能让你的请求载荷保持精简，因为 Schema 会计入 Converse API 载荷大小。
5. 复用 Schema 以利用缓存优势：在架构设计上让应用程序在多次请求中复用 Schema。24 小时的语法缓存能够显著提升重复查询的性能。
6. 在每个响应中检查停止原因（stop reason）：有两种情况可能会产生不符合规范的输出……

Amazon Bedrock now supports structured outputs for all Anthropic Claude models, on both the bedrock-runtime and bedrock-mantle endpoints, where the model is available.

Whether you call Claude through Boto3 and the bedrock-runtime APIs or through the Messages API and the bedrock-mantle endpoint, you can now receive schema-compliant JSON responses that conform to a defined structure. You no longer need custom parsing, retry logic, or post-processing.

Practical applications

With structured outputs for Claude on Amazon Bedrock, you can automate reliable, schema-compliant tasks across industries. Examples include extracting every required field from financial earnings reports and compliance documents, parsing clinical notes into Electronic Health Records (EHR), and enriching product catalogs with consistent, validated results. You can also analyze contracts for key terms, parties, and obligations, or power intelligent support ticket routing where intents, sentiments, and entities always match your application’s data model.

What changes with structured outputs on Amazon Bedrock

Structured outputs use constrained decoding to enforce your JSON schema during token generation, not after the fact. The model doesn’t produce tokens that would violate your schema. This changes output formatting from probabilistic to deterministic.

Two complementary mechanisms are now available on both Amazon Bedrock endpoints:

Feature	Purpose	Use case
JSON Schema output format	Control the model’s response structure	Data extraction, report generation, API responses
Strict tool use	Validate tool parameters against schemas	Agentic workflows, function calling, multi-step automation

What this means for you

Each response is a valid JSON, so you no longer encounter JSON.parse() errors or parsing exceptions. Responses are also type safe: field types are enforced, and required fields are always present. Because outputs always conform to your schema, you don’t need retries to handle schema violations, making your integration more reliable. Structured outputs also constrains responses to only the fields your schema defines, which reduces output token count and can lower inference costs for high-volume workloads. These properties make structured outputs production ready, so you can deploy at scale without additional schema-validation code.

Supported models and availability

Structured outputs works with batch inference, so you can process large volumes of requests asynchronously while still receiving schema-compliant outputs. On the bedrock-runtime endpoint, it also works with cross-Region inference, so you can use it across AWS Regions without additional setup. If you need responses in real time, you can stream structured responses as typed events.

How it works

When you make a request with a JSON schema, here’s what happens behind the scenes:

1. Schema validation – Amazon Bedrock validates your JSON schema against the supported JSON Schema Draft 2020-12 subset.
2. Grammar compilation – For new schemas, Amazon Bedrock compiles a grammar artifact (the first request might take slightly longer).
3. Caching – Compiled grammars are cached for 24 hours, making subsequent requests faster.
4. Constrained generation – The model generates tokens that produce valid JSON matching your schema.

Performance considerations

For performance, the first request with a new schema might take longer because Amazon Bedrock compiles a grammar artifact before generation begins. After that initial compilation, subsequent requests using the same schema run with minimal overhead because the compiled grammar is cached. This cache is scoped to your account and lasts for 24 hours from first access. Changing the structure of your JSON schema invalidates the cache and triggers a fresh compilation, while changing only the name or description fields leaves the cached grammar intact.

Getting started: Structured outputs with the InvokeModel API (bedrock-runtime)

The InvokeModel API takes the Anthropic-native request body, so the schema goes in output_config.format as a JSON object rather than a JSON string. The following example shows how to extract the structured lead data from a customer email using boto3 with an Anthropic Claude model:

Python

import boto3
import json

REGION = "us-east-1" # Choose your preferred region
bedrock_runtime = boto3.client(service_name="bedrock-runtime", region_name=REGION)

# Define the JSON schema for structured output
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 a request with structured outputs via the InvokeModel API
# (reusing the schema defined for the Converse example)
response = bedrock_runtime.invoke_model(
    modelId="global.anthropic.claude-sonnet-5-5",
    body=json.dumps({
        "anthropic_version": "bedrock-2023-05-31",
        "max_tokens": 512,
        "messages": [
            {"role": "user", "content": (
                "Paulo Santos (paulo@example.com) is interested in our Enterprise plan "
                "and wants to schedule a demo for next Tuesday at 2pm."
            )}
        ],
        "output_config": {"format": {"type": "json_schema", "schema": schema}}
    })
)

body = json.loads(response["body"].read())

# Check the stop reason before parsing
if body["stop_reason"] == "end_turn":
    result_text = next(b["text"] for b in body["content"] if b["type"] == "text")
    print(json.dumps(json.loads(result_text), indent=2))
elif body["stop_reason"] == "max_tokens":
    print("Response truncated: increase max_tokens and retry.")

JSON

{
    "name": "Paulo Santos",
    "email": "paulo@example.com",
    "plan_interest": "Enterprise",
    "demo_requested": true
}

The response conforms to your schema. No additional validation is required.

For additional API usage examples, including the Messages API, see the accompanying sample notebook.

Amazon Bedrock Mantle is designed for agentic applications with server-side tools, background inference, and stateful conversations. With strict tool use on the bedrock-mantle endpoint, you can now guarantee that tool parameters match your input schema exactly. The following example shows how to define a tool with strict schema enforcement:

Import json
from anthropic import AnthropicBedrockMantle

# Reusing the client created in the Messages API example
client = AnthropicBedrockMantle(aws_region="us-east-1")

message = client.messages.create(
    model="anthropic.claude-sonnet-5",
    max_tokens=512,
    messages=[{"role": "user", "content": "What's the weather like in San Francisco?"}],
    tools=[
        {
            "name": "get_weather",
            "description": "Get the current weather for a specified location",
            "strict": True,
            "input_schema": {
                "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 block in message.content:
    if block.type == "tool_use":
        print(f"Tool: {block.name}")
        print(f"Input: {json.dumps(block.input, indent=2)}")

Setting strict: true constrains the model’s tool input to match your schema exactly. The location field is always a string, and the unit field is always either celsius or fahrenheit. The model can’t add fields outside your schema, so the tool input contains only what your schema specifies.

This is especially valuable for agentic use cases on Amazon Bedrock Mantle, where models orchestrate multi-step workflows with server-side tools like web search and code interpreter.

Top use cases for Claude structured outputs

Structured outputs reduce error-handling complexity the most in three common patterns:

• Data extraction: Extract fields from invoices, contracts, email, and transcripts into JSON that always matches your schema, ready to load into databases or customer relationship management (CRM) systems.
• Reliable agent tool calls: Validate tool arguments against their schemas at generation time, so multi-step agent workflows run without failures from malformed input.
• Classification at scale: Classify tickets, leads, or content by intent, priority, and sentiment for routing, moderation, and evaluation.

Claude Haiku 5.5 reliably handles quick and repetitive workloads such as summaries, compactions, database queries, and classification requests. The following example shows how to classify and route incoming data using the Invoke API and Haiku 5.5:

import boto3
import json

REGION = "us-east-1" # Choose your preferred region
bedrock_runtime = boto3.client(service_name="bedrock-runtime", region_name=REGION)

# Classification schema: enums restrict output to a fixed set of labels
schema = {
    "type": "object",
    "properties": {
        "category": {
            "type": "string",
            "enum": ["billing", "technical", "account", "sales", "other"],
            "description": "Primary ticket category"
        },
        "priority": {
            "type": "string",
            "enum": ["low", "medium", "high", "urgent"],
            "description": "Urgency based on business impact"
        },
        "sentiment": {
            "type": "string",
            "enum": ["positive", "neutral", "negative"],
            "description": "Customer sentiment"
        },
        "escalate": {"type": "boolean", "description": "Whether a human should review immediately"},
        "reason": {"type": "string", "description": "One-sentence justification for the classification"}
    },
    "required": ["category", "priority", "sentiment", "escalate", "reason"],
    "additionalProperties": False
}

ticket = (
    "Our production API calls have been failing with 500 errors since this morning. "
    "We're losing orders every minute. This is the second outage this month!"
)

# Make a request with structured outputs via the InvokeModel API
response = bedrock_runtime.invoke_model(
    modelId="global.anthropic.claude-haiku-5-5",
    body=json.dumps({
        "anthropic_version": "bedrock-2023-05-31",
        "max_tokens": 512,
        "system": "You are a support ticket classifier. Classify the ticket accurately.",
        "messages": [
            {"role": "user", "content": f"Classify this support ticket:\n\n{ticket}"}
        ],
        "output_config": {"format": {"type": "json_schema", "schema": schema}}
    })
)

body = json.loads(response["body"].read())

# Check the stop reason before parsing
if body["stop_reason"] == "end_turn":
    result_text = next(b["text"] for b in body["content"] if b["type"] == "text")
    result = json.loads(result_text)
    print(json.dumps(result, indent=2))
    # Route the ticket based on the guaranteed-valid labels
    if result["escalate"]:
        print(f"Escalating to on-call: {result['category']} / {result['priority']}")
elif body["stop_reason"] == "max_tokens":
    print("Response truncated: increase max_tokens and retry.")

Requirements and best practices

To use structured outputs effectively on Amazon Bedrock, follow these guidelines:

1. Set additionalProperties: false on all objects : This is required for structured outputs to work. Without it, your schema won’t be accepted.
2. Use descriptive field names and descriptions : Models use property names and descriptions to understand what data to extract. Clear names like customer_email outperform generic names like field1.
3. Use enum for constrained values : When a field has a limited set of valid values, use enum to constrain options.
4. Start basic, then add complexity : Begin with the minimum required fields and add complexity incrementally. Basic schemas compile faster, are easier to debug, and keep your request payload lean because the schema counts toward the Converse API payload size.
5. Reuse schemas to benefit from caching : Structure your application to reuse schemas across requests. The 24-hour grammar cache improves performance for repeated queries.
6. Check the stop reason in every response : Two scenarios can produce non-conforming responses: refusals (when the model declines for safety reasons) and token limits (when max_tokens is reached before completing). Handle both cases in your code.
7. Test with realistic data before deployment : Validate your schemas against production-representative inputs. Edge cases in real data often reveal schema design issues.

For additional best practices and schema design recommendations, see Structured outputs in the Amazon Bedrock User Guide.

Supported JSON Schema features

1. All basic types: object, array, string, integer, number, boolean, null.
2. enum (strings, numbers, booleans, or nulls only).
3. const, anyOf, allOf (with limitations).
4. $ref, $def, and definitions (internal references only).
5. String formats: date-time, time, date, duration, email, hostname, uri, ipv4, ipv6, uuid.
6. Array minItems (only values 0 and 1).

Not supported

These keywords are accepted by the API but are not enforced during generation. A request that includes them returns a successful response, and the model can still return values that violate them. Validate these constraints in your application rather than relying on the schema to enforce them.

1. Recursive schemas.
2. External $ref references.
3. Numerical constraints (minimum, maximum, multipleOf).
4. String constraints (minLength, maxLength).
5. additionalProperties set to anything other than false.

Conclusion

Structured outputs for Anthropic Claude models on Amazon Bedrock provides the reliability that production AI applications require. It is available now on both the bedrock-runtime and bedrock-mantle endpoints. By combining JSON Schema output format and strict tool use, you can build data pipelines that need no additional validation. You can also create reliable agentic workflows and production AI applications without custom parsing or retry logic.

Structured outputs for Claude on Amazon Bedrock is now generally available. To learn more, see the Amazon Bedrock documentation and explore our sample notebook.

What workflows could validated, schema-compliant JSON improve in your organization? Share your feedback and questions in the comments.

---

About the authors

Anshika Saxena

Anshika is a Generative AI Data Scientist at AWS, focused on Amazon Bedrock. She helps enterprise customers accelerate their generative AI and agentic AI adoption by guiding them through building and implementing solutions on Amazon Bedrock. She also works with ISVs and startups to enable them with the latest Anthropic services on Amazon Bedrock.

Dani Mitchell

Dani is a Senior Specialist Solutions Architect for Generative AI at AWS, working on go-to-market for Anthropic on Amazon Bedrock. He helps enterprises across the world design and deploy generative AI solutions using Anthropic’s models and capabilities on Amazon Bedrock to build scalable, production-ready applications.

Alfredo Castillo

Alfredo is a Senior Specialist Solutions Architect for Generative AI at AWS, focusing on Anthropic models go-to-market on Amazon Bedrock. He works with Financial Services customers to design and scale generative AI solutions across distributed systems and turn generative AI experiments into production workloads. Outside of work, he is passionate about family and endurance sports.

Aamna Najmi

Aamna is a Senior Specialist Solutions Architect for Generative AI focusing on Anthropic models and operationalizing and governing generative AI systems at scale on Amazon Bedrock. She helps ISVs solve their challenges, embrace innovation, and create new business opportunities with Amazon Bedrock.

Sofian Hamiti

Sofian is a technology leader with over 12 years of experience building AI solutions, and leading high-performing teams to maximize customer outcomes. He is passionate about empowering diverse talents to drive global impact and achieve their career aspirations.

Ayan Ray

Ayan is a Principal Partner Solutions Architect and AI Tech Lead at AWS, serving as the Worldwide Tech Lead for Anthropic at AWS. He works at the intersection of cloud architecture and Artificial Intelligence, helping organizations adopt and scale Anthropic’s technologies on AWS.