1. 问题现象与背景分析

上周在客户生产环境遇到一个典型的AWS网络问题：通过EC2实例向S3上传文件时，原本应该毫秒级完成的请求却频繁出现5-10秒的延迟。作为负责该客户架构优化的解决方案架构师，我立即展开了排查。这个案例非常具有代表性，涉及AWS网络架构中VPC Endpoint这个关键组件的正确配置。

关键现象提示：当S3操作出现异常延迟时，VPC Endpoint路由缺失是需要优先排查的方向之一

客户环境采用标准的Hub-Spoke网络架构，所有子网都通过Transit Gateway互联。应用部署在Spoke VPC的私有子网中，按照安全最佳实践，这些子网没有配置NAT网关，理论上所有S3流量都应该通过VPC Endpoint走AWS私有网络。但实际监控数据显示，约30%的PUT请求存在明显延迟。

2. 核心排查流程与工具

2.1 网络路径验证

首先通过traceroute工具确认实际网络路径：

# 在问题EC2上执行 traceroute s3.us-east-1.amazonaws.com

结果显示部分请求确实绕道公网（经过NAT网关），这与架构设计不符。正常情况下的路由应该显示为：

1 ip-10-2-1.ec2.internal (10.2.1.1) 2 * * * 3 s3.us-east-1.amazonaws.com (52.216.0.0/15)

2.2 VPC Endpoint配置检查

检查VPC Endpoint的配置细节：

1. 确认Endpoint类型为"Interface"（Gateway类型已弃用）
2. 验证Security Group放行了443端口
3. 检查路由表关联情况：

aws ec2 describe-route-tables \ --filters "Name=route.vpc-endpoint-id,Values=vpce-123456"

发现关键问题：Spoke VPC的私有子网路由表中，缺少指向S3的pl-xxxxxx（AWS服务前缀列表）的路由条目。这意味着部分请求会"漏网"到默认路由。

3. 问题根因与解决方案

3.1 路由缺失的根本原因

经过与客户团队沟通，发现他们在最近一次网络重构时：

1. 新建了一组子网用于部署新应用
2. 这些子网的路由表是从旧子网复制的
3. 但复制时漏掉了对pl-xxxxxx的路由配置

这导致新子网的EC2实例访问S3时：

• 约70%请求命中Endpoint（通过服务发现）
• 30%请求因路由缺失走默认路由，触发NAT网关

3.2 完整修复方案

实施以下修复步骤：

1. 获取S3服务的Prefix List ID：

aws ec2 describe-managed-prefix-lists \ --filters "Name=prefix-list-name,Values=com.amazonaws.us-east-1.s3"

2. 更新所有问题子网的路由表：

aws ec2 create-route \ --route-table-id rtb-123456 \ --destination-prefix-list-id pl-xxxxxx \ --vpc-endpoint-id vpce-123456

3. 验证路由生效：

aws ec2 describe-route-tables \ --route-table-ids rtb-123456

4. 深度优化建议

4.1 监控与告警配置

建议增加以下CloudWatch监控项：

4.2 架构加固措施

1. 使用Terraform模块化管理路由配置：

module "vpc_endpoint_routes" { source = "terraform-aws-modules/vpc/aws//modules/vpc-endpoints" endpoints = { s3 = { service = "s3" route_table_ids = [module.vpc.private_route_table_ids] } } }

2. 实施配置漂移检测：

aws configservice put-config-rule \ --config-rule file://vpc-endpoint-rule.json

5. 典型误区和排查技巧

5.1 常见配置错误

1. 安全组方向错误：

   • 错误配置：仅允许出站（Egress）
   • 正确做法：Interface类型Endpoint需要配置入站（Ingress）规则

2. 路由目标混淆：

   • 错误示例：将pl-xxxxxx路由指向Internet Gateway
   • 正确示例：必须指向VPC Endpoint ID

5.2 高级排查工具

1. 使用VPC Flow Logs分析实际流量路径：

fields @timestamp, srcAddr, dstAddr, action | filter dstAddr like /s3/ | stats count() by bin(1m) as minute, action

2. 通过X-Ray跟踪请求链路：

from aws_xray_sdk.core import xray_recorder @xray_recorder.capture('s3_upload') def upload_to_s3(bucket, key): s3 = boto3.client('s3') s3.put_object(Bucket=bucket, Key=key, Body=data)

6. 性能对比测试

修复前后使用s3-benchmark工具测试结果：

这个案例给我的深刻教训是：在AWS混合网络环境中，任何路由表的变更都必须进行双重验证。我们后来在变更管理流程中增加了"路由矩阵检查"环节，要求任何新子网创建都必须核对7类核心路由（VPC内、TGW、S3等）。