使用 AWS RTB Fabric 为外部合作伙伴构建自定义域名入站链路（ASG / EKS 实战）

摘要：AWS RTB Fabric 是专为实时竞价（RTB）广告负载打造的全托管服务，提供个位数毫秒级延迟，网络成本最高降低约 80%。本文聚焦“外部到内部”场景：作为 DSP，让 RTB Fabric 之外的外部 SSP 通过你现有的公开域名，把竞价流量投递到 VPC 内的竞价服务器。文中给出 EC2 Auto Scaling 组与 Amazon EKS 两种后端的端到端实践，覆盖 IAM、ACM 证书、路由规则、流量模块与 DNS 迁移；迁移完全基于 DNS，合作伙伴无需改 URL 或代码。

01一、概述

02二、AWS RTB Fabric 基本架构

03三、前置条件

04四、步骤一：配置 IAM 权限

05五、步骤二：创建外部响应方网关

06六、步骤三：关联 TLS 证书（仅 HTTPS）

07七、步骤四：创建入站外部链路

08八、步骤五：配置路由规则

09九、步骤六：配置流量模块（可选但推荐）

10十、步骤七：更新 DNS 并验证

11十一、基于 DNS 的流量迁移与回滚

12十二、价格计算方式

13十三、关键配额与约束

14十四、总结

15十五、参考资料

一、概述

实时竞价（Real-Time Bidding，RTB）是程序化广告的核心。广告技术（AdTech）公司每秒要在发布商、供给侧平台（SSP）与需求侧平台（DSP）之间处理数百万个竞价请求，而且绝大多数竞价必须在 200–300 毫秒内完成。为了压低延迟，很多企业不得不在靠近合作伙伴的托管数据中心（Colocation）自建基础设施，这带来了高昂的成本、漫长的开通周期和沉重的运维负担。

AWS RTB Fabric 是一项专为 RTB 广告负载打造的全托管服务。它为 RTB 流量提供了一张专用的高性能私有网络，帮助 AdTech 公司无需自建托管机房、也无需预付承诺，就能与供给侧和需求侧合作伙伴无缝互联，获得稳定的个位数毫秒级延迟，同时相比标准网络最高可降低约 80% 的网络成本。

本文首先介绍 AWS RTB Fabric 的基本架构与核心概念，然后聚焦一个非常典型的落地场景——作为 DSP（响应方），如何让仍在 RTB Fabric 之外的外部 SSP 合作伙伴，通过你现有的公开域名，把竞价流量安全地投递到你 VPC 内的竞价服务器（bidder）。我们会给出基于 EC2 Auto Scaling 组（ASG）与 Amazon EKS 两种后端的端到端配置实践，并覆盖 IAM 权限、TLS 证书、路由规则、流量模块、DNS 迁移以及价格计算。

本文场景下，外部合作伙伴无需修改任何 URL，整个迁移完全基于 DNS 完成，供给侧和需求侧的应用都无需改动代码。

二、AWS RTB Fabric 基本架构

RTB Fabric 本身并不托管你的应用，而是作为连接各方应用的”网络织物（Fabric）“，让原本要走公网的 RTB（Real Time Bidding）通信改走私有、低延迟的网络。你始终完全掌控自己的应用、数据与竞价决策，RTB Fabric 只负责底层的安全、可靠连接。

下图展示了 AWS RTB Fabric 的高层架构（请求方与响应方都已接入 RTB Fabric 的”内部到内部”模式）：

[图 1：AWS RTB Fabric 高层架构——“内部到内部”模式（来源：AWS 官方文档）]

如图所示，请求方应用（Requester）连接到 RTB Fabric 的请求方网关（Requester gateway），请求经由链路（Link）转发到响应方网关（Responder gateway），再由响应方网关投递给响应方应用（Responder），响应沿原路返回。整条链路都运行在与客户 VPC 就近部署（colocated）的 AWS 托管网关之上。

需要注意的是，图 1 展示的是双方都已接入 RTB Fabric 的基础模式。实际业务中，合作伙伴（例如 SSP）可能尚未接入 RTB Fabric，甚至完全不在 AWS 上运行——RTB Fabric 通过外部链路（External Link）同样支持与这类外部伙伴互联（见下文”三种典型连接模式”），本文实战部分正是围绕”SSP 不在 AWS 上”这一场景展开。

2.1 核心组件

