当 Amazon WorkSpaces 使用 VPC Endpoint 时的可用性与延迟监控方案

一、背景

当配置了 WorkSpaces 的内网 VPC Endpoint 时，使用 ping 命令探测 Endpoint 域名，能解析出 IP，但是并不能 ping 通。这是正常现象。AWS 官方明确说明：Interface VPC Endpoint 不响应 ICMP Ping 请求。因此，虽然在 Endpoint 使用的安全组上放行了 ICMP，ping <endpoint-ip> 仍然会超时；继续使用 ping 监控该 Endpoint 没有诊断价值，可以移除入站规则中的 ICMP 放行规则，同时来源应限制为客户侧客户端的私网 CIDR，避免使用 0.0.0.0/0。

WorkSpaces Streaming VPC Endpoint 应主要探测实际业务协议：

• TCP 443
• UDP 443
• TCP 4195
• UDP 4195

对于这一需求，有两种探测方式：

以上两个可组合使用。

二、从客户端一侧网络中的 Linux 环境使用脚本主动探测 Endpoint

注意：本方式的探针必须部署在与 WorkSpaces 客户端使用相同网络路径的位置，例如：

1、探测整个 Endpoint（自动解析为多个 IP）

首先获取 Endpoint 地址：

以 Linux 或 macOS 为例，先把 Endpoint 的地址代入环境变量。

export ENDPOINT="<your-workspaces-streaming-endpoint-dns-name>"

执行如下命令发起探测：

dig +short A "${ENDPOINT}"

nc -vz -w 3 "${ENDPOINT}" 443
nc -vz -w 3 "${ENDPOINT}" 4195

curl -sS -o /dev/null \
  --connect-timeout 3 \
  -w 'dns=%{time_namelookup}s tcp=%{time_connect}s tls=%{time_appconnect}s total=%{time_total}s\n' \
  "https://${ENDPOINT}/"

这些测试分别反映：

• dig：私有 DNS 是否正常解析；
• nc 443：HTTPS 端口是否可以建立 TCP 连接；
• nc 4195：Streaming TCP 端口是否可以建立连接；
• curl：DNS、TCP、TLS 握手以及整体响应耗时。

返回结果如下：

