企业官网建设流程全解析

Terraform AWS Provider 的 aws_bedrock_foundation_model 数据源：查询与使用 Bedrock 基础模型元数据

【免费下载链接】terraform-provider-awsThe AWS Provider enables Terraform to manage AWS resources.项目地址: https://gitcode.com/GitHub_Trending/te/terraform-provider-aws

本篇文章围绕 Terraform AWS Provider 提供的aws_bedrock_foundation_model数据源展开，讲解如何通过 Terraform 查询单个 Amazon Bedrock 基础模型（Foundation Model）的详细元数据，包括模型 ARN、名称、提供商、支持的推理类型、输入输出模态、流式响应与自定义能力等。读完本文，你将掌握该数据源的全部参数与导出属性、与aws_bedrock_foundation_models列表数据源的组合用法，以及其底层调用 AWS SDK 的实现原理与验收测试证据，可直接用于配置可复现、可审计的 Bedrock 模型访问与调用场景。

数据源定位与使用场景

aws_bedrock_foundation_model是 AWS Provider 在 Bedrock 子类目下提供的数据源，用于按model_id精确查询某一个基础模型的元数据。它在仓库中的官方文档位于 website/docs/d/bedrock_foundation_model.html.markdown，对应的 Go 实现位于 internal/service/bedrock/foundation_model_data_source.go。

典型使用场景包括：

• 动态发现模型能力：在编写调用 Bedrock 的配置前，先读取模型支持的能力（如是否支持流式响应、支持的模态），据此决定调用策略；
• 与列表数据源联动：先通过aws_bedrock_foundation_models获取全部模型摘要列表，再对列表中第一个模型取详细元数据；
• 引用模型 ARN 与名称：将model_arn、model_name、provider_name等属性作为其他资源（如aws_bedrock_provisioned_model_throughput、aws_bedrock_custom_model）的输入，实现模型标识的自动化管理。

基础用法示例

数据源要求至少提供model_id参数。最典型的写法是先使用列表数据源aws_bedrock_foundation_models取得模型摘要，再取其第一个元素的model_id：

data "aws_bedrock_foundation_models" "test" {} data "aws_bedrock_foundation_model" "test" { model_id = data.aws_bedrock_foundation_models.test.model_summaries[0].model_id }

这段示例与官方文档 website/docs/d/bedrock_foundation_model.html.markdown 中的 Basic Usage 完全一致，并且被仓库的验收测试直接复用——见 internal/service/bedrock/foundation_model_data_source_test.go 中的testAccFoundationModelDataSourceConfig_basic()，测试会通过resource.TestCheckResourceAttrSet校验customizations_supported.#、inference_types_supported.#、input_modalities.#、model_arn、model_name、output_modalities.#、provider_name、response_streaming_supported等属性均已被填充，证明该数据源可真实读取 AWS 返回的完整模型详情。

如果你已经知道具体的模型 ID，也可以直接硬编码，例如：

data "aws_bedrock_foundation_model" "claude" { model_id = "anthropic.claude-3-5-sonnet-20241022-v2:0" }

从源码结构看，model_id在数据源的 Schema 中被标记为Required（internal/service/bedrock/foundation_model_data_source.go），因此不指定模型 ID 时 Terraform 会直接报错。

参数详解（Argument Reference）

该数据源支持以下参数：

关于region参数的实现：数据源的模型结构中嵌入了framework.WithRegionModel，其中定义了Region types.String \tfsdk:"region"`字段（见 [internal/framework/with_region.go](https://link.gitcode.com/i/a555f5b807f5a535630536dfc28e1786)）。当配置中省略region时，AWS Provider 会自动回退到 Provider 级配置的区域，因此在多区域管理时可以通过显式指定region` 来查询不同区域可用的 Bedrock 模型目录：

provider "aws" { region = "us-east-1" } data "aws_bedrock_foundation_model" "eu" { region = "eu-central-1" model_id = "amazon.titan-text-express-v1" }

导出属性详解（Attribute Reference）

除参数外，数据源还会导出以下只读属性：

这些属性与底层 AWS API 返回的ModelDetails结构一一对应。在 Go 实现中，foundationModelDataSourceModel结构体为每个属性定义了对应的 tfsdk 字段，其中集合类型使用fwtypes.SetOfString，ARN 使用fwtypes.ARN自定义类型（internal/service/bedrock/foundation_model_data_source.go），这使得 Terraform 状态中可以承载强类型数据。

底层实现原理：调用链与数据流

aws_bedrock_foundation_model数据源基于 Terraform Plugin Framework 实现，其读取流程如下（参见 internal/service/bedrock/foundation_model_data_source.go）：

1. 解析配置：request.Config.Get将用户配置反序列化到foundationModelDataSourceModel模型；
2. 获取客户端：通过d.Meta().BedrockClient(ctx)获取 Bedrock 服务客户端（aws-sdk-go-v2/service/bedrock）；
3. 构造请求：用fwflex.StringFromFramework将框架层的model_id转换为 SDK 的ModelIdentifier，构造bedrock.GetFoundationModelInput；
4. 发起 API 调用：调用conn.GetFoundationModel(ctx, input)，即 AWS SDK for Go v2 的 GetFoundationModel API；
5. 写入状态：通过fwflex.Flatten将 API 返回的output.ModelDetails平铺映射回模型结构，并将id设置为model_id，最后写入 Terraform 状态。

