在 AWS 上部署 Eclipse Dataspace Components（EDC）连接器时，困难往往不是让服务成功启动，而是回答三个持续影响预算的问题：需要多大的基础设施、不同环境应该如何配置，以及业务增长后成本会怎样变化。缺少可复用的基准数据时，团队很容易按生产峰值配置所有环境，或者只关注计算实例价格，忽略网络、存储、日志和数据库等费用。
成本优化不应从简单地缩小实例开始。更可靠的方法是先建立可归因的成本基线，再通过负载测试找到资源需求与业务指标之间的关系，最后针对开发、测试和生产环境采用不同的容量策略。
先把 EDC 成本拆成可测量的部分
EDC 连接器的实际部署形态会因架构而异，但在 AWS 账单中，成本通常会落在几类基础设施上：
- 运行连接器工作负载的计算资源，例如容器或虚拟机。
- 保存配置、状态或业务数据的数据库和存储资源。
- 跨可用区、跨区域或经由公网传输数据产生的网络费用。
- 负载均衡、NAT、日志、指标和追踪等平台服务。
- 为高可用、备份和灾难恢复保留的冗余容量。
这类拆分很重要，因为计算资源利用率偏低，并不代表整个部署都存在同样的优化空间。例如，数据传输增长可能不会明显增加连接器的 CPU 使用率，却会推高网络、日志和数据处理费用。
建议为成本模型定义一组业务单位，而不是只记录每月总账单：
- 每个运行环境每天的固定成本。
- 每 1,000 次 API 请求的增量成本。
- 每 GB 数据传输的基础设施成本。
- 每个并发传输任务所需的 CPU 和内存。
- 满足可用性目标所需的最低副本数。
这些指标可以把容量决策转化为可验证的问题。例如，与其询问是否应该增加节点，不如检查当前副本在目标并发量下是否超过 CPU、内存或延迟阈值。
用标签和 Cost Explorer 建立成本基线
可以这样实践：为 EDC 相关资源统一添加 Application、Environment 和 Component 标签，并在 AWS Billing 控制台中将它们激活为成本分配标签。标签激活前产生的费用通常不能自动获得同样的归因效果，因此应在基准测试开始前完成配置。
下面的命令查询指定月份内、带有 Application=edc 标签的每日非混合成本。运行前需要配置 AWS CLI、允许调用 Cost Explorer，并修改日期和标签值：
export START_DATE=2025-01-01
export END_DATE=2025-02-01
export APPLICATION_TAG=edc
aws ce get-cost-and-usage \
--time-period Start="$START_DATE",End="$END_DATE" \
--granularity DAILY \
--metrics UnblendedCost UsageQuantity \
--filter "{\"Tags\":{\"Key\":\"Application\",\"Values\":[\"$APPLICATION_TAG\"]}}" \
--group-by Type=DIMENSION,Key=SERVICE \
--output json
查询结果按 AWS 服务分组，可以帮助团队判断主要费用来自计算、数据库、网络还是可观测性服务。若标签尚未激活，也可以暂时按账户、区域或服务查询，但这种方式难以区分共享账户中的不同应用。
还应给环境设置预算告警。下面的示例创建一个每月 500 美元的成本预算，并在预测支出达到预算的 80% 时发送通知。请修改账户 ID、邮箱和预算金额：
export AWS_ACCOUNT_ID=123456789012
export ALERT_EMAIL=platform-team@example.com
aws budgets create-budget \
--account-id "$AWS_ACCOUNT_ID" \
--budget '{
"BudgetName": "edc-monthly-cost",
"BudgetLimit": {"Amount": "500", "Unit": "USD"},
"TimeUnit": "MONTHLY",
"BudgetType": "COST",
"CostFilters": {
"TagKeyValue": ["user:Application$edc"]
}
}' \
--notifications-with-subscribers "[
{
\"Notification\": {
\"NotificationType\": \"FORECASTED\",
\"ComparisonOperator\": \"GREATER_THAN\",
\"Threshold\": 80,
\"ThresholdType\": \"PERCENTAGE\"
},
\"Subscribers\": [
{
\"SubscriptionType\": \"EMAIL\",
\"Address\": \"$ALERT_EMAIL\"
}
]
}
]"
预算告警不是硬性限额，不会自动停止服务。它适合发现趋势偏移；是否缩容、暂停环境或限制流量，仍应由明确的运维策略决定。
用负载测试决定容量，而不是凭实例规格猜测
一个有意义的基准测试至少要记录请求速率、并发量、数据大小、响应时间、错误率、CPU、内存和网络吞吐。测试数据也应区分空闲成本与负载增加后的边际成本。
可以按以下顺序执行基准测试：
- 在没有业务流量时运行足够长的观测窗口，记录环境的固定成本和后台资源占用。
- 逐级增加请求速率或并发传输数，每一级保持稳定时间。
- 找到延迟或错误率明显恶化前的容量区间。
- 只调整一个变量，例如副本数、CPU 请求量或数据库规格，然后重复测试。
- 将测试窗口对应到 Cost Explorer 数据，计算单位工作负载成本。
如果 EDC 运行在 Kubernetes 上，可以从保守的资源请求开始，再依据指标调整。下面是一个可改造的 Deployment 片段；镜像地址、端口、健康检查路径和环境变量必须替换成项目的实际配置：
apiVersion: apps/v1
kind: Deployment
metadata:
name: edc-connector
labels:
app.kubernetes.io/name: edc-connector
spec:
replicas: 2
selector:
matchLabels:
app.kubernetes.io/name: edc-connector
template:
metadata:
labels:
app.kubernetes.io/name: edc-connector
spec:
containers:
- name: connector
image: 123456789012.dkr.ecr.us-east-1.amazonaws.com/edc-connector:1.0.0
ports:
- name: http
containerPort: 8181
resources:
requests:
cpu: 250m
memory: 512Mi
limits:
cpu: "1"
memory: 1Gi
readinessProbe:
httpGet:
path: /api/check/readiness
port: http
initialDelaySeconds: 20
periodSeconds: 10
这里的数值只是基准测试起点，不是适用于所有 EDC 部署的推荐规格。CPU 限制可能造成节流，内存限制过低则可能触发容器重启；生产配置必须由真实工作负载和稳定性目标验证。
不同环境采用不同的优化策略
开发和集成环境通常更适合优化固定成本。可以在非工作时间缩容、减少副本、缩短日志保留期，并避免为偶发测试长期保留高规格数据库。自动暂停前要确认环境没有正在运行的数据传输任务或共享依赖。
生产环境应优先优化单位工作负载成本，而不是追求最低账单。常见决策包括：
- 根据 CPU、内存和业务队列指标扩缩容，但保留满足可用性目标的最低副本。
- 对稳定的基础负载评估长期用量承诺，对突发容量保留弹性资源。
- 检查跨可用区和跨区域的数据路径，避免不必要的数据往返。
- 控制调试日志和高基数指标，防止可观测性费用随流量失控。
- 定期清理测试快照、未挂载存储、旧负载均衡器和闲置公网地址。
需要注意，过度缩容会把基础设施费用转化为延迟、失败重试和运维成本。网络路径优化也不能以破坏隔离、合规或高可用要求为代价。
落地检查清单
开始长期投入前，可以用下面的清单审查 EDC 部署：
- 所有专用资源都能通过标签归属到应用、环境和组件。
- 成本报告同时展示固定成本、增量成本和单位工作负载成本。
- 基准测试覆盖空闲、常规流量和峰值流量。
- 开发、测试和生产环境没有共用同一套容量假设。
- 预算告警有明确负责人，也有告警后的处理步骤。
- 网络、日志、数据库和备份费用已纳入模型，而不只是计算价格。
- 每次 EDC 版本、部署架构或流量模式发生变化后都会重新测量。
成本优化是一套持续校准机制。先让费用可见，再用负载数据调整容量，最后才考虑购买承诺或重构架构，能减少因为错误基线而形成的长期投入。