请求方 / 响应方 RTB 应用：由客户拥有并运营的 RTB 应用。请求方发起竞价请求（如 SSP、广告服务器、发布商），响应方接收并处理竞价请求（如 DSP）。应用始终运行在客户可控的环境中。
请求方网关 / 响应方网关（Gateway）：AWS 托管的网络端点，与客户 VPC 就近部署，作为进出 RTB Fabric 的连接点。网关只负责路由，不存储、不处理客户的业务逻辑与数据。
链路（Link）：RTB Fabric 内部由 AWS 托管的连接组件，在请求方网关与响应方网关之间建立安全的双向通信。链路由请求方网关创建，并需由响应方网关所属账户接受后才会生效。
模块（Module）：在链路上处理 RTB 流量的可配置组件，用于限流、过滤、错误处理等。RTB Fabric 内置了 Rate Limiter（限流）、OpenRTB Filter（OpenRTB 属性过滤）和 Error Masking（错误屏蔽）等模块，免费且内联执行，不引入应用级延迟。
日志（Logs）：链路可选生成的请求方/响应方日志，可投递到 Amazon CloudWatch Logs 或 Amazon S3。日志不会存储在 RTB Fabric 基础设施内。

2.2 三种典型连接模式

RTB Fabric 中”内部 / 外部”的划分标准是是否接入了 RTB Fabric，而不是是否在 AWS 上——合作伙伴即使跑在 AWS 上，只要没有接入 RTB Fabric，也按”外部”对待。三种模式各方所需的配置如下：

模式	说明	典型示例	各方所需配置
内部到内部	请求方与响应方都是 RTB Fabric 客户（见图 1）	SSP 与 DSP 都接入了 RTB Fabric	双方各自创建请求方网关 / 响应方网关；由请求方创建链路（Link），响应方接受后生效
外部到内部	请求方在 RTB Fabric 之外（可在 AWS 上或不在 AWS 上），响应方是 RTB Fabric 客户（见图 2）	不在 AWS 上的 SSP 连接使用 RTB Fabric 的 DSP	响应方创建外部响应方网关（External Responder Gateway），并配置入站外部链路（Inbound External Link）与路由规则；如需沿用现有公开域名，再关联 ACM 证书并配置自定义域名（Custom Domain）。外部请求方零配置，仅需把请求继续发往原域名（DNS CNAME 切换）
内部到外部	请求方是 RTB Fabric 客户，响应方在 RTB Fabric 之外（可在 AWS 上或不在 AWS 上）	使用 RTB Fabric 的 SSP 连接不在 AWS 上的 DSP	请求方在请求方网关上创建出站外部链路（Outbound External Link），填入外部响应方的公共 HTTP/HTTPS 端点 URL。外部响应方零配置，继续以现有公开端点接收请求

本文聚焦”外部到内部”模式：作为 DSP，你希望外部 SSP 继续向你现有的公开域名（如 bid.example.com）发送竞价请求，流量经 RTB Fabric 处理后投递到你 VPC 内的竞价服务器。为此，你需要创建外部响应方网关（External Responder Gateway），并配置入站外部链路（Inbound External Link）与自定义域名（Custom Domain）。下图展示了这一模式下的整体架构与请求路径：

[图 2：外部到内部模式——自定义域名入站链路架构]

2.3 入站请求的处理流程

配置完成后，一次外部竞价请求的处理路径如下：

外部 SSP 通过 HTTPS 把请求发送到你的自定义域名 bid.example.com；
该域名通过 CNAME 指向区域网关端点（externalInboundEndpoint）；
外部响应方网关完成 TLS 终止（使用你在 ACM 申请的证书 / SNI 匹配）；
网关按路由规则解析出目标链路（Link）；
请求依次经过模块流（如限流、OpenRTB 属性过滤）；
通过跨账户 ENI（私有网络）投递到你 VPC 内 ASG 或 EKS 上的竞价服务器。

整个链路保留原始的 host、path、查询串和请求体，合作伙伴完全无感知。

ASG 还是 EKS？竞价服务器跑在 EC2 Auto Scaling 组上就选 ASG；竞价服务器以 Pod 形式跑在 EKS 上就选 EKS。两者的链路 / 证书 / 路由规则 / 模块 / DNS 步骤完全相同，差异只在”IAM 角色授权方式”和创建网关时的 –managed-endpoint-configuration。

三、前置条件