值得注意的实现细节：

• 集合属性（如customizations_supported、inference_types_supported、input_modalities、output_modalities）在 Schema 中均被声明为Computed: true，不会参与配置输入；
• 错误处理使用response.Diagnostics.AddError，在读取失败时会附带模型 ID 便于排查（internal/service/bedrock/foundation_model_data_source.go）；
• 数据源通过@FrameworkDataSource("aws_bedrock_foundation_model", name="Foundation Model")注解注册（internal/service/bedrock/foundation_model_data_source.go），说明它属于该仓库中基于 Plugin Framework 的新一代数据源实现。

与列表数据源 aws_bedrock_foundation_models 的配合

aws_bedrock_foundation_model通常与列表数据源aws_bedrock_foundation_models搭配使用。后者负责列出区域内全部可用的基础模型摘要（其文档与实现分别位于 website/docs/d/bedrock_foundation_models.html.markdown 和 internal/service/bedrock/foundation_models_data_source.go），并支持以下过滤参数：

• by_customization_type：按自定义类型过滤，合法值为FINE_TUNING；
• by_inference_type：按推理类型过滤，合法值为ON_DEMAND与PROVISIONED；
• by_output_modality：按输出模态过滤，合法值为TEXT、IMAGE、EMBEDDING；
• by_provider：按模型提供商过滤（如Mistral AI），其实现中对by_provider应用了正则校验（^[A-Za-z0-9- ]{1,63}$，见 internal/service/bedrock/foundation_models_data_source.go）。

列表数据源返回的model_summaries列表中的每个元素，其字段与aws_bedrock_foundation_model的导出属性几乎一一对应（model_summaries元素结构定义在 internal/service/bedrock/foundation_models_data_source.go）。因此，一个完整的"先筛选、再取详情"的链路可以这样写：

# 1. 筛选出支持按需推理、输出文本的模型 data "aws_bedrock_foundation_models" "on_demand_text" { by_inference_type = "ON_DEMAND" by_output_modality = "TEXT" } # 2. 对筛选结果中的第一个模型取完整详情 data "aws_bedrock_foundation_model" "first" { model_id = data.aws_bedrock_foundation_models.on_demand_text.model_summaries[0].model_id } output "first_model_arn" { value = data.aws_bedrock_foundation_model.first.model_arn } output "first_model_provider" { value = data.aws_bedrock_foundation_model.first.provider_name } output "first_model_streaming" { value = data.aws_bedrock_foundation_model.first.response_streaming_supported }

从源码可以看出，列表数据源aws_bedrock_foundation_models底层调用的是ListFoundationModelsAPI，其id直接取当前区域（internal/service/bedrock/foundation_models_data_source.go）；而单个模型数据源调用的是GetFoundationModelAPI。二者叠加即可实现"区域内模型目录 + 单个模型详情"的完整查询能力。

测试验证与实战注意点

仓库中为这两个数据源都编写了验收测试（Acceptance Test）：

• internal/service/bedrock/foundation_model_data_source_test.go 中的TestAccBedrockFoundationModelDataSource_basic：验证读取单个模型后全部导出属性非空；
• internal/service/bedrock/foundation_models_data_source_test.go 中的多个测试用例：分别验证按自定义类型、推理类型、输出模态、提供商过滤后model_summaries.#大于 0。

这些测试使用acctest.ParallelTest并行执行，并通过acctest.PreCheckPartitionHasService(t, names.BedrockEndpointID)校验当前分区提供 Bedrock 服务后才运行（见 internal/service/bedrock/foundation_model_data_source_test.go）。这意味着：

1. 区域前提：Bedrock 并非在所有 AWS 区域可用，使用该数据源前需确认目标区域已开放 Bedrock 服务；
2. 账号前提：运行验收测试要求配置了真实 AWS 凭证，且账号有权限访问 Bedrock 模型目录；
3. 模型可用性：Bedrock 的模型目录会随区域、账号以及模型访问权限（Model Access）变化，model_id必须对应当前环境中实际可用的模型，否则 API 会返回读取错误（实现中会在诊断信息中携带模型 ID，便于定位）。

小结

aws_bedrock_foundation_model是 AWS Provider 中查询 Bedrock 基础模型元数据的核心数据源：它通过GetFoundationModelAPI 按model_id精确读取单个模型的 ARN、名称、提供商、推理类型、模态与流式能力等全部元数据，支持region参数覆盖 Provider 默认区域，并可与aws_bedrock_foundation_models列表数据源组合成"筛选—取详情"的完整链路。其基于 Plugin Framework 的实现、fwflex的序列化机制以及仓库内的验收测试，共同保证了该数据源在真实 AWS 环境下的可靠性与可审计性，适合作为 Bedrock 模型管理与调用配置的元数据基础。

如果你需要进一步了解列表数据源的过滤细节，可继续阅读 website/docs/d/bedrock_foundation_models.html.markdown；若要探究 Bedrock 相关的其他资源（如自定义模型、预置吞吐），可浏览 internal/service/bedrock 目录下的实现。

【免费下载链接】terraform-provider-awsThe AWS Provider enables Terraform to manage AWS resources.项目地址: https://gitcode.com/GitHub_Trending/te/terraform-provider-aws