Connection to vpce-037631517224e2347-zagd6c2w.prod.highlander.eu-central-1.vpce.amazonaws.com (172.31.131.255) 443 port [tcp/https] succeeded!
Connection to vpce-037631517224e2347-zagd6c2w.prod.highlander.eu-central-1.vpce.amazonaws.com (172.31.131.255) 4195 port [tcp/*] succeeded!
dns=0.001127s tcp=0.241187s tls=0.483086s total=0.719997s

在以上数据中，TLS 首次建立连接时耗时较长；建立连接后，实际用户体验主要由 TCP 连接建立时间决定。本例中的结果是 tcp=0.241187s，即 241 ms。

注意：nc -u 不能用于可靠测试 UDP 协议。因为 UDP 没有 TCP 三次握手，某些 nc -u 测试即使没有收到服务端响应也会显示成功。UDP 4195 的真实可用性，应结合 WorkSpaces 客户端网络状态和真实会话指标判断。

2、探测单个 AZ 内的 Endpoint ENI（可选）

创建 Endpoint 时，会在多个可用区分别创建 Endpoint ENI，查询时 DNS 会返回多个 A 记录。由于 AZ 之间的延迟在 1 ms 左右，因此其实不用分别探测 3 个 AZ，只探测整个 Endpoint 域名即可。如果要探测特定 AZ 的延迟，那么可以按如下办法查询 Endpoint 域名，获得全部地址：

dig +short A "${ENDPOINT}"

针对特定地址分别编写探测脚本。

3、监控结果上报

建议将上述脚本输出的探测结果每隔 30 秒或 60 秒上报到监控平台：

• DnsResolveSuccess
• ResolvedIpCount
• Tcp443Success
• Tcp4195Success
• Tcp443ConnectTime
• Tcp4195ConnectTime
• TlsHandshakeTime
• ProbeTotalTime

三、使用 WorkSpaces 自带监控指标观察使用情况

1、指标含义

在 AWS/WorkSpaces CloudWatch namespace 中，重点监控：

连接过程的启动和关闭相关：

桌面健康相关：

网络连接质量相关：

画面流式传输质量：

网络延迟的阈值，针对桌面协议是 WSP（DCV）的桌面，通常低于 250 毫秒体验较好，250～400 毫秒之间可以连接但性能会下降。

详细说明见 WorkSpaces FAQ 和 WorkSpaces CloudWatch metrics。

2、查看指标方法

首先登录到 AWS 控制台，切换到特定区域，进入本区域的 CloudWatch 服务。点击左侧的 Metrics，在右侧服务清单中，选择 WorkSpaces。如下截图。

在浏览指标 Browse 标签页，找到第一项，点击进入。如下截图。

在列出的指标中，输入过滤条件 InSessionLatency，然后选择当前有效的桌面，即可看到指标。如下截图。

在以上截图中，可看到这个桌面在其活跃期，其延迟最低是 355 ms，最高是 369 ms。该指标的最小统计粒度为 1 分钟，无法获取低于 1 分钟粒度的数据。粒度可以在 Graphed metrics 标签页中调整。

3、典型场景排查

场景：客户端使用时遇到断线，提示 Network Connection is unstable，过一段时间又能恢复。如何查看监控数据确认是桌面后台故障，还是中间的网络通道抖动？

(1) 客户端接入网络导致问题的一些征兆

同时满足以下大部分特征时，优先调查客户端网络：

• 故障期间 Unhealthy=0
• WorkSpace 的 CPU、内存和磁盘没有异常
• InSessionLatency 在中断前明显上升
• UDPPacketLossRate 或 TCPRetransmissionRate 同时上升
• CongestionWindow 明显下降
• FramesPerSecond 和有效带宽随之下降
• 只有同一办公地点、同一 VPN、同一网络出口或同一 Direct Connect 路径下的用户受到影响

在连接协议方面，通常优先使用 UDP。TCP-only 可作为诊断手段：如果 UDP 模式频繁中断，而 TCP-only 明显稳定，应重点检查 UDP 被限速、丢弃、超时回收或错误代理的问题，但 TCP-only 不一定是最终优化方案。

(2) WorkSpaces 后台出现问题的一些征兆

• 只有一个 WorkspaceId 频繁断线
• 用户从不同客户端、不同网络连接同一 WorkSpace，仍然发生中断
• Unhealthy 在故障期间变为 1
• CPUUsage、MemoryUsage、磁盘使用率或磁盘队列出现异常，检查是否存在高 CPU、内存耗尽或磁盘阻塞
• UpTime 在故障后重新开始，表明发生过重启
• 同目录、同区域的其他 WorkSpaces 正常

四、建议的初始告警条件

为了避免瞬态抖动产生大量误报，建议使用连续数据点告警，例如 5 个周期中至少 3 个周期越界，而不是单数据点立即告警。

1、客户端一侧网络监控告警建议

由于是客户自建的探针，因此需要自行配置告警。

2、AWS WorkSpaces CloudWatch 内置指标的告警建议

以上监控在 CloudWatch 上可以配置。以下步骤以法兰克福区域 eu-central-1 为例；告警、指标和 Amazon Simple Notification Service（Amazon SNS）主题必须处于同一区域。

注意：以下告警只发送 SNS 通知，不配置停止、重启、恢复或 Auto Scaling 等资源动作。ConnectionFailure、ConnectionAttempt 和 InSessionLatency 仅在用户通过 WorkSpaces 客户端完成身份验证并发起会话连接后才会产生数据。因此，某个时段没有用户会话不能被视为桌面或 VPC Endpoint 故障。

(1) ConnectionFailure 告警配置步骤

本告警使用 CloudWatch Metric Math（指标数学表达式）计算目录级别的连接失败率。对同一 DirectoryId 同时选择 ConnectionFailure 和 ConnectionAttempt，避免将不同目录的数据混合计算。建议先创建一个告警状态为 ALARM 时向运维人员通知的 SNS 主题；后续两个告警复用该主题。

1. 登录 AWS 管理控制台，切换到 Europe (Frankfurt) 区域，依次进入 Amazon SNS、Topics、Create topic。类型选择 Standard，名称填写 workspaces-monitoring-alerts，创建后在主题的 Subscriptions 中添加通知订阅，例如企业邮箱或内部告警入口，并完成订阅确认。记录该主题，后续在 CloudWatch 告警的 Notification 页面选择它。
2. 进入 CloudWatch、Metrics、All metrics、WorkSpaces，选择包含 DirectoryId 的指标维度组合。搜索并同时勾选 ConnectionFailure 和 ConnectionAttempt，且两行均筛选为同一个目录 <directory-id>。如需对单个桌面告警，应改为同时选择包含相同 WorkspaceId 的两个指标。
3. 打开 Graphed metrics 标签页，将两个原始指标的 Statistic 设置为 Sum，Period 设置为 1 minute。选择 Add math、Start with empty expression，输入以下表达式；其中 m1 是 ConnectionFailure，m2 是 ConnectionAttempt。将表达式标签修改为 ConnectionFailureRate，并取消勾选两个原始指标，仅保留表达式用于创建告警。

IF(m2 > 0, 100 * m1 / m2, 0)

4. 在表达式所在行的 Actions 列选择告警图标。Threshold type 选择 Static，Whenever ConnectionFailureRate is... 选择 Greater。配置 Warning 告警时，阈值填写 5；配置 Critical 告警时，阈值填写 10。
5. 展开 Additional configuration，将 Datapoints to alarm 设置为 3 out of 5，即五个 1 分钟周期中至少三个周期超过阈值才进入 ALARM。Missing data treatment 选择 Treat missing data as not breaching，避免没有用户发起会话时误报连接失败。
6. 选择 Next。在 Notification 中，选择 In alarm，并选择步骤 1 创建的 workspaces-monitoring-alerts SNS 主题。可按需增加 OK 状态通知，用于告警恢复确认。
7. 选择 Next，分别创建两个告警：WorkSpaces-<directory-id>-ConnectionFailureRate-Warning 和 WorkSpaces-<directory-id>-ConnectionFailureRate-Critical。在 Preview and create 页确认表达式、目录维度、阈值和 SNS 主题均正确后，选择 Create alarm。

注意：失败率指标反映用户完成身份验证之后的会话连接结果，不能替代第二章中从客户网络到 VPC Endpoint 的 TCP/TLS 连通性探测。若 ConnectionAttempt 长时间为零，应结合业务在线人数和客户端探针判断是否存在访问链路问题。

(2) Unhealthy 告警配置步骤

Unhealthy 表示不健康的 WorkSpaces 数量。目录级告警适合发现任意桌面不健康；如需定位到单台桌面，可为每个 WorkspaceId 创建同样的告警。由于该指标是数量而不是比率，使用 Maximum 统计值和 Greater than or equal to 1 条件。

1. 进入 CloudWatch、Metrics、All metrics、WorkSpaces，选择包含 DirectoryId 的指标维度组合，搜索并勾选 Unhealthy，再选择目标目录 <directory-id>。若目标是单个桌面，则选择同时包含该桌面 WorkspaceId 的指标。
2. 在 Graphed metrics 中，将 Statistic 设置为 Maximum，Period 设置为 1 minute，然后在该行的 Actions 列选择告警图标。
3. 在 Conditions 中选择 Static，将比较条件配置为 Greater/Equal，阈值填写 1。这表示周期内检测到至少一个不健康的 WorkSpace 时，该数据点越界。
4. 展开 Additional configuration。Warning 告警设置为 1 out of 1，用于立即发现单个异常；Critical 告警设置为 2 out of 2，用于确认异常已持续两分钟。Missing data treatment 选择 Treat missing data as missing，使完全没有健康状态数据时进入 INSUFFICIENT_DATA，而不是将数据缺失解释为健康或不健康。
5. 选择 Next，在 Notification 中为 In alarm 选择 workspaces-monitoring-alerts SNS 主题。建议同时增加 In insufficient data 通知，以便监测指标采集异常；该通知应由值班人员核实，不应直接执行桌面重建等破坏性操作。
6. 选择 Next，分别命名为 WorkSpaces-<directory-id>-Unhealthy-Warning 和 WorkSpaces-<directory-id>-Unhealthy-Critical。在预览页面核对指标范围、Maximum、阈值和数据缺失策略，然后选择 Create alarm。

(3) InSessionLatency 告警配置步骤

InSessionLatency 的单位为毫秒，表示 WorkSpaces 客户端与 WorkSpace 之间的往返时延（Round-Trip Time，RTT）。为避免少数桌面或用户问题被目录平均值掩盖，本告警应优先按 WorkspaceId 创建；仅需要判断整体服务趋势时，才使用 DirectoryId 维度。

1. 进入 CloudWatch、Metrics、All metrics、WorkSpaces，选择包含 WorkspaceId 的指标维度组合，搜索并勾选 InSessionLatency，选择目标桌面 <workspace-id>。确认所选时间序列的 Protocol 维度与实际桌面协议一致；DCV 桌面使用 Protocol=DCV。
2. 在 Graphed metrics 中，将 Statistic 设置为 Average，Period 设置为 1 minute，然后在该行的 Actions 列选择告警图标。选择平均值能够反映持续的交互体验；如需识别短暂尖峰，可额外建立 Maximum 统计值的诊断告警。
3. 在 Conditions 中选择 Static，选择 Greater。创建 Warning 告警时，阈值填写 250；创建 Critical 告警时，阈值填写 400。这两个数值的单位均为毫秒，应根据客户网络基线、桌面协议和实际业务容忍度在试运行阶段复核。
4. 展开 Additional configuration，将 Datapoints to alarm 设置为 3 out of 5，将 Missing data treatment 设置为 Treat missing data as not breaching。该设置避免用户退出会话后，因 InSessionLatency 不再产生数据而引发虚假告警。
5. 选择 Next，在 Notification 中为 In alarm 选择 workspaces-monitoring-alerts SNS 主题；选择 Next 后，分别将告警命名为 WorkSpaces-<workspace-id>-InSessionLatency-Warning 和 WorkSpaces-<workspace-id>-InSessionLatency-Critical。
6. 在 Preview and create 页面确认区域、WorkspaceId、协议、统计值、阈值和通知目标。选择 Create alarm 后，可在 Alarms、All alarms 中查看状态。建议先在有实际用户会话的测试 WorkSpace 上验证一小时，确认指标持续产生、SNS 订阅可收信且阈值符合实际体验后，再批量应用到生产桌面。

五、参考文档

AWS Interface Endpoint 不响应 ICMP Ping 的说明：

https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html

WorkSpaces Streaming VPC Endpoint 端口与安全组配置：

https://docs.aws.amazon.com/workspaces/latest/adminguide/creating-streaming-vpc-endpoints.html

WorkSpaces CloudWatch 指标、维度和统计值：

https://docs.aws.amazon.com/workspaces/latest/adminguide/cloudwatch-metrics.html

从指标图表创建 CloudWatch 告警：

https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/create_alarm_metric_graph.html

CloudWatch 告警的数据缺失处理：

https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/alarms-and-missing-data.html

最后修改于 2026-08-21