在开始之前，请逐项确认：

开通外部入站链路功能：在 Service Quotas 控制台把 RTB Fabric 的”支持外部入站链路”配额设为 1（默认为否/0），该功能必须显式开通。
自定义域名与 DNS 控制权：你必须拥有对外的自定义域名（如 bid.example.com），并能创建/修改其 CNAME 记录。注意 CNAME 不能建在区域顶点（zone apex），需用子域或 Route 53 ALIAS。
ACM 证书（仅 HTTPS）：在与网关同一区域申请或导入证书，状态必须为 ISSUED，其 CN 或 SAN 覆盖自定义域名（精确或通配符），且 CN/SAN 使用小写字符（证书解析大小写敏感）。
VPC / 子网 / 安全组：子网需至少 200 个可用 IPv4 地址，建议与竞价服务器同可用区；为网关单独创建安全组，放行 SSP 到竞价服务器端口的入站流量。仅支持 IPv4。
后端竞价服务器：
1. ASG 方式：竞价服务器以 EC2 实例运行在一个或多个 ASG 中，且 ASG 必须仅在主机可接收流量时才将其标记为 IN_USE。
2. EKS 方式：竞价服务器以 Deployment 运行并由一个 Service 暴露（Service 会自动生成同名 Endpoints 资源供发现）。最关键的前提是：集群 API server 必须对网关 ENI 网络可达，强烈建议开启私网端点访问 endpointPrivateAccess=true（公网可同时保留）。
AWS CLI：版本要足够新，需包含 create-link-routing-rule、associate-certificate 等子命令（实测 awscli ≥ 1.45 / botocore ≥ 1.43）。

⚠️ EKS 常见的坑：集群只开公网 API 端点，而网关 ENI 位于路由指向 IGW 的公网子网却没有公网 IP——IGW 不会为无公网 IP 的 ENI 做 NAT，导致连不上 API server。此时网关仍可 ACTIVE，但永远发现不到 Pod IP，请求返回 503、指标 target-ip-count 为空。解决办法就是开启 endpointPrivateAccess=true，让网关 ENI 经 VPC 内部直连。

四、步骤一：配置 IAM 权限

权限分为三类：操作者权限、关联证书的 ACM 权限、以及供 RTB Fabric 代入的托管端点角色。

4.1 操作者权限

执行 RTB Fabric API 的身份至少需要网关与链路的管理权限（生产环境请按最小权限收敛）：

{
  "Version": "2012-10-17",
  "Statement": [
    { "Effect": "Allow", "Action": ["rtbfabric:*"], "Resource": "*" },
    {
      "Effect": "Allow",
      "Action": [
        "ec2:DescribeNetworkInterfaces", "ec2:DescribeSubnets",
        "ec2:DescribeSecurityGroups", "ec2:DescribeVpcs"
      ],
      "Resource": "*"
    },
    {
      "Effect": "Allow",
      "Action": ["cloudwatch:GetMetricStatistics", "cloudwatch:ListMetrics"],
      "Resource": "*",
      "Condition": { "StringEquals": { "cloudwatch:namespace": "rtbfabric" } }
    }
  ]
}

4.2 关联证书的 ACM 权限（仅 HTTPS）

调用 AssociateCertificate 时，RTB Fabric 通过前向访问会话（FAS）代表你调用 ACM。调用该 API 的身份必须额外具备针对该证书 ARN 的 acm:DescribeCertificate 与 acm:CreateCertificateRelation 权限。

4.3 托管端点角色

RTB Fabric 需要代入一个 IAM 角色来发现要发送流量的目标实例/Pod IP。信任策略需同时信任两个服务主体，并打上必需标签。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": ["rtbfabric.amazonaws.com", "rtbfabric-endpoints.amazonaws.com"]
      },
      "Action": "sts:AssumeRole"
    }
  ]
}
# 以 ASG 为例创建角色并打必需标签（缺此标签托管端点无法工作）
aws iam create-role --role-name RtbFabricRoleForAsgEndpoints \
  --assume-role-policy-document file://trust-policy.json
aws iam tag-role --role-name RtbFabricRoleForAsgEndpoints \
  --tags '[{"Key":"RTBFabricManagedEndpoint","Value":"true"}]'

ASG 方式：附加发现实例的只读权限（autoscaling:DescribeAutoScalingGroups、ec2:DescribeInstances、ec2:DescribeInstanceStatus、ec2:DescribeAvailabilityZones、ec2:DescribeSubnets）。
EKS 方式：附加 ec2:Describe* 网络发现权限；此外还需在集群里创建 Kubernetes RBAC（Role + RoleBinding，授予 endpoints/endpointslices 的 get,list,watch 权限——实测必须含 list/watch，仅 get 会发现失败），并用 access entry 把 IAM 角色映射到该 K8s 用户：

aws eks create-access-entry \
  --cluster-name my-eks-cluster \
  --principal-arn arn:aws:iam::123456789012:role/RtbFabricRoleForEksEndpoints \
  --username rtbfabric-integration \
  --type STANDARD --region us-east-1

实测要点：CLI 参数是 –username（不是旧文档里的 –kubernetes-user），其值必须与 RoleBinding 中 subjects[].name 完全一致。

此外，RTB Fabric 还会使用服务关联角色 AWSServiceRoleForRTBFabric 管理网络接口和发布 CloudWatch 指标，首次创建网关时自动创建，无需手动操作。

五、步骤二：创建外部响应方网关

准备好后端信息与上面创建的角色 ARN 后，即可创建网关。以下为 ASG + HTTPS 示例：

aws rtbfabric create-responder-gateway \
  --description "External gateway with ASG endpoint for custom-domain inbound" \
  --vpc-id vpc-0abc123def456 \
  --subnet-ids subnet-0abc123 subnet-0def456 \
  --security-group-ids sg-0abc123 \
  --port 8080 --protocol HTTP \
  --listener-config '{"protocols":["HTTP","HTTPS"]}' \
  --managed-endpoint-configuration '{
      "autoScalingGroups": {
        "autoScalingGroupNames": ["my-bidder-asg"],
        "roleArn": "arn:aws:iam::123456789012:role/RtbFabricRoleForAsgEndpoints"
      }
  }' \
  --gateway-type EXTERNAL \
  --endpoint-url https://rtbfabric.us-east-1.amazonaws.com \
  --region us-east-1

关键参数说明：

-gateway-type EXTERNAL：必填。只有外部网关才支持证书关联、路由规则和自定义域名入站外部链路。
-managed-endpoint-configuration：外部网关必填。ASG 用 autoScalingGroups；EKS 换成 eksEndpoints（需提供集群 API server URI、CA 证书链、集群名、Endpoints 资源名与命名空间、角色 ARN）。
-port / –protocol：这是网关到竞价服务器（后端）这条腿的端口与协议，请填竞价服务器实际监听的值。
-listener-config：这是合作伙伴到网关（入口）这条腿接受的协议，对外的 HTTPS/TLS 由后续 AssociateCertificate 关联的 ACM 证书处理。

ASG 端点可在线更新（update-responder-gateway），而 EKS 端点创建后不可就地更新，需变更只能重建网关。此外，主动健康检查仅 ASG 端点支持。

网关创建后状态处于 Activating/PENDING_CREATION，官方称约 2–5 分钟，实测可能需要约 10–15 分钟，请耐心轮询至 ACTIVE。务必记录两个值：网关 ID（如 rtb-gw-abc123def456）和外部入站端点 externalInboundEndpoint（更新 DNS 时使用）。

六、步骤三：关联 TLS 证书（仅 HTTPS）

aws rtbfabric associate-certificate \
  --gateway-id rtb-gw-abc123def456 \
  --acm-certificate-arn arn:aws:acm:us-east-1:123456789012:certificate/abcd1234-... \
  --client-token "$(uuidgen)" \
  --endpoint-url https://rtbfabric.us-east-1.amazonaws.com \
  --region us-east-1

证书必须 ISSUED、与网关同区域、CN/SAN 覆盖域名且为小写。
证书轮换由 RTB Fabric 自动处理，建议设置 CloudWatch 告警在到期前 ≥30 天提醒。
关联是异步且较慢：状态先为 PENDING_ASSOCIATION，实测约 10–15 分钟才变为 ASSOCIATED。此步骤可与创建链路、路由规则并行进行。

七、步骤四：创建入站外部链路

入站外部链路只能通过 API / CLI / CloudFormation 创建管理（控制台不支持），且只能用在外部响应方网关上。

aws rtbfabric create-inbound-external-link \
  --gateway-id rtb-gw-abc123def456 \
  --log-settings '{"applicationLogs":{"sampling":{"errorLog":100.0,"filterLog":0}}}' \
  --tags '{"Name":"DSP Inbound External Link"}' \
  --endpoint-url https://rtbfabric.us-east-1.amazonaws.com \
  --region us-east-1

响应会返回 linkId（如 link-xyz789），下一步配置路由规则时会用到。

八、步骤五：配置路由规则

路由规则把到达网关的请求映射到具体链路。规则跨所有链路按 priority 升序全局评估，值越小优先级越高，第一个全部条件匹配的规则获胜；无匹配则返回 HTTP 404。

aws rtbfabric create-link-routing-rule \
  --gateway-id rtb-gw-abc123def456 \
  --link-id link-xyz789 \
  --priority 1 \
  --conditions '{"hostHeader":"bid.example.com","pathPrefix":"/openrtb"}' \
  --client-token "$(uuidgen)" \
  --endpoint-url https://rtbfabric.us-east-1.amazonaws.com \
  --region us-east-1

单规则内多个条件是 AND 逻辑；要实现 OR 就建多条不同优先级的规则。支持的条件包括：hostHeader（精确）、hostHeaderWildcard（通配符）、pathPrefix（前缀，段边界感知）、pathExact（精确）、queryStringEquals 与 queryStringExists。

上线前建议用 /resolve-link 验证规则（不发真实流量）：

curl "https://<externalInboundEndpoint>/resolve-link?url=https%3A%2F%2Fbid.example.com%2Fopenrtb%2Fbid"
# 200 -> {"link_id":"link-xyz789","rule_id":"rule-..."}  命中
# 404 -> 无规则匹配

九、步骤六：配置流量模块（可选但推荐）

模块只能在 ACTIVE 的链路上配置。下例先限流 1000 TPS，再对 COPPA 标记且来自 USA/CAN 的请求直接 no-bid：

aws rtbfabric update-link-module-flow \
  --gateway-id rtb-gw-abc123def456 --link-id link-xyz789 \
  --client-token "$(uuidgen)" \
  --modules '[
    { "name": "rateLimiterModule", "version": "20251204105817",
      "dependsOn": [], "moduleParameters": { "rateLimiter": { "tps": 1000.0 } } },
    { "name": "openRtbAttributeModule", "version": "20251204105817",
      "dependsOn": ["rateLimiterModule"],
      "moduleParameters": { "openRtbAttribute": {
        "filterType": "INCLUDE",
        "filterConfiguration": [ { "criteria": [
          { "path": "$.regs.coppa", "values": ["1"] },
          { "path": "$.device.geo.country", "values": ["USA", "CAN"] }
        ] } ],
        "action": { "noBid": {} }, "holdbackPercentage": 0.0
      } } }
  ]' \
  --region us-east-1

两个易错的格式点（实测）：模块 version 必须匹配 ^[a-z0-9]+$（只能小写字母和数字，不能含连字符或点）；OpenRTB 过滤条件用字段名 path（JSON 路径），不是 key。

十、步骤七：更新 DNS 并验证

警告：创建/切换 CNAME 会立即把实时流量导向 RTB Fabric。务必先完成证书关联、路由规则、链路并用 /resolve-link 验证通过。

在 DNS 提供商创建 CNAME：bid.example.com → 步骤二记录的 externalInboundEndpoint，初期 TTL 设 60 秒。

强烈推荐在不改真实 DNS 的情况下，用 curl –resolve 临时把域名指向网关 IP，完整验证”TLS 证书 + 路由 + 投递到竞价服务器”这条链路：

EP=<你的 externalInboundEndpoint>
IP=$(dig +short $EP | head -1)
# 查看 SNI 下网关回示的证书（应为你的自定义域名证书）
echo | openssl s_client -connect ${IP}:443 -servername bid.example.com 2>/dev/null | openssl x509 -noout -subject
# 用自定义域名发 HTTPS 竞价请求（不改 DNS）
curl -v --resolve bid.example.com:443:$IP https://bid.example.com/openrtb/bid \
  -H "Content-Type: application/json" -d '{"id":"t1","imp":[{"id":"1"}]}'

链路打通时：TLS 握手会呈现你为自定义域名关联的客户证书；请求返回 2xx（竞价服务器的响应）；响应头含 x-amz-response-source: Responder 与正确的 x-amz-rtb-link-id。看到这些即说明全链路正常。

十一、基于 DNS 的流量迁移与回滚

迁移完全基于 DNS，推荐用 Amazon Route 53 加权路由灰度：

阶段	旧端点权重	RTB Fabric 权重	大约切流
初始	90	10	10%
阶段 2	50	50	50%
阶段 3	20	80	80%
完全切换	0	100	100%

迁移前把旧 CNAME 的 TTL 提前 ≥24 小时降到 60–120 秒，并记录当前 CNAME 目标以便回滚。回滚只需把 RTB Fabric 权重设 0、旧端点设 100，无需改动网关、路由规则、证书或应用。

十二、价格计算方式

RTB Fabric 按你发送的交易数计费（接收不计费），价格随月交易量、单笔大小、no-bid 数量、区域，以及流量是”内部”还是”外部”而变化。本文的外部入站场景按 “External to AWS RTB Fabric” 费率计费。以 us-east-1 为例，计费分三个维度：

维度	Inside	External（外部入站适用）
交易条数（前 2 万亿笔/月）	$4.50 /十亿	$34.00 /十亿
交易条数（超过 2 万亿笔/月）	$1.50 /十亿	$10.00 /十亿
超额负载（前 2T，每笔免费 2 KiB）	$0.0015 /GiB	$0.011 /GiB
超额负载（超过 2T）	$0.00046 /GiB	$0.0033 /GiB
No-bid（无竞价响应）	$0.50 /十亿	$3.00 /十亿

计算示例（外部入站，us-east-1）：假设本月发送出价响应 3 万亿条（平均 3048 字节）+ no-bid 响应 2 万亿条。

出价响应交易费：2000 × $34.00 + 1000 × $10.00 = $78,000
超额负载费（每条超出 1000 字节）：约 $20,489 + $3,073 ≈ $23,562
No-bid 费：2000 × $3.00 = $6,000
合计 ≈ $107,562 / 月

对比：同样流量若双方都在 RTB Fabric 内部（Inside），出价交易费仅 $10,500、no-bid 仅 $1,000。这正是为什么尽量让合作伙伴也接入 Fabric（走 Inside 费率）能显著省钱。亚太（新加坡/东京）的 External 费率更高，实际费用请以 AWS Pricing Calculator 或账单为准。

十三、关键配额与约束

项	默认值
网关数量（账户）	2
每网关 link 数	2
每流模块数	2
每网关可用区数	1
支持外部入站链路	否（需设为 1）
每 link TPS	1,000
HTTP 请求超时	1.5 秒

不支持：路径正则、每规则多个查询条件、兜底默认规则、HTTP/2 上行、mTLS、WebSocket、响应头注入、请求/响应体改写。资源按区域、按客户独立，多区域需分别独立迁移。

十四、总结

本文介绍了 AWS RTB Fabric 的基本架构与核心概念，并以”外部到内部”这一典型场景为主线，完整演示了如何为外部 SSP 合作伙伴构建基于自定义域名的入站链路——从 IAM 权限、创建外部响应方网关（ASG / EKS 两种后端）、关联 TLS 证书、创建入站外部链路、配置路由规则与流量模块，到最终基于 DNS 的灰度迁移与回滚。

借助 AWS RTB Fabric，AdTech 公司无需自建托管机房，就能获得稳定的个位数毫秒级延迟与更低的网络成本，同时让外部合作伙伴在完全无感知（无需改 URL）的前提下平滑接入。如果你正在为 RTB 负载的延迟、成本与合作伙伴接入效率而困扰，不妨从一条入站外部链路开始体验。

➡️ 下一步行动：

相关产品：

Amazon EKS — 托管式 Kubernetes 服务
Amazon IAM — 身份管理和访问权限
Amazon VPC — 隔离云网络
Amazon EC2 — 安全且可调整大小的计算容量
Amazon CloudWatch — 可观测性工具

相关文章：

十五、参考资料

立即咨询 → 从 AI 规划到落地实施，我们的专家团队为你全程护航。

*前述特定亚马逊云科技生成式人工智能相关的服务目前在亚马逊云科技海外区域可用。亚马逊云科技中国区域相关云服务由西云数据和光环新网运营，具体信息以中国区域官网为准。

本篇作者

AWS 架构师中心：云端创新的引领者

探索 AWS 架构师中心，获取经实战验证的最佳实践与架构指南，助您高效构建安全、可靠的云上应用

亚马逊AWS官方博客